On Wed, Jul 15, 2015 at 03:40:22PM +0200, Cornelia Huck wrote: > On Wed, 15 Jul 2015 16:16:07 +0300 > "Michael S. Tsirkin" <m...@redhat.com> wrote: > > > On Wed, Jul 15, 2015 at 02:43:51PM +0200, Cornelia Huck wrote: > > > On Wed, 15 Jul 2015 15:01:01 +0300 > > > "Michael S. Tsirkin" <m...@redhat.com> wrote: > > > > > > > On Wed, Jul 15, 2015 at 01:46:38PM +0200, Cornelia Huck wrote: > > > > > On Wed, 15 Jul 2015 13:59:00 +0300 > > > > > "Michael S. Tsirkin" <m...@redhat.com> wrote: > > > > > > > > > > > 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 don't think one should be a strict subset of the other. But I think > > > > > we don't want to withdraw features from legacy guests on qemu updates > > > > > either? > > > > > > > > Absolutely. For now one has to enable the modern interface > > > > explicitly. Around 2.5 we might switch that around, we'll > > > > need to think hard about compatibility at that point. > > > > In any case, we must definitely keep the old capability for old machine > > > > types. > > > > > > ccw only offers revision 0 (legacy) in 2.4. I plan to introduce > > > revision 1 in 2.5 and force revision to 0 for 2.4 compatibility (as 2.4 > > > is the first versioned ccw machine). > > > > I was talking about pci here actually. > > Sure, and these are my plans for ccw ;) > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > I'm not opposing this :) > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > This seems to boil down to the different meaning of "transitional" for > > > > > ccw and pci, see the other thread. > > > > > > > > Before the revision is negotiated, ccw won't know whether > > > > it's a legacy driver - is that the difference? > > > > > > I'd say it doesn't know whether the driver intends to use the modern > > > interface. > > > > That's also the case for pci. > > But does pci know the moment it first tries to get the device's > features? And does pci assume modern as default for transitional > devices?
I don't think it does. > > > > > > 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. -- MST
