From: Halil Pasic <pasic@linux.ibm.com>
To: Cornelia Huck <cohuck@redhat.com>
Cc: linux-s390@vger.kernel.org, Eric Farman <farman@linux.ibm.com>,
Alex Williamson <alex.williamson@redhat.com>,
Pierre Morel <pmorel@linux.ibm.com>,
kvm@vger.kernel.org, Farhan Ali <alifm@linux.ibm.com>,
qemu-devel@nongnu.org, qemu-s390x@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v2 2/5] vfio-ccw: concurrent I/O handling
Date: Mon, 28 Jan 2019 20:30:00 +0100 [thread overview]
Message-ID: <20190128203000.6dbf7ba3@oc2783563651> (raw)
In-Reply-To: <20190128181355.2d79cae7.cohuck@redhat.com>
On Mon, 28 Jan 2019 18:13:55 +0100
Cornelia Huck <cohuck@redhat.com> wrote:
> On Fri, 25 Jan 2019 17:04:04 +0100
> Halil Pasic <pasic@linux.ibm.com> wrote:
>
> > Do we expect userspace/QEMU to fence the bad scenarios as tries to do
> > today, or is this supposed to change to hardware should sort out
> > requests whenever possible.
>
> Does my other mail answer that?
Sorry, I can't find the answer in your other (Date: Mon, 28 Jan 2019
17:59:10 +0100, Message-Id: <20190128175910.5d9677e7@oc2783563651>) mail.
AFAIU that mail talks abut the kernel and not about the userspace.
I guess the answer is we don't expect changes to userspace, so we do
expect userspace to fence bad scenarios.
>
> > The problem I see with the let the hardware sort it out is that, for
> > that to work, we need to juggle multiple translations simultaneously
> > (or am I wrong?). Doing that does not appear particularly simple to
> > me.
>
> None in the first stage, at most two in the second stage, I guess.
>
Expected benefit of the second stage over the first stage? (I see none.)
> > Furthermore we would go through all that hassle knowingly that the
> > sole reason is working around bugs. We still expect our Linux guests
> > serializing it's ssch() stuff as it does today. Thus I would except
> > this code not getting the love nor the coverage that would guard
> > against bugs in that code.
>
> So, we should have test code for that? (Any IBM-internal channel I/O
> exercisers that may help?)
>
None that I'm aware of. Anyone else?
But the point I was trying to make is the following: I prefer keeping
the handling for the case "ssch()'s on top of each other" as trivial as
possible. (E.g. bail out if CP_PENDING without doing any translation.)
> We should not rely on the guest being sane, although Linux probably is
> in that respect.
>
I agree 100%: we should not rely on either guest or userspace emulator
being sane. But IMHO we should handle insanity with the least possible
investment.
Regards,
Halil
next prev parent reply other threads:[~2019-01-28 19:30 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-21 11:03 [Qemu-devel] [PATCH v2 0/5] vfio-ccw: support hsch/csch (kernel part) Cornelia Huck
2019-01-21 11:03 ` [Qemu-devel] [PATCH v2 1/5] vfio-ccw: make it safe to access channel programs Cornelia Huck
2019-01-22 14:56 ` Halil Pasic
2019-01-22 15:19 ` Cornelia Huck
2019-01-21 11:03 ` [Qemu-devel] [PATCH v2 2/5] vfio-ccw: concurrent I/O handling Cornelia Huck
2019-01-21 20:20 ` Halil Pasic
2019-01-22 10:29 ` Cornelia Huck
2019-01-22 11:17 ` Halil Pasic
2019-01-22 11:53 ` Cornelia Huck
2019-01-22 12:46 ` Halil Pasic
2019-01-22 17:26 ` Cornelia Huck
2019-01-22 19:03 ` Halil Pasic
2019-01-23 10:34 ` Cornelia Huck
2019-01-23 13:06 ` Halil Pasic
2019-01-23 13:34 ` Cornelia Huck
2019-01-24 19:16 ` Eric Farman
2019-01-25 10:13 ` Cornelia Huck
2019-01-22 18:33 ` Halil Pasic
2019-01-23 10:21 ` Cornelia Huck
2019-01-23 13:30 ` Halil Pasic
2019-01-24 10:05 ` Cornelia Huck
2019-01-24 10:08 ` Pierre Morel
2019-01-24 10:19 ` Cornelia Huck
2019-01-24 11:18 ` Pierre Morel
2019-01-24 11:45 ` Halil Pasic
2019-01-24 19:14 ` Eric Farman
2019-01-25 2:25 ` Eric Farman
2019-01-25 2:37 ` Eric Farman
2019-01-25 10:24 ` Cornelia Huck
2019-01-25 12:58 ` Cornelia Huck
2019-01-25 14:01 ` Halil Pasic
2019-01-25 14:21 ` Cornelia Huck
2019-01-25 16:04 ` Halil Pasic
2019-01-28 17:13 ` Cornelia Huck
2019-01-28 19:30 ` Halil Pasic [this message]
2019-01-29 9:58 ` Cornelia Huck
2019-01-29 19:39 ` Halil Pasic
2019-01-30 13:29 ` Cornelia Huck
2019-01-30 14:32 ` Farhan Ali
2019-01-28 17:09 ` Cornelia Huck
2019-01-28 19:15 ` Halil Pasic
2019-01-28 21:48 ` Eric Farman
2019-01-29 10:20 ` Cornelia Huck
2019-01-29 14:14 ` Eric Farman
2019-01-29 18:53 ` Cornelia Huck
2019-01-29 10:10 ` Cornelia Huck
2019-01-25 15:57 ` Eric Farman
2019-01-28 17:24 ` Cornelia Huck
2019-01-28 21:50 ` Eric Farman
2019-01-25 20:22 ` Eric Farman
2019-01-28 17:31 ` Cornelia Huck
2019-01-25 13:09 ` Halil Pasic
2019-01-25 12:58 ` Halil Pasic
2019-01-25 20:21 ` Eric Farman
2019-01-21 11:03 ` [Qemu-devel] [PATCH v2 3/5] vfio-ccw: add capabilities chain Cornelia Huck
2019-01-23 15:57 ` [Qemu-devel] [qemu-s390x] " Halil Pasic
2019-01-25 16:19 ` [Qemu-devel] " Eric Farman
2019-01-25 21:00 ` Eric Farman
2019-01-28 17:34 ` Cornelia Huck
2019-01-21 11:03 ` [Qemu-devel] [PATCH v2 4/5] s390/cio: export hsch to modules Cornelia Huck
2019-01-22 15:21 ` [Qemu-devel] [qemu-s390x] " Halil Pasic
2019-01-21 11:03 ` [Qemu-devel] [PATCH v2 5/5] vfio-ccw: add handling for async channel instructions Cornelia Huck
2019-01-23 15:51 ` Halil Pasic
2019-01-24 10:06 ` Cornelia Huck
2019-01-24 10:37 ` Halil Pasic
2019-01-25 21:00 ` Eric Farman
2019-01-28 17:40 ` 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=20190128203000.6dbf7ba3@oc2783563651 \
--to=pasic@linux.ibm.com \
--cc=alex.williamson@redhat.com \
--cc=alifm@linux.ibm.com \
--cc=cohuck@redhat.com \
--cc=farman@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=pmorel@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 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).