On Wed, May 11, 2022 at 09:00:50AM +0100, Jean-Philippe Brucker wrote:
> > /**
> > * struct iommu_device - IOMMU core representation of one IOMMU hardware
> > * instance
> > * @list: Used by the iommu-core to keep a list of registered iommus
> > * @ops: iommu-ops for talk
On Tue, May 10, 2022 at 05:23:09PM -0700, Jacob Pan wrote:
> > > diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
> > > index 5af24befc9f1..55845a8c4f4d 100644
> > > +++ b/include/linux/intel-iommu.h
> > > @@ -627,6 +627,7 @@ struct device_domain_info {
> > > struct intel_i
On Tue, May 10, 2022 at 02:07:02PM -0700, Jacob Pan wrote:
> DMA mapping API is the de facto standard for in-kernel DMA. It operates
> on a per device/RID basis which is not PASID-aware.
>
> Some modern devices such as Intel Data Streaming Accelerator, PASID is
> required for certain work submissi
On Tue, May 10, 2022 at 02:07:01PM -0700, Jacob Pan wrote:
> +static int intel_iommu_attach_dev_pasid(struct iommu_domain *domain,
> + struct device *dev,
> + ioasid_t pasid)
> +{
> + struct device_domain_info *info = dev_i
On Tue, May 10, 2022 at 05:12:04PM +1000, David Gibson wrote:
> On Mon, May 09, 2022 at 11:00:41AM -0300, Jason Gunthorpe wrote:
> > On Mon, May 09, 2022 at 04:01:52PM +1000, David Gibson wrote:
> >
> > > > The default iommu_domain that the iommu driver creates will be
On Tue, May 10, 2022 at 06:52:06PM +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
support any more.
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 16
drivers/iommu/arm/arm-smmu/arm-smmu.c | 16
drivers/iommu/iommu.c | 10 --
drivers/vfio/vfio_iommu_type1.c |
On Tue, May 10, 2022 at 02:17:34PM +0800, Lu Baolu wrote:
> +/**
> + * iommu_sva_bind_device() - Bind a process address space to a device
> + * @dev: the device
> + * @mm: the mm to bind, caller must hold a reference to mm_users
> + * @drvdata: opaque data pointer to pass to bind callback
> + *
>
+++--
> 1 file changed, 12 insertions(+), 41 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Tue, May 10, 2022 at 02:17:28PM +0800, Lu Baolu wrote:
> int iommu_device_register(struct iommu_device *iommu,
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> index 627a3ed5ee8f..afc63fce6107 100644
> +++ b/drivers/iommu/arm/arm-smm
On Tue, May 10, 2022 at 02:17:29PM +0800, Lu Baolu wrote:
> This adds a pair of common domain ops for this purpose and adds helpers
> to attach/detach a domain to/from a {device, PASID}.
I wonder if this should not have a detach op - after discussing with
Robin we can see that detach_dev is not
On Tue, May 10, 2022 at 01:38:26AM +, Tian, Kevin wrote:
> > However, tt costs nothing to have dirty tracking as long as all iommus
> > support it in the system - which seems to be the normal case today.
> >
> > We should just always turn it on at this point.
>
> Then still need a way to rep
On Mon, May 09, 2022 at 11:06:35PM +0100, Robin Murphy wrote:
> The main thing drivers need to do for flush queue support is to actually
> implement the optimisations which make it worthwhile. It's up to individual
> drivers how much use they want to make of the iommu_iotlb_gather mechanism,
> and
On Wed, May 04, 2022 at 01:57:05PM +0200, Joerg Roedel wrote:
> On Wed, May 04, 2022 at 08:51:35AM -0300, Jason Gunthorpe wrote:
> > Nicolin and Eric have been testing with this series on ARM for a long
> > time now, it is not like it is completely broken.
>
> Yeah, I am als
On Mon, May 09, 2022 at 10:59:11AM +0100, Robin Murphy wrote:
> IOMMU_DOMAIN_DMA_FQ now effectively takes over the original
> semantics of IOMMU_DOMAIN_DMA as the one that depends on
> driver-specific functionality.
If I grasp the FQ stuff right, it seems that this only requires the
driver to imp
Qian Cai
Tested-by: Baolu Lu
Tested-by: Nicolin Chen
Co-developed-by: Robin Murphy
Signed-off-by: Robin Murphy
Signed-off-by: Jason Gunthorpe
--
Just minor polishing as discussed
v3:
- Change names to __iommu_group_set_domain() /
__iommu_group_set_core_domain()
- Clarify comments
-
On Mon, May 09, 2022 at 04:01:52PM +1000, David Gibson wrote:
> > The default iommu_domain that the iommu driver creates will be used
> > here, it is up to the iommu driver to choose something reasonable for
> > use by applications like DPDK. ie PPC should probably pick its biggest
> > x86-like ap
On Fri, May 06, 2022 at 05:44:11PM +0100, Robin Murphy wrote:
> > > Nit: if that's true then it's equally true for iommu_attach_group() as
> > > well.
> >
> > Is it? I didn't check this as closely..
>
> Well, there certainly seems no obvious reason for one to WARN where the
> other fails quietl
On Fri, May 06, 2022 at 02:35:50PM +0100, Robin Murphy wrote:
> > So you want to say "DMA is always managed" when attaching a domain of
> > type IOMMU_DOMAIN_UNMANAGED? :)
>
> Touché ;) Just goes to confirm the point above that confusion between
> general concepts and specific API terms is all to
On Fri, May 06, 2022 at 10:12:29AM +0100, Robin Murphy wrote:
> On 2022-05-05 17:15, Jason Gunthorpe via iommu wrote:
> > Call iommu_group_do_attach_device() only from
> > __iommu_group_attach_domain() which should be used to attach any domain to
> > the group.
> >
On Fri, May 06, 2022 at 10:32:50AM +0100, Robin Murphy wrote:
> > > It is as discussed with Robin, NULL means to return the group back to
> > > some platform defined translation, and in some cases this means
> > > returning back to work with the platform's DMA ops - presumably if it
> > > isn't us
On Fri, May 06, 2022 at 03:25:03PM +1000, David Gibson wrote:
> On Thu, May 05, 2022 at 04:07:28PM -0300, Jason Gunthorpe wrote:
> > When the iommu_domain is created I want to have a
> > iommu-driver-specific struct, so PPC can customize its iommu_domain
> > however it like
On Fri, May 06, 2022 at 03:51:40AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Thursday, May 5, 2022 10:08 PM
> >
> > On Thu, May 05, 2022 at 07:40:37AM +, Tian, Kevin wrote:
> >
> > > In concept this is an iommu property instead of
On Thu, May 05, 2022 at 07:56:59PM +0100, Robin Murphy wrote:
> Ack to that, there are certainly further improvements to consider once we've
> got known-working code into a released kernel, but let's not get ahead of
> ourselves just now.
Yes please
> (I'm pretty sure we could get away with a s
On Mon, May 02, 2022 at 05:30:05PM +1000, David Gibson wrote:
> > It is a bit more CPU work since maps in the lower range would have to
> > be copied over, but conceptually the model matches the HW nesting.
>
> Ah.. ok. IIUC what you're saying is that the kernel-side IOASes have
> fixed windows,
wrong.
Suggested-by: "Tian, Kevin"
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/iommu.c | 42 +++---
1 file changed, 19 insertions(+), 23 deletions(-)
This goes after "iommu: iommu_group_claim_dma_owner() must always assign a
domain" an
On Thu, May 05, 2022 at 10:56:28AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Thursday, May 5, 2022 3:09 AM
> >
> > Once the group enters 'owned' mode it can never be assigned back to the
> > default_domain or to a NULL domain. It must a
On Thu, May 05, 2022 at 07:40:37AM +, Tian, Kevin wrote:
> In concept this is an iommu property instead of a domain property.
Not really, domains shouldn't be changing behaviors once they are
created. If a domain supports dirty tracking and I attach a new device
then it still must support di
On Thu, May 05, 2022 at 11:03:18AM +, Tian, Kevin wrote:
> iiuc the purpose of 'write-protection' here is to capture in-fly dirty pages
> in the said race window until unmap and iotlb is invalidated is completed.
No, the purpose is to perform "unmap" without destroying the dirty bit
in the pr
ported-by: Qian Cai
Tested-by: Baolu Lu
Tested-by: Nicolin Chen
Co-developed-by: Robin Murphy
Signed-off-by: Robin Murphy
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/iommu.c | 122 ++
1 file changed, 87 insertions(+), 35 deletions(-)
Joerg, this sho
On Wed, May 04, 2022 at 04:29:24PM +0100, Robin Murphy wrote:
> On 2022-05-04 15:54, Jason Gunthorpe wrote:
> > On Wed, May 04, 2022 at 03:42:09PM +0100, Robin Murphy wrote:
> >
> > > > This fixes an oops with VFIO and SMMUv3 because VFIO will call
> >
On Wed, May 04, 2022 at 10:55:00PM +0800, Baolu Lu wrote:
> On 2022/5/4 22:38, Jason Gunthorpe wrote:
> > > @@ -3180,7 +3181,9 @@ int iommu_group_claim_dma_owner(struct iommu_group
> > > *group, void *owner)
> > > ret = -EPERM;
> >
On Wed, May 04, 2022 at 03:42:09PM +0100, Robin Murphy wrote:
> > This fixes an oops with VFIO and SMMUv3 because VFIO will call
> > iommu_detach_group() and then immediately iommu_domain_free(), but
> > SMMUv3 has no way to know that the domain it is holding a pointer to
> > has been freed. Now t
On Wed, May 04, 2022 at 10:35:12PM +0800, Baolu Lu wrote:
> With below additional changes, this patch works on my Intel test
> machine.
Thanks!
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 513da82f2ed1..7c415e9b6906 100644
> +++ b/drivers/iommu/iommu.c
> @@ -2063,7 +2063
On Wed, May 04, 2022 at 03:25:50PM +0800, Baolu Lu wrote:
> Hi Jason,
>
> On 2022/5/2 21:05, Jason Gunthorpe wrote:
> > On Sun, May 01, 2022 at 07:24:31PM +0800, Lu Baolu wrote:
> > > The SNP bit is only valid for second-level PTEs. Setting this bit in the
> > > f
se right way to retrieve iommu_ops")
> Reported-by: Jan Stancek
> Signed-off-by: Robin Murphy
> ---
> drivers/iommu/iommu.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
Reviewed-by: Jason Gunthorpe
Jason
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Wed, May 04, 2022 at 01:22:00AM -0700, Nicolin Chen wrote:
> I am able to repro the issue on ARM64 and give this a quick try.
> But the patch seems to need to include the following change too.
>
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 94d99768023c..9bb108d01baa 100
On Wed, May 04, 2022 at 07:48:58PM +0800, Baolu Lu wrote:
> > + /*
> > +* New drivers do not implement detach_dev, so changing the domain is
> > +* done by calling attach on the new domain. Drivers should implement
> > +* this so that DMA is always translated by either the new, old,
On Wed, May 04, 2022 at 10:42:07AM +0200, Joerg Roedel wrote:
> On Mon, May 02, 2022 at 12:12:04PM -0400, Qian Cai wrote:
> > Reverting this series fixed an user-after-free while doing SR-IOV.
> >
> > BUG: KASAN: use-after-free in __lock_acquire
>
> Hrm, okay. I am going exclude this series from
ed-by: Qian Cai
Signed-off-by: Robin Murphy
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/iommu.c | 112 +++---
1 file changed, 82 insertions(+), 30 deletions(-)
This is based on Robins draft here:
https://lore.kernel.org/linux-iommu/18831161-473f-e04f-4a
On Tue, May 03, 2022 at 02:04:37PM +0100, Robin Murphy wrote:
> > I'm guessing SMMU3 needs to call it's arm_smmu_detach_dev(master) from
> > the detach_dev op and null it's cached copy of the domain, but I don't
> > know this driver.. Robin?
>
> The original intent was that .detach_dev is depreca
On Mon, May 02, 2022 at 12:11:07PM -0600, Alex Williamson wrote:
> On Fri, 29 Apr 2022 05:45:20 +
> "Tian, Kevin" wrote:
> > > From: Joao Martins
> > > 3) Unmapping an IOVA range while returning its dirty bit prior to
> > > unmap. This case is specific for non-nested vIOMMU case where an
> >
On Mon, May 02, 2022 at 12:12:04PM -0400, Qian Cai wrote:
> On Mon, Apr 18, 2022 at 08:49:49AM +0800, Lu Baolu wrote:
> > Hi Joerg,
> >
> > This is a resend version of v8 posted here:
> > https://lore.kernel.org/linux-iommu/20220308054421.847385-1-baolu...@linux.intel.com/
> > as we discussed in t
On Sun, May 01, 2022 at 07:24:34PM +0800, Lu Baolu wrote:
> As enforce_cache_coherency has been introduced into the iommu_domain_ops,
> the kernel component which owns the iommu domain is able to opt-in its
> requirement for force snooping support. The iommu driver has no need to
> hard code the pa
ead code now.
>
> Signed-off-by: Lu Baolu
> ---
> drivers/iommu/intel/iommu.c | 34 +-
> 1 file changed, 1 insertion(+), 33 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
___
iommu mailing list
iommu@lists
On Sun, May 01, 2022 at 07:24:32PM +0800, Lu Baolu wrote:
> +static bool domain_support_force_snooping(struct dmar_domain *domain)
> +{
> + struct device_domain_info *info;
> + unsigned long flags;
> + bool support = true;
> +
> + spin_lock_irqsave(&device_domain_lock, flags);
> +
On Sun, May 01, 2022 at 07:24:31PM +0800, Lu Baolu wrote:
> The SNP bit is only valid for second-level PTEs. Setting this bit in the
> first-level PTEs has no functional impact because the Intel IOMMU always
> ignores the same bit in first-level PTEs. Anyway, let's check the page
> table type befor
gt; return a corresponding error code.
>
> Signed-off-by: Lu Baolu
> ---
> drivers/iommu/intel/iommu.c | 3 +++
> 1 file changed, 3 insertions(+)
Reviewed-by: Jason Gunthorpe
Jason
___
iommu mailing list
iommu@lists.linux-foundation.org
https:
+0200)
Jason Gunthorpe (1):
vfio: Delete the unbound_list
Lu Baolu (10):
iommu: Add DMA ownership management interfaces
driver core: Add dma_cleanup callback in bus_type
amba: Stop sharing platform_dma_configure()
bus: platform,amba,fsl-mc,PCI: Add devic
On Fri, Apr 29, 2022 at 05:40:56PM +0100, Joao Martins wrote:
> > A common use model might be to just destroy the iommu_domain without
> > doing stop so prefering the clearing io page table at stop might be a
> > better overall design.
>
> If we want to ensure that the IOPTE dirty state is immuta
On Fri, Apr 29, 2022 at 03:45:23PM +0100, Joao Martins wrote:
> On 4/29/22 13:23, Jason Gunthorpe wrote:
> > On Fri, Apr 29, 2022 at 01:06:06PM +0100, Joao Martins wrote:
> >
> >>> TBH I'd be inclined to just enable DBM unconditionally in
> >>> arm_sm
On Fri, Apr 29, 2022 at 03:27:00PM +0100, Joao Martins wrote:
> > We've made a qemu patch to allow qemu to be happy if dirty tracking is
> > not supported in the vfio container for migration, which is part of
> > the v2 enablement series. That seems like the better direction.
> >
> So in my audit
On Fri, Apr 29, 2022 at 03:26:41PM +0100, Joao Martins wrote:
> I had this in the iommufd_dirty_iter logic given that the iommu iteration
> logic is in the parent structure that stores iommu_dirty_data.
>
> My thinking with this patch was just to have what the IOMMU driver needs.
I would put the
On Fri, Apr 29, 2022 at 04:00:14PM +1000, David Gibson wrote:
> > But I don't have a use case in mind? The simplified things I know
> > about want to attach their devices then allocate valid IOVA, they
> > don't really have a notion about what IOVA regions they are willing to
> > accept, or necessa
On Fri, Apr 29, 2022 at 04:22:56PM +1000, David Gibson wrote:
> On Fri, Apr 29, 2022 at 01:21:30AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Thursday, April 28, 2022 11:11 PM
> > >
> > >
> > > > 3) "dynamic DMA wi
On Fri, Apr 29, 2022 at 04:20:36PM +1000, David Gibson wrote:
> > I think PPC and S390 are solving the same problem here. I think S390
> > is going to go to a SW nested model where it has an iommu_domain
> > controlled by iommufd that is populated with the pinned pages, eg
> > stored in an xarray.
On Fri, Apr 29, 2022 at 11:27:58AM +0100, Joao Martins wrote:
> >> 3) Unmapping an IOVA range while returning its dirty bit prior to
> >> unmap. This case is specific for non-nested vIOMMU case where an
> >> erronous guest (or device) DMAing to an address being unmapped at the
> >> same time.
> >
On Fri, Apr 29, 2022 at 01:06:06PM +0100, Joao Martins wrote:
> > TBH I'd be inclined to just enable DBM unconditionally in
> > arm_smmu_domain_finalise() if the SMMU supports it. Trying to toggle it
> > dynamically (especially on a live domain) seems more trouble that it's
> > worth.
>
> Hmmm
On Thu, Apr 28, 2022 at 10:09:21PM +0100, Joao Martins wrote:
> Add the correspondent APIs for performing VFIO dirty tracking,
> particularly VFIO_IOMMU_DIRTY_PAGES ioctl subcmds:
> * VFIO_IOMMU_DIRTY_PAGES_FLAG_START: Start dirty tracking and allocates
>the area
On Thu, Apr 28, 2022 at 10:09:19PM +0100, Joao Martins wrote:
> +static void iommu_unmap_read_dirty_nofail(struct iommu_domain *domain,
> + unsigned long iova, size_t size,
> + struct iommufd_dirty_data *bitmap,
> +
On Fri, Apr 29, 2022 at 11:54:16AM +0100, Joao Martins wrote:
> On 4/29/22 09:12, Tian, Kevin wrote:
> >> From: Joao Martins
> >> Sent: Friday, April 29, 2022 5:09 AM
> > [...]
> >> +
> >> +static int iommu_read_and_clear_dirty(struct iommu_domain *domain,
> >> +str
On Thu, Apr 28, 2022 at 10:09:15PM +0100, Joao Martins wrote:
> +
> +unsigned int iommu_dirty_bitmap_record(struct iommu_dirty_bitmap *dirty,
> +unsigned long iova, unsigned long length)
> +{
Lets put iommu_dirty_bitmap in its own patch, the VFIO driver side
wil
On Fri, Apr 29, 2022 at 08:07:14AM +, Tian, Kevin wrote:
> > From: Joao Martins
> > Sent: Friday, April 29, 2022 5:09 AM
> >
> > +static int __set_dirty_tracking_range_locked(struct iommu_domain
> > *domain,
>
> suppose anything using iommu_domain as the first argument should
> be put in the
On Fri, Apr 29, 2022 at 12:53:16AM +1000, David Gibson wrote:
> 2) Costly GUPs. pseries (the most common ppc machine type) always
> expects a (v)IOMMU. That means that unlike the common x86 model of a
> host with IOMMU, but guests with no-vIOMMU, guest initiated
> maps/unmaps can be a hot path.
On Thu, Apr 28, 2022 at 03:58:30PM +1000, David Gibson wrote:
> On Thu, Mar 31, 2022 at 09:58:41AM -0300, Jason Gunthorpe wrote:
> > On Thu, Mar 31, 2022 at 03:36:29PM +1100, David Gibson wrote:
> >
> > > > +/**
> > > > + * struct iommu_ioas_iov
On Thu, Apr 28, 2022 at 11:32:04AM +0200, Joerg Roedel wrote:
> On Mon, Apr 18, 2022 at 08:49:49AM +0800, Lu Baolu wrote:
> > Lu Baolu (10):
> > iommu: Add DMA ownership management interfaces
> > driver core: Add dma_cleanup callback in bus_type
> > amba: Stop sharing platform_dma_configure()
tch fixes the issue by doing the calculation correctly.
>
> Fixes: 2f7e8c553e98d ("iommu/arm-smmu-v3: Hook up ATC invalidation to mm ops")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Nicolin Chen
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 9
On Fri, Apr 15, 2022 at 07:03:20PM -0700, Nicolin Chen wrote:
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> index d816759a6bcf..e280568bb513 100644
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> @@ -183,7 +183,7 @@
On Wed, Apr 13, 2022 at 10:02:58PM +0800, Yi Liu wrote:
> > +/**
> > + * iopt_unmap_iova() - Remove a range of iova
> > + * @iopt: io_pagetable to act on
> > + * @iova: Starting iova to unmap
> > + * @length: Number of bytes to unmap
> > + *
> > + * The requested range must exactly match an existin
On Tue, Apr 12, 2022 at 10:13:32PM +0200, Eric Auger wrote:
> Hi,
>
> On 3/18/22 6:27 PM, Jason Gunthorpe wrote:
> > iommufd is the user API to control the IOMMU subsystem as it relates to
> > managing IO page tables that point at user space memory.
> >
> >
On Tue, Apr 12, 2022 at 09:13:27PM +0800, Lu Baolu wrote:
> > > > btw as discussed in last version it is not necessarily to recalculate
> > > > snoop control globally with this new approach. Will follow up to
> > > > clean it up after this series is merged.
> > > Agreed. But it also requires the e
& usnic do before
allowing an IOMMU backed VFIO device to be created.
Reviewed-by: Kevin Tian
Acked-by: Alex Williamson
Acked-by: Robin Murphy
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/vfio.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/vfio/vfio.c b/drivers/
requesting no-snoop behavior at the device
level. Other places using domains with real kernel drivers should simply
avoid asking their devices to set the no-snoop bit.
Reviewed-by: Lu Baolu
Reviewed-by: Kevin Tian
Acked-by: Robin Murphy
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/amd
U_CACHE is supported
- Put the VFIO tests for IOMMU_CACHE at VFIO device registration
- In the Intel driver remove the domain->iommu_snooping value, this is
global not per-domain
v1:
https://lore.kernel.org/r/0-v1-ef02c60ddb76+12ca2-intel_no_snoop_...@nvidia.com
Signed-off-by: Jason Guntho
Acked-by: Alex Williamson
Acked-by: Robin Murphy
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/intel/iommu.c | 7 ++-
drivers/vfio/vfio_iommu_type1.c | 30 +++---
include/linux/intel-iommu.h | 1 -
3 files changed, 21 insertions(+), 17 deletions(-)
d
require
IOMMU_CACHE behavior as they offer no way for userspace to synchronize
caches.
Reviewed-by: Kevin Tian
Reviewed-by: Lu Baolu
Acked-by: Robin Murphy
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/intel/iommu.c | 2 +-
include/linux/iommu.h | 3 +--
2 files changed, 2 insertions
On Fri, Apr 08, 2022 at 09:47:57AM -0600, Alex Williamson wrote:
> > Ultimately VFIO plumbs the result of enforce_cache_coherency() back into
> > the x86 platform code through kvm_arch_register_noncoherent_dma() which
> > controls if the WBINVD instruction is available in the guest. No other
> > a
On Fri, Apr 08, 2022 at 08:05:38AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Thursday, April 7, 2022 11:24 PM
> >
> > This new mechanism will replace using IOMMU_CAP_CACHE_COHERENCY
> > and
> > IOMMU_CACHE to control the no-
On Fri, Apr 08, 2022 at 10:07:50AM -0600, Alex Williamson wrote:
> On Fri, 8 Apr 2022 10:59:22 -0500
> Bjorn Helgaas wrote:
>
> > On Fri, Apr 08, 2022 at 05:37:16PM +0200, Joerg Roedel wrote:
> > > On Fri, Apr 08, 2022 at 11:17:47AM -0300, Jason Gunthorpe wrote:
&g
On Tue, Apr 05, 2022 at 03:35:59PM +0100, Robin Murphy wrote:
> Rather than hard-coding pci_bus_type, pass the PF device through to
> usnic_uiom_alloc_pd() and retrieve its bus there. This prepares for
> iommu_domain_alloc() changing to take a device rather than a bus_type.
>
> Signed-off-by: Robi
On Tue, Apr 05, 2022 at 01:19:59PM +0100, Robin Murphy wrote:
> Even if an IOMMU might be present for some PCI segment in the system,
> that doesn't necessarily mean it provides translation for the device(s)
> we care about. Replace iommu_present() with a more appropriate check at
> probe time, and
On Fri, Apr 08, 2022 at 04:00:31PM +0200, Joerg Roedel wrote:
> On Fri, Apr 08, 2022 at 09:23:52AM -0300, Jason Gunthorpe wrote:
> > Why rc3? It has been 4 weeks now with no futher comments.
>
> Because I start applying new code to branches based on -rc3. In the past
> I used d
On Fri, Apr 08, 2022 at 02:28:02PM +0100, Robin Murphy wrote:
> > > One nit. Is it logistically more reasonable to put this patch before
> > > changing VFIO to always set IOMMU_CACHE?
> >
> > For bisectability it has to be after
> >
> > iommu: Redefine IOMMU_CAP_CACHE_COHERENCY as the cap f
On Fri, Apr 08, 2022 at 02:11:10PM +0100, Robin Murphy wrote:
> > However, this creates an oddball situation where the vfio_device and
> > it's struct device could become unplugged from the system while the
> > domain that the struct device spawned continues to exist and remains
> > attached to ot
On Fri, Apr 08, 2022 at 08:22:35PM +0800, Lu Baolu wrote:
> Hi Joerg,
>
> On 2022/4/8 15:57, Joerg Roedel wrote:
> > On Mon, Mar 14, 2022 at 09:21:25PM -0300, Jason Gunthorpe wrote:
> > > Joerg, are we good for the coming v5.18 merge window now? There are
> > >
On Fri, Apr 08, 2022 at 08:26:10AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Thursday, April 7, 2022 11:24 PM
> >
> > IOMMU_CACHE means that normal DMAs do not require any additional
> > coherency
> > mechanism and is the basic uAPI
On Fri, Apr 08, 2022 at 08:21:55AM +, Tian, Kevin wrote:
> (CC Jason Wang)
>
> > From: Jason Gunthorpe
> > Sent: Thursday, April 7, 2022 11:24 PM
> >
> > While the comment was correct that this flag was intended to convey the
> > block no-snoop suppor
On Thu, Apr 07, 2022 at 08:27:05PM +0100, Robin Murphy wrote:
> On 2022-04-07 20:08, Jason Gunthorpe wrote:
> > On Thu, Apr 07, 2022 at 07:02:03PM +0100, Robin Murphy wrote:
> > > On 2022-04-07 18:43, Jason Gunthorpe wrote:
> > > > On Thu, Apr 07, 2022 at 06:03:
On Thu, Apr 07, 2022 at 07:02:03PM +0100, Robin Murphy wrote:
> On 2022-04-07 18:43, Jason Gunthorpe wrote:
> > On Thu, Apr 07, 2022 at 06:03:37PM +0100, Robin Murphy wrote:
> > > At a glance, this all looks about the right shape to me now, thanks!
> >
> > Thank
On Thu, Apr 07, 2022 at 06:03:37PM +0100, Robin Murphy wrote:
> At a glance, this all looks about the right shape to me now, thanks!
Thanks!
> Ideally I'd hope patch #4 could go straight to device_iommu_capable() from
> my Thunderbolt series, but we can figure that out in a couple of weeks once
require
IOMMU_CACHE behavior as they offer no way for userspace to synchronize
caches.
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/intel/iommu.c | 2 +-
include/linux/iommu.h | 3 +--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/intel/iommu.c b/drivers
if the WBINVD instruction is available in the guest. No other
arch implements kvm_arch_register_noncoherent_dma().
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/intel/iommu.c | 7 ++-
drivers/vfio/vfio_iommu_type1.c | 30 +++---
include/linux/intel-iommu.h
& usnic do before
allowing an IOMMU backed VFIO device to be created.
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/vfio.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index a4555014bd1e72..9edad767cfdad3 100644
--- a/drivers/vfio/vf
outside the IOPTE - AMD also documents such a HW capability.
Leave AMD out of sync with Intel and have it block no-snoop even for
in-kernel users. This can be trivially resolved in a follow up patch.
Only VFIO will call this new API.
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/amd/iommu.c
tion
- In the Intel driver remove the domain->iommu_snooping value, this is
global not per-domain
v1:
https://lore.kernel.org/r/0-v1-ef02c60ddb76+12ca2-intel_no_snoop_...@nvidia.com
Jason Gunthorpe (4):
iommu: Introduce the domain op enforce_cache_coherency()
vfio: Move the Intel
On Thu, Apr 07, 2022 at 04:17:11PM +0100, Robin Murphy wrote:
> For the specific case of overriding PCIe No Snoop (which is more problematic
> from an Arm SMMU PoV) when assigning to a VM, would that not be easier
> solved by just having vfio-pci clear the "Enable No Snoop" control bit in
> the en
On Wed, Apr 06, 2022 at 06:52:04AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Wednesday, April 6, 2022 12:16 AM
> >
> > PCIe defines a 'no-snoop' bit in each the TLP which is usually implemented
> > by a platform as bypassin
On Wed, Apr 06, 2022 at 07:02:36AM +, Tian, Kevin wrote:
> > So like this:
> >
> > int vfio_register_group_dev(struct vfio_device *device)
> > {
> > + if (!dev_is_dma_coherent(device->dev))
> > + return -EINVAL;
> > +
> > return __vfio_register_dev(device,
> >
On Thu, Apr 07, 2022 at 07:18:48AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Thursday, April 7, 2022 1:17 AM
> >
> > On Wed, Apr 06, 2022 at 06:10:31PM +0200, Christoph Hellwig wrote:
> > > On Wed, Apr 06, 2022 at 01:06:23PM -0300, Jason Gun
On Wed, Apr 06, 2022 at 10:39:47PM +0100, Robin Murphy wrote:
> On 2022-04-06 20:54, kernel test robot wrote:
> > Hi Robin,
> >
> > I love your patch! Yet something to improve:
> >
> > [auto build test ERROR on rdma/for-next]
> > [also build test ERROR on v5.18-rc1 next-20220406]
> > [If your pat
101 - 200 of 1005 matches
Mail list logo
