cp15 infrastructure rework

Registered by Peter Maydell on 2011-05-26

At the moment QEMU handles cp15 accesses by calling out to a single helper function which is an enormous set of nested switch statements to handle the different coprocessor registers. Access permissions are checked separately at translate time. This design makes specifying board-dependent or cpu-dependent registers somewhat painful; it's also easy for the access permission checks to be out of sync. There is no support for banked cp15 registers either (needed for trustzone and virtualisation). We need a better design which lets a board or core register handler routines for cp15 registers. This will make the code cleaner and more maintainable as a base for new features.

Note that this is purely a refactoring, with no user-visible consequences. Acceptance criteria are therefore simply getting the patches upstream.

Blueprint information

Status:
Complete
Approver:
Michael Hope
Priority:
High
Drafter:
Peter Maydell
Direction:
Approved
Assignee:
Peter Maydell
Definition:
Approved
Series goal:
Accepted for trunk
Implementation:
Implemented
Milestone target:
None
Started by
Peter Maydell on 2011-12-15
Completed by
Peter Maydell on 2012-06-24

Related branches

Sprints

Whiteboard

Meta:
Headline: n/a, this is an internal engineering milestone
Acceptance: refactoring patches accepted upstream

[michaelh1 2012-01-24] Deleted the roadmap link. Bump to the next KVM related card as we chose to do the system model first and didn't intend to finish this by Connect.

[michaelh1 2012-06-25] Marked as 'beta available' as posted upstream

[pmaydell 2012-06-25] Patches now in upstream master: blueprint complete

(?)

Work Items

Work items:
confirm requirements (usual number of cp15 regs, different banking arrangements, access permissions, 64 bit regs): DONE
write up sketch of proposed design: DONE
implement core design: DONE
convert existing cores to new system: DONE
testing and bugfixing: DONE
clean up and submit patches upstream: DONE
handle any issues raised in code review: DONE

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.