From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41234) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4xwc-00083n-1L for qemu-devel@nongnu.org; Tue, 06 Mar 2012 12:13:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S4xwD-0000LA-3c for qemu-devel@nongnu.org; Tue, 06 Mar 2012 12:13:01 -0500 Received: from mx1.redhat.com ([209.132.183.28]:18787) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4xwC-0000Ko-Rn for qemu-devel@nongnu.org; Tue, 06 Mar 2012 12:12:37 -0500 Message-ID: <4F56457E.9010205@redhat.com> Date: Tue, 06 Mar 2012 18:12:30 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1331036527-7651-1-git-send-email-pbonzini@redhat.com> <1331036527-7651-4-git-send-email-pbonzini@redhat.com> <4F564365.2000009@codemonkey.ws> In-Reply-To: <4F564365.2000009@codemonkey.ws> 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: mst@redhat.com, uobergfe@redhat.com, qemu-devel@nongnu.org, armbru@redhat.com, owasserm@redhat.com, amit.shah@redhat.com Il 06/03/2012 18:03, Anthony Liguori ha scritto: > I don't know how comfortable I feel about this. > > You can't just remove a feature in flight. The guest is going to behave > differently in such a way that the host isn't expecting. Yes, it should > fail gracefully, but nonetheless it will fail. > > Aren't you just delaying the inevitable? Instead of having migration > fail, the guest workload is going to fail. How is this an improvement? VIRTIO_BLK_F_SCSI feature was almost never used but was always marked as available. Because of possible security problems connected to it, libvirt started making it an opt-in feature. In practice, you need to configure your host specially if you want to use SCSI passthrough (e.g. you must not use labels and UUIDs in your /etc/fstab), so it's safe to assume that guests that have SG_IO disabled under their feet will keep working. That said, instead of this hack we can just decouple scsi=on/off from VIRTIO_BLK_F_SCSI, and just report the feature. After all we do not clear VIRTIO_BLK_F_SCSI just because the device is backed by a file or partition, yet SG_IO is still unavailable in those cases. I'll send patches for this tomorrow. Paolo