qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Halil Pasic <pasic@linux.ibm.com>
Cc: qemu-s390x@nongnu.org,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Thomas Huth <thuth@redhat.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [PATCH] virtio-ccw: commands on revision-less devices
Date: Tue, 16 Feb 2021 16:54:05 +0100	[thread overview]
Message-ID: <20210216165405.57599fe8.cohuck@redhat.com> (raw)
In-Reply-To: <20210216151945.736eb6c7.pasic@linux.ibm.com>

On Tue, 16 Feb 2021 15:19:45 +0100
Halil Pasic <pasic@linux.ibm.com> wrote:

> On Tue, 16 Feb 2021 12:18:30 +0100
> Cornelia Huck <cohuck@redhat.com> wrote:
> 
> > The virtio standard specifies that any non-transitional device must
> > reject commands prior to revision setting (which we do) and else
> > assume revision 0 (legacy) if the driver sends a non-revision-setting
> > command first. We neglected to do the latter.  
> 
> Huh, I my opinion, it ain't very clear what is specified by the virtio
> standard (which starts with version 1.0) for the described situation.
> 
> The corresponding device normative section (4.3.2.1.1 Device
> Requirements: Setting the Virtio Revision) says that: "A device MUST
> treat the revision as unset from the time the associated subchannel has
> been enabled until a revision has been successfully set by the driver.
> This implies that revisions are not persistent across disabling and
> enabling of the associated subchannel.". It doesn't say anything more
> about the situation where the first command is not SET_VIRTIO_REV.
> 
> The section "4.3.2.1.3 Legacy Interfaces: A Note on Setting the Virtio
> Revision" which is to my best knowledge not normative, as none of the
> legacy-interface stuff is normative, but a mere advice on how to deal
> with legacy then says: "A legacy driver will not issue the
> CCW_CMD_SET_VIRTIO_REV prior to issuing other virtio-ccw specific
> channel commands." ... "A transitional device MUST assume
> in this case that the driver is a legacy driver and continue as if the
> driver selected revision 0. This implies that the device MUST reject any
> command not valid for revision 0, including a subsequent
> CCW_CMD_SET_VIRTIO_REV."
> 
> Do we agree that the legacy interface sections in general, and 4.3.2.1.3
> in particular is non-normative?

IMHO, normative and non-normative are not something that applies to the
legacy sections. The legacy sections are supposed to give guidance on
how to write transitional devices/drivers that can deal with legacy
implementations. If you want to write something that strictly only
adheres to normative statements, you have to write a non-transitional
device/driver. Legacy support was never an official standard, so
'normative' is meaningless in that context.

> 
> In my opinion the normative 'must threat as unset until set by driver'
> and 'if first cmd is not _REV, must continue as if the driver selected
> revision 0' is in a slight collision.

I don't think there's a collision. If we want to accommodate legacy
drivers, we have to deal with their lack of revision handling, and
therefore treat non-_REV commands as implicitly selecting revision 0.

If we want to implement a non-transitional device, the implicit
selection of revision 0 goes away, of course. In fact, I'm currently
trying to make legacy support optional for virtio-ccw, so that's why I
had been looking at the revision handling :)

> 
> 
> > 
> > Fortunately, nearly everything worked as intended anyway; the only
> > problem was not properly rejecting revision setting after some other
> > command had been issued. Easy to fix by setting revision to 0 if
> > we see a non-revision command on a legacy-capable revision-less
> > device.
> > 
> > Signed-off-by: Cornelia Huck <cohuck@redhat.com>  
> 
> The change won't hurt so with a toned down commit message:
> Acked-by: Halil Pasic <pasic@linux.ibm.com>

Replace 'and else' with 'a transitional device needs to'?

> 
> > ---
> >  hw/s390x/virtio-ccw.c | 21 ++++++++++++++-------
> >  1 file changed, 14 insertions(+), 7 deletions(-)
> > 
> > diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
> > index 4582e94ae7dc..06c06056814b 100644
> > --- a/hw/s390x/virtio-ccw.c
> > +++ b/hw/s390x/virtio-ccw.c
> > @@ -327,13 +327,20 @@ static int virtio_ccw_cb(SubchDev *sch, CCW1 ccw)
> >                                     ccw.cmd_code);
> >      check_len = !((ccw.flags & CCW_FLAG_SLI) && !(ccw.flags & CCW_FLAG_DC));
> >  
> > -    if (dev->force_revision_1 && dev->revision < 0 &&
> > -        ccw.cmd_code != CCW_CMD_SET_VIRTIO_REV) {
> > -        /*
> > -         * virtio-1 drivers must start with negotiating to a revision >= 1,
> > -         * so post a command reject for all other commands
> > -         */
> > -        return -ENOSYS;
> > +    if (dev->revision < 0 && ccw.cmd_code != CCW_CMD_SET_VIRTIO_REV) {
> > +        if (dev->force_revision_1) {
> > +            /*
> > +             * virtio-1 drivers must start with negotiating to a revision >= 1,
> > +             * so post a command reject for all other commands
> > +             */
> > +            return -ENOSYS;
> > +        } else {
> > +            /*
> > +             * If the driver issues any command that is not SET_VIRTIO_REV,
> > +             * we'll have to operate the device in legacy mode.
> > +             */
> > +            dev->revision = 0;
> > +        }
> >      }
> >  
> >      /* Look at the command. */  
> 



  reply	other threads:[~2021-02-16 15:56 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-16 11:18 [PATCH] virtio-ccw: commands on revision-less devices Cornelia Huck
2021-02-16 11:33 ` Thomas Huth
2021-02-16 11:40 ` Michael S. Tsirkin
2021-02-16 11:51   ` Cornelia Huck
2021-02-16 11:58     ` Michael S. Tsirkin
2021-02-16 14:19 ` Halil Pasic
2021-02-16 15:54   ` Cornelia Huck [this message]
2021-02-17 14:39     ` Halil Pasic
2021-02-18 13:51       ` Cornelia Huck
2021-02-18 18:51         ` Halil Pasic
2021-02-19 11:21 ` Cornelia Huck
2021-02-19 17:01   ` Cornelia Huck
2021-02-21 11:48   ` Michael S. Tsirkin

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=20210216165405.57599fe8.cohuck@redhat.com \
    --to=cohuck@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=mst@redhat.com \
    --cc=pasic@linux.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=thuth@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).