Re: [Xen-devel] Stubdom breakage in 4.5

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Paul Durrant
> Sent: 03 February 2015 14:00
> To: Ian Campbell
> Cc: Wei Liu; xen-devel@xxxxxxxxxxxxx; Ian Jackson; Jan Beulich; Andrew
> Cooper; Stefano Stabellini
> Subject: RE: Stubdom breakage in 4.5
> 
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 03 February 2015 13:48
> > To: Paul Durrant
> > Cc: Wei Liu; xen-devel@xxxxxxxxxxxxx; Ian Jackson; Jan Beulich; Andrew
> > Cooper; Stefano Stabellini
> > Subject: Re: Stubdom breakage in 4.5
> >
> > On Tue, 2015-02-03 at 13:42 +0000, Paul Durrant wrote:
> > > > -----Original Message-----
> > > > From: Wei Liu [mailto:wei.liu2@xxxxxxxxxx]
> > > > Sent: 03 February 2015 12:22
> > > > To: xen-devel@xxxxxxxxxxxxx
> > > > Cc: Wei Liu; Ian Campbell; Ian Jackson; Paul Durrant; Jan Beulich;
> Andrew
> > > > Cooper; Stefano Stabellini
> > > > Subject: Stubdom breakage in 4.5
> > > >
> > > > Hi all
> > > >
> > > > I recently found out that stubdom in 4.5 is broken.
> > > >
> > > > A proper fix to that issue is likely to alter the start up protocol,
> > > > which is not acceptable for backport.
> > > >
> > > > Providing a backport that doesn't alter the protocol used to start up
> > > > stubdom is difficult.
> > > >
> > > > Paul, do you have any insight how we can fix stubdom in 4.5? Even a
> > > > backportable workaround is better than just have stubdom broken.
> > > >
> > >
> > > The minimal fix from your PoV, I guess, would be something that tells
> > > Xen not to complete I/O in the absence of a matching IOREQ but to wait
> > > until one is there, IIUC? It's a bit icky, and I don't know what form
> > > that something would be in.
> >
> > "wait until one is there" == "the default ioreq is registered", i.e. put
> > it on the default ring in anticipation of something eventually consuming
> > it? This was the behaviour in 4.4 and earlier AIUI.
> >
> > I think reverting to that behaviour (nb, not by actually reverting the
> > feature) in the 4.5 branch would be the best compromise, since as Wei
> > says the proper fix for 4.6 will likely involve too much to backport
> > (since it will involve fixing the startup interlock between toolstack
> > and multiple qemus, and protocol changes like that aren't really stable
> > backport candidates).
> >
> > Either way, this regression certainly needs fixing in 4.5 as well as
> > unstable/4.6. It's my understanding that the stuff Don is doing is (at
> > least partially) addressing the latter?
> >
> 
> No, I don't think the stuff Don is doing will help this. He has need to steer 
> his
> emulation requests, which are new and distinct. The case here is that you
> need an emulator for existent types of IOREQ to be present before the guest
> gets going and the toolstack is not ensuring this, so yes, forcibly creating 
> the
> default emulator during domain build would solve that problem. However it
> does introduce another problem...
> Upstream QEMU now no longer hooks into Xen as the default emulator and
> therefore will not get emulation requests for the TPM probe done by
> hvmloader; those are now completed by Xen but would end up wedging the
> VM if Xen thought that a default emulator would eventually turn up. So,
> forcible creation of the default emulator would still need to be something
> that could be turned off if the latest upstream QEMU were in use.
> 
> > Paul, can you take care of fixing, or ensuring someone else is fixing,
> > the issue, please.
> >
> 
> I'm happy to fix once the best course of action is agreed.
> 

How about this as a slightly hacky solution that I think may work in both cases?

If Xen finds no emulator at all for an HVM guest then it waits around for at 
least one to show up before processing an emulation request. Until one does it 
stalls the vcpu in question indefinitely, but on the first emulator attach 
(i.e. ioreq server creations) then the IO will always be processed, even if it 
doesn't match the ioreq server.

If no-one shouts I'll proceed along those lines.

  Paul

>   Paul
> 
> 
> > Ian.

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