On 06/08/2018 04:45 PM, Cornelia Huck wrote:
On Fri, 8 Jun 2018 15:13:28 +0200
Halil Pasic <pasic@xxxxxxxxxxxxx> wrote:
On 06/08/2018 02:20 PM, Cornelia Huck wrote:
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. The vfio code now needs to do a hsch
(instead of a ssch). The real channel subsystem should figure this out,
as we can't reliably check whether the start function has concluded
already (there's always a race window).
This I do not agree scsw(r) is part of the driver.
The interface here is not a device interface anymore but a driver
interface.
SCSW is a status, it is at its place in QEMU device interface with the
guest
but here pwrite() sends a command.
Hm, I rather consider that "we write a status, and the backend figures
out what to do based on that status".
The status of what? Kind of a target status?
I think this approach is the source of lots of complications. For instance
take xsch. How are we supposed to react to a guest xsch (in QEMU and
in the kernel module)? My guess is that the right thing to do is to issue
an xsch in the vfio-ccw kernel module on the passed through subchannel.
But there is no bit in fctl for cancel.
Bottom line is: I'm not happy with the current design but I'm not sure
if it's practical to do something about it (i.e. change it radically).
It might make sense to keep this for ssch, maybe reuse it for hsch/csch,
and think about something else for other things we want to handle
(xsch, channel monitoring, the path handling stuff for which we already
had a prototype etc.) It's probably not practical to do radical surgery
on the existing code.
I'm reluctant to have a strong opinion. As far as i can tell ssch is
functionally quite good (see in the other sub-thread the part about host
ssch cc being reflected in the guest cc). I have the feeling the
implementation is at places unnecessarily complicated and at places
confusing and misleading (e.g. the stale comment you have mentioned).
That feeling obviously has an impact on my confidence, e.g. the
confidence of my 'quite good' above.
I definitely don't have the time for even evaluating the prospects of a
radical surgery, let alone for making it happen. IMHO the key is not
making things worse as we proceed.
But I try to keep in touch and at least voice concern when I disagree. I
have been neglecting this series of yours and I feel bad about it. I even
lost track of the discussion and the conclusions (mainly between You and
Pierre). Your scsw write-up gave me the opportunity to connect.
I will try to do more for the next version, but it really depends on what
else do I have to do in parallel.
[Speaking of which: Is there any current effort on the path handling
things?]
Dong Jia is the person with the best answers for this question. I hope
he will give us a piece of his mind about the design questions discussed
here too -- as the author he should have the best understanding of the
design decisions made.
Regards,
Halil
--
To unsubscribe from this list: send the line "unsubscribe linux-s390" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
