This is the 8th revision of the vfio-user client implementation. The vfio-user
protocol allows for implementing (PCI) devices in another userspace process;
SPDK is one example, which includes a virtual NVMe implementation.

The vfio-user framework consists of 3 parts:
 1) The VFIO user protocol specification.
 2) A client - the VFIO device in QEMU that encapsulates VFIO messages
    and sends them to the server.
 3) A server - a remote process that emulates a device.

This patchset implements parts 1 and 2.

It has been tested against libvfio-user test servers as well as SPDK.

Thanks for previous reviews & comments.

Changes since v7:

 - split up pci patches for easier reviewing
 - fixed lots of device ops error handling
 - vfio-user code now in hw/vfio-user
 - improved commit messages
 - various other small cleanups

Jagannathan Raman (20):
  vfio/container: pass MemoryRegion to DMA operations
  vfio: add region cache
  vfio: split out VFIOKernelPCIDevice
  vfio: add device IO ops vector
  vfio-user: add vfio-user class and container
  vfio-user: connect vfio proxy to remote server
  vfio-user: implement message receive infrastructure
  vfio-user: implement message send infrastructure
  vfio-user: implement VFIO_USER_DEVICE_GET_INFO
  vfio-user: implement VFIO_USER_DEVICE_GET_REGION_INFO
  vfio-user: implement VFIO_USER_REGION_READ/WRITE
  vfio-user: set up PCI in vfio_user_pci_realize()
  vfio-user: implement VFIO_USER_DEVICE_GET/SET_IRQ*
  vfio-user: forward MSI-X PBA BAR accesses to server
  vfio-user: set up container access to the proxy
  vfio-user: implement VFIO_USER_DEVICE_RESET
  vfio-user: implement VFIO_USER_DMA_READ/WRITE
  vfio-user: add 'no-direct-dma' option
  vfio-user: add 'x-msg-timeout' option
  vfio-user: add coalesced posted writes

John Levon (7):
  vfio/container: pass listener_begin/commit callbacks
  vfio/container: support VFIO_DMA_UNMAP_FLAG_ALL
  vfio: add vfio_attach_device_by_iommu_type()
  vfio: add vfio_prepare_device()
  vfio: refactor out vfio_interrupt_setup()
  vfio: refactor out vfio_pci_config_setup()
  vfio-user: implement VFIO_USER_DMA_MAP/UNMAP

Thanos Makatos (1):
  vfio-user: introduce vfio-user protocol specification

 MAINTAINERS                           |   10 +-
 docs/devel/index-internals.rst        |    1 +
 docs/devel/vfio-user.rst              | 1522 ++++++++++++++++++++++
 hw/meson.build                        |    1 +
 hw/vfio-user/common.c                 | 1702 +++++++++++++++++++++++++
 hw/vfio-user/common.h                 |  123 ++
 hw/vfio-user/container.c              |  358 ++++++
 hw/vfio-user/container.h              |   24 +
 hw/vfio-user/meson.build              |   10 +
 hw/vfio-user/pci.c                    |  443 +++++++
 hw/vfio-user/protocol.h               |  243 ++++
 hw/vfio-user/trace-events             |   18 +
 hw/vfio-user/trace.h                  |    1 +
 hw/vfio/ap.c                          |    4 +-
 hw/vfio/ccw.c                         |    9 +-
 hw/vfio/common.c                      |  137 +-
 hw/vfio/container-base.c              |    8 +-
 hw/vfio/container.c                   |   78 +-
 hw/vfio/helpers.c                     |  185 ++-
 hw/vfio/igd.c                         |    8 +-
 hw/vfio/iommufd.c                     |   31 +-
 hw/vfio/pci.c                         |  591 +++++----
 hw/vfio/pci.h                         |   34 +-
 hw/vfio/platform.c                    |    4 +-
 hw/virtio/vhost-vdpa.c                |    2 +-
 include/exec/memory.h                 |    4 +-
 include/hw/vfio/vfio-common.h         |   45 +-
 include/hw/vfio/vfio-container-base.h |   11 +-
 meson.build                           |    1 +
 meson_options.txt                     |    2 +
 scripts/meson-buildoptions.sh         |    4 +
 system/memory.c                       |    7 +-
 32 files changed, 5281 insertions(+), 340 deletions(-)
 create mode 100644 docs/devel/vfio-user.rst
 create mode 100644 hw/vfio-user/common.c
 create mode 100644 hw/vfio-user/common.h
 create mode 100644 hw/vfio-user/container.c
 create mode 100644 hw/vfio-user/container.h
 create mode 100644 hw/vfio-user/meson.build
 create mode 100644 hw/vfio-user/pci.c
 create mode 100644 hw/vfio-user/protocol.h
 create mode 100644 hw/vfio-user/trace-events
 create mode 100644 hw/vfio-user/trace.h

-- 
2.34.1

John,

On 2/19/25 15:48, John Levon wrote:
> This is the 8th revision of the vfio-user client implementation. The vfio-user
> protocol allows for implementing (PCI) devices in another userspace process;
> SPDK is one example, which includes a virtual NVMe implementation.
> 
> The vfio-user framework consists of 3 parts:
>   1) The VFIO user protocol specification.
>   2) A client - the VFIO device in QEMU that encapsulates VFIO messages
>      and sends them to the server.
>   3) A server - a remote process that emulates a device.
> 
> This patchset implements parts 1 and 2.
> 
> It has been tested against libvfio-user test servers as well as SPDK.
> 
> Thanks for previous reviews & comments.
> 
> Changes since v7:
> 
>   - split up pci patches for easier reviewing
>   - fixed lots of device ops error handling
>   - vfio-user code now in hw/vfio-user
>   - improved commit messages
>   - various other small cleanups

Could please resend next version on top

   https://github.com/legoater/qemu/commits/vfio-10.1

This is the branch in which I put the experimental stuff for the
current cycle. It contains today the  "spring cleanup" v2 series
I plan to send when QEMU 10.1 opens. Well, not exactly it because
I am waiting for some emails from Avihai to reach the list before
doing an update. It should be very close.

Also, could you please resend the vfio prerequisites only ? The
first 10 patches or so. It seems these could be merged soon. At
least checked for functional and performance regressions.

There are still relatively big changes in VFIO to discuss in these
patches:

   vfio-user: implement VFIO_USER_DEVICE_GET_REGION_INFO
   vfio-user: implement VFIO_USER_REGION_READ/WRITE
   vfio-user: set up PCI in vfio_user_pci_realize()
   vfio-user: forward MSI-X PBA BAR accesses to server

Something for later.
  
Thanks,

C.

John,

+Steven, for the Live upsate series.

On 2/19/25 15:48, John Levon wrote:
> This is the 8th revision of the vfio-user client implementation. The vfio-user
> protocol allows for implementing (PCI) devices in another userspace process;
> SPDK is one example, which includes a virtual NVMe implementation.
> 
> The vfio-user framework consists of 3 parts:
>   1) The VFIO user protocol specification.
>   2) A client - the VFIO device in QEMU that encapsulates VFIO messages
>      and sends them to the server.
>   3) A server - a remote process that emulates a device.
> 
> This patchset implements parts 1 and 2.
> 
> It has been tested against libvfio-user test servers as well as SPDK.
> 
> Thanks for previous reviews & comments.

This series is going in the right direction. Thanks for all the
changes. However, I will postpone my review for the reasons below.



VFIO initial commit in 2012 was a single file adding support for a
"vfio-pci" device. Since, the subsystem has changed a lot and it grew
to +16K line of code. Over the years, we've had numerous additions,
VFIO platform devices, s390x VFIO AP and CCW devices, migration
support with dirty tracking, support for different host IOMMU backend
devices, multifd, etc. All these additions never took the opportunity
to introduce a VFIO interface for external usage and PPC, s390x,
migration, backends subsystems happily and randomly peek and poke into
it. The subsystem is now a happy jumble of disparate functions, with
weak organization and names. The vfio-common.h header file is
good example of the result.

It's time for a global code reshuffling. I'll take care of it (and
I've already started) and this means nothing new (fixes are OK) will
be merged before this is done. I hope I have made enough progress
before the start of the QEMU 10.1 cycle. There won't be any functional
changes, but there will be new files and new function names, so it's
probably a real earthquake for your series.


Thanks,

C.


> 
> Changes since v7:
> 
>   - split up pci patches for easier reviewing
>   - fixed lots of device ops error handling
>   - vfio-user code now in hw/vfio-user
>   - improved commit messages
>   - various other small cleanups
> 
> Jagannathan Raman (20):
>    vfio/container: pass MemoryRegion to DMA operations
>    vfio: add region cache
>    vfio: split out VFIOKernelPCIDevice
>    vfio: add device IO ops vector
>    vfio-user: add vfio-user class and container
>    vfio-user: connect vfio proxy to remote server
>    vfio-user: implement message receive infrastructure
>    vfio-user: implement message send infrastructure
>    vfio-user: implement VFIO_USER_DEVICE_GET_INFO
>    vfio-user: implement VFIO_USER_DEVICE_GET_REGION_INFO
>    vfio-user: implement VFIO_USER_REGION_READ/WRITE
>    vfio-user: set up PCI in vfio_user_pci_realize()
>    vfio-user: implement VFIO_USER_DEVICE_GET/SET_IRQ*
>    vfio-user: forward MSI-X PBA BAR accesses to server
>    vfio-user: set up container access to the proxy
>    vfio-user: implement VFIO_USER_DEVICE_RESET
>    vfio-user: implement VFIO_USER_DMA_READ/WRITE
>    vfio-user: add 'no-direct-dma' option
>    vfio-user: add 'x-msg-timeout' option
>    vfio-user: add coalesced posted writes
> 
> John Levon (7):
>    vfio/container: pass listener_begin/commit callbacks
>    vfio/container: support VFIO_DMA_UNMAP_FLAG_ALL
>    vfio: add vfio_attach_device_by_iommu_type()
>    vfio: add vfio_prepare_device()
>    vfio: refactor out vfio_interrupt_setup()
>    vfio: refactor out vfio_pci_config_setup()
>    vfio-user: implement VFIO_USER_DMA_MAP/UNMAP
> 
> Thanos Makatos (1):
>    vfio-user: introduce vfio-user protocol specification
> 
>   MAINTAINERS                           |   10 +-
>   docs/devel/index-internals.rst        |    1 +
>   docs/devel/vfio-user.rst              | 1522 ++++++++++++++++++++++
>   hw/meson.build                        |    1 +
>   hw/vfio-user/common.c                 | 1702 +++++++++++++++++++++++++
>   hw/vfio-user/common.h                 |  123 ++
>   hw/vfio-user/container.c              |  358 ++++++
>   hw/vfio-user/container.h              |   24 +
>   hw/vfio-user/meson.build              |   10 +
>   hw/vfio-user/pci.c                    |  443 +++++++
>   hw/vfio-user/protocol.h               |  243 ++++
>   hw/vfio-user/trace-events             |   18 +
>   hw/vfio-user/trace.h                  |    1 +
>   hw/vfio/ap.c                          |    4 +-
>   hw/vfio/ccw.c                         |    9 +-
>   hw/vfio/common.c                      |  137 +-
>   hw/vfio/container-base.c              |    8 +-
>   hw/vfio/container.c                   |   78 +-
>   hw/vfio/helpers.c                     |  185 ++-
>   hw/vfio/igd.c                         |    8 +-
>   hw/vfio/iommufd.c                     |   31 +-
>   hw/vfio/pci.c                         |  591 +++++----
>   hw/vfio/pci.h                         |   34 +-
>   hw/vfio/platform.c                    |    4 +-
>   hw/virtio/vhost-vdpa.c                |    2 +-
>   include/exec/memory.h                 |    4 +-
>   include/hw/vfio/vfio-common.h         |   45 +-
>   include/hw/vfio/vfio-container-base.h |   11 +-
>   meson.build                           |    1 +
>   meson_options.txt                     |    2 +
>   scripts/meson-buildoptions.sh         |    4 +
>   system/memory.c                       |    7 +-
>   32 files changed, 5281 insertions(+), 340 deletions(-)
>   create mode 100644 docs/devel/vfio-user.rst
>   create mode 100644 hw/vfio-user/common.c
>   create mode 100644 hw/vfio-user/common.h
>   create mode 100644 hw/vfio-user/container.c
>   create mode 100644 hw/vfio-user/container.h
>   create mode 100644 hw/vfio-user/meson.build
>   create mode 100644 hw/vfio-user/pci.c
>   create mode 100644 hw/vfio-user/protocol.h
>   create mode 100644 hw/vfio-user/trace-events
>   create mode 100644 hw/vfio-user/trace.h
>

On Fri, Mar 14, 2025 at 03:25:53PM +0100, Cédric Le Goater wrote:

> > This is the 8th revision of the vfio-user client implementation. The vfio-user
> > protocol allows for implementing (PCI) devices in another userspace process;
> > SPDK is one example, which includes a virtual NVMe implementation.
> 
> This series is going in the right direction. Thanks for all the
> changes. However, I will postpone my review for the reasons below.
> 
> VFIO initial commit in 2012 was a single file adding support for a
> "vfio-pci" device. Since, the subsystem has changed a lot and it grew
> to +16K line of code. Over the years, we've had numerous additions,
> VFIO platform devices, s390x VFIO AP and CCW devices, migration
> support with dirty tracking, support for different host IOMMU backend
> devices, multifd, etc. All these additions never took the opportunity
> to introduce a VFIO interface for external usage and PPC, s390x,
> migration, backends subsystems happily and randomly peek and poke into
> it. The subsystem is now a happy jumble of disparate functions, with
> weak organization and names. The vfio-common.h header file is
> good example of the result.

Right, I certainly agree!

> It's time for a global code reshuffling. I'll take care of it (and
> I've already started) and this means nothing new (fixes are OK) will
> be merged before this is done. I hope I have made enough progress
> before the start of the QEMU 10.1 cycle. There won't be any functional
> changes, but there will be new files and new function names, so it's
> probably a real earthquake for your series.

It's had a couple of earthquakes already, very happy to bear the pain for a
better end result! I will try to look out for your series and review where I can
as well.

thanks
john

On 3/14/25 16:13, John Levon wrote:
> On Fri, Mar 14, 2025 at 03:25:53PM +0100, Cédric Le Goater wrote:
> 
>>> This is the 8th revision of the vfio-user client implementation. The vfio-user
>>> protocol allows for implementing (PCI) devices in another userspace process;
>>> SPDK is one example, which includes a virtual NVMe implementation.
>>
>> This series is going in the right direction. Thanks for all the
>> changes. However, I will postpone my review for the reasons below.
>>
>> VFIO initial commit in 2012 was a single file adding support for a
>> "vfio-pci" device. Since, the subsystem has changed a lot and it grew
>> to +16K line of code. Over the years, we've had numerous additions,
>> VFIO platform devices, s390x VFIO AP and CCW devices, migration
>> support with dirty tracking, support for different host IOMMU backend
>> devices, multifd, etc. All these additions never took the opportunity
>> to introduce a VFIO interface for external usage and PPC, s390x,
>> migration, backends subsystems happily and randomly peek and poke into
>> it. The subsystem is now a happy jumble of disparate functions, with
>> weak organization and names. The vfio-common.h header file is
>> good example of the result.
> 
> Right, I certainly agree!
> 
>> It's time for a global code reshuffling. I'll take care of it (and
>> I've already started) and this means nothing new (fixes are OK) will
>> be merged before this is done. I hope I have made enough progress
>> before the start of the QEMU 10.1 cycle. There won't be any functional
>> changes, but there will be new files and new function names, so it's
>> probably a real earthquake for your series.
> 
> It's had a couple of earthquakes already, very happy to bear the pain for a
> better end result! I will try to look out for your series and review where I can
> as well.

Here it is  :

   https://lore.kernel.org/qemu-devel/20250318095415.670319-1-clg@redhat.com/

Now is the time to prepare ground for your needs.

Thanks,

C.


> thanks
> john
> 

On 3/14/2025 10:25 AM, Cédric Le Goater wrote:
> John,
> 
> +Steven, for the Live upsate series.
> 
> On 2/19/25 15:48, John Levon wrote:
>> This is the 8th revision of the vfio-user client implementation. The vfio-user
>> protocol allows for implementing (PCI) devices in another userspace process;
>> SPDK is one example, which includes a virtual NVMe implementation.
>>
>> The vfio-user framework consists of 3 parts:
>>   1) The VFIO user protocol specification.
>>   2) A client - the VFIO device in QEMU that encapsulates VFIO messages
>>      and sends them to the server.
>>   3) A server - a remote process that emulates a device.
>>
>> This patchset implements parts 1 and 2.
>>
>> It has been tested against libvfio-user test servers as well as SPDK.
>>
>> Thanks for previous reviews & comments.
> 
> This series is going in the right direction. Thanks for all the
> changes. However, I will postpone my review for the reasons below.
> 
> VFIO initial commit in 2012 was a single file adding support for a
> "vfio-pci" device. Since, the subsystem has changed a lot and it grew
> to +16K line of code. Over the years, we've had numerous additions,
> VFIO platform devices, s390x VFIO AP and CCW devices, migration
> support with dirty tracking, support for different host IOMMU backend
> devices, multifd, etc. All these additions never took the opportunity
> to introduce a VFIO interface for external usage and PPC, s390x,
> migration, backends subsystems happily and randomly peek and poke into
> it. The subsystem is now a happy jumble of disparate functions, with
> weak organization and names. The vfio-common.h header file is
> good example of the result.
> 
> It's time for a global code reshuffling. I'll take care of it (and
> I've already started) and this means nothing new (fixes are OK) will
> be merged before this is done. I hope I have made enough progress
> before the start of the QEMU 10.1 cycle. There won't be any functional
> changes, but there will be new files and new function names, so it's
> probably a real earthquake for your series.

Hi Cedric, as part of your reshuffling, can you incorporate the code cleanup
patches that I submitted in the live update series?

- Steve

On 3/14/25 15:48, Steven Sistare wrote:
> 
> 
> On 3/14/2025 10:25 AM, Cédric Le Goater wrote:
>> John,
>>
>> +Steven, for the Live upsate series.
>>
>> On 2/19/25 15:48, John Levon wrote:
>>> This is the 8th revision of the vfio-user client implementation. The vfio-user
>>> protocol allows for implementing (PCI) devices in another userspace process;
>>> SPDK is one example, which includes a virtual NVMe implementation.
>>>
>>> The vfio-user framework consists of 3 parts:
>>>   1) The VFIO user protocol specification.
>>>   2) A client - the VFIO device in QEMU that encapsulates VFIO messages
>>>      and sends them to the server.
>>>   3) A server - a remote process that emulates a device.
>>>
>>> This patchset implements parts 1 and 2.
>>>
>>> It has been tested against libvfio-user test servers as well as SPDK.
>>>
>>> Thanks for previous reviews & comments.
>>
>> This series is going in the right direction. Thanks for all the
>> changes. However, I will postpone my review for the reasons below.
>>
>> VFIO initial commit in 2012 was a single file adding support for a
>> "vfio-pci" device. Since, the subsystem has changed a lot and it grew
>> to +16K line of code. Over the years, we've had numerous additions,
>> VFIO platform devices, s390x VFIO AP and CCW devices, migration
>> support with dirty tracking, support for different host IOMMU backend
>> devices, multifd, etc. All these additions never took the opportunity
>> to introduce a VFIO interface for external usage and PPC, s390x,
>> migration, backends subsystems happily and randomly peek and poke into
>> it. The subsystem is now a happy jumble of disparate functions, with
>> weak organization and names. The vfio-common.h header file is
>> good example of the result.
>>
>> It's time for a global code reshuffling. I'll take care of it (and
>> I've already started) and this means nothing new (fixes are OK) will
>> be merged before this is done. I hope I have made enough progress
>> before the start of the QEMU 10.1 cycle. There won't be any functional
>> changes, but there will be new files and new function names, so it's
>> probably a real earthquake for your series.
> 
> Hi Cedric, as part of your reshuffling, can you incorporate the code cleanup
> patches that I submitted in the live update series?


I will try when this series has had some reviews :

   https://lore.kernel.org/qemu-devel/20250318095415.670319-1-clg@redhat.com/

Thanks,

C.

I appreciate you posting the patches. I didn't author the patches, actually; John Johnson did it.

You could use your name as the author since you should be familiar with it now, and I can review the patches.

Please add the following to each patch so it recognizes Oracle's contribution:
Co-authored-by: John Johnson <john.g.johnson@oracle.com>

Thank you so much!

> On Feb 19, 2025, at 9:48 AM, John Levon <john.levon@nutanix.com> wrote:
> 
> This is the 8th revision of the vfio-user client implementation. The vfio-user
> protocol allows for implementing (PCI) devices in another userspace process;
> SPDK is one example, which includes a virtual NVMe implementation.
> 
> The vfio-user framework consists of 3 parts:
> 1) The VFIO user protocol specification.
> 2) A client - the VFIO device in QEMU that encapsulates VFIO messages
>    and sends them to the server.
> 3) A server - a remote process that emulates a device.
> 
> This patchset implements parts 1 and 2.
> 
> It has been tested against libvfio-user test servers as well as SPDK.
> 
> Thanks for previous reviews & comments.
> 
> Changes since v7:
> 
> - split up pci patches for easier reviewing
> - fixed lots of device ops error handling
> - vfio-user code now in hw/vfio-user
> - improved commit messages
> - various other small cleanups
> 
> Jagannathan Raman (20):
>  vfio/container: pass MemoryRegion to DMA operations
>  vfio: add region cache
>  vfio: split out VFIOKernelPCIDevice
>  vfio: add device IO ops vector
>  vfio-user: add vfio-user class and container
>  vfio-user: connect vfio proxy to remote server
>  vfio-user: implement message receive infrastructure
>  vfio-user: implement message send infrastructure
>  vfio-user: implement VFIO_USER_DEVICE_GET_INFO
>  vfio-user: implement VFIO_USER_DEVICE_GET_REGION_INFO
>  vfio-user: implement VFIO_USER_REGION_READ/WRITE
>  vfio-user: set up PCI in vfio_user_pci_realize()
>  vfio-user: implement VFIO_USER_DEVICE_GET/SET_IRQ*
>  vfio-user: forward MSI-X PBA BAR accesses to server
>  vfio-user: set up container access to the proxy
>  vfio-user: implement VFIO_USER_DEVICE_RESET
>  vfio-user: implement VFIO_USER_DMA_READ/WRITE
>  vfio-user: add 'no-direct-dma' option
>  vfio-user: add 'x-msg-timeout' option
>  vfio-user: add coalesced posted writes
> 
> John Levon (7):
>  vfio/container: pass listener_begin/commit callbacks
>  vfio/container: support VFIO_DMA_UNMAP_FLAG_ALL
>  vfio: add vfio_attach_device_by_iommu_type()
>  vfio: add vfio_prepare_device()
>  vfio: refactor out vfio_interrupt_setup()
>  vfio: refactor out vfio_pci_config_setup()
>  vfio-user: implement VFIO_USER_DMA_MAP/UNMAP
> 
> Thanos Makatos (1):
>  vfio-user: introduce vfio-user protocol specification
> 
> MAINTAINERS                           |   10 +-
> docs/devel/index-internals.rst        |    1 +
> docs/devel/vfio-user.rst              | 1522 ++++++++++++++++++++++
> hw/meson.build                        |    1 +
> hw/vfio-user/common.c                 | 1702 +++++++++++++++++++++++++
> hw/vfio-user/common.h                 |  123 ++
> hw/vfio-user/container.c              |  358 ++++++
> hw/vfio-user/container.h              |   24 +
> hw/vfio-user/meson.build              |   10 +
> hw/vfio-user/pci.c                    |  443 +++++++
> hw/vfio-user/protocol.h               |  243 ++++
> hw/vfio-user/trace-events             |   18 +
> hw/vfio-user/trace.h                  |    1 +
> hw/vfio/ap.c                          |    4 +-
> hw/vfio/ccw.c                         |    9 +-
> hw/vfio/common.c                      |  137 +-
> hw/vfio/container-base.c              |    8 +-
> hw/vfio/container.c                   |   78 +-
> hw/vfio/helpers.c                     |  185 ++-
> hw/vfio/igd.c                         |    8 +-
> hw/vfio/iommufd.c                     |   31 +-
> hw/vfio/pci.c                         |  591 +++++----
> hw/vfio/pci.h                         |   34 +-
> hw/vfio/platform.c                    |    4 +-
> hw/virtio/vhost-vdpa.c                |    2 +-
> include/exec/memory.h                 |    4 +-
> include/hw/vfio/vfio-common.h         |   45 +-
> include/hw/vfio/vfio-container-base.h |   11 +-
> meson.build                           |    1 +
> meson_options.txt                     |    2 +
> scripts/meson-buildoptions.sh         |    4 +
> system/memory.c                       |    7 +-
> 32 files changed, 5281 insertions(+), 340 deletions(-)
> create mode 100644 docs/devel/vfio-user.rst
> create mode 100644 hw/vfio-user/common.c
> create mode 100644 hw/vfio-user/common.h
> create mode 100644 hw/vfio-user/container.c
> create mode 100644 hw/vfio-user/container.h
> create mode 100644 hw/vfio-user/meson.build
> create mode 100644 hw/vfio-user/pci.c
> create mode 100644 hw/vfio-user/protocol.h
> create mode 100644 hw/vfio-user/trace-events
> create mode 100644 hw/vfio-user/trace.h
> 
> -- 
> 2.34.1
> 
> 

On Fri, Feb 28, 2025 at 05:09:00PM +0000, Jag Raman wrote:

> I appreciate you posting the patches. I didn't author the patches, actually;
> John Johnson did it.

I'll adjust the Author field and fix up the "Originally-by" tags for the next
round, thanks.

> You could use your name as the author since you should be familiar with it
> now, and I can review the patches.

This doesn't sound like the right thing to do: for most of these patches, I've
at best made small changes and JJ should remain the primary author, I think?

> Please add the following to each patch so it recognizes Oracle's contribution:
> Co-authored-by: John Johnson <john.g.johnson@oracle.com>

I can add these as well as having JJ as author if you'd prefer.

regards
john

> On Mar 3, 2025, at 6:19 AM, John Levon <john.levon@nutanix.com> wrote:
> 
> On Fri, Feb 28, 2025 at 05:09:00PM +0000, Jag Raman wrote:
> 
>> I appreciate you posting the patches. I didn't author the patches, actually;
>> John Johnson did it.
> 
> I'll adjust the Author field and fix up the "Originally-by" tags for the next
> round, thanks.
> 
>> You could use your name as the author since you should be familiar with it
>> now, and I can review the patches.
> 
> This doesn't sound like the right thing to do: for most of these patches, I've
> at best made small changes and JJ should remain the primary author, I think?
> 
>> Please add the following to each patch so it recognizes Oracle's contribution:
>> Co-authored-by: John Johnson <john.g.johnson@oracle.com>
> 
> I can add these as well as having JJ as author if you'd prefer.

That sounds good to me.

Thanks,
Jag

> 
> regards
> john