> -----Original Message-----
> From: Stefan Hajnoczi <[email protected]>
> Sent: 24 September 2020 09:22
> To: Thanos Makatos <[email protected]>
> Cc: [email protected]; Michael S. Tsirkin <[email protected]>;
> [email protected]; [email protected];
> [email protected]; [email protected]; Swapnil Ingle
> <[email protected]>; [email protected];
> [email protected]; Raphael Norwitz <[email protected]>;
> [email protected]; [email protected]; Felipe
> Franciosi <[email protected]>; [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected]; John G Johnson
> <[email protected]>
> Subject: Re: [PATCH v4] introduce vfio-user protocol specification
>
> On Tue, Sep 15, 2020 at 07:29:17AM -0700, Thanos Makatos wrote:
> > This patch introduces the vfio-user protocol specification (formerly
> > known as VFIO-over-socket), which is designed to allow devices to be
> > emulated outside QEMU, in a separate process. vfio-user reuses the
> > existing VFIO defines, structs and concepts.
> >
> > It has been earlier discussed as an RFC in:
> > "RFC: use VFIO over a UNIX domain socket to implement device offloading"
> >
> > Signed-off-by: John G Johnson <[email protected]>
> > Signed-off-by: Thanos Makatos <[email protected]>
>
> The approach looks promising. It's hard to know what changes will be
> required when this is implemented, so let's not worry about getting
> every detail of the spec right.
>
> Now that there is a spec to start from, the next step is patches
> implementing --device vfio-user-pci,chardev=<chardev> in
> hw/vfio-user/pci.c (mirroring hw/vfio/).
>
> It should be accompanied by a test in tests/. PCI-level testing APIS for
> BARs, configuration space, interrupts, etc are available in
> tests/qtest/libqos/pci.h. The test case needs to include a vfio-user
> device backend interact with QEMU's vfio-user-pci implementation.
We plan to use a libmuser-based backend for testing. This, I suppose, will
make libmuser a dependency of QEMU (either as a submodule or as a library),
which for now can be disabled in the default configuration. Is this acceptable?
>
> I think this spec can be merged in docs/devel/ now and marked as
> "subject to change (not a stable public interface
Great!
>
> After the details have been proven and any necessary changes have been
> made the spec can be promoted to docs/interop/ as a stable public
> interface. This gives the freedom to make changes discovered when
> figuring out issues like disconnect/reconnect, live migration, etc that
> can be hard to get right without a working implementation.
>
> Does this approach sound good?
Yes.
>
> Also please let us know who is working on what so additional people can
> get involved in areas that need work!
Swapnil and I will be working on libmuser and the test in QEMU, John and
the mp-qemu folks will be working on the patches for implementing
--device vfio-user-pci.
>
> Stefan
