From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38977) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4xzR-0001h0-KR for qemu-devel@nongnu.org; Tue, 06 Mar 2012 12:16:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S4xz2-0001Ix-0U for qemu-devel@nongnu.org; Tue, 06 Mar 2012 12:15:57 -0500 Received: from mail-pw0-f45.google.com ([209.85.160.45]:33189) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4xz1-0001Iq-QG for qemu-devel@nongnu.org; Tue, 06 Mar 2012 12:15:31 -0500 Received: by pbcuo5 with SMTP id uo5so6010915pbc.4 for ; Tue, 06 Mar 2012 09:15:30 -0800 (PST) Message-ID: <4F56462E.6010003@codemonkey.ws> Date: Tue, 06 Mar 2012 11:15:26 -0600 From: Anthony Liguori 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> <4F56457E.9010205@redhat.com> In-Reply-To: <4F56457E.9010205@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Paolo Bonzini Cc: mst@redhat.com, uobergfe@redhat.com, qemu-devel@nongnu.org, armbru@redhat.com, owasserm@redhat.com, amit.shah@redhat.com On 03/06/2012 11:12 AM, Paolo Bonzini wrote: > 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. Okay, that makes more sense to me. I think this is an exceptional circumstance so handling it as a one-off verses a generic mechanism would be preferred. Regards, Anthony Liguori > > Paolo