[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



Hi Vijay,

On 05/05/14 07:53, Vijay Kilari wrote:
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 GICR_NSACR
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_SGI0R_EL1/ICC_SGI1R_EL1/
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_SGI0R_EL1/
ICC_ASGI1R_EL1. Even if I implement, I have no SW environment to test
secure interrupt handling for now

As secure interrupt should not happen from the guest. You can check that we correctly trap the access to thoses interrupts.



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.

Right. You have to call this function only if the domain is arm aarch64 guest.

AFAIU, it's possible to have GICv3 support when the guest is armv8 32 bit. So you will have to call inject_undef32_exception for this case.

Regards,

--
Julien Grall

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


 


Rackspace

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