kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).