Re: [Xen-devel] Stubdom breakage in 4.5

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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?

Paul, can you take care of fixing, or ensuring someone else is fixing,
the issue, please.

Ian.


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