On Mon, 28 Jan 2019 18:13:55 +0100 Cornelia Huck <cohuck@xxxxxxxxxx> wrote: > On Fri, 25 Jan 2019 17:04:04 +0100 > Halil Pasic <pasic@xxxxxxxxxxxxx> 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
