From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38048) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFNqJ-0004Tz-Uc for qemu-devel@nongnu.org; Wed, 15 Jul 2015 10:39:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZFNqI-0003sX-TK for qemu-devel@nongnu.org; Wed, 15 Jul 2015 10:39:27 -0400 Date: Wed, 15 Jul 2015 17:39:18 +0300 From: "Michael S. Tsirkin" Message-ID: <20150715173508-mutt-send-email-mst@redhat.com> References: <20150713182901-mutt-send-email-mst@redhat.com> <20150714194344.529a6ea4.cornelia.huck@de.ibm.com> <20150715135237-mutt-send-email-mst@redhat.com> <20150715134638.065bbd03.cornelia.huck@de.ibm.com> <20150715145257-mutt-send-email-mst@redhat.com> <20150715144351.39348922.cornelia.huck@de.ibm.com> <20150715160821-mutt-send-email-mst@redhat.com> <20150715154022.0d388aae.cornelia.huck@de.ibm.com> <20150715170944-mutt-send-email-mst@redhat.com> <20150715163051.354798d6.cornelia.huck@de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150715163051.354798d6.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 Wed, Jul 15, 2015 at 04:30:51PM +0200, Cornelia Huck wrote: > On Wed, 15 Jul 2015 17:11:57 +0300 > "Michael S. Tsirkin" wrote: > > > > > > > Fine, but revision is negotiated way before features are > > > > > > probed so why does it make a practical difference? > > > > > > > > > > Legacy drivers (that don't know about the set-revision command) will > > > > > read features without revision negotiation - we need to offer them the > > > > > legacy feature set. > > > > > > > > Right. So simply do if (revision < 1) return features & 0xffffffff > > > > and that will do this, will it not? > > > > > > Not for bits that we want to offer for legacy but not for modern. > > > > I don't think this selective offering works at least for scsi. > > scsi is a backend feature, if you connect a modern device > > in front the device simply does not work. > > It therefore makes no sense to attach a transitional device > > to such a backend. > > My point is that we're losing legacy features with that approach, and > it would not be possible to offer them to legacy guests with newer > qemus (at least with ccw). What's wrong with adding a disable-modern flag, like pci has? User can set that to get a legacy device. > What about the other way around (i.e. scsi is configured, therefore the > device is legacy-only)? We'd only retain the scsi bit if it is actually > wanted by the user's configuration. I would need to enforce a max > revision of 0 for such a device in ccw, and pci could disable modern > for it. Will have to think about it. But I think a flag to disable/enable modern is useful in any case, and it seems sufficient. -- MST