Re: [Xen-devel] [PATCH] xen: arm: fully implement multicall interface.

[Julien Grall <julien.grall@xxxxxxxxxx>]

On 04/01/2014 12:15 PM, Ian Campbell wrote:
> On Tue, 2014-04-01 at 12:00 +0100, Julien Grall wrote:
>> On 04/01/2014 11:49 AM, Ian Campbell wrote:
>>> On Tue, 2014-04-01 at 11:46 +0100, Julien Grall wrote:
>>>> On 04/01/2014 10:28 AM, Ian Campbell wrote:
>>>>> On Tue, 2014-04-01 at 10:05 +0100, Julien Grall wrote:
>>>>>> Out-of-context, I've noticed that most of trap failure will kill the 
>>>>>> domain. From the ARM ARM , if a coprocessor instruction is failing, we 
>>>>>> should   generate an Undefined Instruction exception (see P.7.5).
>>>>>
>>>>> You mean HSR_EC_CP15_32, HSR_EC_CP15_64 and HSR_EC_SYSREG?
>>>>>
>>>>> I've not checked but I think we only ask for traps for things which we
>>>>> are supposed to be able to handle, so anything which is trapped which we
>>>>> can't handle is a bug and would indicate the guest doing something
>>>>> funky.
>>>>
>>>> Right, but if the emulation of the instruction fails (see
>>>> vtimer_emulate, do_trap_psci,...), Xen will destroy the domain instead
>>>> of sending an UNDEF exception.
>>>
>>> My point was that the emulation should never fail...
>>
>> The emulation can fail if the guest decides to write on an RO register.
> 
> Hrm yes, I'd forgotten that case.
> 
> Is that an undef or some other sort of exception? Perhaps it depends on
> the cp register whether it faults or is ignored? In either case that
> seems to suggest that it is up to the specific handler to inject the
> correct kind of exception and return an appropriate error code to the
> generic handler.

The default exception is "undefined instruction". I didn't find any
specific exception following the coprocessor. Actually the only ways to
kill the domain in traps.c:
        - we try to access in read (resp. write) on WO (resp. RO) registers
        - the hypercall tags is wrong
        - the PSCI function is not implemented

I think we can replace every (?) domain_crash_synchronous by
inject_undef*_exception.

-- 
Julien Grall

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