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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Mon, 3 Apr 2017, Julien Grall wrote:
> 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.

That's fine by me.

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