Re: [Xen-devel] [PATCH] qemu-trad: xenstore: use relative path for device-model node

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Thu, Apr 09, 2015 at 06:46:31PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH] qemu-trad: xenstore: use relative path for 
> device-model node"):
> > On Thu, Apr 09, 2015 at 05:47:08PM +0100, Ian Jackson wrote:
> > > 
> > > I think you mean:
> > > ...
> > 
> > So far so good.
> > 
> > >   QEMU traditional stubdom was broken by #### and is still broken in
> > >   -unstable, so this incompatible change is not a regression.
> > > 
> > 
> > It's complicated.
> > 
> > QEMU traditional stubdom was broken by a0731cca "ioreq-server: on-demand
> > creation of ioreq server" in 4.5. Currently there is a workaround in
> > -unstable dd748d12 "x86/hvm: wait for at least one ioreq server to be
> > enabled" (which should be backported to 4.5). QEMU traditional stubdom
> > works with that workaround in -unstable but it's not ideal situation.
> 
> Right.  So that means that this patch needs to go in at the same time
> as the corresponding libxl change.
> 

I don't follow "go in at the same time". They are in two different
trees, don't they?

> > This incompatible change is not a regression because we don't change the
> > protocol 4.5 uses. We will only use the new protocol for -unstable.
> 
> I meant, is it a regression in -unstable from earlier -unstable ?
> 
> And the answer is that unless both libxl and qemu change at the same
> time, it would be a regression in -unstable ?
> 

It would be a regression because stubdom in -unstable is working now
with Paul's workaround. So yes, both changes need to go in at the same
time -- though I don't know how you would do that.

Wei.

> Ian.

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