On 23 April 2015 at 04:37, Edgar E. Iglesias <edgar.igles...@gmail.com> wrote:
> On Wed, Apr 22, 2015 at 12:09:12PM -0500, Greg Bellows wrote:
>> Initial patchset adding support for trapping to an EL other than EL1.
>> Support
>> includes changes to interfaces to allow specification of the target EL. Also
>> includes the addition of the ARMv8 CPTR system registers used for controlling
>> the trapping of features.
>
> Hi Greg,
>
> I'm not sure I see the value with the target_el member, it felt OK
> to call the route function from the do_interrupt functions but I may
> be missing something.
The problem is that for some exceptions (particularly the ones which are
"some trap bit means an insn causes a trap to EL2 or EL3") you can't
determine the target-el after the fact: all you have is "EXCP_UDEF"
and you don't know which of the various possible trappable insns it
was, so you don't know whether to take it to EL1, EL2 or EL3.
There were two solutions to this that we tossed around:
(1) this one, where you determine the target EL for the trap at
translate time (by encoding the trap bits into the TB flags,
or at least the target EL for each kind of trap)
(2) an approach which splits EXCP_UDEF up into effectively one
exception type for each case of trappable instructions, and
then check the trap bits at runtime to figure out the routing
Once you've decided on approach (1) you might as well use the new
exception.target_el member to avoid repeating the routing calculations
for IRQ, FIQ etc.
-- PMM
