From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:59617)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1S4wmb-0004QP-7j
	for qemu-devel@nongnu.org; Tue, 06 Mar 2012 10:58:41 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1S4wmV-00077x-2v
	for qemu-devel@nongnu.org; Tue, 06 Mar 2012 10:58:36 -0500
Received: from mx1.redhat.com ([209.132.183.28]:48548)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1S4wmU-00077h-R7
	for qemu-devel@nongnu.org; Tue, 06 Mar 2012 10:58:31 -0500
Received: from int-mx01.intmail.prod.int.phx2.redhat.com
	(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q26FwTX9029024
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <qemu-devel@nongnu.org>; Tue, 6 Mar 2012 10:58:29 -0500
Message-ID: <4F563422.8010401@redhat.com>
Date: Tue, 06 Mar 2012 16:58:26 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <1331036527-7651-1-git-send-email-pbonzini@redhat.com>
	<1331036527-7651-4-git-send-email-pbonzini@redhat.com>
	<20120306145319.GE12096@redhat.com>
In-Reply-To: <20120306145319.GE12096@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 3/3] virtio-blk: note optional features
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: "Michael S. Tsirkin" <mst@redhat.com>
Cc: amit.shah@redhat.com, uobergfe@redhat.com, owasserm@redhat.com, qemu-devel@nongnu.org, armbru@redhat.com

Il 06/03/2012 15:53, Michael S. Tsirkin ha scritto:
> > The guest must already be prepared to see SG_IO support
> > disappear from under its feet, for example if migration
> > refers to a block device on the source and file-based
> > storage on the destination; or more likely, if the source
> > kernel allows (gasp) SG_IO on a partition and the destination
> > does not.  So, we can migrate safely even if the source
> > had VIRTIO_BLK_F_SCSI and the destination does not.
> > 
> > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> 
> My first reaction is you want a new non guest
> visible flag to control whether SG_IO fails on host.
> guest visible ones must be consistent across migration.

So scsi=off/on would control VIRTIO_BLK_F_SCSI, while the new flag would
cause requests to fail.  Then it's simpler to do the other way round.
Make the "new non guest-visible flag" be scsi=on/off and set
VIRTIO_BLK_F_SCSI unconditionally as you suggested first.

Paolo