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@lists.xen.org
https://lists.xen.org/xen-devel