On 9/12/24 9:12 PM, Yi Liu wrote:
Provide a high-level API to allow replacements of one domain with
another for specific pasid of a device. This is similar to
iommu_group_replace_domain() and it is expected to be used only by
IOMMUFD.
Co-developed-by: Lu Baolu
Signed-off-by: Lu Baolu
Signed-of
On 9/12/24 9:06 PM, Yi Liu wrote:
The iommu drivers are on the way to drop the remove_dev_pasid op by
extending the blocked_domain to support PASID. However, this cannot be
done in one shot. So far, the Intel iommu and the ARM SMMUv3 driver have
supported it, while the AMD iommu driver has not ye
On 9/13/24 9:35 AM, Baolu Lu wrote:
On 9/12/24 9:04 PM, Yi Liu wrote:
set_dev_pasid op is going to support domain replacement and keep the old
hardware config if it fails. Make the Intel iommu driver be prepared for
it.
Signed-off-by: Yi Liu
---
drivers/iommu/intel/iommu.c | 98 +
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski :
On Wed, 11 Sep 2024 20:52:39 -0400 you wrote:
> From: Willem de Bruijn
>
> 1/3: run in nets, as discussed, and add missing CONFIGs
> 2/3: import tcp/zerocopy
> 3/3: import tcp/slow_start
>
> Willem de Bruijn (3):
On 9/12/24 9:04 PM, Yi Liu wrote:
diff --git a/drivers/iommu/intel/pasid.c b/drivers/iommu/intel/pasid.c
index b51fc268dc84..ceb9c5274a39 100644
--- a/drivers/iommu/intel/pasid.c
+++ b/drivers/iommu/intel/pasid.c
@@ -236,8 +236,13 @@ devtlb_invalidation_with_pasid(struct intel_iommu *iommu,
On 9/12/24 9:04 PM, Yi Liu wrote:
@@ -4299,7 +4304,12 @@ domain_prepare_dev_pasid(struct iommu_domain *domain,
unsigned long flags;
int ret;
- ret = prepare_domain_attach_device(domain, dev);
+ /* Nested type domain should prepare its parent domain */
+ if (domain_
On 9/12/24 9:04 PM, Yi Liu wrote:
@@ -4325,24 +4363,18 @@ static int intel_iommu_set_dev_pasid(struct
iommu_domain *domain,
ret = intel_pasid_setup_second_level(iommu, dmar_domain,
dev, pasid);
if (ret)
-
On 9/12/24 9:04 PM, Yi Liu wrote:
set_dev_pasid op is going to support domain replacement and keep the old
hardware config if it fails. Make the Intel iommu driver be prepared for
it.
Signed-off-by: Yi Liu
---
drivers/iommu/intel/iommu.c | 98 -
1 file cha
On 9/10/24 22:33, David Gow wrote:
On Tue, 10 Sept 2024 at 09:10, Luis Felipe Hernandez
wrote:
Adds test suite for integer based power function.
It would be nice to see more details on what this test does>
What's the output look like?
I fixed it up with the details from the Kconfig. Please
On Thu, Sep 12, 2024 at 06:17:26AM -0700, Yi Liu wrote:
> There is no helpers for user to check if a given ID is allocated or not,
> neither a helper to loop all the allocated IDs in an IDA and do something
> for cleanup. With the two needs, a helper to get the lowest allocated ID
> of a range and
On Thu Sep 12, 2024 at 10:15 AM CEST, Claudio Imbrenda wrote:
> On Mon, 2 Sep 2024 13:50:01 +0200
> Christoph Schlameuss wrote:
>
> > Add a test case manipulating s390 storage keys from within the ucontrol
> > VM.
> >
> > Signed-off-by: Christoph Schlameuss
> > ---
> > .../selftests/kvm/s390x/
On 2024/9/12 21:04, Yi Liu wrote:
Draining PRQ is mostly conjuncted with pasid teardown, and with more callers
coming,
move it into it in the intel_pasid_tear_down_entry(). But there is scenario
that only
teardown pasid entry but no PRQ drain, so passing a flag to mark it.
Is it a reasonable
PASID usage requires PASID support in both device and IOMMU. Since the
iommu drivers always enable the PASID capability for the device if it
is supported, so it is reasonable to extend the IOMMU_GET_HW_INFO to
report the PASID capability to userspace.
Signed-off-by: Yi Liu
---
drivers/iommu/iomm
This adds ioctls for the userspace to attach/detach a given pasid of a
vfio device to/from an IOAS/HWPT.
Reviewed-by: Jason Gunthorpe
Signed-off-by: Yi Liu
---
drivers/vfio/device_cdev.c | 51 +++
drivers/vfio/vfio.h| 4 +++
drivers/vfio/vfio_main.c |
This adds pasid_at|de]tach_ioas ops for attaching hwpt to pasid of a
device and the helpers for it. For now, only vfio-pci supports pasid
attach/detach.
Signed-off-by: Kevin Tian
Signed-off-by: Yi Liu
---
drivers/vfio/iommufd.c | 50 +
drivers/vfio/pci/v
There is no helpers for user to check if a given ID is allocated or not,
neither a helper to loop all the allocated IDs in an IDA and do something
for cleanup. With the two needs, a helper to get the lowest allocated ID
of a range and two variants based on it.
Caller can check if a given ID is all
This adds the pasid attach/detach uAPIs for userspace to attach/detach
a PASID of a device to/from a given ioas/hwpt. Only vfio-pci driver is
enabled in this series. After this series, PASID-capable devices bound
with vfio-pci can report PASID capability to userspace and VM to enable
PASID usages l
This tests iommufd pasid attach/replace/detach.
Signed-off-by: Yi Liu
---
tools/testing/selftests/iommu/iommufd.c | 256 ++
.../selftests/iommu/iommufd_fail_nth.c| 29 +-
tools/testing/selftests/iommu/iommufd_utils.h | 78 ++
3 files changed, 359 insertions(+)
This adds 4 test ops for pasid attach/replace/detach testing. There are
ops to attach/detach pasid, and also op to check the attached domain of
a pasid.
Signed-off-by: Yi Liu
---
drivers/iommu/iommufd/iommufd_test.h | 30 ++
drivers/iommu/iommufd/selftest.c | 138 +++
There is need to get the selftest device (sobj->type == TYPE_IDEV) in
multiple places, so have a helper to for it.
Signed-off-by: Yi Liu
---
drivers/iommu/iommufd/selftest.c | 32 +---
1 file changed, 21 insertions(+), 11 deletions(-)
diff --git a/drivers/iommu/iommu
The two callbacks are needed to make pasid_attach/detach path complete for
mock device. A nop is enough for set_dev_pasid, a domain type check in the
remove_dev_pasid is also helpful.
Signed-off-by: Yi Liu
---
drivers/iommu/iommufd/selftest.c | 38
1 file changed
Most of the core logic before conducting the actual device attach/
replace operation can be shared with pasid attach/replace. So pass
pasid through the device attach/replace helpers to prepare adding
pasid attach/replace.
So far the @pasid should only be IOMMU_NO_PASID. No functional change.
Sign
This introduces three APIs for device drivers to manage pasid attach/
replace/detach.
int iommufd_device_pasid_attach(struct iommufd_device *idev,
ioasid_t pasid, u32 *pt_id);
int iommufd_device_pasid_replace(struct iommufd_device *idev,
The iommu_attach_handle is optional in the RID attach/replace API and the
PASID attach APIs. But it is a mandatory argument for the PASID replace API.
Without it, the PASID replace path cannot get the old domain. Hence, the
PASID path (attach/replace) requires the attach handle. As iommufd is the
m
iommufd plans to always pass in an iommu_attach_handle to the iommu
core, so it's no longer fault specific, hence move the helpers out
of the fault.c
Signed-off-by: Yi Liu
---
drivers/iommu/iommufd/fault.c | 61 +
drivers/iommu/iommufd/iommufd_private.h | 57 +++
There is a wrapper of iommu_attach_group_handle(), so making a wrapper for
iommu_replace_group_handle() for further code refactor. No functional change
intended.
Signed-off-by: Yi Liu
---
drivers/iommu/iommufd/fault.c | 54 ---
1 file changed, 31 insertions(+), 23
PASID (Process Address Space ID) is a PCIe extension to tag the DMA
transactions out of a physical device, and most modern IOMMU hardware
have supported PASID granular address translation. So a PASID-capable
device can be attached to multiple hwpts (a.k.a. domains), and each
attachment is tagged wi
Provide a high-level API to allow replacements of one domain with
another for specific pasid of a device. This is similar to
iommu_group_replace_domain() and it is expected to be used only by
IOMMUFD.
Co-developed-by: Lu Baolu
Signed-off-by: Lu Baolu
Signed-off-by: Yi Liu
---
drivers/iommu/iom
The blocked domain can be extended to park PASID of a device to be the
DMA blocking state. By this the remove_dev_pasid() op is dropped.
Signed-off-by: Yi Liu
---
drivers/iommu/intel/iommu.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/inte
During the review of iommufd pasid series, Kevin and Jason suggested
attaching PASID to the blocked domain hence replacing the usage of
remove_dev_pasid() op [1]. This makes sense as it makes the PASID path
aligned with the RID path which attaches the RID to the blocked_domain
when it is to be bloc
The iommu drivers are on the way to drop the remove_dev_pasid op by
extending the blocked_domain to support PASID. However, this cannot be
done in one shot. So far, the Intel iommu and the ARM SMMUv3 driver have
supported it, while the AMD iommu driver has not yet. During this
transition, the IOMMU
From: Jason Gunthorpe
The blocked domain is used to park RID to be blocking DMA state. This
can be extended to PASID as well. By this, the remove_dev_pasid() op
of ARM SMMUv3 can be dropped.
Signed-off-by: Jason Gunthorpe
Signed-off-by: Yi Liu
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c |
From: Lu Baolu
Extend intel_iommu_set_dev_pasid() to set a nested type domain to a PASID
of a device.
Signed-off-by: Lu Baolu
Co-developed-by: Yi Liu
Signed-off-by: Yi Liu
---
drivers/iommu/intel/iommu.c | 22 +-
drivers/iommu/intel/iommu.h | 3 +++
drivers/iommu/intel
The iommu core is going to support domain replacement for pasid, it needs
to make the set_dev_pasid op support replacing domain and keep the old
domain config in the failure case.
AMD iommu driver does not support domain replacement for pasid yet, so it
would fail the set_dev_pasid op to keep the
set_dev_pasid op is going to support domain replacement and keep the old
hardware config if it fails. Make the Intel iommu driver be prepared for
it.
Signed-off-by: Yi Liu
---
drivers/iommu/intel/iommu.c | 98 -
1 file changed, 65 insertions(+), 33 deletions(-
To support domain replacement for pasid, the underlying iommu driver needs
to know the old domain hence be able to clean up the existing attachment.
It would be much convenient for iommu layer to pass down the old domain.
Otherwise, iommu drivers would need to track domain for pasids by themselves,
This splits the preparation works of the iommu and the Intel iommu driver
out from the iommufd pasid attach/replace series. [1]
To support domain replacement, the definition of the set_dev_pasid op
needs to be enhanced. Meanwhile, the existing set_dev_pasid callbacks
should be extended as well to
From: Jason Gunthorpe
set_dev_pasid() op is going to be enhanced to support domain replacement
of a pasid. This prepares for this op definition.
Signed-off-by: Jason Gunthorpe
Signed-off-by: Yi Liu
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 2 +-
drivers/iommu/arm/arm-smmu-v3/arm-s
Draining PRQ is mostly conjuncted with pasid teardown, and with more callers
coming,
move it into it in the intel_pasid_tear_down_entry(). But there is scenario
that only
teardown pasid entry but no PRQ drain, so passing a flag to mark it.
Signed-off-by: Yi Liu
---
drivers/iommu/intel/iommu.c
On Thu, Sep 12, 2024 at 11:50:18AM +0100, Will Deacon wrote:
> Hi Dave,
>
> On Wed, Sep 11, 2024 at 08:33:54AM -0700, Dave Hansen wrote:
> > On 9/11/24 08:01, Kevin Brodsky wrote:
> > > On 22/08/2024 17:10, Joey Gouly wrote:
> > >> @@ -371,6 +382,9 @@ int copy_thread(struct task_struct *p, const s
Matthieu Baerts wrote:
> Hi Willem,
>
> On 12/09/2024 02:52, Willem de Bruijn wrote:
> > From: Willem de Bruijn
> >
> > 1/3: run in nets, as discussed, and add missing CONFIGs
> > 2/3: import tcp/zerocopy
> > 3/3: import tcp/slow_start
>
> Thank you for the v2. This new version looks good to me
On Mon, 12 Aug 2024 15:11:52 +0530, Madhavan Srinivasan wrote:
> Currently exec-target.c file is linked as static and this
> post a requirement to install libc dev package to build.
> Without it, build-break when compiling selftest/powerpc/benchmark.
>
> CC exec_target
> /usr/bin/ld: canno
Hi Willem,
On 12/09/2024 02:52, Willem de Bruijn wrote:
> From: Willem de Bruijn
>
> 1/3: run in nets, as discussed, and add missing CONFIGs
> 2/3: import tcp/zerocopy
> 3/3: import tcp/slow_start
Thank you for the v2. This new version looks good to me:
Acked-by: Matthieu Baerts (NGI0)
I di
Hi Dave,
On Wed, Sep 11, 2024 at 08:33:54AM -0700, Dave Hansen wrote:
> On 9/11/24 08:01, Kevin Brodsky wrote:
> > On 22/08/2024 17:10, Joey Gouly wrote:
> >> @@ -371,6 +382,9 @@ int copy_thread(struct task_struct *p, const struct
> >> kernel_clone_args *args)
> >>if (system_supports_
On Mon, 2 Sep 2024 13:50:01 +0200
Christoph Schlameuss wrote:
> Add a test case manipulating s390 storage keys from within the ucontrol
> VM.
>
> Signed-off-by: Christoph Schlameuss
> ---
> .../selftests/kvm/s390x/ucontrol_test.c | 89 ++-
> 1 file changed, 88 insertions
On Mon, 2 Sep 2024 13:50:00 +0200
Christoph Schlameuss wrote:
> Add a test case verifying basic running and interaction of ucontrol VMs.
> Fill the segment and page tables for allocated memory and map memory on
> first access.
>
> * uc_map_unmap
> Store and load data to mapped and unmapped me
46 matches
Mail list logo
