On 08/06/2018 16:45, 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,
I do not think we need to change the interface radically but
I also do not thing we should extend it by using multiple commands
in a single syscall.
Currently:
- only SSCH bit is used
- only the SSCH instruction is implemented
- all other bits, CSCH,HSCH produce an error when used alone
or are ignored in conjonction with SSCH
- there is no implementation using the other bits
- It is not specified in the documentation that multiple commands
can be used.
Looking at these, I think there is no trouble to modify the way
the Kernel interface is implemented without impact on current QEMU.
But if we begin to allow ssch/hsch/csch in a single command
in a new implementation we will be stuck with it.
and think about something else for other things we want to handle
Yes we will need to have another interface, ioctl, or new region,
all possible, but really more complex.
(xsch, channel monitoring, the path handling stuff for which we already
We can use another region for getting up information on path handling
or monitoring, as does the patch IIRC.
This is not a problem.
had a prototype etc.) It's probably not practical to do radical surgery
on the existing code.
There is no need for radical surgery, no change is required to older or
current QEMU code.
My concern is to avoid a future implementation merging multiple commands
in a single syscall.
It is not only a problem of beauty of the interface,
using a status is for the up-stream, from device to program.
Using the same construct, same name and same location, to produce commands
for the down stream is misleading and source of incoherence.
Sorry to have insisted so much but it seems so obvious to me.
May be I missed something.
Regards,
Pierre
[Speaking of which: Is there any current effort on the path handling
things?]
--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany
--
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
