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

Re: [Xen-devel] [PATCH] xen/arm: implement GICD_ICACTIVER read/write

On Mon, 30 Nov 2015, Julien Grall wrote:
> Hi Stefano,
> On 25/11/15 16:40, Stefano Stabellini wrote:
> > Implement GICD_ICACTIVER and GICD_ISACTIVER reads by looking for the
> > GIC_IRQ_GUEST_ACTIVE bit in the relevant struct pending_irq. However
> > given that the pending to active transaction for irqs in LRs in done in
> > hardware, the GIC_IRQ_GUEST_ACTIVE bit might be out of date. We'll have
> > to live with that.
> Looking to the Linux tree again, I found this commit:
> commit 1c7d4dd46ee048afe19e1294634df6fa66862519
> Author: Marc Zyngier <marc.zyngier@xxxxxxx>
> Date:   Mon Nov 16 19:13:28 2015 +0000
>     irqchip/gic: Add save/restore of the active state
>     When using EOImode==1, we may mark interrupts as being forwarded
>     to a virtual machine. In that case, the interrupt is left active
>     while being passed to the VM.
>     If we suspend the system before the VM has deactivated the interrupt,
>     the active state will be lost (which may be very annoying, as this
>     may result in spurious interrupts and a confused guest).
>     To avoid this, save and restore the active state together with the
>     rest of the GIC registers.
>     Signed-off-by: Marc Zyngier <marc.zyngier@xxxxxxx>
>     Cc: <linux-arm-kernel@xxxxxxxxxxxxxxxxxxx>
>     Cc: Jason Cooper <jason@xxxxxxxxxxxxxx>
>     Cc: Russell King <linux@xxxxxxxxxxxxxxxx>
>     Link:
> http://lkml.kernel.org/r/1447701208-18150-5-git-send-email-marc.zyngier@xxxxxxx
>     Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
> So, we have to handle properly active/deactivate in order to get
> suspend/resume working correctly.

We won't have any active interrupts: suspending the guest is done in
cooperation with the guest kernel (see drivers/xen/manage.c), which will
deactive the interrupts.  In any case we only have evtchn_irq and the

Xen-devel mailing list



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