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 05:47:08PM +0100, Ian Jackson wrote:
> Wei Liu writes ("[PATCH] qemu-trad: xenstore: use relative path for 
> device-model node"):
> > For QEMU traditional stubdom, this is incompatible startup protocol
> > change.  This change needs to work with corresponding libxl changeset.
> > QEMU traditional is shipped with Xen so we are allowed to do such
> > change.
> > 
> > For QEMU traditional running in Dom0, there is no functional change
> > because it will still write to the same /local/domain/0 path.
> 
> I think you mean:
> 
>   For QEMU traditional running in Dom0, there is no functional change
>   because it will still write to the same /local/domain/0 path.
> 
>   For QEMU traditional stubdom, this is an incompatible startup
>   protocol change.  There is a corresponding libxl changeset "libxl:
>   use new QEMU xenstore protocol", which has not yet been committed
>   (54c2e621 was reverted in 84066dd4).
> 

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.

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.

Wei.

> where #### is some commit I haven't been able to easily identify.
> 
> Is that right ?
> 
> Thanks,
> Ian.

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