From: Jason Gunthorpe <jgg@ziepe.ca>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
Will Deacon <will@kernel.org>,
Kirti Wankhede <kwankhede@nvidia.com>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
Alex Williamson <alex.williamson@redhat.com>,
David Woodhouse <dwmw2@infradead.org>,
Christoph Hellwig <hch@lst.de>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 3/6] vfio: remove the unused mdev iommu hook
Date: Fri, 14 May 2021 11:44:43 -0300 [thread overview]
Message-ID: <20210514144443.GN1096940@ziepe.ca> (raw)
In-Reply-To: <MWHPR11MB1886AE36746C8F82553471088C509@MWHPR11MB1886.namprd11.prod.outlook.com>
On Fri, May 14, 2021 at 02:28:44PM +0000, Tian, Kevin wrote:
> Well, I see what you meant now. Basically you want to make IOASID
> as the first-class object in the entire iommu stack, replacing what
> iommu domain fulfill todays.
Alternatively you transform domain into being a full fledged IOASID.
I don't know which path works out to be a better patch series.
> Our original proposal was still based on domain-centric philosophy
> thus containing IOASID and its routing info only in the uAPI layer
> of /dev/ioasid and then connecting to domains.
Where do the domains come from though? You still have to hack hack all
the drivers to create dummy domains to support this plan, and in the
process PASID is pretty hobbled as an actual API if every PASID
instance requires a wonky dummy struct device and domain.
> btw are you OK with our ongoing uAPI proposal still based on domain
> flavor for now? the uAPI semantics should be generic regardless of
> how underlying iommu interfaces are designed. At least separate
> uAPI discussion from iommu ops re-design.
The most important thing is the uAPI, you don't get to change that later.
The next most is the driver facing API.
You can figure out the IOMMU layer internals in stages.
Clearly IOASID == domain today as domain is kind of half a
IOASID. When you extend to PASID and other stuff I think you have
little choice but to make a full IOASID more first class.
Dummy domains are a very poor substitute.
In my experiance these kinds of transformations can usually be managed
as "just alot of typing". Usually the old driver code structure can be
kept enough to not break it while reorganizing.
Jason
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2021-05-14 14:44 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-10 6:53 more iommu dead code removal Christoph Hellwig
2021-05-10 6:54 ` [PATCH 1/6] iommu: remove the unused dev_has_feat method Christoph Hellwig
2021-05-10 6:54 ` [PATCH 2/6] iommu: remove the unused iommu_aux_get_pasid interface Christoph Hellwig
2021-05-10 6:54 ` [PATCH 3/6] vfio: remove the unused mdev iommu hook Christoph Hellwig
2021-05-10 15:54 ` Jason Gunthorpe
2021-05-13 3:28 ` Tian, Kevin
2021-05-13 12:00 ` Jason Gunthorpe
2021-05-14 6:27 ` Tian, Kevin
2021-05-14 6:54 ` Tian, Kevin
2021-05-14 12:19 ` Jason Gunthorpe
2021-05-14 12:58 ` Tian, Kevin
2021-05-14 13:31 ` Jason Gunthorpe
2021-05-17 12:22 ` Joerg Roedel
2021-05-17 12:30 ` Jason Gunthorpe
2021-05-17 12:53 ` Joerg Roedel
2021-05-17 13:35 ` Jason Gunthorpe
2021-05-17 15:35 ` Joerg Roedel
2021-05-19 15:23 ` Robin Murphy
2021-05-19 18:06 ` Jason Gunthorpe
2021-05-19 23:12 ` Tian, Kevin
2021-05-19 23:24 ` Jason Gunthorpe
2021-05-20 14:13 ` Robin Murphy
2021-05-20 14:34 ` Jason Gunthorpe
2021-05-24 18:18 ` Robin Murphy
2021-05-25 0:00 ` Jason Gunthorpe
2021-06-30 9:08 ` Tian, Kevin
2021-07-22 13:34 ` Christoph Hellwig
2021-07-23 5:36 ` Tian, Kevin
2021-07-23 5:41 ` Christoph Hellwig
2021-07-23 5:44 ` Tian, Kevin
2021-07-22 6:02 ` Tian, Kevin
2021-05-14 13:17 ` Tian, Kevin
2021-05-14 13:39 ` Jason Gunthorpe
2021-05-14 14:08 ` Liu Yi L
2021-05-14 14:28 ` Tian, Kevin
2021-05-14 14:44 ` Jason Gunthorpe [this message]
2021-05-10 6:54 ` [PATCH 4/6] iommu: remove iommu_aux_{attach,detach}_device Christoph Hellwig
2021-05-10 6:54 ` [PATCH 5/6] iommu: remove IOMMU_DEV_FEAT_AUX Christoph Hellwig
2021-05-10 6:54 ` [PATCH 6/6] iommu: remove iommu_dev_feature_enabled Christoph Hellwig
2021-05-10 11:54 ` more iommu dead code removal Jason Gunthorpe
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=20210514144443.GN1096940@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=alex.williamson@redhat.com \
--cc=dwmw2@infradead.org \
--cc=hch@lst.de \
--cc=iommu@lists.linux-foundation.org \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=kwankhede@nvidia.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=will@kernel.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).