On Mon, 13 Dec 2010, Ian Jackson wrote:
> 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 ?
Sorry, I make a typo in my mail. I was speaking about qemu-xen in my
reply, and not qemu upstream.
> 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 ?
No, because the arguments for qemu-xen are not make by the same
function. There are two functions that do almost the same thing:
- libxl_build_device_model_args_old
this function make argument for qemu-xen, the one in xen-unstable.
- libxl_build_device_model_args_new
and this one make arguments for qemu (upstream).
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home