Re: [Xen-devel] [PATCH v2 10/27] ARM: GICv3: forward pending LPIs to guests

[Julien Grall <julien.grall@xxxxxxx>]

On 04/04/17 13:51, Andre Przywara wrote:
> On 04/04/17 12:49, Julien Grall wrote:
> > On 03/04/17 15:18, Andre Przywara wrote:
> > > Hi,
> > Hi Andre,
> >
> > > On 24/03/17 12:03, Julien Grall wrote:
> > > > > +    /* We may have mapped more host LPIs than the guest actually
> > > > > asked for. */
> > > > Another way, is the interrupt has been received at the same time the
> > > > guest is configuring it. What will happen if the interrupt is lost?
> > > I don't see how this would be our problem. If the guest is still about
> > > to configure an LPI, then any incoming one is pretty clearly a spurious
> > > interrupt.
> > > I take it that you mean "mapping an LPI using ITS commands" when you say
> > > "configuring" here. If this is not what you mean, please correct me.
> > >
> > > I'd expect a guest to first map the LPI, then enable it and send an INV
> > > command. Doing that differently will not result in any sane behavior (as
> > > in: a guest cannot expect an LPI to come through), so nothing we need to
> > > worry about (from a lost IRQ perspective).
> > >
> > > Or what do I miss here?
> > All host LPIs will be enabled when a device is assigned to a guest. So
> > technically an LPI can come at anytime before the guest is configuring
> > the virtual mapping.
> As I said: what is the problem? Any LPI coming in without being mapped
> by a guest would be spurious from a guest point of view, as in not
> expected and ignored. But a guest will never receive it, since we
> explicitly check for that and on the host side and bail out early. From
> do_LPI():
>     /* Unmapped events are marked with an invalid LPI ID. */
>     if ( hlpi.virt_lpi == INVALID_LPI )
>         return;
>
> And we (atomically) update the entry once the guest has configured it,
> so either it's ignored or delivered. And this is a benign race you have
> on real hardware too.
The document it... if I ask a questions multiple time it is likely the 
code is not clear enough.
Cheers,

--
Julien Grall

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