Re: [Xen-devel] [PATCH v5 3/3] xen/arm: vgic_migrate_irq: do not race against GIC_IRQ_GUEST_MIGRATING

[Julien Grall <julien.grall@xxxxxxx>]

Hi Stefano,

On 31/03/17 21:24, Stefano Stabellini wrote:
> On Fri, 31 Mar 2017, Julien Grall wrote:
> > On 30/03/17 00:47, Stefano Stabellini wrote:
> > > On Fri, 3 Mar 2017, Julien Grall wrote:
> > What you described is not a data corruption to me.
> No, it is not, thanks to the previous two patches. The commit
> description needs an update.
>
>
> > The host IRQ will be routed
> > to the wrong pCPU and then what? The IRQ will still trigger, ok on the wrong
> > pCPU, it will be slower but we are capable to handle that.
> >
> > The use case you describe would only happen if a guest is trying to change the
> > routing multiple times while an interrupt is pending. So to be honest, a sane
> > guest would not do that. But this would only affect stupid guest.
> >
> > So I don't think this is worth to support considering how this patch will
> > increase the code complexity in a component that is already a nightmare to
> > handle.
> I think we have to fix this because it is not predictable. Latency could
> be much higher, depending on who wins the race. It also uses more Xen
> resources -- the time that Xen spends to send and to handle SGIs could
> be used for something  else.  I think it is more important to be
> predictable than correct. Especially given that a sane guest shouldn't
> do this, I prefer to refuse a "nested" migration we cannot handle (even
> though it is a mistake) than provide unreliable latency.
Good point. We already have a couple of place in the vGIC we don't 
handle and print a message instead (see ACTIVER, I*PENDR registers).
I would prefer to refuse "nested" migration and warn the guest. If 
someone complain, then we can think about it.
Cheers,

--
Julien Grall

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