From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:54066)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1Qf9XL-0002ZN-IL
	for qemu-devel@nongnu.org; Fri, 08 Jul 2011 07:48:01 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1Qf9XK-0007og-Al
	for qemu-devel@nongnu.org; Fri, 08 Jul 2011 07:47:59 -0400
Received: from mx1.redhat.com ([209.132.183.28]:25600)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1Qf9XJ-0007oR-PU
	for qemu-devel@nongnu.org; Fri, 08 Jul 2011 07:47:58 -0400
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p68Blufw010227
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <qemu-devel@nongnu.org>; Fri, 8 Jul 2011 07:47:56 -0400
Message-ID: <4E16EE6A.6000506@redhat.com>
Date: Fri, 08 Jul 2011 13:47:54 +0200
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
References: <1310115239-19288-1-git-send-email-kraxel@redhat.com>
	<4E16D3D8.60908@redhat.com> <4E16D4EF.5020903@redhat.com>
	<4E16D949.2060305@redhat.com>
In-Reply-To: <4E16D949.2060305@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 0/3] non-migratable devices
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel@nongnu.org

   Hi,

> scsi-cd is new in 0.15, older versions have scsi-disk only. That's why
> we should take the occasion to add the empty vmstate at least to it.

Ok, good opportunity in that specific case.

> For other devices, it's better to make the breakage in a single version.
> It also allows to make 0.15 the "flag day" where each device shall have
> a VMState or the entire VM will not be migratable.

Not that easy given that we didn't fully migrate to vmstate yet, 
otherwise we could simply fail migration in case we find any device with 
qdev->vmsd == NULL.

> If desired, in the
> future we can revert this behavior for pc-0.14 and earlier machines.

And I'm still looking for a sane way to handle *this*.

cheers,
   Gerd