[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2 2/5] vfio-ccw: concurrent I/O handling
From: |
Halil Pasic |
Subject: |
Re: [Qemu-devel] [PATCH v2 2/5] vfio-ccw: concurrent I/O handling |
Date: |
Mon, 28 Jan 2019 20:30:00 +0100 |
On Mon, 28 Jan 2019 18:13:55 +0100
Cornelia Huck <address@hidden> wrote:
> On Fri, 25 Jan 2019 17:04:04 +0100
> Halil Pasic <address@hidden> 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: <address@hidden>) 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
- Re: [Qemu-devel] [PATCH v2 2/5] vfio-ccw: concurrent I/O handling, (continued)
- Re: [Qemu-devel] [PATCH v2 2/5] vfio-ccw: concurrent I/O handling, Eric Farman, 2019/01/24
- Re: [Qemu-devel] [PATCH v2 2/5] vfio-ccw: concurrent I/O handling, Eric Farman, 2019/01/24
- Re: [Qemu-devel] [PATCH v2 2/5] vfio-ccw: concurrent I/O handling, Cornelia Huck, 2019/01/25
- Re: [Qemu-devel] [PATCH v2 2/5] vfio-ccw: concurrent I/O handling, Cornelia Huck, 2019/01/25
- Re: [Qemu-devel] [PATCH v2 2/5] vfio-ccw: concurrent I/O handling, Halil Pasic, 2019/01/25
- Re: [Qemu-devel] [PATCH v2 2/5] vfio-ccw: concurrent I/O handling, Cornelia Huck, 2019/01/25
- Re: [Qemu-devel] [PATCH v2 2/5] vfio-ccw: concurrent I/O handling, Halil Pasic, 2019/01/25
- Re: [Qemu-devel] [PATCH v2 2/5] vfio-ccw: concurrent I/O handling, Cornelia Huck, 2019/01/28
- Re: [Qemu-devel] [PATCH v2 2/5] vfio-ccw: concurrent I/O handling,
Halil Pasic <=
- Re: [Qemu-devel] [PATCH v2 2/5] vfio-ccw: concurrent I/O handling, Cornelia Huck, 2019/01/29
- Re: [Qemu-devel] [PATCH v2 2/5] vfio-ccw: concurrent I/O handling, Halil Pasic, 2019/01/29
- Re: [Qemu-devel] [PATCH v2 2/5] vfio-ccw: concurrent I/O handling, Cornelia Huck, 2019/01/30
- Re: [Qemu-devel] [PATCH v2 2/5] vfio-ccw: concurrent I/O handling, Farhan Ali, 2019/01/30
- Re: [Qemu-devel] [PATCH v2 2/5] vfio-ccw: concurrent I/O handling, Cornelia Huck, 2019/01/28
- Re: [Qemu-devel] [PATCH v2 2/5] vfio-ccw: concurrent I/O handling, Halil Pasic, 2019/01/28
- Re: [Qemu-devel] [PATCH v2 2/5] vfio-ccw: concurrent I/O handling, Eric Farman, 2019/01/28
- Re: [Qemu-devel] [PATCH v2 2/5] vfio-ccw: concurrent I/O handling, Cornelia Huck, 2019/01/29
- Re: [Qemu-devel] [PATCH v2 2/5] vfio-ccw: concurrent I/O handling, Eric Farman, 2019/01/29
- Re: [Qemu-devel] [PATCH v2 2/5] vfio-ccw: concurrent I/O handling, Cornelia Huck, 2019/01/29