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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 26 Jun 2013, Ian Campbell wrote:
> 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? 

I think that ignoring the case, although not ideal, would be acceptable.

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