On Wed, Jan 19, 2022 at 08:44:32AM -0400, Jason Gunthorpe wrote:
> > What about leaving the existing migration region alone (in order to not
> > break whatever exists out there) and add a v2 migration region that
> > defines a base specification (the mandatory part that everyone must
> > support) and a capability mechanism to allow for extensions like
> > P2P?
Actually, I misunderstood your remark, I think.
The ARC_SUPPORTED *is* the capability mechanism you are asking for.
It is naturally defined in terms of the thing we are querying instead
of being an 'capability bit'.
It would be reasonable to define bundles of arcs, eg if any of these
are supported then all of them must be supported:
PRE_COPY -> RUNNING
PRE_COPY -> STOP_COPY
RESUMING -> STOP
RUNNING -> PRE_COPY
RUNNING -> STOP
STOP -> RESUMING
STOP -> RUNNING
STOP -> STOP_COPY
STOP_COPY -> STOP
(And since we already defined this as mandatory already, it must
succeed)
And similar for P2P, if any are supported all must be supported
PRE_COPY -> PRE_COPY_P2P
PRE_COPY_P2P -> PRE_COPY
PRE_COPY_P2P -> RUNNING_P2P
PRE_COPY_P2P -> STOP_COPY
RUNNING -> RUNNING_P2P
RUNNING_P2P -> PRE_COPY_P2P
RUNNING_P2P -> RUNNING
RUNNING_P2P -> STOP
STOP -> RUNNING_P2P
[Plus the frst group]
This is pretty much the intention anyhow, even if it is was not
fully written down.
Which means that qemu needs to do one ARC_SUPPORTED call to determine
if it should use the P2P arcs or not.
We also have the possible STOP_COPY -> PRE_COPY scenario Alex thought
about which fits nicely here as well.
I can't see a good reason to use capability flags to represent the
same thing, that is less precise and a bit more obfuscated, IMHO. But
it doesn't really matter either way - it expresses the same idea. We
used a cap flag in the prior attempt for NDMA already, it isn't a big
change.
Please lets just pick the colour of this bike shed and move on.
Thanks,
Jason
