>-Original Message-
>From: Liu, Yi L
>Sent: Monday, November 27, 2023 2:39 PM
>Subject: [PATCH 3/3] vfio: Report PASID capability via VFIO_DEVICE_FEATURE
>ioctl
>
>This reports the PASID capability data to userspace via VFIO_DEVICE_FEATURE,
>hence userspace could probe PASID capability
>-Original Message-
>From: Liu, Yi L
>Sent: Monday, November 27, 2023 2:39 PM
>Subject: [PATCH 2/3] vfio: Add
>VFIO_DEVICE_PASID_[AT|DE]TACH_IOMMUFD_PT
>
>This adds ioctls for the userspace to attach a given pasid of a vfio
>device to/from an IOAS/HWPT.
>
>Signed-off-by: Yi Liu
>---
>
This reports the PASID capability data to userspace via VFIO_DEVICE_FEATURE,
hence userspace could probe PASID capability by it. This is a bit different
with other capabilities which are reported to userspace when the user reads
the device's PCI configuration space. There are two reasons for this.
This adds ioctls for the userspace to attach a given pasid of a vfio
device to/from an IOAS/HWPT.
Signed-off-by: Yi Liu
---
drivers/vfio/device_cdev.c | 45 +++
drivers/vfio/vfio.h| 4 +++
drivers/vfio/vfio_main.c | 8 ++
include/uapi/linux/vfio.h |
From: Kevin Tian
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 | 48 +
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
From: Lu Baolu
This allows the upper layers to set a nested type domain to a PASID of a
device if the PASID feature is supported by the IOMMU hardware.
The set_dev_pasid callback for non-nest domain has already be there, so
this only needs to add it for nested domains.
Signed-off-by: Lu Baolu
This tests iommufd pasid attach/replace/detach.
Signed-off-by: Yi Liu
---
tools/testing/selftests/iommu/iommufd.c | 172 ++
.../selftests/iommu/iommufd_fail_nth.c| 28 ++-
tools/testing/selftests/iommu/iommufd_utils.h | 78
3 files changed, 274
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 | 24 ++
drivers/iommu/iommufd/selftest.c | 116
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
From: Kevin Tian
This introduces three APIs for device drivers to manage pasid attach/
replace/detach.
int iommufd_device_pasid_attach(struct iommufd_device *idev,
u32 pasid, u32 *pt_id);
int iommufd_device_pasid_replace(struct iommufd_device *idev,
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 | 28
1 file changed,
Most of the core logic before conducting the actual device attach/
replace operation can be shared with pasid attach/replace. Create
a new structure so more information (e.g. pasid) can be later added
along with the attach_fn.
Signed-off-by: Kevin Tian
Signed-off-by: Yi Liu
---
From: Lu Baolu
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 also expected to be used
only by IOMMUFD.
Signed-off-by: Lu Baolu
Signed-off-by: Yi Liu
---
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), each attachment
is tagged with
On 11/27/23 12:44 AM, Yonghong Song wrote:
On 11/26/23 8:52 PM, Eduard Zingerman wrote:
On Sun, 2023-11-26 at 18:04 -0600, Daniel Xu wrote:
[...]
Tbh I'm not sure. This test passes with preserve_static_offset
because it suppresses preserve_access_index. In general clang
translates bitfield
On 11/26/23 8:52 PM, Eduard Zingerman wrote:
On Sun, 2023-11-26 at 18:04 -0600, Daniel Xu wrote:
[...]
Tbh I'm not sure. This test passes with preserve_static_offset
because it suppresses preserve_access_index. In general clang
translates bitfield access to a set of IR statements like:
C:
On 11/26/23 3:14 PM, Eduard Zingerman wrote:
On Sat, 2023-11-25 at 20:22 -0800, Yonghong Song wrote:
[...]
--- a/tools/testing/selftests/bpf/progs/test_tunnel_kern.c
+++ b/tools/testing/selftests/bpf/progs/test_tunnel_kern.c
@@ -6,7 +6,10 @@
* modify it under the terms of version 2 of the
On 11/24/23 2:26 AM, Hangbin Liu wrote:
> As Guillaume pointed, many selftests create namespaces with very common
> names (like "client" or "server") or even (partially) run directly in
> init_net.
> This makes these tests prone to failure if another namespace with the same
> name already exists.
On Sun, 2023-11-26 at 18:04 -0600, Daniel Xu wrote:
[...]
> > Tbh I'm not sure. This test passes with preserve_static_offset
> > because it suppresses preserve_access_index. In general clang
> > translates bitfield access to a set of IR statements like:
> >
> > C:
> > struct foo {
> >
Hi,
On Sun, Nov 26, 2023 at 10:14:21PM +0200, Eduard Zingerman wrote:
> On Sat, 2023-11-25 at 20:22 -0800, Yonghong Song wrote:
> [...]
> > --- a/tools/testing/selftests/bpf/progs/test_tunnel_kern.c
> > +++ b/tools/testing/selftests/bpf/progs/test_tunnel_kern.c
> > @@ -6,7 +6,10 @@
> >*
On Sat, 2023-11-25 at 20:22 -0800, Yonghong Song wrote:
[...]
> --- a/tools/testing/selftests/bpf/progs/test_tunnel_kern.c
> +++ b/tools/testing/selftests/bpf/progs/test_tunnel_kern.c
> @@ -6,7 +6,10 @@
>* modify it under the terms of version 2 of the GNU General Public
>* License as
On Fri, Nov 24, 2023 at 12:54:30PM +0100, Peter Zijlstra wrote:
> On Fri, Nov 24, 2023 at 12:04:09PM +0100, Jonas Oberhauser wrote:
>
> > > I think ARM64 approached this problem by adding the
> > > load-acquire/store-release instructions and for TSO based code,
> > > translate into those (eg. x86
On 2023-11-26 10:28:28+0100, Willy Tarreau wrote:
> Hi Thomas,
>
> > +int test_rlimit(void)
> > +{
> > + struct rlimit rlim = {
> > + .rlim_cur = 1 << 20,
> > + .rlim_max = 1 << 20,
> > + };
> > + int ret;
> > +
> > + ret = setrlimit(RLIMIT_CORE, );
> > + if (ret)
>
Hi Thomas,
> +int test_rlimit(void)
> +{
> + struct rlimit rlim = {
> + .rlim_cur = 1 << 20,
> + .rlim_max = 1 << 20,
> + };
> + int ret;
> +
> + ret = setrlimit(RLIMIT_CORE, );
> + if (ret)
> + return -1;
> +
> + rlim.rlim_cur = 0;
> +
25 matches
Mail list logo
