Re: [Xen-devel] [Qemu-devel] [PATCH] Remove hardcoded xen-platform device initialization

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 19 Jun 2013, Paul Durrant wrote:
> > -----Original Message-----
> > From: qemu-devel-bounces+paul.durrant=citrix.com@xxxxxxxxxx
> > [mailto:qemu-devel-bounces+paul.durrant=citrix.com@xxxxxxxxxx] On
> > Behalf Of Stefano Stabellini
> > Sent: 19 June 2013 14:53
> > To: Ian Campbell
> > Cc: Paolo Bonzini; Paul Durrant; xen-devel@xxxxxxxxxxxxx; qemu-
> > devel@xxxxxxxxxx; Stefano Stabellini
> > Subject: Re: [Qemu-devel] [Xen-devel] [PATCH] Remove hardcoded xen-
> > platform device initialization
> > 
> > On Wed, 19 Jun 2013, Ian Campbell wrote:
> > > On Tue, 2013-06-18 at 19:56 +0100, Stefano Stabellini wrote:
> > > > On Fri, 14 Jun 2013, Paul Durrant wrote:
> > > > > > -----Original Message-----
> > > > > > From: Paolo Bonzini [mailto:paolo.bonzini@xxxxxxxxx] On Behalf Of
> > Paolo
> > > > > > Bonzini
> > > > > > Sent: 14 June 2013 15:58
> > > > > > To: Paul Durrant
> > > > > > Cc: Ian Campbell; Stefano Stabellini; qemu-devel@xxxxxxxxxx; xen-
> > > > > > devel@xxxxxxxxxxxxx
> > > > > > Subject: Re: [Xen-devel] [PATCH] Remove hardcoded xen-platform
> > device
> > > > > > initialization
> > > > > >
> > > > > > Il 14/06/2013 10:11, Paul Durrant ha scritto:
> > > > > > > I think we're still going to need -M xenpv, I think; it's quite
> > > > > > > distinct from pc.
> > > > > >
> > > > > > Of course!  Even more: "-M xenpv" should be reused on ARM.
> > > > > >
> > > > > > > I guess we could use -M pc for HVM and gate the
> > > > > > > accel code as you suggest but, if that's the way we're going, it
> > > > > > > would seem more logical just to ditch the accel code for xenpv
> > > > > > > completely (assuming we can do all we need from the machine init)
> > and
> > > > > > > then use -M pc -accel=xen for HVM guests going forward.
> > > > > >
> > > > > > There is common code between pv and fv, and that one definitely
> > belongs
> > > > > > in xen_init.  Most fv-only code probably should be in pc_init.  The 
> > > > > > rest
> > > > > > should move to xen_init though, because it would apply just as well
> > for
> > > > > > example to Q35.  It's a bit ugly to have fv-only code there, but 
> > > > > > it's
> > > > > > better than having a Xen-specific machine type.  Xen/KVM/TCG
> > should be
> > > > > > as similar as possible at the QEMU level, any difference should be
> > > > > > handled in the toolstack.
> > > > > >
> > > > > > > But that does
> > > > > > > rather screw up my autodiscovery plans because I would not know,
> > for
> > > > > > > a given qemu binary, which machine type to use.
> > > > > >
> > > > > > There's no need for that.  4.4 can just use "-M pc" unconditionally,
> > > > > > <=4.3 will just use "-M xenfv" unconditionally.
> > > > > >
> > > > > > > If I create a new
> > > > > > > xenfv-2.0 machine type though I *can* do auto discovery... in 
> > > > > > > which
> > > > > > > case do we need the -accel=xen option at all?
> > > > > >
> > > > > > Yes.  Please try not do things differently from other accelerators.
> > > > > >
> > > > >
> > > > > Ok. I guess we can have the ability to override the machine type in 
> > > > > the
> > VM config, so you could still kick off an older qemu with a newer libxl - 
> > but it
> > sounds like the auto-discovery idea is a no-go then.
> > > >
> > > > xenfv-2.0 is a bad idea, like Paolo wrote, it should be possible to just
> > > > use -M pc for HVM guests and retain -M xenpv for pv guests.
> > > >
> > > > However it seems to me that we also need a way in libxl to find out
> > > > whether QEMU is new enough for us to be able to use -M pc.
> > > > We can't just assume that users will be able to figure out the magic
> > > > rune they need to write in the VM config file to solve their VM crash at
> > > > boot problem.
> > >
> > > What crash at boot problem?
> > 
> > If you start QEMU as device model on Xen with the wrong machine option
> > (for example -M pc on an old QEMU), QEMU would probably just abort
> > during initialization.
> > 
> > 
> > > > We could spawn an instance of QEMU just to figure out the QEMU
> > version
> > > > but we certainly cannot do that every time we start a new VM.
> > > > Once we figure out the QEMU version the first time we could write it to
> > > > xenstore so that the next time we don't have to go through the same
> > > > process again.
> > >
> > > Due to the device_model_override we might need to make this per-path.
> > > You'd also likely need to store mtime or something in case qemu gets
> > > upgraded, although perhaps that is getting unnecessarily picky...
> > 
> > I think of device_model_override as an option for developers. People
> > that use device_model_override can also override the QEMUMachine
> > version.
> 
> Are you suggesting we allow a freeform -machine option in libxl, or are you 
> suggesting they point device_model_override at a script which drops the -M 
> argument and inserts their new choice before invoking qemu?

I am suggesting that we could have a qemu_machine_override option in
QEMU, or maybe a device_models_args_override that not only adds any user
supplied arguments to QEMU (like the current device_model_args) but also
replace the default arguments completely.

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