On Thu, 24 Feb 2022 17:53:59 +0100 Cornelia Huck <cohuck@xxxxxxxxxx> wrote: > On Thu, Feb 24 2022, Alex Williamson <alex.williamson@xxxxxxxxxx> wrote: > > Chatting with Connie offline, I think the clarification that might help > > is something alone the lines that the combination of bits must support > > migration, which currently requires the STOP_COPY and RESUMING states. > > The VFIO_MIGRATION_P2P flag alone does not provide these states. The > > only flag in the current specification to provide these states is > > VFIO_MIGRATION_STOP_COPY. I don't think we want to preclude that some > > future flag might provide variants of STOP_COPY and RESUMING, so it's > > not so much that VFIO_MIGRATION_STOP_COPY is mandatory, but it is > > currently the only flag which provides the base degree of migration > > support. > > Indeed. > > > > > How or if that translates to an actual documentation update, I'm not > > sure. As it stands, we're not speculating about future support, we're > > only stating these two combinations are valid. Future combinations may > > or may not include VFIO_MIGRATION_STOP_COPY. As the existing proposed > > comment indicates, other combinations are TBD. Connie? Thanks, > > > > Alex > > Hm... "a flag indicating support for a migration state machine such as > VFIO_MIGRATION_STOP_COPY is mandatory"? TBH, I'm not sure this makes a substantive improvement. We don't know what those new flag bits will be used for, including which bit or bits will combine to indicate a valid state machine. Userspace written to this spec needs to support STOP_COPY and optionally P2P as we're stating. Nothing really compels us to speculate general rules for unknown future bit combinations. Thanks, Alex
