From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: Configuration vs. compat hints [was Re: [Qemu-devel] [PATCHv3 03/13] qemu: add routines to manage PCI capabilities] Date: Mon, 15 Jun 2009 17:34:06 +0300 Message-ID: <20090615143406.GA14405@redhat.com> References: <4A326C7E.3020309@codemonkey.ws> <1244822007.30522.68.camel@blaa> <4A327E87.6080005@codemonkey.ws> <1244825333.26769.20.camel@blaa> <4A34ADA9.80709@redhat.com> <1245056955.6891.33.camel@blaa> <4A36314A.8040206@redhat.com> <4A364316.5070402@codemonkey.ws> <1245074447.3222.53.camel@blaa> <4A365890.1050106@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Mark McLoughlin , Avi Kivity , Jamie Lokier , Carsten Otte , kvm@vger.kernel.org, Glauber Costa , Rusty Russell , qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org, Blue Swirl , Christian Borntraeger , Paul Brook To: Anthony Liguori Return-path: Received: from mx2.redhat.com ([66.187.237.31]:39729 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753381AbZFOOgZ (ORCPT ); Mon, 15 Jun 2009 10:36:25 -0400 Content-Disposition: inline In-Reply-To: <4A365890.1050106@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, Jun 15, 2009 at 09:20:00AM -0500, Anthony Liguori wrote: > Mark McLoughlin wrote: >> On Mon, 2009-06-15 at 07:48 -0500, Anthony Liguori wrote: >> >>>> Eventually the default configuration becomes increasingly unusable >>>> and you need a new baseline. You must still be able to fall back >>>> to the old baseline for older guests. I don't think games with >>>> configuration files can hide that. >>>> >>> -M pc1 >>> -M pc2 >>> >>> etc. >>> >>> This is pretty easy to maintain with config files. >>> >> >> I think this would be reasonable, but it is essentially just a version >> number which you objected to on the basis that it would make >> cherry-picking harder for distros. >> > > It doesn't have to be pc1, pc2. It could be pc-with-usb or > pc-with-balloon. If a distro cherry picks in such a way that their pc > is not a standard QEMU pc, they would add a new PC type that's specific > to their distro. > >> One thing that would be nice with this '-M pc1' thing would be to retain >> '-M pc' as a symlink to the latest version. We'd also need a way to read >> the symlink too, so that you can query what the current latest version >> is and use that in future. >> > > Another option is an explicit -M default which always uses the default > machine for the architecture. Likewise, we would need a way to query > what the default machine was for an architecture. > >> How would this machine type version relate to e.g. changing the default >> PCI class of virtio-blk? Would we bump the version number of all machine >> types can use virtio-blk? >> > You would introduce a new machine type. For instance, > pc-virtio-class-other. The names don't have to look like that, I'm just > doing that to make a point. This may mean that you end up with dozens > of machine types but you preserve compatibility, which is a good thing. And then pc-virtio-class-other-with-balloon-without-usb? Wouldn't it be more straightforward to have capability bits which can be switched on and off independently rather than trying to fit unrelated features into a machine type? IMO it only seems more work at first, and QA gets a bit nervious that they can't exhaustively test all options. But in the long run it simplifies things as you don't have to set policy and invent silly names. > Of course, the flip side is that you make preserving the machine config > the duty of the user and we don't maintain compatible machine types. > This won't work without a proper config file though so for now, we're > stuck maintaining machine types. > > Regards, > > Anthony Liguori From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MGDIV-0007S2-32 for qemu-devel@nongnu.org; Mon, 15 Jun 2009 10:36:32 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MGDIN-0007PL-IA for qemu-devel@nongnu.org; Mon, 15 Jun 2009 10:36:28 -0400 Received: from [199.232.76.173] (port=50144 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MGDIM-0007P3-4W for qemu-devel@nongnu.org; Mon, 15 Jun 2009 10:36:22 -0400 Received: from mx2.redhat.com ([66.187.237.31]:46503) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MGDIL-00080f-Kv for qemu-devel@nongnu.org; Mon, 15 Jun 2009 10:36:21 -0400 Date: Mon, 15 Jun 2009 17:34:06 +0300 From: "Michael S. Tsirkin" Subject: Re: Configuration vs. compat hints [was Re: [Qemu-devel] [PATCHv3 03/13] qemu: add routines to manage PCI capabilities] Message-ID: <20090615143406.GA14405@redhat.com> References: <4A326C7E.3020309@codemonkey.ws> <1244822007.30522.68.camel@blaa> <4A327E87.6080005@codemonkey.ws> <1244825333.26769.20.camel@blaa> <4A34ADA9.80709@redhat.com> <1245056955.6891.33.camel@blaa> <4A36314A.8040206@redhat.com> <4A364316.5070402@codemonkey.ws> <1245074447.3222.53.camel@blaa> <4A365890.1050106@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A365890.1050106@codemonkey.ws> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Mark McLoughlin , kvm@vger.kernel.org, Carsten Otte , Glauber Costa , Rusty Russell , qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org, Blue Swirl , Christian Borntraeger , Avi Kivity , Paul Brook On Mon, Jun 15, 2009 at 09:20:00AM -0500, Anthony Liguori wrote: > Mark McLoughlin wrote: >> On Mon, 2009-06-15 at 07:48 -0500, Anthony Liguori wrote: >> >>>> Eventually the default configuration becomes increasingly unusable >>>> and you need a new baseline. You must still be able to fall back >>>> to the old baseline for older guests. I don't think games with >>>> configuration files can hide that. >>>> >>> -M pc1 >>> -M pc2 >>> >>> etc. >>> >>> This is pretty easy to maintain with config files. >>> >> >> I think this would be reasonable, but it is essentially just a version >> number which you objected to on the basis that it would make >> cherry-picking harder for distros. >> > > It doesn't have to be pc1, pc2. It could be pc-with-usb or > pc-with-balloon. If a distro cherry picks in such a way that their pc > is not a standard QEMU pc, they would add a new PC type that's specific > to their distro. > >> One thing that would be nice with this '-M pc1' thing would be to retain >> '-M pc' as a symlink to the latest version. We'd also need a way to read >> the symlink too, so that you can query what the current latest version >> is and use that in future. >> > > Another option is an explicit -M default which always uses the default > machine for the architecture. Likewise, we would need a way to query > what the default machine was for an architecture. > >> How would this machine type version relate to e.g. changing the default >> PCI class of virtio-blk? Would we bump the version number of all machine >> types can use virtio-blk? >> > You would introduce a new machine type. For instance, > pc-virtio-class-other. The names don't have to look like that, I'm just > doing that to make a point. This may mean that you end up with dozens > of machine types but you preserve compatibility, which is a good thing. And then pc-virtio-class-other-with-balloon-without-usb? Wouldn't it be more straightforward to have capability bits which can be switched on and off independently rather than trying to fit unrelated features into a machine type? IMO it only seems more work at first, and QA gets a bit nervious that they can't exhaustively test all options. But in the long run it simplifies things as you don't have to set policy and invent silly names. > Of course, the flip side is that you make preserving the machine config > the duty of the user and we don't maintain compatible machine types. > This won't work without a proper config file though so for now, we're > stuck maintaining machine types. > > Regards, > > Anthony Liguori