From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59421) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZuPdm-0003bF-AI for qemu-devel@nongnu.org; Thu, 05 Nov 2015 13:52:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZuPdh-0000oB-L9 for qemu-devel@nongnu.org; Thu, 05 Nov 2015 13:52:06 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56937) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZuPdh-0000o7-Eb for qemu-devel@nongnu.org; Thu, 05 Nov 2015 13:52:01 -0500 Date: Thu, 5 Nov 2015 18:51:56 +0000 From: "Dr. David Alan Gilbert" Message-ID: <20151105185156.GE2445@work-vm> References: <5635D82C.6030400@redhat.com> <20151102100730.6836dc5f.cornelia.huck@de.ibm.com> <56372AF2.8040500@redhat.com> <20151102105425.32230aca.cornelia.huck@de.ibm.com> <56373462.2050601@redhat.com> <20151102130531.6a4a4175.cornelia.huck@de.ibm.com> <56375330.70702@redhat.com> <20151105174216.GQ4180@thinpad.lan.raisama.net> <20151105182209.GC2445@work-vm> <563BA39E.70706@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <563BA39E.70706@redhat.com> Subject: Re: [Qemu-devel] [PATCH V3] hw/virtio: Add PCIe capability to virtio devices List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marcel Apfelbaum Cc: Eduardo Habkost , Juan Quintela , mst@redhat.com, qemu-devel@nongnu.org, Amit Shah , kraxel@redhat.com, Cornelia Huck * Marcel Apfelbaum (marcel@redhat.com) wrote: > On 11/05/2015 08:22 PM, Dr. David Alan Gilbert wrote: > >* Eduardo Habkost (ehabkost@redhat.com) wrote: > >>On Mon, Nov 02, 2015 at 02:12:32PM +0200, Marcel Apfelbaum wrote: > >>>On 11/02/2015 02:05 PM, Cornelia Huck wrote: > >>[...] > >>>>What's the word on compat machines and new device types, btw.? If we > >>>>fire up a compat machine, we can still specify devices that were added > >>>>with later machine versions, but of course we can't migrate to an old > >>>>machine as the device types did not exist there. Do we want to give the > >>>>user a hint here by disallowing new device types? > >>>> > >>> > >>>I started to wonder about this too, so I added to this thread the migration > >>>maintainers that should be qualified to answer this :) > >> > >>This looks no different from all other features that are available on > >>newer QEMU versions and prevent migration to older hosts (even ones that > >>are not guest-visible, like backend configuration). Management can > >>easily detect the unavailability of those features in other hosts, long > >>before trying migration (and have better ways to warn the user if > >>necessary). > >> > >>Also, it looks like a potential nightmare for downstream maintainers > >>that cherry-pick and rebase patches, so I hope we don't consider > >>implementing that. :) > > > > a) It's fine to add new devices and allow them to be used with old machine > > types > > b) The rule is that any old machine type used in the way it used to be used > > must stay the same. > > c) That also means it's fine to add new features that can be turned on > > with old machine types; as long as the default is that they behave > > just like they always did. > > d) If you know a new device just isn't going to work with an old > > machine type then please make it fail early with an obvious > > error. > > > >Having said all that; I have seen requests for some magic which would > >tell the management tool whether something is 'safe for migration'; > >so imagine that a user has a pile of hosts, some of which have qemu 2.n on > >and some have qemu 2.n+1 ; if he creates his VM on 2.n+1 and uses > >a feature that's new in 2.n+1 the management tool can't warn him > >because they've not yet expressed an interest in migrating to > >the 2.n machine. > > Exactly, so how can I do (d) ? Note that (d) is talking about making it fail on a new version of qemu with an old machine type; e.g. if you know that your new device for some reason just won't work on pc-i440fx-2.4 or older then add a check in - I'm not sure if we've got any easy way to do that at the moment but it shouldn't be hard. However I don't think I'm aware of any device with that type of interaction; but maybe there is somewhere. > A "migration possible" machine mapping qemu-pc-2.x -> qemu-pc-2.y is not enough, we need to > compare also the QEMU versions and have a "minimum QEMU version per feature." > Do we have a way to do this today in QEMU? (d) is entirely separate from knowing that it won't work on an old machine type on an old qemu. No, I don't think we have anything for minimum version for features; but, management tools can probe for all features, so some management tool could group those feature sets together somewhere to know the features of all the hosts involved; but it doesn't sound that easy. Dave > > Thanks, > Marcel > > > > >Dave > > > >> > >>-- > >>Eduardo > >-- > >Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK > > > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK