WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH 4/5] libxl: Makes libxl be able to call Qemu upst

Anthony PERARD writes ("Re: [Xen-devel] [PATCH 4/5] libxl: Makes libxl be able 
to call Qemu upstream for XenPV guest."):
> On Fri, 10 Dec 2010, Ian Jackson wrote:
> 
> > anthony.perard@xxxxxxxxxx writes ("[Xen-devel] [PATCH 4/5] libxl: Makes 
> > libxl be able to call Qemu upstream for XenPV guest."):
> > > From: Anthony PERARD <anthony.perard@xxxxxxxxxx>
> > > In libxl_build_device_model_args_new:
> > >   - Adds -xen-attach options to the list of arguments to Qemu.
> >
> > Is that understood by qemu-xen ?
> 
> Not really, it is understood by Qemu only when we have this:
> #if defined(CONFIG_XEN) && !defined(CONFIG_DM).
> 
> And even in this case, it will do nothing because the variable that
> receives the option is write only, it is never read.
> 
> So the answer is no, it is not understood by Qemu.

Your reply seems confusing to me.  Are we talking about the same
things ?

By "qemu-xen" I mean the old qemu tree which we are still using for
xen-unstable.  By "understood" I mean that the program will accept the
option.  You write "Qemu" but by "Qemu" I would normally understand
the current upstream qemu (presumably with your Xen patch series).

If the option is not understood by qemu-xen then current xen-unstable
will break if we apply your patch, surely ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>