From: "Michael S. Tsirkin" <mst@redhat.com>
To: Cornelia Huck <cornelia.huck@de.ibm.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
qemu-block@nongnu.org, Jason Wang <jasowang@redhat.com>,
qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>,
pbonzini@redhat.com
Subject: Re: [Qemu-devel] [PATCH 2/5] virtio-blk: disable scsi passthrough for 1.0 device
Date: Wed, 15 Jul 2015 15:01:01 +0300 [thread overview]
Message-ID: <20150715145257-mutt-send-email-mst@redhat.com> (raw)
In-Reply-To: <20150715134638.065bbd03.cornelia.huck@de.ibm.com>
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" <mst@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.
> >
> > 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
next prev parent reply other threads:[~2015-07-15 12:01 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-13 5:46 [Qemu-devel] [PATCH 1/5] virtio-pci: ignore unaligned read/write in virtio_address_space_read()/write() Jason Wang
2015-07-13 5:46 ` [Qemu-devel] [PATCH 2/5] virtio-blk: disable scsi passthrough for 1.0 device Jason Wang
2015-07-13 7:46 ` Michael S. Tsirkin
2015-07-13 9:00 ` Jason Wang
2015-07-13 9:56 ` Kevin Wolf
2015-07-13 11:51 ` Cornelia Huck
2015-07-13 12:22 ` Michael S. Tsirkin
2015-07-13 12:30 ` Cornelia Huck
2015-07-13 12:36 ` Michael S. Tsirkin
2015-07-13 13:20 ` Cornelia Huck
2015-07-13 14:34 ` Paolo Bonzini
2015-07-13 14:41 ` Cornelia Huck
2015-07-13 15:13 ` Paolo Bonzini
2015-07-13 15:35 ` Michael S. Tsirkin
2015-07-14 17:43 ` Cornelia Huck
2015-07-15 10:59 ` Michael S. Tsirkin
2015-07-15 11:46 ` Cornelia Huck
2015-07-15 12:01 ` Michael S. Tsirkin [this message]
2015-07-15 12:43 ` Cornelia Huck
2015-07-15 13:16 ` Michael S. Tsirkin
2015-07-15 13:40 ` Cornelia Huck
2015-07-15 14:11 ` Michael S. Tsirkin
2015-07-15 14:30 ` Cornelia Huck
2015-07-15 14:39 ` Michael S. Tsirkin
2015-07-15 15:38 ` Cornelia Huck
2015-07-15 18:51 ` Michael S. Tsirkin
2015-07-16 12:37 ` Cornelia Huck
2015-07-16 12:47 ` Michael S. Tsirkin
2015-07-16 17:22 ` Paolo Bonzini
2015-07-17 7:18 ` Cornelia Huck
2015-07-13 11:27 ` Michael S. Tsirkin
2015-07-13 5:46 ` [Qemu-devel] [PATCH 3/5] virtio-blk: set VIRTIO_F_ANY_LAYOUT when 1.0 is supported Jason Wang
2015-07-13 5:46 ` [Qemu-devel] [PATCH 4/5] Revert "virtio-net: enable virtio 1.0" Jason Wang
2015-07-13 6:16 ` Cornelia Huck
2015-07-13 7:22 ` Michael S. Tsirkin
2015-07-13 8:46 ` Cornelia Huck
2015-07-13 8:29 ` Jason Wang
2015-07-13 5:46 ` [Qemu-devel] [PATCH 5/5] virtio-net: unbreak any layout Jason Wang
2015-07-13 6:50 ` Paolo Bonzini
2015-07-13 8:30 ` Jason Wang
2015-07-13 7:24 ` Michael S. Tsirkin
2015-07-13 8:22 ` Michael S. Tsirkin
2015-07-13 10:54 ` Greg Kurz
2015-07-13 11:13 ` Michael S. Tsirkin
2015-07-13 8:30 ` Jason Wang
2015-07-13 7:36 ` [Qemu-devel] [PATCH 1/5] virtio-pci: ignore unaligned read/write in virtio_address_space_read()/write() Michael S. Tsirkin
2015-07-13 7:53 ` Gerd Hoffmann
2015-07-13 8:00 ` Michael S. Tsirkin
2015-07-13 8:39 ` Gerd Hoffmann
2015-07-13 8:37 ` Jason Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150715145257-mutt-send-email-mst@redhat.com \
--to=mst@redhat.com \
--cc=cornelia.huck@de.ibm.com \
--cc=jasowang@redhat.com \
--cc=kwolf@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).