From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NCvUE-0001H4-UD
	for qemu-devel@nongnu.org; Tue, 24 Nov 2009 08:31:19 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NCvU8-0001Ep-9Z
	for qemu-devel@nongnu.org; Tue, 24 Nov 2009 08:31:16 -0500
Received: from [199.232.76.173] (port=54533 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NCvU6-0001EZ-MF
	for qemu-devel@nongnu.org; Tue, 24 Nov 2009 08:31:10 -0500
Received: from mx1.redhat.com ([209.132.183.28]:35606)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <mst@redhat.com>) id 1NCvU6-0006Dh-6I
	for qemu-devel@nongnu.org; Tue, 24 Nov 2009 08:31:10 -0500
Date: Tue, 24 Nov 2009 15:28:32 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
Message-ID: <20091124132832.GF2405@redhat.com>
References: <4B0952C9.9010803@redhat.com> <4B095D86.700@codemonkey.ws>
	<hec6i6$j3r$1@ger.gmane.org> <4B09F0CA.3060705@codemonkey.ws>
	<20091123082659.GC2999@redhat.com> <m3iqd14edf.fsf@neno.neno>
	<20091123123640.GL2999@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20091123123640.GL2999@redhat.com>
Subject: [Qemu-devel] Re: Live migration protocol, device features,
	ABIs and other beasts
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Gleb Natapov <gleb@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Juan Quintela <quintela@trasno.org>, qemu-devel@nongnu.org

On Mon, Nov 23, 2009 at 02:36:40PM +0200, Gleb Natapov wrote:
> > My problem implementing optional features/sections/... is not the
> > savevm/VMState bits.  At the end, implementing that is easy.  What is
> > more dificult is once that a device have 5 features, what are the valid
> > combinations.  i.e. if you have pci and msix features, msix requires
> > pci.  In this case, the dependency is trivial, but in others that
> > hasen't to be so obvious.
> It doesn't matter what device support and how it is configured. This can
> be handled by each device separately. i.e if destination detects that
> source had MSIX enabled for the device but destination hasn't it will
> signal an error.

Yes, this can't work.
But the reverse can: if source does not have MSIX capability
and destination does have it, you can remove MSIX in destination
and make user happy.
One way to do this would be to use the same machine desription
on both sides.

-- 
MST