On Thu, 30 Sep 2021 12:25:23 +0300 Max Gurtovoy <mgurtovoy@xxxxxxxxxx> wrote: > On 9/30/2021 1:44 AM, Alex Williamson wrote: > > On Thu, 30 Sep 2021 00:48:55 +0300 > > Max Gurtovoy <mgurtovoy@xxxxxxxxxx> wrote: > > > >> On 9/29/2021 7:14 PM, Jason Gunthorpe wrote: > >>> On Wed, Sep 29, 2021 at 06:28:44PM +0300, Max Gurtovoy wrote: > >>> > >>>>> So you have a device that's actively modifying its internal state, > >>>>> performing I/O, including DMA (thereby dirtying VM memory), all while > >>>>> in the _STOP state? And you don't see this as a problem? > >>>> I don't see how is it different from vfio-pci situation. > >>> vfio-pci provides no way to observe the migration state. It isn't > >>> "000b" > >> Alex said that there is a problem of compatibility. > >> > >> I migration SW is not involved, nobody will read this migration state. > > The _STOP state has a specific meaning regardless of whether userspace > > reads the device state value. I think what you're suggesting is that > > the device reports itself as _STOP'd but it's actually _RUNNING. Is > > that the compatibility workaround, create a self inconsistency? > > From migration point of view the device is stopped. The _RESUMING and _SAVING bits control the migration activity, the _RUNNING bit controls the ability of the device to modify its internal state and affect external state. The initial state of the device is absolutely not stopped. > > We cannot impose on userspace to move a device from _STOP to _RUNNING > > simply because the device supports the migration region, nor should we > > report a device state that is inconsistent with the actual device state. > > In this case we can think maybe moving to running during enabling the > bus master.. There are no spontaneous state transitions, device_state changes only via user manipulation of the register. > >>>> Maybe we need to rename STOP state. We can call it READY or LIVE or > >>>> NON_MIGRATION_STATE. > >>> It was a poor choice to use 000b as stop, but it doesn't really > >>> matter. The mlx5 driver should just pre-init this readable to running. > >> I guess we can do it for this reason. There is no functional problem nor > >> compatibility issue here as was mentioned. > >> > >> But still we need the kernel to track transitions. We don't want to > >> allow moving from RESUMING to SAVING state for example. How this > >> transition can be allowed ? > >> > >> In this case we need to fail the request from the migration SW... > > _RESUMING to _SAVING seems like a good way to test round trip migration > > without running the device to modify the state. Potentially it's a > > means to update a saved device migration data stream to a newer format > > using an intermediate driver version. > > what do you mean by "without running the device to modify the state." ? If a device is !_RUNNING it should not be advancing its internal state, therefore state-in == state-out. > did you describe a case where you migrate from source to dst and then > back to source with a new migration data format ? I'm speculating that as the driver evolves, the migration data stream generated from the device's migration region can change. Hopefully in compatible ways. The above sequence of restoring and extracting state without the complication of the device running could help to validate compatibility. Thanks, Alex
