From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56640) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFKP9-0005Ep-3N for qemu-devel@nongnu.org; Wed, 15 Jul 2015 06:59:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZFKP8-0007q4-7j for qemu-devel@nongnu.org; Wed, 15 Jul 2015 06:59:11 -0400 Date: Wed, 15 Jul 2015 13:59:00 +0300 From: "Michael S. Tsirkin" Message-ID: <20150715135237-mutt-send-email-mst@redhat.com> References: <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> <20150713182901-mutt-send-email-mst@redhat.com> <20150714194344.529a6ea4.cornelia.huck@de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150714194344.529a6ea4.cornelia.huck@de.ibm.com> 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, Jason Wang , qemu-devel@nongnu.org, Stefan Hajnoczi , pbonzini@redhat.com On Tue, Jul 14, 2015 at 07:43:44PM +0200, Cornelia Huck wrote: > > Yes, and that's because as written, transitional devices must set > > ANY_LAYOUT, but that's incompatible with scsi. > > Hm, I had a patch before that dynamically allowed different feature > sets for legacy or modern, not only a subset. Probably won't apply > anymore, but I'd like to able to do the following: > > - driver reads features without negotiating a revision: driver is > legacy, offer legacy bits > - driver negotiates revision 0: dito > - driver negotiates revision >= 1: driver is modern, offer modern bits > > That way we could offer SCSI and !ANY_LAYOUT (if scsi is enabled) in the > first two cases, and a new qemu could still offer scsi to old guests. > > Would it be worth pursuing that idea? Frankly, I don't think so: I don't see why it makes sense to expose more features on the legacy interface than on the modern one. Imagine updating drivers to fix a bug and losing some features. How does this make sense? I think the virtio TC's assumption was that the scsi passthrough was a bad idea, so in QEMU we only keep it around for legacy devices to avoid regressions. If you disagree and think transitional devices need the SCSI feature, either try to convince pbonzini or rewrite the spec youself to support it in the virtio 1 mode. -- MST