Messages in this thread | | | Subject | Re: [PATCH mlx5-next 2/7] vfio: Add an API to check migration state transition validity | From | Max Gurtovoy <> | Date | Wed, 29 Sep 2021 13:44:10 +0300 |
| |
On 9/28/2021 2:12 AM, Jason Gunthorpe wrote: > On Mon, Sep 27, 2021 at 04:46:48PM -0600, Alex Williamson wrote: >>> + enum { MAX_STATE = VFIO_DEVICE_STATE_RESUMING }; >>> + static const u8 vfio_from_state_table[MAX_STATE + 1][MAX_STATE + 1] = { >>> + [VFIO_DEVICE_STATE_STOP] = { >>> + [VFIO_DEVICE_STATE_RUNNING] = 1, >>> + [VFIO_DEVICE_STATE_RESUMING] = 1, >>> + }, >> Our state transition diagram is pretty weak on reachable transitions >> out of the _STOP state, why do we select only these two as valid? > I have no particular opinion on specific states here, however adding > more states means more stuff for drivers to implement and more risk > driver writers will mess up this uAPI.
_STOP == 000b => Device Stopped, not saving or resuming (from UAPI).
This is the default initial state and not RUNNING.
The user application should move device from STOP => RUNNING or STOP => RESUMING.
Maybe we need to extend the comment in the UAPI file.
> > So only on those grounds I'd suggest to keep this to the minimum > needed instead of the maximum logically possible.. > > Also, probably the FSM comment from the uapi header file should be > moved into a function comment above this function? > > Jason
| |