qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com>
Cc: Halil Pasic <pasic@linux.vnet.ibm.com>,
	Pierre Morel <pmorel@linux.vnet.ibm.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v2 3/4] virtio-ccw: use ccw data stream
Date: Tue, 19 Sep 2017 11:06:31 +0200	[thread overview]
Message-ID: <20170919110631.59039743.cohuck@redhat.com> (raw)
In-Reply-To: <20170919033730.GD5274@bjsdjshi@linux.vnet.ibm.com>

On Tue, 19 Sep 2017 11:37:30 +0800
Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> wrote:

> * Halil Pasic <pasic@linux.vnet.ibm.com> [2017-09-13 13:50:28 +0200]:
> 
> > Replace direct access which implicitly assumes no IDA
> > or MIDA with the new ccw data stream interface which should
> > cope with these transparently in the future.
> > 
> > Signed-off-by: Halil Pasic <pasic@linux.vnet.ibm.com>
> > 
> > ---
> > 
> > v1 --> v2:
> > Removed todo comments on possible errno change as with
> > https://lists.nongnu.org/archive/html/qemu-devel/2017-09/msg02441.html
> > applied it does not matter any more.
> > 
> > Error handling: At the moment we ignore errors reported
> > by stream ops to keep the change minimal. An add-on
> > patch improving on this is to be expected later.  
> Add a TODO somewhere around the code as a reminder?

I expect Halil to have it on his TODO list and send a patch later ;)

> 
> > ---
> >  hw/s390x/virtio-ccw.c | 156 +++++++++++++++-----------------------------------
> >  1 file changed, 46 insertions(+), 110 deletions(-)
> > 
> > diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
> > index b1976fdd19..a9baf6f7ab 100644
> > --- a/hw/s390x/virtio-ccw.c
> > +++ b/hw/s390x/virtio-ccw.c  
> [...]
> 
> > @@ -394,11 +362,8 @@ static int virtio_ccw_cb(SubchDev *sch, CCW1 ccw)
> >          } else {
> >              VirtioDeviceClass *vdc = VIRTIO_DEVICE_GET_CLASS(vdev);
> > 
> > -            features.index = address_space_ldub(&address_space_memory,
> > -                                                ccw.cda
> > -                                                + sizeof(features.features),
> > -                                                MEMTXATTRS_UNSPECIFIED,
> > -                                                NULL);
> > +            ccw_dstream_advance(&sch->cds, sizeof(features.features));  
> How about:
> ccw_dstream_advance(&sch->cds, offsetof(VirtioFeatDesc, index));

I think keeping sizeof(features.features) is better: It matches the old
code, and we really do jump over the features flag and revisit it
later...

> 
> > +            ccw_dstream_read(&sch->cds, features.index);
> >              if (features.index == 0) {
> >                  if (dev->revision >= 1) {
> >                      /* Don't offer legacy features for modern devices. */
> > @@ -417,9 +382,9 @@ static int virtio_ccw_cb(SubchDev *sch, CCW1 ccw)
> >                  /* Return zeroes if the guest supports more feature bits. */
> >                  features.features = 0;
> >              }
> > -            address_space_stl_le(&address_space_memory, ccw.cda,
> > -                                 features.features, MEMTXATTRS_UNSPECIFIED,
> > -                                 NULL);
> > +            ccw_dstream_rewind(&sch->cds);
> > +            cpu_to_le32s(&features.features);
> > +            ccw_dstream_write(&sch->cds, features.features);
> >              sch->curr_status.scsw.count = ccw.count - sizeof(features);  
> How about:
> sch->curr_status.scsw.count = ccw_dstream_residual_count(&sch->cds);

Hm, I thought I had commented on this, but I seem to have missed
these...

I'd prefer to do it as a follow-up patch.

> 
> This also applies to other places.
> 
> >              ret = 0;
> >          }  
> [...]
> 
> > @@ -501,21 +459,13 @@ static int virtio_ccw_cb(SubchDev *sch, CCW1 ccw)
> >              }
> >          }
> >          len = MIN(ccw.count, vdev->config_len);
> > -        hw_len = len;
> >          if (!ccw.cda) {
> >              ret = -EFAULT;
> >          } else {
> > -            config = cpu_physical_memory_map(ccw.cda, &hw_len, 0);
> > -            if (!config) {
> > -                ret = -EFAULT;
> > -            } else {
> > -                len = hw_len;
> > -                /* XXX config space endianness */
> > -                memcpy(vdev->config, config, len);
> > -                cpu_physical_memory_unmap(config, hw_len, 0, hw_len);
> > +            ret = ccw_dstream_read_buf(&sch->cds, vdev->config, len);
> > +            if (!ret) {  
> Add a TODO here, and:
> 
> if (ccw_dstream_read_buf(&sch->cds, vdev->config, len)) {
>     ret = -EFAULT;
> } else {
>     ....
> }

I don't think that would be correct: The function will (at least
currently) return 0 or -EINVAL, and you are now mapping any error to
-EFAULT? (Not that it has an effect in the end: We map both to a
channel program check as of "s390x/css: drop data-check in
interpretation".)

> 
> >                  virtio_bus_set_vdev_config(&dev->bus, vdev->config);
> >                  sch->curr_status.scsw.count = ccw.count - len;
> > -                ret = 0;
> >              }
> >          }
> >          break;  
> [...]
> 
> > @@ -714,13 +654,9 @@ static int virtio_ccw_cb(SubchDev *sch, CCW1 ccw)
> >              ret = -EFAULT;
> >              break;
> >          }
> > -        revinfo.revision =
> > -            address_space_lduw_be(&address_space_memory, ccw.cda,
> > -                                  MEMTXATTRS_UNSPECIFIED, NULL);
> > -        revinfo.length =
> > -            address_space_lduw_be(&address_space_memory,
> > -                                  ccw.cda + sizeof(revinfo.revision),
> > -                                  MEMTXATTRS_UNSPECIFIED, NULL);
> > +        ccw_dstream_read_buf(&sch->cds, &revinfo, 4);  
>                                                      ^
> A magic number? O:)

Hah :)

We can't use sizeof(revinfo), and sizeof(revinfo.revision) +
sizeof(revinfo.length) is a bit unwieldy. Let's keep some magic in our
code :)

> 
> > +        be16_to_cpus(&revinfo.revision);
> > +        be16_to_cpus(&revinfo.length);
> >          if (ccw.count < len + revinfo.length ||
> >              (check_len && ccw.count > len + revinfo.length)) {
> >              ret = -EINVAL;
> > -- 
> > 2.13.5
> >   
> 
> Otherwise, looks good.
> 

Can I get an ack?

  reply	other threads:[~2017-09-19  9:06 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-13 11:50 [Qemu-devel] [PATCH v2 0/4] add CCW indirect data access support Halil Pasic
2017-09-13 11:50 ` [Qemu-devel] [PATCH v2 1/4] s390x/css: introduce css data stream Halil Pasic
2017-09-14  9:08   ` Cornelia Huck
2017-09-19  2:21   ` Dong Jia Shi
2017-09-19  8:38     ` Cornelia Huck
2017-09-19  9:11   ` Pierre Morel
2017-09-19  9:53     ` Cornelia Huck
2017-09-19 11:41       ` Pierre Morel
2017-09-19 12:16         ` Halil Pasic
2017-09-19 13:55       ` Pierre Morel
2017-09-13 11:50 ` [Qemu-devel] [PATCH v2 2/4] s390x/css: use ccw " Halil Pasic
2017-09-19  2:45   ` Dong Jia Shi
2017-09-19 13:57   ` Pierre Morel
2017-09-13 11:50 ` [Qemu-devel] [PATCH v2 3/4] virtio-ccw: " Halil Pasic
2017-09-14  8:47   ` Cornelia Huck
2017-09-19  3:37   ` Dong Jia Shi
2017-09-19  9:06     ` Cornelia Huck [this message]
2017-09-19 13:30       ` Halil Pasic
2017-09-20  1:16         ` Dong Jia Shi
2017-09-19 14:07   ` Pierre Morel
2017-09-13 11:50 ` [Qemu-devel] [PATCH v2 4/4] s390x/css: support ccw IDA Halil Pasic
2017-09-14  9:14   ` Cornelia Huck
2017-09-19  5:50   ` Dong Jia Shi
2017-09-19  9:48     ` Cornelia Huck
2017-09-19 10:36       ` Halil Pasic
2017-09-19 10:57         ` Cornelia Huck
2017-09-19 12:04           ` Halil Pasic
2017-09-19 12:23             ` Cornelia Huck
2017-09-19 12:32               ` Halil Pasic
2017-09-19 14:34                 ` Cornelia Huck
2017-09-19 18:05               ` Halil Pasic
2017-09-20  1:37                 ` Dong Jia Shi
2017-09-20  6:40             ` Dong Jia Shi
2017-09-19 13:46           ` Pierre Morel
2017-09-19 16:49             ` Halil Pasic
2017-09-14  9:15 ` [Qemu-devel] [PATCH v2 0/4] add CCW indirect data access support Cornelia Huck
2017-09-14 11:02   ` Halil Pasic
2017-09-14 11:19     ` Cornelia Huck
2017-09-14 14:16 ` Cornelia Huck

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=20170919110631.59039743.cohuck@redhat.com \
    --to=cohuck@redhat.com \
    --cc=bjsdjshi@linux.vnet.ibm.com \
    --cc=pasic@linux.vnet.ibm.com \
    --cc=pmorel@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    /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).