From: Alex Williamson <alex.williamson@redhat.com>
To: John Johnson <john.g.johnson@oracle.com>
Cc: qemu-devel@nongnu.org, clg@redhat.com, philmd@linaro.org
Subject: Re: [PATCH v2 03/23] vfio-user: add container IO ops vector
Date: Fri, 3 Feb 2023 15:33:33 -0700 [thread overview]
Message-ID: <20230203153333.095b0827.alex.williamson@redhat.com> (raw)
In-Reply-To: <20230203152109.60a8cd33.alex.williamson@redhat.com>
On Fri, 3 Feb 2023 15:21:09 -0700
Alex Williamson <alex.williamson@redhat.com> wrote:
> 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,
The same comment really applies to .dirty_bitmap() with respect to the
range arg, but I think it's also important to note that both of these
are all but deprecated interfaces for the kernel. The migration
series[1] is pre-enabling these kernel interfaces to be removed by
adding support to QEMU to dirty all pages when support isn't present,
then we replace it with what we expect to be a longer term solution
with device dirty tracking support[2]. All the more reason not to make
these part of the internal API shared by kernel and user versions.
Thanks,
Alex
[1]https://lore.kernel.org/all/20230116141135.12021-1-avihaih@nvidia.com/
[2]https://lore.kernel.org/all/20230126184948.10478-1-avihaih@nvidia.com/
next prev parent reply other threads:[~2023-02-03 22:34 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-02 5:55 [PATCH v2 00/23] vfio-user client John Johnson
2023-02-02 5:55 ` [PATCH v2 01/23] vfio-user: introduce vfio-user protocol specification John Johnson
2023-02-02 5:55 ` [PATCH v2 02/23] vfio-user: add VFIO base abstract class John Johnson
2023-02-02 5:55 ` [PATCH v2 03/23] vfio-user: add container IO ops vector John Johnson
2023-02-03 22:21 ` Alex Williamson
2023-02-03 22:33 ` Alex Williamson [this message]
2023-02-02 5:55 ` [PATCH v2 04/23] vfio-user: add region cache John Johnson
2023-02-02 5:55 ` [PATCH v2 05/23] vfio-user: add device IO ops vector John Johnson
2023-02-02 5:55 ` [PATCH v2 06/23] vfio-user: Define type vfio_user_pci_dev_info John Johnson
2023-02-02 5:55 ` [PATCH v2 07/23] vfio-user: connect vfio proxy to remote server John Johnson
2023-02-02 5:55 ` [PATCH v2 08/23] vfio-user: define socket receive functions John Johnson
2023-02-02 5:55 ` [PATCH v2 09/23] vfio-user: define socket send functions John Johnson
2023-02-02 5:55 ` [PATCH v2 10/23] vfio-user: get device info John Johnson
2023-02-02 5:55 ` [PATCH v2 11/23] vfio-user: get region info John Johnson
2023-02-03 23:11 ` Alex Williamson
2023-02-02 5:55 ` [PATCH v2 12/23] vfio-user: region read/write John Johnson
2023-02-06 19:07 ` Alex Williamson
2023-02-08 6:38 ` John Johnson
2023-02-08 20:33 ` Alex Williamson
2023-02-10 5:28 ` John Johnson
2023-02-02 5:55 ` [PATCH v2 13/23] vfio-user: pci_user_realize PCI setup John Johnson
2023-02-02 5:55 ` [PATCH v2 14/23] vfio-user: get and set IRQs John Johnson
2023-02-02 5:55 ` [PATCH v2 15/23] vfio-user: forward msix BAR accesses to server John Johnson
2023-02-06 20:33 ` Alex Williamson
2023-02-08 6:38 ` John Johnson
2023-02-08 21:30 ` Alex Williamson
2023-02-10 5:28 ` John Johnson
2023-02-02 5:55 ` [PATCH v2 16/23] vfio-user: proxy container connect/disconnect John Johnson
2023-02-02 5:55 ` [PATCH v2 17/23] vfio-user: dma map/unmap operations John Johnson
2023-02-03 21:28 ` Alex Williamson
2023-02-06 20:58 ` Alex Williamson
2023-02-02 5:55 ` [PATCH v2 18/23] vfio-user: add dma_unmap_all John Johnson
2023-02-06 21:29 ` Alex Williamson
2023-02-02 5:55 ` [PATCH v2 19/23] vfio-user: no-mmap DMA support John Johnson
2023-02-02 5:55 ` [PATCH v2 20/23] vfio-user: dma read/write operations John Johnson
2023-02-02 5:55 ` [PATCH v2 21/23] vfio-user: pci reset John Johnson
2023-02-02 5:55 ` [PATCH v2 22/23] vfio-user: add 'x-msg-timeout' option that specifies msg wait times John Johnson
2023-02-02 5:55 ` [PATCH v2 23/23] vfio-user: add coalesced posted writes John Johnson
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=20230203153333.095b0827.alex.williamson@redhat.com \
--to=alex.williamson@redhat.com \
--cc=clg@redhat.com \
--cc=john.g.johnson@oracle.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).