From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MESBo-0002so-C2 for qemu-devel@nongnu.org; Wed, 10 Jun 2009 14:06:20 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MESBj-0002rO-Ex for qemu-devel@nongnu.org; Wed, 10 Jun 2009 14:06:19 -0400 Received: from [199.232.76.173] (port=59033 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MESBj-0002rJ-6G for qemu-devel@nongnu.org; Wed, 10 Jun 2009 14:06:15 -0400 Received: from mx2.redhat.com ([66.187.237.31]:46797) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MESBi-0005uV-Jl for qemu-devel@nongnu.org; Wed, 10 Jun 2009 14:06:14 -0400 Date: Wed, 10 Jun 2009 20:03:06 +0300 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] [PATCH 05/11] qemu: MSI-X support functions Message-ID: <20090610170306.GL28601@redhat.com> References: <200906101708.27815.paul@codesourcery.com> <20090610162644.GJ28601@redhat.com> <200906101746.06740.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200906101746.06740.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, Rusty Russell , qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org, Blue Swirl , Christian Borntraeger , Avi Kivity On Wed, Jun 10, 2009 at 05:46:03PM +0100, Paul Brook wrote: > > > If you can't create an identical machine from scratch then I don't > > > consider snapshot/migration to be a useful feature. i.e. as soon as you > > > shutdown and restart the guest it is liable to break anyway. > > > > Why is liable to break? > > A VM booted on an old version of qemu and migrated to a new version will > behave differently to a the same VM booted on a new version of qemu. It will behave identically. That's what the patch does: discover how did the device behave on old qemu, and make it behave the same way on new qemu. > I hope I don't need to explain why this is bad. > > As previously discussed, any guest visible changes are liable to break a guest > OS, particularly guests like Windows which deliberately break when run on > "different" hardware. Personally I don't particularly care, but if we support > live migration we also need to support "cold" migration - i.e. shutdown and > restart. > > >So once you load and image with MSIX capability off, > >it will stay off across guest restarts. > > I'm assuming guest restart includes restarting qemu. > > Paul If you restart qemu, and load an image, what we should do is look at the image and behave in a way consistent with how the qemu that created the image behaved. If you load an image, you switch to a VM, and should be consistent with the VM you just loaded. And we do not need a flag or a machine description file to tell us this. -- MST