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

[Andre Przywara <andre.przywara@xxxxxxx>]

Hi,

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.

Cheers,
Andre.

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