qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [Qemu-devel] [PATCH 2/5] virtio-blk: disable scsi passt


From: Michael S. Tsirkin
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH 2/5] virtio-blk: disable scsi passthrough for 1.0 device
Date: Wed, 15 Jul 2015 15:01:01 +0300

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" <address@hidden> 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.

> > 
> > 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?
Fine, but revision is negotiated way before features are
probed so why does it make a practical difference?

-- 
MST



reply via email to

[Prev in Thread] Current Thread [Next in Thread]