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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2013-06-20 at 11:04 +0100, Stefano Stabellini wrote:
> 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.

Don't forget that it also needs to detect the case where the user has
used an override for the qemu binary, such that it doesn't match the
dom0 instance. Or are you planning to just ignore this case and require
users of device_model_override to also use the machine type override? 

> > 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.

I'm not sure that requiring a free form field rather than an enumeration
is the best interface. An enumeration allows us to note which machines
we have support for i.e. the things we might reasonably expect people to
use in order to remain compatible with the virtual platform from a
previous release. It also naturally provides us a list of versions which
we can compare against qemu's machine-list command.

A free form list does give more of an escape hatch though.

Ian.


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