From: Jason Gunthorpe <jgg@nvidia.com>
To: Cornelia Huck <cohuck@redhat.com>
Cc: Alex Williamson <alex.williamson@redhat.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"farman@linux.ibm.com" <farman@linux.ibm.com>,
"mjrosato@linux.ibm.com" <mjrosato@linux.ibm.com>,
"pasic@linux.ibm.com" <pasic@linux.ibm.com>,
"Tian, Kevin" <kevin.tian@intel.com>,
Yishai Hadas <yishaih@nvidia.com>
Subject: Re: [PATCH RFC] vfio: Revise and update the migration uAPI description
Date: Wed, 19 Jan 2022 09:42:30 -0400 [thread overview]
Message-ID: <20220119134230.GM84788@nvidia.com> (raw)
In-Reply-To: <20220119124432.GJ84788@nvidia.com>
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
next prev parent reply other threads:[~2022-01-19 13:42 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-14 19:35 [PATCH RFC] vfio: Revise and update the migration uAPI description Jason Gunthorpe
2022-01-18 14:04 ` Yishai Hadas
2022-01-18 19:55 ` Alex Williamson
2022-01-18 21:00 ` Jason Gunthorpe
2022-01-19 11:40 ` Cornelia Huck
2022-01-19 12:44 ` Jason Gunthorpe
2022-01-19 13:42 ` Jason Gunthorpe [this message]
2022-01-19 14:59 ` Jason Gunthorpe
2022-01-19 15:32 ` Alex Williamson
2022-01-19 15:40 ` Jason Gunthorpe
2022-01-19 16:06 ` Alex Williamson
2022-01-19 16:38 ` Jason Gunthorpe
2022-01-19 17:02 ` Alex Williamson
2022-01-20 0:19 ` Jason Gunthorpe
2022-01-24 10:24 ` Cornelia Huck
2022-01-24 17:57 ` Jason Gunthorpe
2022-01-19 13:18 ` Jason Gunthorpe
2022-01-25 3:55 ` Tian, Kevin
2022-01-25 13:11 ` Jason Gunthorpe
2022-01-26 1:17 ` Tian, Kevin
2022-01-26 1:32 ` Jason Gunthorpe
2022-01-26 1:49 ` Tian, Kevin
2022-01-26 12:14 ` Jason Gunthorpe
2022-01-26 15:33 ` Jason Gunthorpe
2022-01-27 0:38 ` Tian, Kevin
2022-01-27 0:48 ` Jason Gunthorpe
2022-01-27 1:03 ` Tian, Kevin
2022-01-27 0:53 ` Tian, Kevin
2022-01-27 1:10 ` Jason Gunthorpe
2022-01-27 1:21 ` Tian, Kevin
2022-01-26 1:35 ` Jason Gunthorpe
2022-01-26 1:58 ` Tian, Kevin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220119134230.GM84788@nvidia.com \
--to=jgg@nvidia.com \
--cc=alex.williamson@redhat.com \
--cc=cohuck@redhat.com \
--cc=farman@linux.ibm.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=mjrosato@linux.ibm.com \
--cc=pasic@linux.ibm.com \
--cc=yishaih@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).