Messages in this thread | | | Subject | Re: [qemu-s390x] [PATCH RFC 2/2] vfio-ccw: support for halt/clear subchannel | From | Halil Pasic <> | Date | Fri, 8 Jun 2018 22:40:39 +0200 |
| |
On 06/07/2018 06:34 PM, Cornelia Huck wrote: > On Thu, 7 Jun 2018 18:17:57 +0200 > Halil Pasic <pasic@linux.ibm.com> wrote: > >> On 06/07/2018 11:54 AM, Cornelia Huck wrote: >>> Hm, I think we need to be more precise as to what scsw we're talking >>> about. Bad ascii art time: >>> >>> -------------- >>> | scsw(g) | ssch >>> -------------- | >>> | guest [..]
>> (5) AFAIK this is how the current implementation works. We don't wait >> for the I/O interrupt on the host to present a cc to the guest for it's >> ssch. > > But the vfio code does wait, no? We just signal the interrupt via > eventfd as well. >
We have sorted this out in the other thread.
>> >>> >>> If the guest now does a hsch, it would trap in the same way as the ssch >>> before. When qemu gets control, it adds the halt bit in scsw(q) (which >>> is in accordance with the architecture). >> >> (7) Again it's when is fctl set according to the architecture... > > Same comment as above. If we do a hsch for a subchannel with the start > function set, we'll set cc 0. > >> >>> My proposal is to do the same >>> copying to scsw(r) again, which would mean we get a request with both >>> the halt and the start bit set. >> >> (8) IMHO when receiving the 'request' we are and should be in instruction >> context -- opposed to basic io function context. So we should not set fctl >> before we know what will our guest cc be. But since scsw(r) is not a real >> scsw it is just strange. > > I think what we are doing is really 'performing the start function' - > it's just not asynchronous in the current implementation.
The code is written as if, especially in QEMU. But this was in my current understanding a bad decision. The why is the following. It makes reasoning both about architectural correctness and the code a lot trickier compared to the interpretation of the guest instruction finishes after the host instruction finishes (unless we can prove we don't need any) approach.
> So we already know that ssch will return with cc 0. >
I will use your example, and another example to explain what I mean by tricky.
One can probably argue that setting cc 0 even if the host device responds to the host ssch with cc 3 because the device is not any more on the given subchannel or simply just disabled. It is probably true that the guest would not have any means to prove that we were 'lying' to it.
But AFAIR this is not how the current implementation works. The pwrite in qemu basically depends on the cc of the host ssch. So if the host ssch completes with cc 3 the vfio-ccw kernel module map ist to pwrite reporting -ENODEV and vfio_ccw_handle_request makes sure that the guest instruction completes with cc 3 by mapping it to return code IOINST_CC_NOT_OPERATIONAL.
I mentioned xsch in the other thread. I don't think we can tell if cc 0 or cc 2. In my reading xsch in simple words xsch completes with cc 2 and does nothing else if the channel subsystem already started talking to the cu/device. If in time it makes sure we don't start talking to the device, and clear away stuff. So if we don't consider cc of the xsch to be issued by the host the only safe bet seems to be cc 2. But that's effectively getting around implementing the desired functionality of xsch and still staying architecturally correct. Which however might be good enough for vfio-ccw. But I think I demonstrated it's kinda tricky business.
I prefer to avoid tricky if there is no good reason not to.
[..]
> > Thanks for reading! >
Your welcome. The discussion is kind of taking place all over the place. I'm actively trying to find the best place to answer, and avoid overtalking topics -- but it does not seem to work. Please bear with me.
Regards, Halil
[..]
| |