Re: [Xen-devel] Stubdom breakage in 4.5

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----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.

  Paul


> Ian.

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