From: Jason Gunthorpe <jgg@nvidia.com>
To: Will Deacon <will@kernel.org>
Cc: Robin Murphy <robin.murphy@arm.com>,
Cornelia Huck <cohuck@redhat.com>,
Alex Williamson <alex.williamson@redhat.com>,
iommu@lists.linux-foundation.org, kvm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] vfio: Remove VFIO_TYPE1_NESTING_IOMMU
Date: Fri, 20 May 2022 09:28:07 -0300 [thread overview]
Message-ID: <20220520122807.GF1343366@nvidia.com> (raw)
In-Reply-To: <20220520120032.GB6700@willie-the-truck>
On Fri, May 20, 2022 at 01:00:32PM +0100, Will Deacon wrote:
> On Fri, May 20, 2022 at 12:02:23PM +0100, Robin Murphy wrote:
> > On 2022-05-10 17:55, Jason Gunthorpe via iommu wrote:
> > > This control causes the ARM SMMU drivers to choose a stage 2
> > > implementation for the IO pagetable (vs the stage 1 usual default),
> > > however this choice has no visible impact to the VFIO user.
> >
> > Oh, I should have read more carefully... this isn't entirely true. Stage 2
> > has a different permission model from stage 1, so although it's arguably
> > undocumented behaviour, VFIO users that know enough about the underlying
> > system could use this to get write-only mappings if they so wish.
>
> There's also an impact on combining memory attributes, but it's not hugely
> clear how that impacts userspace via things like VFIO_DMA_CC_IOMMU.
VFIO_DMA_CC_IOMMU has been clarified now to only be about the ability
to reject device requested no-snoop transactions. ie ignore the
NoSnoop bit in PCIe TLPs.
AFAICT SMMU can't implement this currently, and maybe doesn't need to.
VFIO requires the IO page tables be setup for cache coherent operation
for ordinary device DMA otherwises users like DPDK will not work.
It is surprising to hear you say that VFIO_TYPE1_NESTING_IOMMU might
also cause the IO to become non-coherent..
Jason
next prev parent reply other threads:[~2022-05-20 12:28 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-10 16:55 [PATCH] vfio: Remove VFIO_TYPE1_NESTING_IOMMU Jason Gunthorpe
2022-05-10 17:52 ` Robin Murphy
2022-05-10 18:13 ` Jason Gunthorpe
2022-05-12 7:07 ` Zhangfei Gao
2022-05-12 11:32 ` Jason Gunthorpe
2022-05-12 11:57 ` zhangfei.gao
2022-05-12 11:59 ` Jason Gunthorpe
2022-05-12 12:07 ` zhangfei.gao
2022-05-12 17:27 ` Eric Auger
2022-05-10 18:31 ` Nicolin Chen
2022-05-12 5:04 ` Tian, Kevin
2022-05-16 6:39 ` Christoph Hellwig
2022-05-17 20:26 ` Alex Williamson
2022-05-20 7:38 ` Joerg Roedel
2022-05-20 11:02 ` Robin Murphy
2022-05-20 12:00 ` Will Deacon
2022-05-20 12:28 ` Jason Gunthorpe [this message]
2022-05-20 12:18 ` 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=20220520122807.GF1343366@nvidia.com \
--to=jgg@nvidia.com \
--cc=alex.williamson@redhat.com \
--cc=cohuck@redhat.com \
--cc=iommu@lists.linux-foundation.org \
--cc=kvm@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=robin.murphy@arm.com \
--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