All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com>
To: Halil Pasic <pasic@linux.vnet.ibm.com>
Cc: Cornelia Huck <cohuck@redhat.com>,
	Dong Jia Shi <bjsdjshi@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: Wed, 20 Sep 2017 09:16:52 +0800	[thread overview]
Message-ID: <20170920011652.GC11080@bjsdjshi@linux.vnet.ibm.com> (raw)
In-Reply-To: <6a51f84b-9185-ec5c-b0ec-1fc21fbfb201@linux.vnet.ibm.com>

* Halil Pasic <pasic@linux.vnet.ibm.com> [2017-09-19 15:30:29 +0200]:

> 
> 
> On 09/19/2017 11:06 AM, Cornelia Huck wrote:
> > 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 ;)
No problem with me.

> > 
> >>
> >>> ---
> >>>  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...
I was thinking 'advance' to the offset of features.index, then 'read'
the value for features.index seems more natural, and you do not need to
care too much for what exaclty the elements are that you need to
'advance'.

Not big deal for me. I could also accept the original version.

> > 
> >>
> >>> +            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.
No problem.

> > 
> >>
> >> 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".)
Ah, I missed this. Now no problem from me.

> > 
> >>
> >>>                  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 :)
No problem. This seems the best option.

> > 
> >>
> >>> +        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?
Sure:
Reviewed-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com>

> > 
> 
> I agree that further cleanups are possible (e.g. using
> ccw_dstream_residual_count() and tightening error handling) but
> I also prefer to see these as on-top, and prefer sticking to
> change as little as possible in the transformation patch and stay
> as close as possible to what we had before in terms of behavior).
Understand and agree.

> 
> Regards,
> Halil 
> 

-- 
Dong Jia Shi

  reply	other threads:[~2017-09-20  1:17 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
2017-09-19 13:30       ` Halil Pasic
2017-09-20  1:16         ` Dong Jia Shi [this message]
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=20170920011652.GC11080@bjsdjshi@linux.vnet.ibm.com \
    --to=bjsdjshi@linux.vnet.ibm.com \
    --cc=cohuck@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.