Re: [Xen-devel] [PATCH] Add a device_model_machine option for HVM domains to libxl.

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Thu, 20 Jun 2013, Paul Durrant wrote:
> > -----Original Message-----
> > From: Stefano Stabellini [mailto:stefano.stabellini@xxxxxxxxxxxxx]
> > Sent: 19 June 2013 18:26
> > To: Paul Durrant
> > Cc: Stefano Stabellini; xen-devel@xxxxxxxxxxxxx
> > Subject: RE: [Xen-devel] [PATCH] Add a device_model_machine option for
> > HVM domains to libxl.
> > 
> > On Wed, 19 Jun 2013, Paul Durrant wrote:
> > > > -----Original Message-----
> > > > From: Stefano Stabellini [mailto:stefano.stabellini@xxxxxxxxxxxxx]
> > > > Sent: 18 June 2013 20:06
> > > > To: Paul Durrant
> > > > Cc: xen-devel@xxxxxxxxxxxxx
> > > > Subject: Re: [Xen-devel] [PATCH] Add a device_model_machine option
> > for
> > > > HVM domains to libxl.
> > > >
> > > > On Mon, 17 Jun 2013, Paul Durrant wrote:
> > > > > The device-model machine type used for HVM domains is currently
> > > > hardcoded to
> > > > > 'xenfv'. This patch adds a device_model_machine option, which
> > defaults to
> > > > > 'xenfv' for comatibility, but allows the specification of an 
> > > > > alternative
> > > > > machine type 'pc'.
> > > > > Note that use of the 'pc' machine type relies on patches that I have
> > > > > submitted to qemu-devel.
> > > > >
> > > > > Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
> > > >
> > > > NACK
> > > >
> > > > I don't think that this kind of option should exposed to the user except
> > > > maybe for debugging purposed.
> > > > We need a way to automatically select the right one.
> > > >
> > >
> > > Ok, but what is the *right* one? Would you accept this patch without the
> > manpage tweak? Xenfv's hardcoded platform device creation is completely
> > stalling my attempts to get Citrix Windows PV drivers running on upstream.
> > Having this option and defaulting it to xenfv seems like a fairly pragmatic
> > approach to me.
> > 
> > Sorry, I realize that my messages have been a bit confusing.
> > 
> > I am not opposed to having this option as a companion of
> > device_model_override, I am just opposed to using this option to solve
> > the compatibility problem with QEMU.
> > 
> > I would like to see an additional patch that queries the running QEMU
> > for its version and uses it to determine the default QEMU machine
> > version.  Then we can also allow users to override it with something
> > like this patch.
> 
> Yes, that's quite reasonable and such an additional patch series is my 
> intention, but like so many things I don't have time to work on that now.

You just need to use the already existing QMP command query-version and
send it to the QEMU instance instantiated from the init script. It
should be a pretty small patch.


> So, if you think the new option has implications beyond my intention as an 
> override then I'd be happy to modify it.
> Here's a plan:
> 
> - I make it freeform, rather than an enumeration (meaning folks have to add 
> the ,accel=xen option themselves, but giving flexibility)
> - I make it more clear in the manpage (and possibly in the option name 
> itself) that it is an override
> 
> Does that sound ok?

They look like reasonable improvements over this patch.

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