From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45466) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZHx62-0006cU-Cc for qemu-devel@nongnu.org; Wed, 22 Jul 2015 12:42:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZHx5w-0003o0-BK for qemu-devel@nongnu.org; Wed, 22 Jul 2015 12:42:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49459) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZHx5w-0003nB-5c for qemu-devel@nongnu.org; Wed, 22 Jul 2015 12:42:12 -0400 References: <1437544792-3949-1-git-send-email-jasowang@redhat.com> <1437544792-3949-3-git-send-email-jasowang@redhat.com> <20150722093145.GD12010@redhat.com> <20150722131342-mutt-send-email-mst@redhat.com> <55AF8129.50105@redhat.com> <20150722175640-mutt-send-email-mst@redhat.com> From: Paolo Bonzini Message-ID: <55AFC7DF.2040704@redhat.com> Date: Wed, 22 Jul 2015 18:42:07 +0200 MIME-Version: 1.0 In-Reply-To: <20150722175640-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH V3 2/3] virtio-blk: fail get_features when both scsi and 1.0 were set List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: cornelia.huck@de.ibm.com, Jason Wang , qemu-devel@nongnu.org On 22/07/2015 18:15, Michael S. Tsirkin wrote: > > No, the feature is not desirable in the future. There is no reason > > really not to use virtio-scsi passthrough instead, since virtio-scsi = has > > been out for about 3 years now and is stable. >=20 > Given the amount of work we are spending handling this corner case, > I'm beginning to think we should just bring it back in. Please don't. Perhaps it made sense when Rusty was thinking of virtio-blk as simply "struct request over virtio", but I'm not even sure what the use case is. For virtio-scsi, for example, one reason to use passthrough is that you can use the same /dev/disk/by-id path on physical and virtual machines. But that doesn't work with virtio-blk's pseudo passthrough. Another is to pass "weird" devices (tapes, media changers, etc.) to backup appliances, but that also doesn't work with virtio-blk. So what is it used for? That's what is needed to make an informed decisi= on. > > In addition, the implementation would either not be compatible with > > virtio 0.9, or would be different from everything else in the spec > > because it requires a particular framing for the buffers. >=20 > Of course we'll need some kind of change to avoid depending on framing > of buffers, but how hard is it? Just stick the header size > somewhere in the buffer or in the config space. >=20 > Not compatible is probably not the right term to use here, > since when using the legacy interface we can make the old > framing assumption. Not compatible in the sense that it requires work in the drivers too (unlike e.g. CONFIG_WCE, where the old code just works with the proposed modifications to 1.0). Paolo