[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] Remove hardcoded xen-platform device initialization
> -----Original Message----- > From: Stefano Stabellini [mailto:stefano.stabellini@xxxxxxxxxxxxx] > Sent: 18 June 2013 20:35 > To: Paolo Bonzini > Cc: Stefano Stabellini; Paul Durrant; qemu-devel@xxxxxxxxxx; xen- > devel@xxxxxxxxxxxxx; Ian Campbell > Subject: Re: [Xen-devel] [PATCH] Remove hardcoded xen-platform device > initialization > > On Tue, 18 Jun 2013, Paolo Bonzini wrote: > > Il 18/06/2013 20:56, Stefano Stabellini ha scritto: > > >> > > > >> > 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. > > > > > > 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. Can't we just leave the default set at xenfv (as it is in my patch) until we're happy that most distros are carrying a new enough qemu? Paul _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |