Re: [PATCH v2 03/23] vfio-user: add container IO ops vector

[Alex Williamson]

On Wed,  1 Feb 2023 21:55:39 -0800
John Johnson <john.g.johnson@oracle.com> wrote:

> Used for communication with VFIO driver
> (prep work for vfio-user, which will communicate over a socket)
> 
> Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
> ---
>  include/hw/vfio/vfio-common.h |  24 ++++++++
>  hw/vfio/common.c              | 128 
> ++++++++++++++++++++++++++++--------------
>  2 files changed, 110 insertions(+), 42 deletions(-)
> 
> diff --git a/include/hw/vfio/vfio-common.h b/include/hw/vfio/vfio-common.h
> index e573f5a..953bc0f 100644
> --- a/include/hw/vfio/vfio-common.h
> +++ b/include/hw/vfio/vfio-common.h
> @@ -75,6 +75,7 @@ typedef struct VFIOAddressSpace {
>  } VFIOAddressSpace;
>  
>  struct VFIOGroup;
> +typedef struct VFIOContainerIO VFIOContainerIO;
>  
>  typedef struct VFIOContainer {
>      VFIOAddressSpace *space;
> @@ -83,6 +84,7 @@ typedef struct VFIOContainer {
>      MemoryListener prereg_listener;
>      unsigned iommu_type;
>      Error *error;
> +    VFIOContainerIO *io;
>      bool initialized;
>      bool dirty_pages_supported;
>      uint64_t dirty_pgsizes;
> @@ -154,6 +156,28 @@ struct VFIODeviceOps {
>      int (*vfio_load_config)(VFIODevice *vdev, QEMUFile *f);
>  };
>  
> +#ifdef CONFIG_LINUX
> +
> +/*
> + * The next 2 ops vectors are how Devices and Containers
> + * communicate with the server.  The default option is
> + * through ioctl() to the kernel VFIO driver, but vfio-user
> + * can use a socket to a remote process.
> + */
> +
> +struct VFIOContainerIO {
> +    int (*dma_map)(VFIOContainer *container,
> +                   struct vfio_iommu_type1_dma_map *map);
> +    int (*dma_unmap)(VFIOContainer *container,
> +                     struct vfio_iommu_type1_dma_unmap *unmap,
> +                     struct vfio_bitmap *bitmap);
> +    int (*dirty_bitmap)(VFIOContainer *container,
> +                        struct vfio_iommu_type1_dirty_bitmap *bitmap,
> +                        struct vfio_iommu_type1_dirty_bitmap_get *range);
> +};
> +
> +#endif /* CONFIG_LINUX */
> +
>  typedef struct VFIOGroup {
>      int fd;
>      int groupid;
> diff --git a/hw/vfio/common.c b/hw/vfio/common.c
> index ace9562..9310a7f 100644
> --- a/hw/vfio/common.c
> +++ b/hw/vfio/common.c
> @@ -58,6 +58,8 @@ static QLIST_HEAD(, VFIOAddressSpace) vfio_address_spaces =
>  static int vfio_kvm_device_fd = -1;
>  #endif
>  
> +static VFIOContainerIO vfio_cont_io_ioctl;
> +
>  /*
>   * Common VFIO interrupt disable
>   */
> @@ -432,12 +434,12 @@ static int vfio_dma_unmap_bitmap(VFIOContainer 
> *container,
>          goto unmap_exit;
>      }
>  
> -    ret = ioctl(container->fd, VFIO_IOMMU_UNMAP_DMA, unmap);
> +    ret = container->io->dma_unmap(container, unmap, bitmap);

The bitmap arg doesn't make a lot of sense here, its use doesn't come
around until vfio_user_dma_unmap() is added, but even then, it's
readily available at &unmap->data with validity determined by
unmap->flags.  The eventual sanity test in vfio_user_dma_unmap() really
only seems to prove the arg is unnecessary.  Thanks,

Alex