public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Joao Martins <joao.m.martins@oracle.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
	Joerg Roedel <joro@8bytes.org>,
	Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
	Will Deacon <will@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Jean-Philippe Brucker <jean-philippe@linaro.org>,
	Keqian Zhu <zhukeqian1@huawei.com>,
	Shameerali Kolothum Thodi  <shameerali.kolothum.thodi@huawei.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Lu Baolu <baolu.lu@linux.intel.com>,
	Nicolin Chen <nicolinc@nvidia.com>,
	Yishai Hadas <yishaih@nvidia.com>,
	Eric Auger <eric.auger@redhat.com>,
	"Liu, Yi L" <yi.l.liu@intel.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Cornelia Huck <cohuck@redhat.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>
Subject: Re: [PATCH RFC 00/19] IOMMUFD Dirty Tracking
Date: Thu, 21 Jul 2022 11:24:21 -0300	[thread overview]
Message-ID: <20220721142421.GB4609@nvidia.com> (raw)
In-Reply-To: <b97658a2-2eb4-11d4-d957-e7d9d9eeb85b@oracle.com>

On Tue, Jul 12, 2022 at 07:34:48PM +0100, Joao Martins wrote:

> > In general I saw three options here:
> > 
> > a) 'try and fail' when creating the domain. It succeeds only when
> > all iommus support tracking;
> > 
> > b) capability reported on iommu domain. The capability is reported true
> > only when all iommus support tracking. This allows domain property
> > to be set after domain is created. But there is no much gain of doing
> > so when comparing to a).
> > 
> > c) capability reported on device. future compatible for heterogenous
> > platform. domain property is specified at domain creation and domains
> > can have different properties based on tracking capability of attached
> > devices.
> > 
> > I'm inclined to c) as it is more aligned to Robin's cleanup effort on
> > iommu_capable() and iommu_present() in the iommu layer which
> > moves away from global manner to per-device style. Along with 
> > that direction I guess we want to discourage adding more APIs
> > assuming 'all iommus supporting certain capability' thing?
> > 
> 
> Not sure where we are left off on this one, so hopefully just for my own
> clarification on what we see is the path forward.

I prefer we stick to the APIs we know we already need.

We need an API to create an iommu_domain for a device with a bunch of
parameters. "I want dirty tracking" is a very reasonable parameter to
put here. This can support "try and fail" if we want.

We certainly need "c", somehow the userspace needs to know what inputs
the create domain call will accept - minimally it needs to know what
the IOMMU driver is under the device so it knows how to ask for a user
space page table. This could also report other paramters that are
interesting, like "device could support dirty tracking"

Having the domain set to dirty tracking also means that it will refuse
to attach to any device that doesn't have dirty tracking support (eg
if there are non-uniformity in the iommu) - this composes will with
the EMEDIUMTYPE work

So, I would only change from your proposal to move to the create
domain command. Which we should really pull out of one of the HW
branchs and lock down RSN..

Jason

  reply	other threads:[~2022-07-21 14:25 UTC|newest]

Thread overview: 108+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-28 21:09 [PATCH RFC 00/19] IOMMUFD Dirty Tracking Joao Martins
2022-04-28 21:09 ` [PATCH RFC 01/19] iommu: Add iommu_domain ops for dirty tracking Joao Martins
2022-04-29  7:54   ` Tian, Kevin
2022-04-29 10:44     ` Joao Martins
2022-04-29 12:08   ` Jason Gunthorpe
2022-04-29 14:26     ` Joao Martins
2022-04-29 14:35       ` Jason Gunthorpe
2022-04-29 13:40   ` Baolu Lu
2022-04-29 15:27     ` Joao Martins
2022-04-28 21:09 ` [PATCH RFC 02/19] iommufd: Dirty tracking for io_pagetable Joao Martins
2022-04-29  8:07   ` Tian, Kevin
2022-04-29 10:48     ` Joao Martins
2022-04-29 11:56     ` Jason Gunthorpe
2022-04-29 14:28       ` Joao Martins
2022-04-29 23:51   ` Baolu Lu
2022-05-02 11:57     ` Joao Martins
2022-08-29 10:01   ` Shameerali Kolothum Thodi
2022-04-28 21:09 ` [PATCH RFC 03/19] iommufd: Dirty tracking data support Joao Martins
2022-04-29  8:12   ` Tian, Kevin
2022-04-29 10:54     ` Joao Martins
2022-04-29 12:09       ` Jason Gunthorpe
2022-04-29 14:33         ` Joao Martins
2022-04-30  4:11   ` Baolu Lu
2022-05-02 12:06     ` Joao Martins
2022-04-28 21:09 ` [PATCH RFC 04/19] iommu: Add an unmap API that returns dirtied IOPTEs Joao Martins
2022-04-30  5:12   ` Baolu Lu
2022-05-02 12:22     ` Joao Martins
2022-04-28 21:09 ` [PATCH RFC 05/19] iommufd: Add a dirty bitmap to iopt_unmap_iova() Joao Martins
2022-04-29 12:14   ` Jason Gunthorpe
2022-04-29 14:36     ` Joao Martins
2022-04-28 21:09 ` [PATCH RFC 06/19] iommufd: Dirty tracking IOCTLs for the hw_pagetable Joao Martins
2022-04-28 21:09 ` [PATCH RFC 07/19] iommufd/vfio-compat: Dirty tracking IOCTLs compatibility Joao Martins
2022-04-29 12:19   ` Jason Gunthorpe
2022-04-29 14:27     ` Joao Martins
2022-04-29 14:36       ` Jason Gunthorpe
2022-04-29 14:52         ` Joao Martins
2022-04-28 21:09 ` [PATCH RFC 08/19] iommufd: Add a test for dirty tracking ioctls Joao Martins
2022-04-28 21:09 ` [PATCH RFC 09/19] iommu/amd: Access/Dirty bit support in IOPTEs Joao Martins
2022-05-31 11:34   ` Suravee Suthikulpanit
2022-05-31 12:15     ` Baolu Lu
2022-05-31 15:22     ` Joao Martins
2022-04-28 21:09 ` [PATCH RFC 10/19] iommu/amd: Add unmap_read_dirty() support Joao Martins
2022-05-31 12:39   ` Suravee Suthikulpanit
2022-05-31 15:51     ` Joao Martins
2022-04-28 21:09 ` [PATCH RFC 11/19] iommu/amd: Print access/dirty bits if supported Joao Martins
2022-04-28 21:09 ` [PATCH RFC 12/19] iommu/arm-smmu-v3: Add feature detection for HTTU Joao Martins
2022-04-28 21:09 ` [PATCH RFC 13/19] iommu/arm-smmu-v3: Add feature detection for BBML Joao Martins
2022-04-29 11:11   ` Robin Murphy
2022-04-29 11:54     ` Joao Martins
2022-04-29 12:26       ` Robin Murphy
2022-04-29 14:34         ` Joao Martins
2022-04-28 21:09 ` [PATCH RFC 14/19] iommu/arm-smmu-v3: Add read_and_clear_dirty() support Joao Martins
2022-08-29  9:59   ` Shameerali Kolothum Thodi
2022-04-28 21:09 ` [PATCH RFC 15/19] iommu/arm-smmu-v3: Add set_dirty_tracking_range() support Joao Martins
2022-04-29  8:28   ` Tian, Kevin
2022-04-29 11:05     ` Joao Martins
2022-04-29 11:19       ` Robin Murphy
2022-04-29 12:06         ` Joao Martins
2022-04-29 12:23           ` Jason Gunthorpe
2022-04-29 14:45             ` Joao Martins
2022-04-29 16:11               ` Jason Gunthorpe
2022-04-29 16:40                 ` Joao Martins
2022-04-29 16:46                   ` Jason Gunthorpe
2022-04-29 19:20                   ` Robin Murphy
2022-05-02 11:52                     ` Joao Martins
2022-05-02 11:57                       ` Joao Martins
2022-05-05  7:25       ` Shameerali Kolothum Thodi
2022-05-05  9:52         ` Joao Martins
2022-08-29  9:59           ` Shameerali Kolothum Thodi
2022-08-29 10:00   ` Shameerali Kolothum Thodi
2022-04-28 21:09 ` [PATCH RFC 16/19] iommu/arm-smmu-v3: Enable HTTU for stage1 with io-pgtable mapping Joao Martins
2022-04-29 11:35   ` Robin Murphy
2022-04-29 12:10     ` Joao Martins
2022-04-29 12:46       ` Robin Murphy
2022-08-29 10:00   ` Shameerali Kolothum Thodi
2022-04-28 21:09 ` [PATCH RFC 17/19] iommu/arm-smmu-v3: Add unmap_read_dirty() support Joao Martins
2022-04-29 11:53   ` Robin Murphy
2022-04-28 21:09 ` [PATCH RFC 18/19] iommu/intel: Access/Dirty bit support for SL domains Joao Martins
2022-04-29  9:03   ` Tian, Kevin
2022-04-29 11:20     ` Joao Martins
2022-04-30  6:12   ` Baolu Lu
2022-05-02 12:24     ` Joao Martins
2022-04-28 21:09 ` [PATCH RFC 19/19] iommu/intel: Add unmap_read_dirty() support Joao Martins
2022-04-29  5:45 ` [PATCH RFC 00/19] IOMMUFD Dirty Tracking Tian, Kevin
2022-04-29 10:27   ` Joao Martins
2022-04-29 12:38     ` Jason Gunthorpe
2022-04-29 15:20       ` Joao Martins
2022-05-05  7:40       ` Tian, Kevin
2022-05-05 14:07         ` Jason Gunthorpe
2022-05-06  3:51           ` Tian, Kevin
2022-05-06 11:46             ` Jason Gunthorpe
2022-05-10  1:38               ` Tian, Kevin
2022-05-10 11:50                 ` Joao Martins
2022-05-11  1:17                   ` Tian, Kevin
2022-05-10 13:46                 ` Jason Gunthorpe
2022-05-11  1:10                   ` Tian, Kevin
2022-07-12 18:34                     ` Joao Martins
2022-07-21 14:24                       ` Jason Gunthorpe [this message]
2022-05-02 18:11   ` Alex Williamson
2022-05-02 18:52     ` Jason Gunthorpe
2022-05-03 10:48       ` Joao Martins
2022-05-05  7:42       ` Tian, Kevin
2022-05-05 10:06         ` Joao Martins
2022-05-05 11:03           ` Tian, Kevin
2022-05-05 11:50             ` Joao Martins
2022-05-06  3:14               ` Tian, Kevin
2022-05-05 13:55             ` Jason Gunthorpe
2022-05-06  3:17               ` Tian, Kevin

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=20220721142421.GB4609@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=alex.williamson@redhat.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=cohuck@redhat.com \
    --cc=dwmw2@infradead.org \
    --cc=eric.auger@redhat.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jean-philippe@linaro.org \
    --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=yishaih@nvidia.com \
    --cc=zhukeqian1@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox