On 2022/5/24 21:44, Jason Gunthorpe wrote:
+{
+ struct iommu_sva_domain *sva_domain;
+ struct iommu_domain *domain;
+
+ if (!bus->iommu_ops || !bus->iommu_ops->sva_domain_ops)
+ return ERR_PTR(-ENODEV);
+
+ sva_domain = kzalloc(sizeof(*sva_domain),
Hi Jason,
On 2022/5/24 21:44, Jason Gunthorpe wrote:
diff --git a/drivers/iommu/iommu-sva-lib.c b/drivers/iommu/iommu-sva-lib.c
index 106506143896..210c376f6043 100644
+++ b/drivers/iommu/iommu-sva-lib.c
@@ -69,3 +69,51 @@ struct mm_struct *iommu_sva_find(ioasid_t pasid)
return
On 2022/5/24 17:39, Tian, Kevin wrote:
From: Lu Baolu
Sent: Thursday, May 19, 2022 3:21 PM
The iommu_sva_domain represents a hardware pagetable that the IOMMU
hardware could use for SVA translation. This adds some infrastructure
to support SVA domain in the iommu common layer. It includes:
-
On 2022/5/25 08:44, Tian, Kevin wrote:
From: Jason Gunthorpe
Sent: Tuesday, May 24, 2022 9:39 PM
On Tue, May 24, 2022 at 09:39:52AM +, Tian, Kevin wrote:
From: Lu Baolu
Sent: Thursday, May 19, 2022 3:21 PM
The iommu_sva_domain represents a hardware pagetable that the
IOMMU
hardware
On 2022/5/24 17:44, Tian, Kevin wrote:
From: Baolu Lu
Sent: Monday, May 23, 2022 3:13 PM
@@ -254,6 +259,7 @@ struct iommu_ops {
int (*def_domain_type)(struct device *dev);
const struct iommu_domain_ops *default_domain_ops;
+ const struct iommu_domain_ops *sva_domain_ops
On 2022/5/25 10:03, Baolu Lu wrote:
diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c
index 4de960834a1b..1c3cf267934d 100644
--- a/drivers/iommu/intel/dmar.c
+++ b/drivers/iommu/intel/dmar.c
@@ -1126,6 +1126,10 @@ static int alloc_iommu(struct dmar_drhd_unit
*drhd
Hi Kevin,
Thank you for reviewing my patches.
On 2022/5/24 17:24, Tian, Kevin wrote:
From: Lu Baolu
Sent: Thursday, May 19, 2022 3:21 PM
Use this field to keep the number of supported PASIDs that an IOMMU
hardware is able to support. This is a generic attribute of an IOMMU
and lifting it
Hi Joerg,
On 2022/5/21 08:21, Yian Chen wrote:
Notifier calling chain uses priority to determine the execution
order of the notifiers or listeners registered to the chain.
PCI bus device hot add utilizes the notification mechanism.
The current code sets low priority (INT_MIN) to Intel
On 2022/5/19 15:20, Lu Baolu wrote:
The iommu_sva_domain represents a hardware pagetable that the IOMMU
hardware could use for SVA translation. This adds some infrastructure
to support SVA domain in the iommu common layer. It includes:
- Add a new struct iommu_sva_domain and new
On 2022/5/20 19:28, Jean-Philippe Brucker wrote:
On Fri, May 20, 2022 at 02:38:12PM +0800, Baolu Lu wrote:
On 2022/5/20 00:39, Jean-Philippe Brucker wrote:
+struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct mm_struct
*mm)
+{
+ struct iommu_sva_domain *sva_domain
On 2022/5/20 16:45, Joerg Roedel wrote:
On Mon, May 16, 2022 at 09:57:56AM +0800, Lu Baolu wrote:
const struct iommu_domain_ops *default_domain_ops;
+ const struct iommu_domain_ops *blocking_domain_ops;
I don't understand why extra domain-ops are needed for this. I think it
On 2022/5/20 00:39, Jean-Philippe Brucker wrote:
+struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct mm_struct
*mm)
+{
+ struct iommu_sva_domain *sva_domain;
+ struct iommu_domain *domain;
+ ioasid_t max_pasid = 0;
+ int ret = -EINVAL;
+
+ /*
On 2022/5/20 00:33, Jean-Philippe Brucker wrote:
diff --git a/drivers/iommu/iommu-sva-lib.h b/drivers/iommu/iommu-sva-lib.h
index 8909ea1094e3..1be21e6b93ec 100644
--- a/drivers/iommu/iommu-sva-lib.h
+++ b/drivers/iommu/iommu-sva-lib.h
@@ -7,6 +7,7 @@
#include
#include
+#include
Hi Jean,
On 2022/5/19 18:37, Jean-Philippe Brucker wrote:
On Thu, May 19, 2022 at 03:20:38PM +0800, Lu Baolu wrote:
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 88817a3376ef..6e2cd082c670 100644
---
On 2022/5/19 02:21, Jacob Pan wrote:
DMA requests tagged with PASID can target individual IOMMU domains.
Introduce a domain-wide PASID for DMA API, it will be used on the same
mapping as legacy DMA without PASID. Let it be IOVA or PA in case of
identity domain.
Signed-off-by: Jacob Pan
---
On 2022/5/19 02:21, Jacob Pan wrote:
IOMMU group maintains a PASID array which stores the associated IOMMU
domains. This patch introduces a helper function to do domain to PASID
look up. It will be used by TLB flush and device-PASID attach verification.
Do you really need this?
The IOMMU
On 2022/5/17 19:13, Jason Gunthorpe wrote:
On Tue, May 17, 2022 at 10:05:43AM +0800, Baolu Lu wrote:
Hi Jason,
On 2022/5/17 02:06, Jason Gunthorpe wrote:
+static __init int tboot_force_iommu(void)
+{
+ if (!tboot_enabled())
+ return 0;
+
+ if (no_iommu
On 2022/5/17 21:13, Jason Gunthorpe wrote:
On Tue, May 17, 2022 at 01:43:03PM +0100, Robin Murphy wrote:
FWIW from my point of view I'm happy with having a .detach_dev_pasid op
meaning implicitly-blocked access for now.
If this is the path then lets not call it attach/detach
please.
Hi Jason,
On 2022/5/16 21:57, Jason Gunthorpe wrote:
On Mon, May 16, 2022 at 12:22:08PM +0100, Robin Murphy wrote:
On 2022-05-16 02:57, Lu Baolu wrote:
Each IOMMU driver must provide a blocking domain ops. If the hardware
supports detaching domain from device, setting blocking domain equals
Hi Jason,
On 2022/5/17 02:06, Jason Gunthorpe wrote:
+static __init int tboot_force_iommu(void)
+{
+ if (!tboot_enabled())
+ return 0;
+
+ if (no_iommu || dmar_disabled)
+ pr_warn("Forcing Intel-IOMMU to enabled\n");
Unrelated, but when we are in the
Hi Robin,
On 2022/5/16 19:22, Robin Murphy wrote:
On 2022-05-16 02:57, Lu Baolu wrote:
Each IOMMU driver must provide a blocking domain ops. If the hardware
supports detaching domain from device, setting blocking domain equals
detaching the existing domain from the deivce. Otherwise, an
On 2022/5/12 19:51, Jason Gunthorpe wrote:
On Thu, May 12, 2022 at 08:00:59AM +0100, Jean-Philippe Brucker wrote:
It is not "missing" it is just renamed to blocking_domain->ops->set_dev_pasid()
The implementation of that function would be identical to
detach_dev_pasid.
attach(dev, pasid,
On 2022/5/13 08:32, Nicolin Chen wrote:
Local boot test and VFIO sanity test show that info->iommu can be
used in device_to_iommu() as a fast path. So this patch adds it.
Signed-off-by: Nicolin Chen
---
drivers/iommu/intel/iommu.c | 5 +
1 file changed, 5 insertions(+)
diff --git
On 2022/5/13 07:12, Steve Wahl wrote:
On Thu, May 12, 2022 at 10:13:09AM -0500, Steve Wahl wrote:
To support up to 64 sockets with 10 DMAR units each (640), make the
value of DMAR_UNITS_SUPPORTED adjustable by a config variable,
CONFIG_DMAR_UNITS_SUPPORTED, and make it's default 1024 when
On 2022/5/12 20:03, Jason Gunthorpe wrote:
On Thu, May 12, 2022 at 07:59:41PM +0800, Baolu Lu wrote:
On 2022/5/12 19:48, Jason Gunthorpe wrote:
On Thu, May 12, 2022 at 01:17:08PM +0800, Baolu Lu wrote:
On 2022/5/12 13:01, Tian, Kevin wrote:
From: Baolu Lu
Sent: Thursday, May 12, 2022 11:03
On 2022/5/12 19:51, Jason Gunthorpe wrote:
On Thu, May 12, 2022 at 11:02:39AM +0800, Baolu Lu wrote:
+ mutex_lock(>mutex);
+ domain = xa_load(>pasid_array, pasid);
+ if (domain && domain->type != type)
+ domain = NULL;
+ mu
On 2022/5/12 19:48, Jason Gunthorpe wrote:
On Thu, May 12, 2022 at 01:17:08PM +0800, Baolu Lu wrote:
On 2022/5/12 13:01, Tian, Kevin wrote:
From: Baolu Lu
Sent: Thursday, May 12, 2022 11:03 AM
On 2022/5/11 22:53, Jason Gunthorpe wrote:
Also, given the current arrangement it might make sense
Hi Jason,
On 2022/5/12 01:00, Jason Gunthorpe wrote:
Consolidate pasid programming into dev_set_pasid() then called by both
intel_svm_attach_dev_pasid() and intel_iommu_attach_dev_pasid(), right?
I was only suggesting that really dev_attach_pasid() op is misnamed,
it should be called
On 2022/5/12 13:44, Tian, Kevin wrote:
From: Baolu Lu
Sent: Thursday, May 12, 2022 1:17 PM
On 2022/5/12 13:01, Tian, Kevin wrote:
From: Baolu Lu
Sent: Thursday, May 12, 2022 11:03 AM
On 2022/5/11 22:53, Jason Gunthorpe wrote:
Also, given the current arrangement it might make sense to have
On 2022/5/12 13:01, Tian, Kevin wrote:
From: Baolu Lu
Sent: Thursday, May 12, 2022 11:03 AM
On 2022/5/11 22:53, Jason Gunthorpe wrote:
Also, given the current arrangement it might make sense to have a
struct iommu_domain_sva given that no driver is wrappering this in
something else.
Fair
On 2022/5/11 22:53, Jason Gunthorpe wrote:
Assuming we leave room for multi-device groups this logic should just
be
group = iommu_group_get(dev);
if (!group)
return -ENODEV;
mutex_lock(>mutex);
domain = xa_load(>pasid_array, mm->pasid);
On 2022/5/12 01:25, Jacob Pan wrote:
Hi Jason,
On Wed, 11 May 2022 14:00:25 -0300, Jason Gunthorpe wrote:
On Wed, May 11, 2022 at 10:02:16AM -0700, Jacob Pan wrote:
If not global, perhaps we could have a list of pasids (e.g. xarray)
attached to the device_domain_info. The TLB flush logic
On 2022/5/10 23:23, Jason Gunthorpe wrote:
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
On 2022/5/10 22:02, Jason Gunthorpe wrote:
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
On 2022/5/10 22:34, Jason Gunthorpe wrote:
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
On 2022/5/10 08:51, Tian, Kevin wrote:
From: Lu Baolu
Sent: Sunday, May 8, 2022 8:35 PM
As domain->force_snooping only impacts the devices attached with the
domain, there's no need to check against all IOMMU units. On the other
hand, force_snooping could be set on a domain no matter whether it
On 2022/5/7 16:32, Baolu Lu wrote:
Hi Jean,
On 2022/5/5 14:42, Baolu Lu wrote:
On 2022/5/4 02:09, Jean-Philippe Brucker wrote:
On Mon, May 02, 2022 at 09:48:34AM +0800, Lu Baolu wrote:
Use below data structures for SVA implementation in the IOMMU core:
- struct iommu_sva_ioas
Represent
Hi Jean,
On 2022/5/5 14:42, Baolu Lu wrote:
On 2022/5/4 02:09, Jean-Philippe Brucker wrote:
On Mon, May 02, 2022 at 09:48:34AM +0800, Lu Baolu wrote:
Use below data structures for SVA implementation in the IOMMU core:
- struct iommu_sva_ioas
Represent the I/O address space shared
On 2022/5/6 03:27, Jason Gunthorpe wrote:
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
On 2022/5/6 14:10, Tian, Kevin wrote:
From: Lu Baolu
Sent: Friday, May 6, 2022 1:27 PM
+
+/*
+ * Set the page snoop control for a pasid entry which has been set up.
+ */
+void intel_pasid_setup_page_snoop_control(struct intel_iommu *iommu,
+ struct device
On 2022/5/6 03:46, Steve Wahl wrote:
Increase DMAR_UNITS_SUPPORTED to support 64 sockets with 10 DMAR units
each, for a total of 640.
If the available hardware exceeds DMAR_UNITS_SUPPORTED (previously set
to MAX_IO_APICS, or 128), it causes these messages: "DMAR: Failed to
allocate seq_id",
On 2022/5/5 21:38, Jean-Philippe Brucker wrote:
Hi Baolu,
On Thu, May 05, 2022 at 04:31:38PM +0800, Baolu Lu wrote:
On 2022/5/4 02:20, Jean-Philippe Brucker wrote:
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 7cae631c1baa..33449523afbe 100644
--- a/drivers/iommu/iommu.c
On 2022/5/3 15:49, Jean-Philippe Brucker wrote:
On Sat, Apr 30, 2022 at 03:33:17PM +0800, Baolu Lu wrote:
Jean, another quick question about the iommu_sva_bind_device()
/**
* iommu_sva_bind_device() - Bind a process address space to a device
* @dev: the device
* @mm: the mm to bind
On 2022/5/5 16:46, Tian, Kevin wrote:
From: Lu Baolu
Sent: Thursday, May 5, 2022 9:07 AM
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
On 2022/5/5 16:43, Tian, Kevin wrote:
From: Lu Baolu
Sent: Thursday, May 5, 2022 9:07 AM
As domain->force_snooping only impacts the devices attached with the
domain, there's no need to check against all IOMMU units. At the same
time, for a brand new domain (hasn't been attached to any device),
On 2022/5/4 02:20, Jean-Philippe Brucker wrote:
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 7cae631c1baa..33449523afbe 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -3174,3 +3174,24 @@ void iommu_detach_device_pasid(struct iommu_domain
*domain,
On 2022/5/4 02:12, Jean-Philippe Brucker wrote:
On Mon, May 02, 2022 at 09:48:37AM +0800, Lu Baolu wrote:
Add support for SVA domain allocation and provide an SVA-specific
iommu_domain_ops.
Signed-off-by: Lu Baolu
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 14 +++
On 2022/5/4 02:09, Jean-Philippe Brucker wrote:
On Mon, May 02, 2022 at 09:48:34AM +0800, Lu Baolu wrote:
Use below data structures for SVA implementation in the IOMMU core:
- struct iommu_sva_ioas
Represent the I/O address space shared with an application CPU address
space. This
On 2022/5/4 02:07, Jean-Philippe Brucker wrote:
On Mon, May 02, 2022 at 09:48:33AM +0800, Lu Baolu wrote:
Attaching an IOMMU domain to a PASID of a device is a generic operation
for modern IOMMU drivers which support PASID-granular DMA address
translation. Currently visible usage scenarios
On 2022/5/4 02:02, Jean-Philippe Brucker wrote:
On Mon, May 02, 2022 at 09:48:32AM +0800, Lu Baolu wrote:
Use this field to save the pasid/ssid bits that a device is able to
support with its IOMMU hardware. It is a generic attribute of a device
and lifting it into the per-device dev_iommu
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;
goto unlock_out;
} else {
- if (group->domain && group->domain != group->default_domain)
On 2022/5/4 21:31, Jason Gunthorpe wrote:
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
first
Hi Jason,
On 2022/5/4 08:11, Jason Gunthorpe wrote:
Once the group enters 'owned' mode it can never be assigned back to the
default_domain or to a NULL domain. It must always be actively assigned to
a current domain. If the caller hasn't provided a domain then the core
must provide an explicit
Hi Jason,
On 2022/5/4 08:11, Jason Gunthorpe wrote:
+static int __iommu_group_attach_domain(struct iommu_group *group,
+ struct iommu_domain *new_domain)
{
int ret;
+ if (group->domain == new_domain)
+ return 0;
+
/*
-
On 2022/5/2 21:19, Jason Gunthorpe wrote:
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
On 2022/5/3 05:36, Jacob Pan wrote:
Hi BaoLu,
On Sun, 1 May 2022 19:24:33 +0800, Lu Baolu
wrote:
The IOMMU force snooping capability is not required to be consistent
among all the IOMMUs anymore. Remove force snooping capability check
in the IOMMU hot-add path and
On 2022/5/3 05:31, Jacob Pan wrote:
Hi BaoLu,
Hi Jacob,
On Sun, 1 May 2022 19:24:32 +0800, Lu Baolu
wrote:
As domain->force_snooping only impacts the devices attached with the
domain, there's no need to check against all IOMMU units. At the same
time, for a brand new domain (hasn't been
On 2022/5/2 21:17, Jason Gunthorpe wrote:
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;
+
+
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
first-level PTEs has no functional impact because the Intel IOMMU always
ignores the same bit in first-level
On 2022/4/30 06:19, Fenghua Yu wrote:
Hi, Jean and Baolu,
On Fri, Apr 29, 2022 at 03:34:36PM +0100, Jean-Philippe Brucker wrote:
On Fri, Apr 29, 2022 at 06:51:17AM -0700, Fenghua Yu wrote:
Hi, Baolu,
On Fri, Apr 29, 2022 at 03:53:57PM +0800, Baolu Lu wrote:
On 2022/4/28 16:39, Jean-Philippe
On 2022/4/29 05:09, Joao Martins wrote:
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -5089,6 +5089,113 @@ static void intel_iommu_iotlb_sync_map(struct
iommu_domain *domain,
}
}
+static int intel_iommu_set_dirty_tracking(struct iommu_domain *domain,
+
On 2022/4/29 05:09, Joao Martins wrote:
Today, the dirty state is lost and the page wouldn't be migrated to
destination potentially leading the guest into error.
Add an unmap API that reads the dirty bit and sets it in the
user passed bitmap. This unmap iommu API tackles a potentially
racy
On 2022/4/29 05:09, Joao Martins wrote:
Add an IO pagetable API iopt_read_and_clear_dirty_data() that
performs the reading of dirty IOPTEs for a given IOVA range and
then copying back to userspace from each area-internal bitmap.
Underneath it uses the IOMMU equivalent API which will read the
On 2022/4/29 05:09, Joao Martins wrote:
+int iopt_set_dirty_tracking(struct io_pagetable *iopt,
+ struct iommu_domain *domain, bool enable)
+{
+ struct iommu_domain *dom;
+ unsigned long index;
+ int ret = -EOPNOTSUPP;
+
+
Hi Joao,
Thanks for doing this.
On 2022/4/29 05:09, Joao Martins wrote:
Add to iommu domain operations a set of callbacks to
perform dirty tracking, particulary to start and stop
tracking and finally to test and clear the dirty data.
Drivers are expected to dynamically change its hw
On 2022/4/28 16:39, Jean-Philippe Brucker wrote:
On Tue, Apr 26, 2022 at 04:31:57PM -0700, Dave Hansen wrote:
On 4/26/22 09:48, Jean-Philippe Brucker wrote:
On Tue, Apr 26, 2022 at 08:27:00AM -0700, Dave Hansen wrote:
On 4/25/22 09:40, Jean-Philippe Brucker wrote:
The problem is that we'd
Hi Robin,
On 2022/4/28 21:18, Robin Murphy wrote:
Move the bus setup to iommu_device_register(). This should allow
bus_iommu_probe() to be correctly replayed for multiple IOMMU instances,
and leaves bus_set_iommu() as a glorified no-op to be cleaned up next.
I re-fetched the latest patches on
On 2022/4/28 22:57, Jean-Philippe Brucker wrote:
On Thu, Apr 21, 2022 at 01:21:20PM +0800, Lu Baolu wrote:
static void iopf_handle_group(struct work_struct *work)
{
struct iopf_group *group;
@@ -134,12 +78,23 @@ static void iopf_handle_group(struct work_struct *work)
group =
On 2022/4/28 22:53, Jean-Philippe Brucker wrote:
On Thu, Apr 21, 2022 at 01:21:12PM +0800, Lu Baolu wrote:
Attaching an IOMMU domain to a PASID of a device is a generic operation
for modern IOMMU drivers which support PASID-granular DMA address
translation. Currently visible usage scenarios
Hi Jean,
On 2022/4/28 22:47, Jean-Philippe Brucker wrote:
Hi Baolu,
On Thu, Apr 21, 2022 at 01:21:19PM +0800, Lu Baolu wrote:
+/*
+ * Get the attached domain for asynchronous usage, for example the I/O
+ * page fault handling framework. The caller get a reference counter
+ * of the domain
101 - 170 of 170 matches
Mail list logo
