[Xen-devel] [PATCH 00/19] xen: arm: cleanup traps.c

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

While working on reenabling 32-bit user space on arm63 I concluded that
the trap handling in traps.c had grown into a twisty confusing mess.
Lets try and sort that out.

This series contains to halves (after a couple of preparatory cleanups).

First clean up the goto maze which we've found ourselves in, by
providing a selection of handle_* helpers e.g. for raz/ro etc and by
calling those and the existing inject_* helpers directly instead of
trying to have only one call to each of the latter by using goto. The
handle_* helpers can also deal with the minimum allowable exception
level, which simplifies things further.

To keep things simpler I've used "return handle_..." when the caller and
callee both return void, since that avoids the need for 3 more lines (2
braces and the return), I think this improves clarity.

Second go through init_traps and for each bit there consolidate the
handling for each type of trap (e.g. do_cp15_32, do_cp15_64, do_sysreg
etc) such that all the registers whose traps are associated with that
bit are kept together beneath a comment which documents why those bits
are trapped, references the appropriate section of the ARMv7 and ARMv8
ARM (the v8 one in particular has a series of very useful tables per
bit) and notes which registers are not explicitly handled (and therefore
take the default case).

For traps which have no explicit handling (i.e. those which trap
implementation defined registers) and which always hit the default case
add the comment above that instead.

Do the same for the GICv3 ICC traps and timer traps.

There is probably scope for doing more, i.e. refactoring related
functionality into subsystem helpers (like we do for vtimer) and even
moving into separate files, but I think this is a good start.

This is a lot of patches, sorry, because I wanted to mostly go through
the trap bits one at a time per patch to keep each one manageable,
although I did end up compressing some of the more obvious ones.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel