From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33581) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZEfQM-00074p-4k for qemu-devel@nongnu.org; Mon, 13 Jul 2015 11:13:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZEfQL-0000KK-5T for qemu-devel@nongnu.org; Mon, 13 Jul 2015 11:13:42 -0400 References: <1436766411-29144-1-git-send-email-jasowang@redhat.com> <1436766411-29144-2-git-send-email-jasowang@redhat.com> <20150713104051-mutt-send-email-mst@redhat.com> <55A37E43.6060403@redhat.com> <20150713095651.GA5893@noname.redhat.com> <20150713135156.0d32ef1e.cornelia.huck@de.ibm.com> <20150713151705-mutt-send-email-mst@redhat.com> <20150713143024.3b102b9c.cornelia.huck@de.ibm.com> <20150713153319-mutt-send-email-mst@redhat.com> <20150713152059.69b373ee.cornelia.huck@de.ibm.com> <55A3CC76.3040107@redhat.com> <20150713164129.52a8a2ed.cornelia.huck@de.ibm.com> From: Paolo Bonzini Message-ID: <55A3D596.9060401@redhat.com> Date: Mon, 13 Jul 2015 17:13:26 +0200 MIME-Version: 1.0 In-Reply-To: <20150713164129.52a8a2ed.cornelia.huck@de.ibm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/5] virtio-blk: disable scsi passthrough for 1.0 device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Cornelia Huck Cc: Kevin Wolf , qemu-block@nongnu.org, "Michael S. Tsirkin" , Jason Wang , qemu-devel@nongnu.org, Stefan Hajnoczi On 13/07/2015 16:41, Cornelia Huck wrote: > On Mon, 13 Jul 2015 16:34:30 +0200 > Paolo Bonzini wrote: >> On 13/07/2015 15:20, Cornelia Huck wrote: >>> This would imply that any transitional device cannot offer scsi, >>> doesn't it? >>> >>> We have two layers interacting here: virtio-blk which may or may not >>> offer scsi support, and the transport layer which may or may not offer >>> VERSION_1 support. Failing scsi commands if VERSION_1 has been >>> negotiated makes sense to me; but I don't want to disable scsi config a >>> priori because the driver might negotiate VERSION_1. This would imply >>> that virtio-blk over virtio-ccw would never offer scsi once we enable >>> virtio-1 support, and it kind of defeats the purpose of a transitional >>> device for me. >>> >>> (The other way round - fail negotiating revison 1 if the device was >>> configured with scsi support - makes more sense to me.) >> >> For newer machine types, it would make sense to block VIRTIO_BLK_F_SCSI >> altogether if !blk->conf.scsi. Would that fix the problem for you too? > > This is probably a sensible approach, and it can be contained in > virtio-block, no? Yes, I think so. Paolo