From: Cornelia Huck <cohuck@redhat.com>
To: Halil Pasic <pasic@linux.ibm.com>
Cc: Jared Rossi <jrossi@linux.ibm.com>,
Eric Farman <farman@linux.ibm.com>,
linux-s390@vger.kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] vfio-ccw: Enable transparent CCW IPL from DASD
Date: Thu, 23 Apr 2020 17:11:03 +0200 [thread overview]
Message-ID: <20200423171103.497dcd02.cohuck@redhat.com> (raw)
In-Reply-To: <20200423155620.493cb7cb.pasic@linux.ibm.com>
On Thu, 23 Apr 2020 15:56:20 +0200
Halil Pasic <pasic@linux.ibm.com> wrote:
> On Fri, 17 Apr 2020 14:29:39 -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.
>
> Hm. This is a guest thing or? So you basically say, it is OK to do
> this, because you know that the guest is gonna be Linux and that it
> the channel program is intended to use prefetch -- but the ORB supplied
> by the guest that designates the channel program happens to state the
> opposite.
>
> Or am I missing something?
I see this as a kind of architecture compliance/ease of administration
tradeoff, as we none of the guests we currently support uses something
that breaks with prefetching outside of IPL (which has a different
workaround).
One thing that still concerns me a bit is debuggability if a future
guest indeed does want to dynamically rewrite a channel program: the
guest thinks it instructed the device to not prefetch, and then
suddenly things do not work as expected. We can log when a guest
submits an orb without prefetch set, but we can't find out if the guest
actually does something that relies on non-prefetch.
The only correct way to handle this would be to actually implement
non-prefetch processing, where I would not really know where to even
start -- and then we'd only have synthetic test cases, for now. None of
the options are pleasant :(
next prev parent reply other threads:[~2020-04-23 15:11 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-17 18:29 [PATCH 0/1] vfio-ccw: Enable transparent CCW IPL from DASD 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 [this message]
2020-04-23 20:25 ` Eric Farman
2020-04-24 12:50 ` Halil Pasic
2020-04-29 0:38 ` Jared Rossi
-- strict thread matches above, loose matches on Subject: below --
2020-04-17 18:38 [PATCH 0/1] " 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
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=20200423171103.497dcd02.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=farman@linux.ibm.com \
--cc=jrossi@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=pasic@linux.ibm.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 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.