From: Jason Gunthorpe <jgg@nvidia.com>
To: Joao Martins <joao.m.martins@oracle.com>
Cc: iommu@lists.linux.dev, Kevin Tian <kevin.tian@intel.com>,
Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>,
Lu Baolu <baolu.lu@linux.intel.com>, Yi Liu <yi.l.liu@intel.com>,
Yi Y Sun <yi.y.sun@intel.com>, Nicolin Chen <nicolinc@nvidia.com>,
Joerg Roedel <joro@8bytes.org>,
Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
Alex Williamson <alex.williamson@redhat.com>,
kvm@vger.kernel.org
Subject: Re: [PATCH v3 02/19] vfio: Move iova_bitmap into iommu core
Date: Fri, 13 Oct 2023 14:28:49 -0300 [thread overview]
Message-ID: <20231013172849.GJ3952@nvidia.com> (raw)
In-Reply-To: <77579409-c318-4bba-8503-637f4653c220@oracle.com>
On Fri, Oct 13, 2023 at 06:23:09PM +0100, Joao Martins wrote:
>
>
> On 13/10/2023 18:16, Jason Gunthorpe wrote:
> > On Fri, Oct 13, 2023 at 06:10:04PM +0100, Joao Martins wrote:
> >> On 13/10/2023 17:00, Joao Martins wrote:
> >>> On 13/10/2023 16:48, Jason Gunthorpe wrote:
> >>>> On Sat, Sep 23, 2023 at 02:24:54AM +0100, Joao Martins wrote:
> >>>>> Both VFIO and IOMMUFD will need iova bitmap for storing dirties and walking
> >>>>> the user bitmaps, so move to the common dependency into IOMMU core. IOMMUFD
> >>>>> can't exactly host it given that VFIO dirty tracking can be used without
> >>>>> IOMMUFD.
> >>>>
> >>>> Hum, this seems strange. Why not just make those VFIO drivers depends
> >>>> on iommufd? That seems harmless to me.
> >>>>
> >>>
> >>> IF you and Alex are OK with it then I can move to IOMMUFD.
> >>>
> >>>> However, I think the real issue is that iommu drivers need to use this
> >>>> API too for their part?
> >>>>
> >>>
> >>> Exactly.
> >>>
> >>
> >> My other concern into moving to IOMMUFD instead of core was VFIO_IOMMU_TYPE1,
> >> and if we always make it depend on IOMMUFD then we can't have what is today
> >> something supported because of VFIO_IOMMU_TYPE1 stuff with migration drivers
> >> (i.e. vfio-iommu-type1 with the live migration stuff).
> >
> > I plan to remove the live migration stuff from vfio-iommu-type1, it is
> > all dead code now.
> >
>
> I wasn't referring to the type1 dirty tracking stuff -- I was referring the
> stuff related to vfio devices, used *together* with type1 (for DMA
> map/unmap).
Ah, well, I guess that is true
> >> But if it's exists an IOMMUFD_DRIVER kconfig, then VFIO_CONTAINER can instead
> >> select the IOMMUFD_DRIVER alone so long as CONFIG_IOMMUFD isn't required? I am
> >> essentially talking about:
> >
> > Not VFIO_CONTAINER, the dirty tracking code is in vfio_main:
> >
> > vfio_main.c:#include <linux/iova_bitmap.h>
> > vfio_main.c:static int vfio_device_log_read_and_clear(struct iova_bitmap *iter,
> > vfio_main.c: struct iova_bitmap *iter;
> > vfio_main.c: iter = iova_bitmap_alloc(report.iova, report.length,
> > vfio_main.c: ret = iova_bitmap_for_each(iter, device,
> > vfio_main.c: iova_bitmap_free(iter);
> >
> > And in various vfio device drivers.
> >
> > So the various drivers can select IOMMUFD_DRIVER
> >
>
> It isn't so much that type1 requires IOMMUFD, but more that it is used together
> with the core code that allows the vfio drivers to do migration. So the concern
> is if we make VFIO core depend on IOMMU that we prevent
> VFIO_CONTAINER/VFIO_GROUP to not be selected. My kconfig read was that we either
> select VFIO_GROUP or VFIO_DEVICE_CDEV but not both
Doing it as I said is still the right thing.
If someone has turned on one of the drivers that actually implements
dirty tracking it will turn on IOMMUFD_DRIVER and that will cause the
supporting core code to compile in the support functions.
Jason
next prev parent reply other threads:[~2023-10-13 17:28 UTC|newest]
Thread overview: 140+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-23 1:24 [PATCH v3 00/19] IOMMUFD Dirty Tracking Joao Martins
2023-09-23 1:24 ` [PATCH v3 01/19] vfio/iova_bitmap: Export more API symbols Joao Martins
2023-10-13 15:43 ` Jason Gunthorpe
2023-10-13 15:57 ` Joao Martins
2023-10-13 16:03 ` Jason Gunthorpe
2023-10-13 16:22 ` Joao Martins
2023-09-23 1:24 ` [PATCH v3 02/19] vfio: Move iova_bitmap into iommu core Joao Martins
2023-10-13 15:48 ` Jason Gunthorpe
2023-10-13 16:00 ` Joao Martins
2023-10-13 16:04 ` Jason Gunthorpe
2023-10-13 16:23 ` Joao Martins
2023-10-13 17:10 ` Joao Martins
2023-10-13 17:16 ` Jason Gunthorpe
2023-10-13 17:23 ` Joao Martins
2023-10-13 17:28 ` Jason Gunthorpe [this message]
2023-10-13 17:32 ` Joao Martins
2023-10-13 20:41 ` Alex Williamson
2023-10-13 21:20 ` Joao Martins
2023-10-13 21:51 ` Alex Williamson
2023-10-14 0:02 ` Jason Gunthorpe
2023-10-16 16:25 ` Joao Martins
2023-10-16 16:34 ` Jason Gunthorpe
2023-10-16 17:52 ` Joao Martins
2023-10-16 18:05 ` Jason Gunthorpe
2023-10-16 18:15 ` Joao Martins
2023-10-16 18:20 ` Jason Gunthorpe
2023-10-16 18:37 ` Joao Martins
2023-10-16 18:50 ` Joao Martins
2023-10-17 12:58 ` Jason Gunthorpe
2023-10-17 15:20 ` Joao Martins
2023-10-17 15:23 ` Jason Gunthorpe
2023-10-17 15:44 ` Joao Martins
2023-10-18 10:19 ` Joao Martins
2023-10-18 12:03 ` Jason Gunthorpe
2023-10-18 12:48 ` Joao Martins
2023-10-18 14:23 ` Jason Gunthorpe
2023-10-18 15:34 ` Joao Martins
2023-10-18 15:43 ` Jason Gunthorpe
2023-09-23 1:24 ` [PATCH v3 03/19] iommu: Add iommu_domain ops for dirty tracking Joao Martins
2023-10-13 16:05 ` Jason Gunthorpe
2023-10-13 16:27 ` Joao Martins
2023-09-23 1:24 ` [PATCH v3 04/19] iommufd: Add a flag to enforce dirty tracking on attach Joao Martins
2023-10-13 15:52 ` Jason Gunthorpe
2023-10-13 16:14 ` Joao Martins
2023-10-13 16:16 ` Jason Gunthorpe
2023-10-13 16:29 ` Joao Martins
2023-09-23 1:24 ` [PATCH v3 05/19] iommufd/selftest: Expand mock_domain with dev_flags Joao Martins
2023-10-13 16:02 ` Jason Gunthorpe
2023-10-13 16:21 ` Joao Martins
2023-09-23 1:24 ` [PATCH v3 06/19] iommufd/selftest: Test IOMMU_HWPT_ALLOC_ENFORCE_DIRTY Joao Martins
2023-09-23 1:24 ` [PATCH v3 07/19] iommufd: Dirty tracking data support Joao Martins
2023-09-23 1:40 ` Joao Martins
2023-10-17 12:06 ` Joao Martins
2023-10-17 15:29 ` Jason Gunthorpe
2023-10-17 15:51 ` Joao Martins
2023-10-17 16:01 ` Jason Gunthorpe
2023-10-17 16:51 ` Joao Martins
2023-10-17 17:13 ` Jason Gunthorpe
2023-10-17 17:30 ` Joao Martins
2023-10-17 18:14 ` Joao Martins
2023-09-23 1:25 ` [PATCH v3 08/19] iommufd: Add IOMMU_HWPT_SET_DIRTY Joao Martins
2023-10-13 16:13 ` Jason Gunthorpe
2023-09-23 1:25 ` [PATCH v3 09/19] iommufd/selftest: Test IOMMU_HWPT_SET_DIRTY Joao Martins
2023-09-23 1:25 ` [PATCH v3 10/19] iommufd: Add IOMMU_HWPT_GET_DIRTY_IOVA Joao Martins
2023-10-13 16:22 ` Jason Gunthorpe
2023-10-13 16:58 ` Joao Martins
2023-10-13 17:03 ` Jason Gunthorpe
2023-09-23 1:25 ` [PATCH v3 11/19] iommufd/selftest: Test IOMMU_HWPT_GET_DIRTY_IOVA Joao Martins
2023-09-23 1:25 ` [PATCH v3 12/19] iommufd: Add capabilities to IOMMU_GET_HW_INFO Joao Martins
2023-09-23 1:25 ` [PATCH v3 13/19] iommufd/selftest: Test out_capabilities in IOMMU_GET_HW_INFO Joao Martins
2023-09-23 1:25 ` [PATCH v3 14/19] iommufd: Add a flag to skip clearing of IOPTE dirty Joao Martins
2023-09-23 1:25 ` [PATCH v3 15/19] iommufd/selftest: Test IOMMU_GET_DIRTY_IOVA_NO_CLEAR flag Joao Martins
2023-09-23 1:25 ` [PATCH v3 16/19] iommu/amd: Add domain_alloc_user based domain allocation Joao Martins
2023-10-17 2:00 ` Suthikulpanit, Suravee
2023-10-17 9:07 ` Joao Martins
2023-10-17 13:10 ` Jason Gunthorpe
2023-10-17 14:14 ` Joao Martins
2023-10-17 14:37 ` Joao Martins
2023-10-17 15:32 ` Jason Gunthorpe
2023-10-18 8:29 ` Vasant Hegde
2023-09-23 1:25 ` [PATCH v3 17/19] iommu/amd: Access/Dirty bit support in IOPTEs Joao Martins
2023-10-04 17:01 ` Joao Martins
2023-10-17 8:18 ` Suthikulpanit, Suravee
2023-10-17 9:54 ` Joao Martins
2023-10-17 18:32 ` Joao Martins
2023-10-17 18:49 ` Jason Gunthorpe
2023-10-17 19:03 ` Joao Martins
2023-10-17 22:04 ` Joao Martins
2023-10-18 11:47 ` Suthikulpanit, Suravee
2023-10-18 20:40 ` Joao Martins
2023-10-18 11:46 ` Suthikulpanit, Suravee
2023-10-18 13:04 ` Suthikulpanit, Suravee
2023-10-18 13:17 ` Joao Martins
2023-10-18 13:31 ` Joao Martins
2023-10-18 15:50 ` Jason Gunthorpe
2023-09-23 1:25 ` [PATCH v3 18/19] iommu/amd: Print access/dirty bits if supported Joao Martins
2023-10-17 3:48 ` Suthikulpanit, Suravee
2023-10-17 9:07 ` Joao Martins
2023-10-18 8:32 ` Vasant Hegde
2023-10-18 8:53 ` Joao Martins
2023-10-18 9:03 ` Vasant Hegde
2023-10-18 9:05 ` Joao Martins
2023-10-18 15:52 ` Jason Gunthorpe
2023-10-18 15:55 ` Joao Martins
2023-09-23 1:25 ` [PATCH v3 19/19] iommu/intel: Access/Dirty bit support for SL domains Joao Martins
2023-09-25 7:01 ` Baolu Lu
2023-09-25 9:08 ` Joao Martins
2023-10-16 2:26 ` Baolu Lu
2023-10-16 0:51 ` Baolu Lu
2023-10-16 10:42 ` Joao Martins
2023-10-16 12:41 ` Baolu Lu
2023-10-16 1:37 ` Baolu Lu
2023-10-16 10:57 ` Joao Martins
2023-10-16 11:42 ` Jason Gunthorpe
2023-10-16 12:58 ` Baolu Lu
2023-10-16 12:59 ` Jason Gunthorpe
2023-10-16 13:01 ` Baolu Lu
2023-10-17 10:51 ` Joao Martins
2023-10-17 12:41 ` Baolu Lu
2023-10-17 14:16 ` Joao Martins
2023-10-17 14:25 ` Joao Martins
2023-10-18 2:06 ` Baolu Lu
2023-10-16 2:07 ` Baolu Lu
2023-10-16 11:26 ` Joao Martins
2023-10-16 16:00 ` Joao Martins
2023-10-17 2:08 ` Baolu Lu
2023-10-17 11:22 ` Joao Martins
2023-10-17 12:49 ` Baolu Lu
2023-10-17 14:19 ` Joao Martins
2023-10-17 13:10 ` Jason Gunthorpe
2023-10-17 14:11 ` Joao Martins
2023-10-17 15:31 ` Jason Gunthorpe
2023-10-17 15:54 ` Joao Martins
2023-10-16 2:21 ` Baolu Lu
2023-10-16 11:39 ` Joao Martins
2023-10-16 13:06 ` Baolu Lu
2023-09-26 8:58 ` [PATCH v3 00/19] IOMMUFD Dirty Tracking Shameerali Kolothum Thodi
2023-10-13 16:29 ` Jason Gunthorpe
2023-10-13 18:11 ` Joao Martins
2023-10-14 7:53 ` Baolu Lu
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=20231013172849.GJ3952@nvidia.com \
--to=jgg@nvidia.com \
--cc=alex.williamson@redhat.com \
--cc=baolu.lu@linux.intel.com \
--cc=iommu@lists.linux.dev \
--cc=joao.m.martins@oracle.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=nicolinc@nvidia.com \
--cc=robin.murphy@arm.com \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=will@kernel.org \
--cc=yi.l.liu@intel.com \
--cc=yi.y.sun@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.