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" <m...@redhat.com> 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
