From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MEQ6w-0003Zm-5r for qemu-devel@nongnu.org; Wed, 10 Jun 2009 11:53:10 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MEQ6r-0003Xy-JS for qemu-devel@nongnu.org; Wed, 10 Jun 2009 11:53:09 -0400 Received: from [199.232.76.173] (port=51602 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MEQ6r-0003Xt-Ef for qemu-devel@nongnu.org; Wed, 10 Jun 2009 11:53:05 -0400 Received: from mx2.redhat.com ([66.187.237.31]:38415) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MEQ6q-00028N-OL for qemu-devel@nongnu.org; Wed, 10 Jun 2009 11:53:05 -0400 Date: Wed, 10 Jun 2009 18:50:00 +0300 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] [PATCHv3 03/13] qemu: add routines to manage PCI capabilities Message-ID: <20090610155000.GG28601@redhat.com> References: <20090610145540.GI19375@poweredge.glommer> <20090610150129.GC28601@redhat.com> <200906101624.30659.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200906101624.30659.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Carsten Otte , kvm@vger.kernel.org, Glauber Costa , Rusty Russell , qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org, Blue Swirl , Christian Borntraeger , Avi Kivity On Wed, Jun 10, 2009 at 04:24:28PM +0100, 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. > > Paul Why shouldn't it? You don't load a snapshot while guest is running. -- MST