On 18/10/2018 14:38, Halil Pasic wrote:
On 10/18/2018 09:51 AM, Pierre Morel wrote:
VFIO_CCW_STATE_BOXED and VFIO_CCW_STATE_BUSY have
identical actions for the same events.
Let's merge both into a single state to simplify the code.
We choose to keep VFIO_CCW_STATE_BUSY.
Your commit message does not convince me. From what I
see VFIO_CCW_STATE_BOXED was a bad idea in the first
place:
* is very very different than DEV_STATE_BOXED,
* its role is obscure and undocumented.
With your patch however, we get a weird VFIO_CCW_STATE_BUSY -->
VFIO_CCW_STATE_BUSY state transition, which I don't consider
much better:
First we go into VFIO_CCW_STATE_BUSY in fsm_io_request() and then
again in fsm_io_helper() which is called by fsm_io_request().
So good path used to go
VFIO_CCW_STATE_IDLE --> VFIO_CCW_STATE_BOXED --> VFIO_CCW_STATE_BUSY --> ?
and with your patch it goes
VFIO_CCW_STATE_IDLE --> VFIO_CCW_STATE_BUSY --> VFIO_CCW_STATE_BUSY --> ?
The patch does not deal with state changes.
Only with merging the two states table entries.
From what I see, the role of VFIO_CCW_STATE_BOXED is to differentiate
between 'doing I/O on the host subchannel' and 'looking at the request,
doing translation, and whatever we need to before interacting with the
host subchannel'. Normally state is exposed via sysfs, but for vfio-ccw
it ain't. Does anybody know why?
I think you are confusing CSS and CCW devices.
CSS devices do not expose a state. And yes, vfio-ccw name is misleading
because vfio-ccw is a css driver. ;)
(Historical reasons)
The vfio-ccw driver do not expose this state to userland or even inside
the kernel. It is purely internal.
Exposing the mediated device internal state is not foreseen in this patch.
Regards,
Pierre
--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany
