Re: [PATCH RFC] vfio: Revise and update the migration uAPI description

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jan 19 2022, Jason Gunthorpe <jgg@xxxxxxxxxx> 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.




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux