All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Jared Rossi <jrossi@linux.ibm.com>
Cc: Eric Farman <farman@linux.ibm.com>,
	qemu-s390x@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [PATCH 1/1] vfio-ccw: Enable transparent CCW IPL from DASD
Date: Tue, 21 Apr 2020 10:29:37 +0200	[thread overview]
Message-ID: <20200421102937.511fde3a.cohuck@redhat.com> (raw)
In-Reply-To: <2fe2e12dee1799afee088bed88e6c671@linux.vnet.ibm.com>

On Mon, 20 Apr 2020 18:35:58 -0400
Jared Rossi <jrossi@linux.ibm.com> wrote:

> On 2020-04-20 08:29, Cornelia Huck wrote:
> > On Mon, 20 Apr 2020 14:26:17 +0200
> > Cornelia Huck <cohuck@redhat.com> wrote:
> >   
> >> On Fri, 17 Apr 2020 14:38:38 -0400
> >> Jared Rossi <jrossi@linux.ibm.com> wrote:
> >>   
> >> > Remove the explicit prefetch check when using vfio-ccw devices.
> >> > This check is not needed as all Linux channel programs are intended
> >> > to use prefetch and will be executed in the same way regardless.  
> >> 
> >> As already commented on the Linux patch: Can we log something, so this
> >> is debuggable if this statement does not hold true in the future?
> >>   
> 
> Agreed.  I will work on debugging improvements so that any future issues
> related to unintended prefetching are more clearly logged.

Great.

> 
> >> >
> >> > Signed-off-by: Jared Rossi <jrossi@linux.ibm.com>
> >> > ---
> >> >  hw/vfio/ccw.c | 13 +++----------
> >> >  1 file changed, 3 insertions(+), 10 deletions(-)
> >> >
> >> > diff --git a/hw/vfio/ccw.c b/hw/vfio/ccw.c
> >> > index 50cc2ec75c..e649377b68 100644
> >> > --- a/hw/vfio/ccw.c
> >> > +++ b/hw/vfio/ccw.c
> >> > @@ -74,16 +74,9 @@ static IOInstEnding vfio_ccw_handle_request(SubchDev *sch)
> >> >      struct ccw_io_region *region = vcdev->io_region;
> >> >      int ret;
> >> >
> >> > -    if (!(sch->orb.ctrl0 & ORB_CTRL0_MASK_PFCH)) {
> >> > -        if (!(vcdev->force_orb_pfch)) {
> >> > -            warn_once_pfch(vcdev, sch, "requires PFCH flag set");
> >> > -            sch_gen_unit_exception(sch);
> >> > -            css_inject_io_interrupt(sch);
> >> > -            return IOINST_CC_EXPECTED;
> >> > -        } else {
> >> > -            sch->orb.ctrl0 |= ORB_CTRL0_MASK_PFCH;
> >> > -            warn_once_pfch(vcdev, sch, "PFCH flag forced");
> >> > -        }
> >> > +    if (!(sch->orb.ctrl0 & ORB_CTRL0_MASK_PFCH) && vcdev->force_orb_pfch) {
> >> > +        sch->orb.ctrl0 |= ORB_CTRL0_MASK_PFCH;
> >> > +        warn_once_pfch(vcdev, sch, "PFCH flag forced");
> >> >      }  
> >> 
> >> What happens when you run it with an old kernel? I guess the I/O is
> >> only rejected later (after a trip into the kernel), but has that path
> >> ever been tested?
> >>   
> 
> Yes, this was tested and you are correct that the kernel will reject the 
> I/O unless
> the corresponding patch is also applied there.  I will revisit this path 
> while I'm
> updating the logging to ensure that any potential interactions are 
> appropriately
> considered.

I've looked at the code again and it seems that the kernel will end up
signaling -EOPNOTSUPP to us on that case, which causes the same unit
exception as without this patch, so we should be all good.

> 
> >> >
> >> >      QEMU_BUILD_BUG_ON(sizeof(region->orb_area) != sizeof(ORB));  
> >>   
> > 
> > Oh, and do we want to deprecate the force prefetch interface in the
> > future? We probably need to wait a bit, until the kernel changes have
> > become widely available.  
> 
> Yes, I think we will want to deprecate it at an appropriate time in the 
> future.
> 



  reply	other threads:[~2020-04-21  8:30 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-17 18:38 [PATCH 0/1] vfio-ccw: Enable transparent CCW IPL from DASD Jared Rossi
2020-04-17 18:38 ` [PATCH 1/1] " Jared Rossi
2020-04-20 12:26   ` Cornelia Huck
2020-04-20 12:29     ` Cornelia Huck
2020-04-20 22:35       ` Jared Rossi
2020-04-21  8:29         ` Cornelia Huck [this message]
  -- strict thread matches above, loose matches on Subject: below --
2020-04-17 18:29 [PATCH 0/1] " Jared Rossi
2020-04-17 18:29 ` [PATCH 1/1] " Jared Rossi
2020-04-20 12:13   ` Cornelia Huck
2020-04-24 13:02     ` Halil Pasic
2020-04-23 13:56   ` Halil Pasic
2020-04-23 15:11     ` Cornelia Huck
2020-04-23 20:25       ` Eric Farman
2020-04-24 12:50         ` Halil Pasic
2020-04-29  0:38           ` Jared Rossi

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=20200421102937.511fde3a.cohuck@redhat.com \
    --to=cohuck@redhat.com \
    --cc=farman@linux.ibm.com \
    --cc=jrossi@linux.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@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.