Hi Thomas,
> +int test_rlimit(void)
> +{
> + struct rlimit rlim = {
> + .rlim_cur = 1 << 20,
> + .rlim_max = 1 << 20,
> + };
> + int ret;
> +
> + ret = setrlimit(RLIMIT_CORE, &rlim);
> + if (ret)
> + return -1;
> +
> + rlim.rlim_cur = 0;
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, &rlim);
> > + if (ret
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 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 publis
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 @@
> >* modify
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 {
> >
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 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/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/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 a
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 a
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
---
drivers/iommu/iommu-pr
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
---
drivers/iommu/io
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, 28
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,
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
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 +++
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 insertions
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 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
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 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 | 5
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.
>-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
>---
>
>-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
25 matches
Mail list logo
