From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MESUo-0007y3-Vl for qemu-devel@nongnu.org; Wed, 10 Jun 2009 14:25:59 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MESUj-0007aA-CK for qemu-devel@nongnu.org; Wed, 10 Jun 2009 14:25:58 -0400 Received: from [199.232.76.173] (port=37593 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MESUj-0007Zg-1z for qemu-devel@nongnu.org; Wed, 10 Jun 2009 14:25:53 -0400 Received: from mx2.redhat.com ([66.187.237.31]:38099) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MESUi-0000QC-I3 for qemu-devel@nongnu.org; Wed, 10 Jun 2009 14:25:52 -0400 Date: Wed, 10 Jun 2009 21:22:27 +0300 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] [PATCHv3 03/13] qemu: add routines to manage PCI capabilities Message-ID: <20090610182227.GN28601@redhat.com> References: <20090610145540.GI19375@poweredge.glommer> <20090610150129.GC28601@redhat.com> <200906101624.30659.paul@codesourcery.com> <20090610174301.GC7416@shareable.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090610174301.GC7416@shareable.org> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: 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 , Avi Kivity On Wed, Jun 10, 2009 at 06:43:02PM +0100, Jamie Lokier wrote: > Paul Brook wrote: > > > > caps can be anywhere, but we don't expect it to change during machine > > > > execution lifetime. > > > > > > > > Or I am just confused by the name "pci_device_load" ? > > > > > > Right. So I want to load an image and it has capability X at offset Y. > > > wmask has to match. I don't want to assume that we never change Y > > > for the device without breaking old images, so I clear wmask here > > > and set it up again after looking up capabilities that I loaded. > > > > We should not be loading state into a different device (or a similar device > > with a different set of capabilities). > > > > If you want to provide backwards compatibility then you should do that by > > creating a device that is the same as the original. As I mentioned in my > > earlier mail, loading a snapshot should never do anything that can not be > > achieved through normal operation. > > If you can create a machine be restoring a snapshot which you can't > create by normally starting QEMU, then you'll soon have guests which > work fine from their snapshots, but which cannot be booted without a > snapshot because there's no way to boot the right machine for the guest. Yes. This clearly isn't what I'm building here. You *can* create a guest without msi-x support by passing an appropriate flag. > Ssomeone might even have guests like that for years without noticing, > because they always save and restore guest state using snapshots, then > one day they simply want to boot the guest from it's disk image and > find there's no way to do it with any QEMU which runs on their host > platform. > > I think the right long term answer to all this is a way to get QEMU to > dump it's current machine configuration in glorious detail as a file > which can be reloaded as a machine configuration. > > -- Jamie And then we'll have the same set of problems there. -- MST