All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Jason Gunthorpe <jgg@nvidia.com>,
	Alex Williamson <alex.williamson@redhat.com>
Cc: "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: Mon, 24 Jan 2022 11:24:32 +0100	[thread overview]
Message-ID: <87fspdl9cv.fsf@redhat.com> (raw)
In-Reply-To: <20220120001923.GR84788@nvidia.com>

On Wed, Jan 19 2022, Jason Gunthorpe <jgg@nvidia.com> wrote:

> So, OK, I drafted a new series that just replaces the whole v1
> protocol. If we are agreed on breaking everything then I'd like to
> clean the other troublesome bits too, already we have some future
> topics on our radar that will benefit from doing this.

Can you share something about those "future topics"? It will help us
understand what you are trying to do, and maybe others might be going
into that direction as well.

>
> The net result is a fairly stunning removal of ~300 lines of ugly
> kernel driver code, which is significant considering the whole mlx5
> project is only about 1000 lines.
>
> The general gist is to stop abusing a migration region as a system
> call interface and instead define two new migration specific ioctls
> (set_state and arc_supported). Data transfer flows over a dedicated FD
> created for each transfer session with a clear lifecycle instead of
> through the region. qemu will discover the new protocol by issuing the
> arc_supported ioctl. (or if we prefer the other shed colour, using the
> VFIO_DEVICE_FEATURE ioctl instead of arc_supported)
>
> Aside from being a more unixy interface, an FD can be used with
> poll/io_uring/splice/etc and opens up better avenues to optimize for
> operating migrations of multiple devices in parallel. It kills a wack
> of goofy tricky driver code too.

Cleaner code certainly sounds compelling. It will be easier to review a
more concrete proposal, though, so I'll reserve judgment until then.


  reply	other threads:[~2022-01-24 10:24 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
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 [this message]
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=87fspdl9cv.fsf@redhat.com \
    --to=cohuck@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=farman@linux.ibm.com \
    --cc=jgg@nvidia.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.