From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NCdeC-0000FU-Am
	for qemu-devel@nongnu.org; Mon, 23 Nov 2009 13:28:24 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NCde8-0000Ax-R7
	for qemu-devel@nongnu.org; Mon, 23 Nov 2009 13:28:24 -0500
Received: from [199.232.76.173] (port=47855 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NCde8-0000Ap-NJ
	for qemu-devel@nongnu.org; Mon, 23 Nov 2009 13:28:20 -0500
Received: from mail-qy0-f194.google.com ([209.85.221.194]:50423)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1NCde8-0001WU-BE
	for qemu-devel@nongnu.org; Mon, 23 Nov 2009 13:28:20 -0500
Received: by qyk32 with SMTP id 32so2666846qyk.4
	for <qemu-devel@nongnu.org>; Mon, 23 Nov 2009 10:28:19 -0800 (PST)
Message-ID: <4B0AD440.1020800@codemonkey.ws>
Date: Mon, 23 Nov 2009 12:28:16 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Re: Live migration protocol, device features, ABIs
	and other beasts
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>
	<4B0A87B2.1030507@codemonkey.ws> <m3vdh1wd0n.fsf@neno.neno>
	<4B0AA0F3.6070205@codemonkey.ws>
	<1258988836-sup-800@blackpad.lan.raisama.net>
	<4B0AB567.8030400@codemonkey.ws>
	<1258993500-sup-5592@blackpad.lan.raisama.net>
In-Reply-To: <1258993500-sup-5592@blackpad.lan.raisama.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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: Eduardo Habkost <ehabkost@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Juan Quintela <quintela@trasno.org>, Gleb Natapov <gleb@redhat.com>, qemu-devel <qemu-devel@nongnu.org>

Eduardo Habkost wrote:
> That may be good enough for upstream Qemu, but IMO for RHEL it is not a
> realistic policy. If the definition of "guest visible state" is buggy on
> the current implementation, we can't drop entirely the possibility of
> fixing it on our stable branch.
>   

After mulling over it a bit, here's what I'd suggest:

1) Integrate VMstate with qdev
2) Introduce a bitmap blacklist for unsupported VMstate versions
3) Expose that bitmap as a qdev property for each device.
4) By default, upstream qemu will always set the bitmap to be 100% correct.

This provides a mechanism for informed users and downstreams to reduce 
correctness in favor of migration compatibility on a case-by-case basis.

This takes qemu out of the business of creating these sort of policies 
but allows RHEL to make decisions about what default policy it uses.  It 
also lets well informed users of RHEL to override those policy decisions 
when they deem it to be appropriate.

This would make me happy both from an upstream qemu perspective but also 
as a consumer of RHEL.

Regards,

Anthony Liguori