[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v3 16/16] xen/arm: add SGI handling for GICv3

On Fri, May 2, 2014 at 8:54 PM, Julien Grall <julien.grall@xxxxxxxxxx> wrote:
> On 05/02/2014 04:18 PM, Ian Campbell wrote:
>> On Fri, 2014-05-02 at 15:26 +0100, Julien Grall wrote:
>>> On 05/02/2014 01:57 PM, Vijay Kilari wrote:
>>>> On Sat, Apr 19, 2014 at 1:50 AM, Julien Grall <julien.grall@xxxxxxxxxx> 
>>>> wrote:
>>>>> Hello Vijaya,
>>>>> On 15/04/14 12:17, vijay.kilari@xxxxxxxxx wrote:
>>>>>> From: Vijaya Kumar K <Vijaya.Kumar@xxxxxxxxxxxxxxxxxx>
>>>>>> In ARMv8, write to ICC_SGI1R_EL1 register raises trap to EL2.
>>>>>> Handle the trap and inject SGI to vcpu.
>>>>>>   /* The base of the stack must always be double-word aligned, which 
>>>>>> means
>>>>>>    * that both the kernel half of struct cpu_user_regs (which is pushed 
>>>>>> in
>>>>>> @@ -1406,6 +1407,14 @@ static void do_sysreg(struct cpu_user_regs *regs,
>>>>>>               domain_crash_synchronous();
>>>>>>           }
>>>>>>           break;
>>>>>> +    case HSR_SYSREG_ICC_SGI1R_EL1:
>>>>> Any reason to not trap ICC_SGI0R_EL1 and ICC_ASGI1R_EL1?
>>>> Does Xen supports Secure guests?. In any case, I can make a check on 
>>>> and reject if generating non-secure writes are permitted to generate
>>>> secure grp0 interrupts.
>>>> Similarly for ICC_ASG1R_EL1.
>>> It's not possible to have secure guest. Are you sure it will never trap
>>> to Xen if the guest try to generate a Group 1 SGIs to a secure state?
>>> (see ICC_ASGI1R_EL1).
>> Wouldn't the correct response be to crash a guest who tried?

As per Spec if ICH_HCR_EL2_TC = 1, virtual access to
ICC_ASGI1R_EL1 generate trap.

As per table 29 of GICv3 spec, non-secure EL1/EL2 can access all the
above three registers.
However only write to ICC_SGI1R_EL1 by non-secure EL1/EL2 forwards
non-secure grp 1 interrupt.
All the register access handles Secure Group 0& 1 interrupts.

For now I will just return 1 (UNDEF) with warning for register access
ICC_ASGI1R_EL1. Even if I implement, I have no SW environment to test
secure interrupt handling for now

> The GICv3 spec requests to send a UNDEF exception if the register is not
> implemented.
> In general way, I think UNDEF is a best solution as some kernel such as
> Linux is able to recover from an undef on some specific access (it's
> actually the case for some debug registers on ARM32).

In my understanding, calling inject_undef64_exception() will generate
UNDEF to guest.

> Regards,
> --
> Julien Grall

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.