[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



> -----Original Message-----
> From: Ian Campbell
> Sent: 19 June 2013 09:29
> To: Andreas FÃrber
> Cc: Stefano Stabellini; Paolo Bonzini; Paul Durrant; xen-devel@xxxxxxxxxxxxx;
> qemu-devel@xxxxxxxxxx
> Subject: Re: [Qemu-devel] [Xen-devel] [PATCH] Remove hardcoded xen-
> platform device initialization
> 
> On Tue, 2013-06-18 at 23:38 +0200, Andreas FÃrber wrote:
> > Am 18.06.2013 21:35, schrieb Stefano Stabellini:
> > > On Tue, 18 Jun 2013, Paolo Bonzini wrote:
> > >> Il 18/06/2013 20:56, Stefano Stabellini ha scritto:
> > >>> 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.
> > >>>
> > >>> 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.
> > >>
> > >> Can you just assume that 4.4 requires QEMU 1.6 or newer?
> > >
> > > I would rather not make that assumption because we cannot control
> what
> > > distro are going to package. I wouldn't want a distro to ship with Xen
> > > HVM guests broken because they choose the wrong QEMU version. Of
> course
> > > we could put that in the release notes, but there are lots of distros
> > > out there and I am pretty sure that at least one of them is not going to
> > > read them.
> >
> > You could check for existence of the pc-i440fx-1.6 machine and infer
> > that it is at least v1.6 (might break in some distant future of course
> > and for current git commits until your changes get merged).
> 
> Actually, this raises an interesting point. AIUI "pc" is simply and
> alias for the most recent "pc-X.Y" and "pc-X.Y" is present to allow for
> qemu "upgrading" the set of emulated hardware, as in it represents
> changing the set of emulated peripherals, not just fixing bugs in the
> emulation etc, is that right?
> 
> I think it would be preferable for us to request a specific platform
> (pc-i440fx-1.6 if that's the one) and a conscious decision to support
> newer platforms (and can test it etc).
> 

If that is the case then the xenfv code is also incorrect, since it does not 
call through to a specific version of 'pc'.

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.