* Re: [PATCH v5 5/5] iommufd/vdevice: add TSM request ioctl
From: Dan Williams (nvidia) @ 2026-06-08 20:58 UTC (permalink / raw)
To: Aneesh Kumar K.V, Dan Williams (nvidia), Dan Williams (nvidia),
Alexey Kardashevskiy, linux-coco, iommu, linux-kernel, kvm
Cc: Bjorn Helgaas, Dan Williams, Jason Gunthorpe, Joerg Roedel,
Jonathan Cameron, Kevin Tian, Nicolin Chen, Samuel Ortiz,
Steven Price, Suzuki K Poulose, Will Deacon, Xu Yilun,
Shameer Kolothum, Paolo Bonzini, Tony Krowiak, Halil Pasic,
Jason Herne, Harald Freudenberger, Holger Dengler, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Sven Schnelle, Alex Williamson, Matthew Rosato, Farhan Ali,
Eric Farman, linux-s390
In-Reply-To: <yq5aik81sf22.fsf@kernel.org>
Aneesh Kumar K.V wrote:
[..]
> > I think we can wait to move it to its own IOMMU operation unless/until
> > there is a need to set RUN outside of an explicit guest request, right?
>
> Something like the below? (the diff against this series)
>
> I have not yet integrated this into the full CCA patchset for testing,
> but I wanted to make sure we are aligned on the UAPI.
[..]
> -static bool iommufd_vdevice_tsm_req_scope_valid(u32 scope)
> +static bool iommufd_vdevice_tsm_req_arch_valid(u32 tvm_arch)
> {
> - if (scope > IOMMU_VDEVICE_TSM_REQ_SCOPE_PCI_LAST)
> + switch (tvm_arch) {
> + case IOMMU_VDEVICE_TSM_TVM_ARCH_CCA:
> + case IOMMU_VDEVICE_TSM_TVM_ARCH_SEV:
> + case IOMMU_VDEVICE_TSM_TVM_ARCH_TDX:
Makes sense for any command that needs tunneling. However, see below, what is
that set, and do we need a IOMMU_VDEVICE_TSM_COMMON when architecture
differentiation is not required?
> + return true;
> + default:
> return false;
> + }
> +}
>
> - switch (scope) {
> - case IOMMU_VDEVICE_TSM_REQ_PCI_INFO:
> - case IOMMU_VDEVICE_TSM_REQ_PCI_STATE_CHANGE:
> - case IOMMU_VDEVICE_TSM_REQ_PCI_DEBUG_READ:
> - case IOMMU_VDEVICE_TSM_REQ_PCI_DEBUG_WRITE:
> +static bool iommufd_vdevice_tsm_req_op_valid(u32 op, u32 tvm_arch)
> +{
> + switch (op) {
> + case TSM_REQ_READ_OBJECT:
> + case TSM_REQ_REGEN_OBJECT:
> + case TSM_REQ_OBJECT_INFO:
The design goal of the netlink device-evidence interface is to be able
to respond to all shapes of requests for evidence. So netlink caches
objects that the hypercall handler can fill responses from.
It eliminates a class of commands that need tunneling.
> + case TSM_REQ_VALIDATE_MMIO:
> + case TSM_REQ_SET_TDI_STATE:
Are these potentially candidates for a IOMMU_VDEVICE_TSM_COMMON? The
handler knows how to do the arch-specific response from the common
iommufd result, or is there TSM-specific payload beyond @tsm_code for
these.
Make it the case that guest_req only needs non-common arch for
operations that are implementation unique, or where the response payload
exceeds what can be conveyed via @tsm_code.
> return true;
> + case TSM_REQ_SEV_ENABLE_DMA:
> + case TSM_REQ_SEV_DISABLE_DMA:
> + return tvm_arch == IOMMU_VDEVICE_TSM_TVM_ARCH_SEV;
Right, this appears to be the only case where the command is
implementation unique. The handler can only ask iommufd to take
arch-specific action.
^ permalink raw reply
* Re: [PATCH v6 6/6] s390: Enable Rust support
From: Jan Polensky @ 2026-06-08 19:45 UTC (permalink / raw)
To: Gary Guo, hca, gor, agordeev, ojeda, peterz, jpoimboe, jbaron,
aliceryhl
Cc: borntraeger, svens, boqun, bjorn3_gh, lossin, a.hindborg, tmgross,
dakr, rostedt, ardb, linux-s390, rust-for-linux, linux-kernel
In-Reply-To: <DJ3VN4EYXCUA.18YA9379UHT5Z@garyguo.net>
On Mon, Jun 08, 2026 at 07:25:06PM +0100, Gary Guo wrote:
> On Mon Jun 8, 2026 at 7:14 PM BST, Jan Polensky wrote:
> > Enable building Rust code on s390 by wiring the architecture into the
> > kernel Rust infrastructure.
> >
> > Add s390 to the Rust arch support documentation, provide the s390 Rust
> > target and required compiler flags, and set the bindgen target for
> > arch/s390. Adjust the Rust target generation and minimum rustc version
> > gating so the s390 setup is handled explicitly.
> >
> > The Rust toolchain uses the "s390x" triple naming for the 64 bit target.
> >
> > Rust support is currently incompatible with CONFIG_EXPOLINE, which
> > relies on compiler support for the -mindirect-branch= and
> > -mfunction_return= options. Therefore, select HAVE_RUST only when
> > EXPOLINE is disabled.
>
> Does `-Zretpoline-external-thunk`/`-Zretpoline` not work for s390? Rust will
> throw a warning saying that it doesn't recognize this for the target, but it
> looks like it does generate target features
> +retpoline-external-thunk,+retpoline-indirect-branches,+retpoline-indirect-calls
> in LLVM IR.
>
> Best,
> Gary
>
Hi Gary,
thanks. The warning by itself does not prove the flags are ignored,
since rustc may still forward unknown target features to the backend.
That said, s390 currently has no Rust/LLVM support for the EXPOLINE
compiler support we rely on in C, and the kernel-side Rust retpoline
handling is only wired up for x86/x86_64 today.
Backend support is planned, but has not been implemented yet. Until then,
keeping Rust support gated behind !CONFIG_EXPOLINE is the intentional and
conservative choice for this series.
Best,
Jan
^ permalink raw reply
* Re: [PATCH v18 3/4] vfio/pci: Add a reset_done callback for vfio-pci driver
From: Farhan Ali @ 2026-06-08 19:26 UTC (permalink / raw)
To: Alex Williamson
Cc: Keith Busch, linux-s390, linux-kernel, linux-pci, helgaas,
schnelle, mjrosato, Julian Ruess, Chengwen Feng
In-Reply-To: <20260604135717.5dc69583@shazbot.org>
On 6/4/2026 12:57 PM, Alex Williamson wrote:
> On Thu, 4 Jun 2026 10:17:04 -0700
> Farhan Ali <alifm@linux.ibm.com> wrote:
>
>> On 6/4/2026 1:28 AM, Keith Busch wrote:
>>> On Wed, Jun 03, 2026 at 11:24:14AM -0700, Farhan Ali wrote:
>>>> +static void vfio_pci_core_aer_reset_done(struct pci_dev *pdev)
>>>> +{
>>>> + struct vfio_pci_core_device *vdev = dev_get_drvdata(&pdev->dev);
>>>> +
>>>> + if (!vdev->pci_saved_state)
>>>> + return;
>>>> +
>>>> + pci_load_saved_state(pdev, vdev->pci_saved_state);
>>>> + pci_restore_state(pdev);
>>>> +}
>>> Shouldn't there be a cooresponding user space notification that the
>>> device has been restored? There's an eventfd on the error detected side
>>> so user space can know the device needs recovery, but how does it come
>>> to know that the reset is completed?
>> I think if the VFIO_DEVICE_RESET ioctl completes successfully it should
>> be an indication that the reset has completed? AFAIU the ioctl will
>> drive a reset via pci_try_reset_function(). If reset completes completes
>> successfully the reset_done() callback is called via pci_dev_restore().
>> So I don't think we need an eventfd to notify on reset completion.
>> Otherwise we would have the same problem today, where userspace is
>> unaware that VFIO_DEVICE_RESET did indeed successfully reset the device,
>> no? Or am I missing something?
> I'm starting to feel a little sketchy about this. I asked claude to
> enumerate the state restores and the source of that restored state.
> Hopefully this ascii table survives:
>
> ┌──────────────────────────┬────────────────────────┬─────────────────────┐
> │ Step │ Source │ Snapshot-dependent? │
> ├──────────────────────────┼────────────────────────┼─────────────────────┤
> │ │ EXP cap save buffer │ │
> │ pci_restore_pcie_state │ (pci_find_saved_cap, │ YES │
> │ │ cap.data) │ │
> ├──────────────────────────┼────────────────────────┼─────────────────────┤
> │ │ live │ │
> │ pci_restore_pasid_state │ pdev->pasid_enabled + │ no │
> │ │ pasid_features │ │
> ├──────────────────────────┼────────────────────────┼─────────────────────┤
> │ pci_restore_pri_state │ live pdev->pri_enabled │ no │
> │ │ + pri_reqs_alloc │ │
> ├──────────────────────────┼────────────────────────┼─────────────────────┤
> │ pci_restore_ats_state │ live dev->ats_enabled │ no │
> │ │ + ats_stu │ │
> ├──────────────────────────┼────────────────────────┼─────────────────────┤
> │ pci_restore_vc_state │ VC ext-cap save buffer │ YES │
> ├──────────────────────────┼────────────────────────┼─────────────────────┤
> │ │ live resource_size() │ │
> │ pci_restore_rebar_state │ (re-derived, written │ no │
> │ │ to hw) │ │
> ├──────────────────────────┼────────────────────────┼─────────────────────┤
> │ pci_restore_dpc_state │ DPC ext-cap save │ YES │
> │ │ buffer │ │
> ├──────────────────────────┼────────────────────────┼─────────────────────┤
> │ pci_restore_ptm_state │ PTM ext-cap save │ YES │
> │ │ buffer │ │
> ├──────────────────────────┼────────────────────────┼─────────────────────┤
> │ │ TPH ext-cap save │ │
> │ pci_restore_tph_state │ buffer, gated on live │ YES (gated) │
> │ │ tph_enabled │ │
> ├──────────────────────────┼────────────────────────┼─────────────────────┤
> │ pci_aer_clear_status │ clears hw status (not │ n/a │
> │ │ a restore) │ │
> ├──────────────────────────┼────────────────────────┼─────────────────────┤
> │ pci_restore_aer_state │ ERR ext-cap save │ YES │
> │ │ buffer │ │
> ├──────────────────────────┼────────────────────────┼─────────────────────┤
> │ │ saved_config_space[16] │ │
> │ pci_restore_config_space │ — type-0 header │ YES │
> │ │ (COMMAND, BARs, │ │
> │ │ cacheline…) │ │
> ├──────────────────────────┼────────────────────────┼─────────────────────┤
> │ pci_restore_pcix_state │ PCI-X cap save buffer │ YES │
> ├──────────────────────────┼────────────────────────┼─────────────────────┤
> │ pci_restore_msi_state │ live msi_desc list + │ no │
> │ │ msi(x)_enabled │ │
> ├──────────────────────────┼────────────────────────┼─────────────────────┤
> │ pci_enable_acs │ re-derived from ACS │ no │
> │ │ policy │ │
> ├──────────────────────────┼────────────────────────┼─────────────────────┤
> │ pci_restore_iov_state │ live dev->sriov │ no │
> │ │ (num_VFs, ctrl) │ │
> └──────────────────────────┴────────────────────────┴─────────────────────┘
>
> For things like MSI/X, SR-IOV, RE-BAR, etc. we're actually restoring
> from the kernel internal state rather than the save buffer state, so
> this is a no-op. However, one thing in that list stands out, TPH.
>
> We don't yet support enabling TPH, but there are series on the list
> that propose to add this. The TPH buffer space in the saved state is
> allocated just by the capability being present. On open TPH is
> disabled and the saved state is untouched, zeros. If TPH is then
> enabled and the device reset, the pre-reset save state populates the
> TPH save buffer and we restore that state post-reset. With the change
> here, reset_done would then push the open saved state. The live TPH
> state is enabled, therefore the restore pushes the original open state,
> zeros.
>
> This would result in a visible user change and maybe more importantly
> shows that we're relying on ad-hoc behavior, without really any specific
> policy to have this work reliably. It actually seems like only in the
> close function, where we've disabled anything the user might have
> enabled, is it really valid to restore the original state. Thanks,
>
> Alex
I was trying to see if we can remove the callback and still restore the
device. The original reason why we wanted the callback, was to restore
the device state into something sane[1]. Since commit a2f1e22390ac
("PCI/ERR: Ensure error recoverability at all times"), which removed the
saved_state check from pci_restore_state(), we will always restore from
the last saved state. However, the last saved state in vfio can have the
Command register Memory bit disabled (for example could be done through
vfio_pci_pre_reset() in QEMU). This becomes problematic when we try to
restore MSI-X from in kernel data and when MSI-X is enabled. AFAICT the
msix restore path doesn't check if the Memory bit is enabled before
writing the MSI-X message, which could cause an Unsupported Request
error from the device. From my experiments, enabling Memory bit before
restoring MSI-X state was sufficient to get the device in a sane state
without this patch.
So we could remove this patch. But maybe there is a gap in MSI-X
restoration path?
[1]
https://lore.kernel.org/all/20250814145743.204ca19a.alex.williamson@redhat.com/
Thanks
Farhan
^ permalink raw reply
* Re: [PATCH v5 0/6] s390: Enable Rust support and add required arch glue
From: Jan Polensky @ 2026-06-08 18:48 UTC (permalink / raw)
To: Gary Guo, Alexander Gordeev, Heiko Carstens
Cc: gor, ojeda, peterz, jpoimboe, jbaron, aliceryhl, borntraeger,
svens, boqun, bjorn3_gh, lossin, a.hindborg, tmgross, dakr,
rostedt, ardb, linux-s390, rust-for-linux, linux-kernel
In-Reply-To: <DJ3SBEPW21J5.2GMLCYBAKF7PW@garyguo.net>
On Mon, Jun 08, 2026 at 04:48:45PM +0100, Gary Guo wrote:
> On Mon Jun 8, 2026 at 3:36 PM BST, Alexander Gordeev wrote:
> > On Mon, Jun 08, 2026 at 04:21:22PM +0200, Heiko Carstens wrote:
> >> I guess Alexander will pick this up and route this via s390.
> >
> > Yes, I applied and scheduled it for -rc7.
> >
> > Two new files fall under the Rust maintainers scope:
> >
> > rust/helpers/helpers.c | 1 +
> > rust/helpers/string.c | 8 ++++++++
> >
> > Please, let me know if someone is against it.
> > Otherwise, an ack would be ideal ;)
>
> Thes string.c is missing __rust_helper and it is also missing a trailing
> newline.
>
> Sashiko's report is accurate here:
> https://sashiko.dev/#/patchset/20260601174625.2910233-1-japo%40linux.ibm.com?part=4
>
> Best,
> Gary
>
> >
> > Thanks!
>
>
Hi Gary,
thanks for pointing this out.
I've added the missing __rust_helper. Regarding the trailing newline,
the file already ends with one locally:
$ tail -c2 rust/helpers/string.c | hexdump -C
00000000 7d 0a |}.|
The other helpers are also mixed in this regard, so I kept it consistent.
If you prefer, I can send a v7 adjusting this as well.
Best regards,
Jan
^ permalink raw reply
* Re: [PATCH 2/3] vmsplice: make vmsplice a trivial wrapper for preadv2/pwritev2
From: David Hildenbrand (Arm) @ 2026-06-08 18:42 UTC (permalink / raw)
To: Alexander Gordeev, Askar Safin
Cc: linux-fsdevel, Christian Brauner, Alexander Viro, Jan Kara,
linux-kernel, linux-mm, linux-api, netdev, Linus Torvalds,
Matthew Wilcox, Jens Axboe, Christoph Hellwig, David Howells,
Andrew Morton, Pedro Falcato, Miklos Szeredi, patches, linux-s390,
linux-next
In-Reply-To: <20260608171917.3195488Afc-agordeev@linux.ibm.com>
On 6/8/26 19:19, Alexander Gordeev wrote:
> On Sun, May 31, 2026 at 01:01:06AM +0000, Askar Safin wrote:
>> vmsplice behavior on writable pipe became equivalent to pwritev2.
>> vmsplice behavior on readable pipe already was nearly
>> equivalent to preadv2, but I made this explicit. I. e. I made it
>> obvious from code that vmsplice now is equivalent to preadv2/pwritev2.
>>
>> Also I moved vmsplice to fs/read_write.c, because now it arguably
>> belongs there.
>>
>> Note that SPLICE_F_NONBLOCK behavior slightly changed: previously
>> vmsplice ignored whether the pipe was opened with O_NONBLOCK, and mode
>> of operation depended on whether SPLICE_F_NONBLOCK was passed only.
>> Now the operation will be non-blocking if O_NONBLOCK was passed when
>> opening *or* SPLICE_F_NONBLOCK was passed to vmsplice. Previous
>> behavior was arguably buggy, and new behavior is arguably better.
>>
>> Now SPLICE_F_GIFT is always ignored by all 3 syscalls: splice, tee
>> and vmsplice.
>>
>> Signed-off-by: Askar Safin <safinaskar@gmail.com>
>> ---
>> fs/read_write.c | 23 +++++
>> fs/splice.c | 192 +--------------------------------------
>> include/linux/skbuff.h | 4 +-
>> include/linux/splice.h | 2 +-
>> include/linux/syscalls.h | 4 +-
>> 5 files changed, 29 insertions(+), 196 deletions(-)
>
> Hi All,
>
> This patch as commit e2c0b2368081b ("vmsplice: make vmsplice a trivial
> wrapper for preadv2/pwritev2") in linux-next on s390 causes the selftest
> tools/testing/selftests/mm/cow.c to hang:
>
> # [RUN] vmsplice() + unmap in child ... with PTE-mapped THP (128 kB)
>
> Recently there has been changes in THP area, so the problem is not
> necessary linked to this patch per se.
If we reach 128 kB, then 64 kB likely worked. Which might hint at a similar problem
as found by the vmsplice01 ltp test case (blocking instead of returning once the
pipe is full).
https://lore.kernel.org/r/20260603-raumfahrt-unmerklich-ertrugen-c4ecae70d5f9@brauner
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v6 6/6] s390: Enable Rust support
From: Gary Guo @ 2026-06-08 18:25 UTC (permalink / raw)
To: Jan Polensky, hca, gor, agordeev, ojeda, peterz, jpoimboe, jbaron,
aliceryhl
Cc: borntraeger, svens, boqun, gary, bjorn3_gh, lossin, a.hindborg,
tmgross, dakr, rostedt, ardb, linux-s390, rust-for-linux,
linux-kernel
In-Reply-To: <20260608181451.3734956-7-japo@linux.ibm.com>
On Mon Jun 8, 2026 at 7:14 PM BST, Jan Polensky wrote:
> Enable building Rust code on s390 by wiring the architecture into the
> kernel Rust infrastructure.
>
> Add s390 to the Rust arch support documentation, provide the s390 Rust
> target and required compiler flags, and set the bindgen target for
> arch/s390. Adjust the Rust target generation and minimum rustc version
> gating so the s390 setup is handled explicitly.
>
> The Rust toolchain uses the "s390x" triple naming for the 64 bit target.
>
> Rust support is currently incompatible with CONFIG_EXPOLINE, which
> relies on compiler support for the -mindirect-branch= and
> -mfunction_return= options. Therefore, select HAVE_RUST only when
> EXPOLINE is disabled.
Does `-Zretpoline-external-thunk`/`-Zretpoline` not work for s390? Rust will
throw a warning saying that it doesn't recognize this for the target, but it
looks like it does generate target features
+retpoline-external-thunk,+retpoline-indirect-branches,+retpoline-indirect-calls
in LLVM IR.
Best,
Gary
>
> Acked-by: Miguel Ojeda <ojeda@kernel.org>
> Acked-by: Heiko Carstens <hca@linux.ibm.com>
> Signed-off-by: Jan Polensky <japo@linux.ibm.com>
> ---
> Documentation/rust/arch-support.rst | 1 +
> arch/s390/Kconfig | 1 +
> arch/s390/Makefile | 28 +++++++++++++++++-----------
> rust/Makefile | 1 +
> scripts/generate_rust_target.rs | 2 ++
> scripts/min-tool-version.sh | 6 +++++-
> 6 files changed, 27 insertions(+), 12 deletions(-)
>
> diff --git a/Documentation/rust/arch-support.rst b/Documentation/rust/arch-support.rst
> index 6e6a515d0899..4f980815e92a 100644
> --- a/Documentation/rust/arch-support.rst
> +++ b/Documentation/rust/arch-support.rst
> @@ -19,6 +19,7 @@ Architecture Level of support Constraints
> ``arm64`` Maintained Little Endian only.
> ``loongarch`` Maintained \-
> ``riscv`` Maintained ``riscv64`` and LLVM/Clang only.
> +``s390`` Maintained ``CONFIG_EXPOLINE`` must be disabled.
> ``um`` Maintained \-
> ``x86`` Maintained ``x86_64`` only.
> ============= ================ ==============================================
> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> index ecbcbb781e40..26951781d74d 100644
> --- a/arch/s390/Kconfig
> +++ b/arch/s390/Kconfig
> @@ -248,6 +248,7 @@ config S390
> select HAVE_RELIABLE_STACKTRACE
> select HAVE_RETHOOK
> select HAVE_RSEQ
> + select HAVE_RUST if !EXPOLINE
> select HAVE_SAMPLE_FTRACE_DIRECT
> select HAVE_SAMPLE_FTRACE_DIRECT_MULTI
> select HAVE_SETUP_PER_CPU_AREA
> diff --git a/arch/s390/Makefile b/arch/s390/Makefile
> index 297976b41088..8b712cd85fcd 100644
> --- a/arch/s390/Makefile
> +++ b/arch/s390/Makefile
> @@ -35,25 +35,31 @@ KBUILD_CFLAGS_DECOMPRESSOR += $(if $(CONFIG_DEBUG_INFO),-g)
> KBUILD_CFLAGS_DECOMPRESSOR += $(if $(CONFIG_DEBUG_INFO_DWARF4), $(call cc-option, -gdwarf-4,))
> KBUILD_CFLAGS_DECOMPRESSOR += $(if $(CONFIG_CC_NO_ARRAY_BOUNDS),-Wno-array-bounds)
>
> +KBUILD_RUSTFLAGS += --target=s390x-unknown-none-softfloat -Zpacked-stack -Ctarget-feature=+backchain
> +
> UTS_MACHINE := s390x
> STACK_SIZE := $(if $(CONFIG_KASAN),65536,$(if $(CONFIG_KMSAN),65536,16384))
> CHECKFLAGS += -D__s390__ -D__s390x__
>
> export LD_BFD
>
> -mflags-$(CONFIG_MARCH_Z10) := -march=z10
> -mflags-$(CONFIG_MARCH_Z196) := -march=z196
> -mflags-$(CONFIG_MARCH_ZEC12) := -march=zEC12
> -mflags-$(CONFIG_MARCH_Z13) := -march=z13
> -mflags-$(CONFIG_MARCH_Z14) := -march=z14
> -mflags-$(CONFIG_MARCH_Z15) := -march=z15
> -mflags-$(CONFIG_MARCH_Z16) := -march=z16
> -mflags-$(CONFIG_MARCH_Z17) := -march=z17
> +march-name-$(CONFIG_MARCH_Z10) := z10
> +march-name-$(CONFIG_MARCH_Z196) := z196
> +march-name-$(CONFIG_MARCH_ZEC12) := zEC12
> +march-name-$(CONFIG_MARCH_Z13) := z13
> +march-name-$(CONFIG_MARCH_Z14) := z14
> +march-name-$(CONFIG_MARCH_Z15) := z15
> +march-name-$(CONFIG_MARCH_Z16) := z16
> +march-name-$(CONFIG_MARCH_Z17) := z17
>
> -export CC_FLAGS_MARCH := $(mflags-y)
> +mflags := -march=$(march-name-y)
>
> -aflags-y += $(mflags-y)
> -cflags-y += $(mflags-y)
> +export CC_FLAGS_MARCH := $(mflags)
> +
> +aflags-y += $(mflags)
> +cflags-y += $(mflags)
> +
> +KBUILD_RUSTFLAGS += -Ctarget-cpu=$(march-name-y)
>
> cflags-$(CONFIG_MARCH_Z10_TUNE) += -mtune=z10
> cflags-$(CONFIG_MARCH_Z196_TUNE) += -mtune=z196
> diff --git a/rust/Makefile b/rust/Makefile
> index b9e9f512cec3..77460502f576 100644
> --- a/rust/Makefile
> +++ b/rust/Makefile
> @@ -403,6 +403,7 @@ BINDGEN_TARGET_x86 := x86_64-linux-gnu
> BINDGEN_TARGET_arm64 := aarch64-linux-gnu
> BINDGEN_TARGET_arm := arm-linux-gnueabi
> BINDGEN_TARGET_loongarch := loongarch64-linux-gnusf
> +BINDGEN_TARGET_s390 := s390x-linux-gnu
> # This is only for i386 UM builds, which need the 32-bit target not -m32
> BINDGEN_TARGET_i386 := i386-linux-gnu
> BINDGEN_TARGET_um := $(BINDGEN_TARGET_$(SUBARCH))
> diff --git a/scripts/generate_rust_target.rs b/scripts/generate_rust_target.rs
> index 16f7e855e012..3bf296581a88 100644
> --- a/scripts/generate_rust_target.rs
> +++ b/scripts/generate_rust_target.rs
> @@ -260,6 +260,8 @@ fn main() {
> }
> } else if cfg.has("LOONGARCH") {
> panic!("loongarch uses the builtin rustc loongarch64-unknown-none-softfloat target");
> + } else if cfg.has("S390") {
> + panic!("s390 uses the builtin rustc s390x-unknown-none-softfloat target");
> } else {
> panic!("Unsupported architecture");
> }
> diff --git a/scripts/min-tool-version.sh b/scripts/min-tool-version.sh
> index b96ec2d379b6..296acf8f71aa 100755
> --- a/scripts/min-tool-version.sh
> +++ b/scripts/min-tool-version.sh
> @@ -31,7 +31,11 @@ llvm)
> fi
> ;;
> rustc)
> - echo 1.85.0
> + if [ "$SRCARCH" = "s390" ]; then
> + echo 1.96.0
> + else
> + echo 1.85.0
> + fi
> ;;
> bindgen)
> echo 0.71.1
^ permalink raw reply
* [PATCH v6 5/6] s390/cmpxchg: Fix KASAN stack-out-of-bounds in atomic helpers
From: Jan Polensky @ 2026-06-08 18:14 UTC (permalink / raw)
To: hca, gor, agordeev, ojeda, peterz, jpoimboe, jbaron, aliceryhl
Cc: borntraeger, svens, boqun, gary, bjorn3_gh, lossin, a.hindborg,
tmgross, dakr, rostedt, ardb, linux-s390, rust-for-linux,
linux-kernel, Jan Polensky
In-Reply-To: <20260608181451.3734956-1-japo@linux.ibm.com>
The __arch_cmpxchg1, __arch_cmpxchg2, __arch_xchg1, and __arch_xchg2
functions emulate 1-byte and 2-byte atomic operations using 4-byte
cmpxchg instructions, since s390 lacks native 1/2-byte cmpxchg support.
When KASAN is enabled, the READ_ONCE() operations in these functions
trigger stack-out-of-bounds warnings because they perform 4-byte reads
when only 1 or 2 bytes should be accessed.
Mark these functions as __no_sanitize_or_inline to prevent KASAN
instrumentation while maintaining correct functionality.
This resolves the following KASAN error during rust_atomics KUnit tests:
BUG: KASAN: stack-out-of-bounds in rust_helper_atomic_i8_xchg+0xb2/0xc0
Read of size 4 at addr 001bff7ffdbefcf0 by task kunit_try_catch/142
Reported-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Link: https://lore.kernel.org/rust-for-linux/CANiq72m4GVWFYqnxNtCHTPu7XcGewHB5LNwOoayTfnXs9pPbNg@mail.gmail.com/
Suggested-by: Gary Guo <gary@garyguo.net>
Link: https://lore.kernel.org/rust-for-linux/DITFTAVVHTNQ.380OHUHGTOI6M@garyguo.net/
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Jan Polensky <japo@linux.ibm.com>
---
arch/s390/include/asm/cmpxchg.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/s390/include/asm/cmpxchg.h b/arch/s390/include/asm/cmpxchg.h
index 008357996262..e6ac55cf3c17 100644
--- a/arch/s390/include/asm/cmpxchg.h
+++ b/arch/s390/include/asm/cmpxchg.h
@@ -35,7 +35,7 @@ static __always_inline u64 __csg_asm(u64 ptr, u64 old, u64 new)
return old;
}
-static inline u8 __arch_cmpxchg1(u64 ptr, u8 old, u8 new)
+static __no_sanitize_or_inline u8 __arch_cmpxchg1(u64 ptr, u8 old, u8 new)
{
union {
u8 b[4];
@@ -58,7 +58,7 @@ static inline u8 __arch_cmpxchg1(u64 ptr, u8 old, u8 new)
return old;
}
-static inline u16 __arch_cmpxchg2(u64 ptr, u16 old, u16 new)
+static __no_sanitize_or_inline u16 __arch_cmpxchg2(u64 ptr, u16 old, u16 new)
{
union {
u16 b[2];
@@ -173,7 +173,7 @@ static __always_inline u64 __arch_cmpxchg(u64 ptr, u64 old, u64 new, int size)
void __xchg_called_with_bad_pointer(void);
-static inline u8 __arch_xchg1(u64 ptr, u8 x)
+static __no_sanitize_or_inline u8 __arch_xchg1(u64 ptr, u8 x)
{
int shift = (3 ^ (ptr & 3)) << 3;
u32 mask, old, new;
@@ -188,7 +188,7 @@ static inline u8 __arch_xchg1(u64 ptr, u8 x)
return old >> shift;
}
-static inline u16 __arch_xchg2(u64 ptr, u16 x)
+static __no_sanitize_or_inline u16 __arch_xchg2(u64 ptr, u16 x)
{
int shift = (2 ^ (ptr & 2)) << 3;
u32 mask, old, new;
--
2.53.0
^ permalink raw reply related
* [PATCH v6 1/6] s390/bug: Provide ARCH_WARN_ASM for Rust WARN/BUG support
From: Jan Polensky @ 2026-06-08 18:14 UTC (permalink / raw)
To: hca, gor, agordeev, ojeda, peterz, jpoimboe, jbaron, aliceryhl
Cc: borntraeger, svens, boqun, gary, bjorn3_gh, lossin, a.hindborg,
tmgross, dakr, rostedt, ardb, linux-s390, rust-for-linux,
linux-kernel, Jan Polensky
In-Reply-To: <20260608181451.3734956-1-japo@linux.ibm.com>
Rust WARN and BUG support relies on ARCH_WARN_ASM to emit __bug_table
entries. On s390 the macro is missing, so Rust code cannot generate
proper WARN/BUG metadata for the kernel's bug reporting infrastructure.
Define ARCH_WARN_ASM to produce the same assembly sequence and
__bug_table entry format as the existing s390 BUG handling, including
the monitor call. Define ARCH_WARN_REACHABLE as empty since s390 does
not provide reachability analysis for warning paths.
Acked-by: Gary Guo <gary@garyguo.net>
Acked-by: Miguel Ojeda <ojeda@kernel.org>
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Jan Polensky <japo@linux.ibm.com>
---
arch/s390/include/asm/bug.h | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/s390/include/asm/bug.h b/arch/s390/include/asm/bug.h
index 50a270edb020..2010342c97b1 100644
--- a/arch/s390/include/asm/bug.h
+++ b/arch/s390/include/asm/bug.h
@@ -4,6 +4,7 @@
#include <linux/compiler.h>
#include <linux/const.h>
+#include <linux/stringify.h>
#define MONCODE_BUG _AC(0, U)
#define MONCODE_BUG_ARG _AC(1, U)
@@ -121,6 +122,17 @@ do { \
#define HAVE_ARCH_BUG_FORMAT
#define HAVE_ARCH_BUG_FORMAT_ARGS
+#define ARCH_WARN_ASM(file, line, flags, size) \
+ ".section .rodata.str,\"aMS\",@progbits,1\n" \
+ "9:\n" \
+ ".asciz \"\"\n" /* Empty string for compatibility */ \
+ ".previous\n" \
+ "0:\n" \
+ __stringify(mc 0(%r0),0) "\n" \
+ __BUG_ENTRY("9b", file, line, flags, size)
+
+#define ARCH_WARN_REACHABLE
+
#endif /* CONFIG_BUG && CONFIG_CC_HAS_ASM_IMMEDIATE_STRINGS */
#endif /* __ASSEMBLER__ */
--
2.53.0
^ permalink raw reply related
* [PATCH v6 0/6] s390: Enable Rust support and add required arch glue
From: Jan Polensky @ 2026-06-08 18:14 UTC (permalink / raw)
To: hca, gor, agordeev, ojeda, peterz, jpoimboe, jbaron, aliceryhl
Cc: borntraeger, svens, boqun, gary, bjorn3_gh, lossin, a.hindborg,
tmgross, dakr, rostedt, ardb, linux-s390, rust-for-linux,
linux-kernel, Jan Polensky
Rust support on s390 requires a small set of architecture-specific pieces
before the generic Rust kernel infrastructure can be used.
The series wires up s390 as a Rust-capable 64-bit architecture, adds the
missing assembly interfaces needed by Rust for WARN/BUG reporting and for
static branches, adjusts bindgen parameters to avoid repr layout conflicts
caused by packed and aligned s390 structures, and fixes issues discovered
during testing.
s390 currently requires rustc with support for -Zpacked-stack, and the
minimum tool version gating is adjusted accordingly.
Link: https://github.com/Rust-for-Linux/linux/issues/2
Tested against: rustc 1.96.0 (ac68faa20 2026-05-25)
Changes since v5:
- Fix indent in bug.h
- Add __rust_helper to rust_helper_memchr() (thanks Gary)
Changes since v4:
- Patch 4/6: Use kernel's memchr() instead of __builtin_memchr (Sashiko AI)
Changes since v3:
- Added patch 4/6: Add memchr wrapper preserving KASAN/FORTIFY_SOURCE (reported by Sashiko AI)
- Added patch 5/6: Fix KASAN stack-out-of-bounds in atomic helpers (reported by Miguel, suggested by Gary)
- Patch 6/6: Document CONFIG_EXPOLINE constraint in arch-support.rst (Sashiko AI feedback)
- Patch 6/6: Added Acked-by from Miguel Ojeda
Changes since v2:
- mflags: cleanup (thanks Gary)
Changes since v1:
- strip the -nightly suffix in min-tool-version.sh (thanks Miguel and Alice)
- ARCH_JUMP_TABLE_ENTRY() moved up to align comments properly (thanks Gary)
- removed MONCODE_BUG to prevent 0U in non-C context in assembler (noted by Sashiko - AI)
- prevent environment pollution by explicit initialization mflag := (noted by Sashiko - AI)
Jan Polensky (6):
s390/bug: Provide ARCH_WARN_ASM for Rust WARN/BUG support
s390/jump_label: Implement ARCH_STATIC_BRANCH_JUMP_ASM and
ARCH_STATIC_BRANCH_ASM macros
rust/bindgen_parameters: Mark s390 types as opaque to prevent repr
conflicts
rust: helpers: Add memchr wrapper for string operations
s390/cmpxchg: Fix KASAN stack-out-of-bounds in atomic helpers
s390: Enable Rust support
Documentation/rust/arch-support.rst | 1 +
arch/s390/Kconfig | 1 +
arch/s390/Makefile | 28 ++++++++++++++----------
arch/s390/include/asm/bug.h | 12 +++++++++++
arch/s390/include/asm/cmpxchg.h | 8 +++----
arch/s390/include/asm/jump_label.h | 33 +++++++++++++++++------------
rust/Makefile | 1 +
rust/bindgen_parameters | 7 ++++++
rust/helpers/helpers.c | 1 +
rust/helpers/string.c | 8 +++++++
scripts/generate_rust_target.rs | 2 ++
scripts/min-tool-version.sh | 6 +++++-
12 files changed, 78 insertions(+), 30 deletions(-)
create mode 100644 rust/helpers/string.c
base-commit: 2d3090a8aeb596a26935db0955d46c9a5db5c6ce
--
2.53.0
^ permalink raw reply
* [PATCH v6 3/6] rust/bindgen_parameters: Mark s390 types as opaque to prevent repr conflicts
From: Jan Polensky @ 2026-06-08 18:14 UTC (permalink / raw)
To: hca, gor, agordeev, ojeda, peterz, jpoimboe, jbaron, aliceryhl
Cc: borntraeger, svens, boqun, gary, bjorn3_gh, lossin, a.hindborg,
tmgross, dakr, rostedt, ardb, linux-s390, rust-for-linux,
linux-kernel, Jan Polensky
In-Reply-To: <20260608181451.3734956-1-japo@linux.ibm.com>
Bindgen attempts to generate Rust layouts for a number of s390 structs
that are packed but contain, or transitively contain, aligned fields.
Rust rejects such layouts with E0588 ("packed type cannot transitively
contain a #[repr(align)] type").
Add the affected s390 types to the opaque type list so bindgen emits
opaque blob types instead of full representations. This matches existing
workarounds for x86 types such as alt_instr and x86_msi_data.
Link: https://lore.kernel.org/all/e5c7aa10-590d-0d20-dd3b-385bee2377e7@intel.com/
Acked-by: Miguel Ojeda <ojeda@kernel.org>
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Jan Polensky <japo@linux.ibm.com>
---
rust/bindgen_parameters | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/rust/bindgen_parameters b/rust/bindgen_parameters
index 6f02d9720ad2..8402b0c93545 100644
--- a/rust/bindgen_parameters
+++ b/rust/bindgen_parameters
@@ -14,6 +14,13 @@
--opaque-type alt_instr
--opaque-type x86_msi_data
--opaque-type x86_msi_addr_lo
+# s390-only: same packed/align issue as above (E0588).
+--opaque-type lowcore
+--opaque-type tod_clock
+--opaque-type tpi_info
+--opaque-type uv_cb.*
+--opaque-type uv_secret.*
+--opaque-type zpci_fib
# If SMP is disabled, `arch_spinlock_t` is defined as a ZST which triggers a Rust
# warning. We don't need to peek into it anyway.
--
2.53.0
^ permalink raw reply related
* [PATCH v6 4/6] rust: helpers: Add memchr wrapper for string operations
From: Jan Polensky @ 2026-06-08 18:14 UTC (permalink / raw)
To: hca, gor, agordeev, ojeda, peterz, jpoimboe, jbaron, aliceryhl
Cc: borntraeger, svens, boqun, gary, bjorn3_gh, lossin, a.hindborg,
tmgross, dakr, rostedt, ardb, linux-s390, rust-for-linux,
linux-kernel, Jan Polensky
In-Reply-To: <20260608181451.3734956-1-japo@linux.ibm.com>
Add a dedicated string helper file with a memchr wrapper that uses the
kernel's instrumented memchr() function to ensure KASAN and FORTIFY_SOURCE
protections are preserved for Rust code.
Reported-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Link: https://lore.kernel.org/rust-for-linux/CANiq72mXAZc0sNM7ShX8VDVs_7zJddawP-e=wt+ERr1YUCcWUw@mail.gmail.com/
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Jan Polensky <japo@linux.ibm.com>
---
rust/helpers/helpers.c | 1 +
rust/helpers/string.c | 8 ++++++++
2 files changed, 9 insertions(+)
create mode 100644 rust/helpers/string.c
diff --git a/rust/helpers/helpers.c b/rust/helpers/helpers.c
index 625921e27dfb..592b9bdb4e4a 100644
--- a/rust/helpers/helpers.c
+++ b/rust/helpers/helpers.c
@@ -88,6 +88,7 @@
#include "signal.c"
#include "slab.c"
#include "spinlock.c"
+#include "string.c"
#include "sync.c"
#include "task.c"
#include "time.c"
diff --git a/rust/helpers/string.c b/rust/helpers/string.c
new file mode 100644
index 000000000000..8ef30eb07a15
--- /dev/null
+++ b/rust/helpers/string.c
@@ -0,0 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include <linux/string.h>
+
+__rust_helper void *rust_helper_memchr(const void *s, int c, size_t n)
+{
+ return memchr(s, c, n);
+}
--
2.53.0
^ permalink raw reply related
* [PATCH v6 2/6] s390/jump_label: Implement ARCH_STATIC_BRANCH_JUMP_ASM and ARCH_STATIC_BRANCH_ASM macros
From: Jan Polensky @ 2026-06-08 18:14 UTC (permalink / raw)
To: hca, gor, agordeev, ojeda, peterz, jpoimboe, jbaron, aliceryhl
Cc: borntraeger, svens, boqun, gary, bjorn3_gh, lossin, a.hindborg,
tmgross, dakr, rostedt, ardb, linux-s390, rust-for-linux,
linux-kernel, Jan Polensky
In-Reply-To: <20260608181451.3734956-1-japo@linux.ibm.com>
Rust static branch support needs the s390 jump label instruction sequence
and __jump_table emission in a reusable form. The current implementation
embeds the sequence directly in the C asm goto blocks, which cannot be
shared with Rust.
Introduce ARCH_STATIC_BRANCH_ASM and ARCH_STATIC_BRANCH_JUMP_ASM to
describe the brcl sequences for the likely-false and likely-true cases
and to emit the same __jump_table entries as before. Switch the existing
C helpers to use the new macros to avoid duplication without changing
the generated code.
Acked-by: Gary Guo <gary@garyguo.net>
Acked-by: Miguel Ojeda <ojeda@kernel.org>
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Jan Polensky <japo@linux.ibm.com>
---
arch/s390/include/asm/jump_label.h | 33 +++++++++++++++++-------------
1 file changed, 19 insertions(+), 14 deletions(-)
diff --git a/arch/s390/include/asm/jump_label.h b/arch/s390/include/asm/jump_label.h
index d9cbc18f6b2e..0e28c90dc242 100644
--- a/arch/s390/include/asm/jump_label.h
+++ b/arch/s390/include/asm/jump_label.h
@@ -19,19 +19,29 @@
#define JUMP_LABEL_STATIC_KEY_CONSTRAINT "jdd"
#endif
+#define ARCH_JUMP_TABLE_ENTRY(key, label, local_label) \
+ ".pushsection __jump_table,\"aw\"\n" \
+ ".balign 8\n" \
+ ".long " local_label "-.," label "-.\n" \
+ ".quad " key "-.\n" \
+ ".popsection\n"
+
/*
* We use a brcl 0,<offset> instruction for jump labels so it
* can be easily distinguished from a hotpatch generated instruction.
*/
+#define ARCH_STATIC_BRANCH_ASM(key, label) \
+ "0: brcl 0," label "\n" \
+ ARCH_JUMP_TABLE_ENTRY(key, label, "0b")
+
+#define ARCH_STATIC_BRANCH_JUMP_ASM(key, label) \
+ "0: brcl 15," label "\n" \
+ ARCH_JUMP_TABLE_ENTRY(key, label, "0b")
+
static __always_inline bool arch_static_branch(struct static_key *key, bool branch)
{
- asm goto("0: brcl 0,%l[label]\n"
- ".pushsection __jump_table,\"aw\"\n"
- ".balign 8\n"
- ".long 0b-.,%l[label]-.\n"
- ".quad %0+%1-.\n"
- ".popsection\n"
- : : JUMP_LABEL_STATIC_KEY_CONSTRAINT (key), "i" (branch) : : label);
+ asm goto(ARCH_STATIC_BRANCH_ASM("%0+%1", "%l[label]")
+ : : JUMP_LABEL_STATIC_KEY_CONSTRAINT (key), "i" (branch) : : label);
return false;
label:
return true;
@@ -39,13 +49,8 @@ static __always_inline bool arch_static_branch(struct static_key *key, bool bran
static __always_inline bool arch_static_branch_jump(struct static_key *key, bool branch)
{
- asm goto("0: brcl 15,%l[label]\n"
- ".pushsection __jump_table,\"aw\"\n"
- ".balign 8\n"
- ".long 0b-.,%l[label]-.\n"
- ".quad %0+%1-.\n"
- ".popsection\n"
- : : JUMP_LABEL_STATIC_KEY_CONSTRAINT (key), "i" (branch) : : label);
+ asm goto(ARCH_STATIC_BRANCH_JUMP_ASM("%0+%1", "%l[label]")
+ : : JUMP_LABEL_STATIC_KEY_CONSTRAINT (key), "i" (branch) : : label);
return false;
label:
return true;
--
2.53.0
^ permalink raw reply related
* [PATCH v6 6/6] s390: Enable Rust support
From: Jan Polensky @ 2026-06-08 18:14 UTC (permalink / raw)
To: hca, gor, agordeev, ojeda, peterz, jpoimboe, jbaron, aliceryhl
Cc: borntraeger, svens, boqun, gary, bjorn3_gh, lossin, a.hindborg,
tmgross, dakr, rostedt, ardb, linux-s390, rust-for-linux,
linux-kernel, Jan Polensky
In-Reply-To: <20260608181451.3734956-1-japo@linux.ibm.com>
Enable building Rust code on s390 by wiring the architecture into the
kernel Rust infrastructure.
Add s390 to the Rust arch support documentation, provide the s390 Rust
target and required compiler flags, and set the bindgen target for
arch/s390. Adjust the Rust target generation and minimum rustc version
gating so the s390 setup is handled explicitly.
The Rust toolchain uses the "s390x" triple naming for the 64 bit target.
Rust support is currently incompatible with CONFIG_EXPOLINE, which
relies on compiler support for the -mindirect-branch= and
-mfunction_return= options. Therefore, select HAVE_RUST only when
EXPOLINE is disabled.
Acked-by: Miguel Ojeda <ojeda@kernel.org>
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Jan Polensky <japo@linux.ibm.com>
---
Documentation/rust/arch-support.rst | 1 +
arch/s390/Kconfig | 1 +
arch/s390/Makefile | 28 +++++++++++++++++-----------
rust/Makefile | 1 +
scripts/generate_rust_target.rs | 2 ++
scripts/min-tool-version.sh | 6 +++++-
6 files changed, 27 insertions(+), 12 deletions(-)
diff --git a/Documentation/rust/arch-support.rst b/Documentation/rust/arch-support.rst
index 6e6a515d0899..4f980815e92a 100644
--- a/Documentation/rust/arch-support.rst
+++ b/Documentation/rust/arch-support.rst
@@ -19,6 +19,7 @@ Architecture Level of support Constraints
``arm64`` Maintained Little Endian only.
``loongarch`` Maintained \-
``riscv`` Maintained ``riscv64`` and LLVM/Clang only.
+``s390`` Maintained ``CONFIG_EXPOLINE`` must be disabled.
``um`` Maintained \-
``x86`` Maintained ``x86_64`` only.
============= ================ ==============================================
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index ecbcbb781e40..26951781d74d 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -248,6 +248,7 @@ config S390
select HAVE_RELIABLE_STACKTRACE
select HAVE_RETHOOK
select HAVE_RSEQ
+ select HAVE_RUST if !EXPOLINE
select HAVE_SAMPLE_FTRACE_DIRECT
select HAVE_SAMPLE_FTRACE_DIRECT_MULTI
select HAVE_SETUP_PER_CPU_AREA
diff --git a/arch/s390/Makefile b/arch/s390/Makefile
index 297976b41088..8b712cd85fcd 100644
--- a/arch/s390/Makefile
+++ b/arch/s390/Makefile
@@ -35,25 +35,31 @@ KBUILD_CFLAGS_DECOMPRESSOR += $(if $(CONFIG_DEBUG_INFO),-g)
KBUILD_CFLAGS_DECOMPRESSOR += $(if $(CONFIG_DEBUG_INFO_DWARF4), $(call cc-option, -gdwarf-4,))
KBUILD_CFLAGS_DECOMPRESSOR += $(if $(CONFIG_CC_NO_ARRAY_BOUNDS),-Wno-array-bounds)
+KBUILD_RUSTFLAGS += --target=s390x-unknown-none-softfloat -Zpacked-stack -Ctarget-feature=+backchain
+
UTS_MACHINE := s390x
STACK_SIZE := $(if $(CONFIG_KASAN),65536,$(if $(CONFIG_KMSAN),65536,16384))
CHECKFLAGS += -D__s390__ -D__s390x__
export LD_BFD
-mflags-$(CONFIG_MARCH_Z10) := -march=z10
-mflags-$(CONFIG_MARCH_Z196) := -march=z196
-mflags-$(CONFIG_MARCH_ZEC12) := -march=zEC12
-mflags-$(CONFIG_MARCH_Z13) := -march=z13
-mflags-$(CONFIG_MARCH_Z14) := -march=z14
-mflags-$(CONFIG_MARCH_Z15) := -march=z15
-mflags-$(CONFIG_MARCH_Z16) := -march=z16
-mflags-$(CONFIG_MARCH_Z17) := -march=z17
+march-name-$(CONFIG_MARCH_Z10) := z10
+march-name-$(CONFIG_MARCH_Z196) := z196
+march-name-$(CONFIG_MARCH_ZEC12) := zEC12
+march-name-$(CONFIG_MARCH_Z13) := z13
+march-name-$(CONFIG_MARCH_Z14) := z14
+march-name-$(CONFIG_MARCH_Z15) := z15
+march-name-$(CONFIG_MARCH_Z16) := z16
+march-name-$(CONFIG_MARCH_Z17) := z17
-export CC_FLAGS_MARCH := $(mflags-y)
+mflags := -march=$(march-name-y)
-aflags-y += $(mflags-y)
-cflags-y += $(mflags-y)
+export CC_FLAGS_MARCH := $(mflags)
+
+aflags-y += $(mflags)
+cflags-y += $(mflags)
+
+KBUILD_RUSTFLAGS += -Ctarget-cpu=$(march-name-y)
cflags-$(CONFIG_MARCH_Z10_TUNE) += -mtune=z10
cflags-$(CONFIG_MARCH_Z196_TUNE) += -mtune=z196
diff --git a/rust/Makefile b/rust/Makefile
index b9e9f512cec3..77460502f576 100644
--- a/rust/Makefile
+++ b/rust/Makefile
@@ -403,6 +403,7 @@ BINDGEN_TARGET_x86 := x86_64-linux-gnu
BINDGEN_TARGET_arm64 := aarch64-linux-gnu
BINDGEN_TARGET_arm := arm-linux-gnueabi
BINDGEN_TARGET_loongarch := loongarch64-linux-gnusf
+BINDGEN_TARGET_s390 := s390x-linux-gnu
# This is only for i386 UM builds, which need the 32-bit target not -m32
BINDGEN_TARGET_i386 := i386-linux-gnu
BINDGEN_TARGET_um := $(BINDGEN_TARGET_$(SUBARCH))
diff --git a/scripts/generate_rust_target.rs b/scripts/generate_rust_target.rs
index 16f7e855e012..3bf296581a88 100644
--- a/scripts/generate_rust_target.rs
+++ b/scripts/generate_rust_target.rs
@@ -260,6 +260,8 @@ fn main() {
}
} else if cfg.has("LOONGARCH") {
panic!("loongarch uses the builtin rustc loongarch64-unknown-none-softfloat target");
+ } else if cfg.has("S390") {
+ panic!("s390 uses the builtin rustc s390x-unknown-none-softfloat target");
} else {
panic!("Unsupported architecture");
}
diff --git a/scripts/min-tool-version.sh b/scripts/min-tool-version.sh
index b96ec2d379b6..296acf8f71aa 100755
--- a/scripts/min-tool-version.sh
+++ b/scripts/min-tool-version.sh
@@ -31,7 +31,11 @@ llvm)
fi
;;
rustc)
- echo 1.85.0
+ if [ "$SRCARCH" = "s390" ]; then
+ echo 1.96.0
+ else
+ echo 1.85.0
+ fi
;;
bindgen)
echo 0.71.1
--
2.53.0
^ permalink raw reply related
* [PATCH v3 4/4] s390/pci: Fence FMB enable/disable via sysfs for passthrough devices
From: Omar Elghoul @ 2026-06-08 17:18 UTC (permalink / raw)
To: linux-s390, linux-kernel, kvm
Cc: oelghoul, hca, gor, agordeev, borntraeger, svens, schnelle,
mjrosato, alifm, farman, gbayer, alex
In-Reply-To: <20260608171850.62829-1-oelghoul@linux.ibm.com>
Introduce a fence over enabling or disabling FMB via sysfs when the zPCI
device is associated with a KVM. This will allow a KVM guest to use FMB
passthrough and avoid the edge-case where the host disables FMB while the
guest is still using it, which may cause partial counter resets and
inconsistent reads which have no parallel in the architecture.
With this patch, the userspace driver, likely QEMU, is still able to enable
or disable the FMB using the VFIO device feature introduced in the previous
patch, effectively securing what is associated with the VM state and
isolating it from other processes on the host.
For VFIO devices that are not associated with a KVM (i.e., for userspace
drivers other than QEMU), this fence does not take effect.
Signed-off-by: Omar Elghoul <oelghoul@linux.ibm.com>
Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com>
---
arch/s390/pci/pci_debug.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/s390/pci/pci_debug.c b/arch/s390/pci/pci_debug.c
index c7ed7bf254b5..a2dc79418c21 100644
--- a/arch/s390/pci/pci_debug.c
+++ b/arch/s390/pci/pci_debug.c
@@ -149,9 +149,15 @@ static ssize_t pci_perf_seq_write(struct file *file, const char __user *ubuf,
if (!zdev)
return 0;
+ mutex_lock(&zdev->kzdev_lock);
+ if (zdev->kzdev) {
+ rc = -EPERM;
+ goto out_unlock_kzdev;
+ }
+
rc = kstrtoul_from_user(ubuf, count, 10, &val);
if (rc)
- return rc;
+ goto out_unlock_kzdev;
mutex_lock(&zdev->fmb_lock);
switch (val) {
@@ -163,6 +169,9 @@ static ssize_t pci_perf_seq_write(struct file *file, const char __user *ubuf,
break;
}
mutex_unlock(&zdev->fmb_lock);
+
+out_unlock_kzdev:
+ mutex_unlock(&zdev->kzdev_lock);
return rc ? rc : count;
}
--
2.54.0
^ permalink raw reply related
* [PATCH v3 3/4] vfio-pci/zdev: Add VFIO FMB device features
From: Omar Elghoul @ 2026-06-08 17:18 UTC (permalink / raw)
To: linux-s390, linux-kernel, kvm
Cc: oelghoul, hca, gor, agordeev, borntraeger, svens, schnelle,
mjrosato, alifm, farman, gbayer, alex
In-Reply-To: <20260608171850.62829-1-oelghoul@linux.ibm.com>
Introduce new VFIO features for zPCI devices to provide FMB passthrough to
userspace.
Allow the user to enable or disable the FMB using the SET-only feature
VFIO_DEVICE_FEATURE_ZPCI_FMB_ENABLE. Likewise allow the user to read the
latest FMB using the GET-only feature VFIO_DEVICE_FEATURE_ZPCI_FMB_READ
in the case where the FMB is enabled.
Signed-off-by: Omar Elghoul <oelghoul@linux.ibm.com>
---
drivers/vfio/pci/vfio_pci_core.c | 4 +++
drivers/vfio/pci/vfio_pci_priv.h | 18 ++++++++++
drivers/vfio/pci/vfio_pci_zdev.c | 57 ++++++++++++++++++++++++++++++++
include/uapi/linux/vfio.h | 29 ++++++++++++++++
4 files changed, 108 insertions(+)
diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
index 050e7542952e..44e8e5526eae 100644
--- a/drivers/vfio/pci/vfio_pci_core.c
+++ b/drivers/vfio/pci/vfio_pci_core.c
@@ -1569,6 +1569,10 @@ int vfio_pci_core_ioctl_feature(struct vfio_device *device, u32 flags,
return vfio_pci_core_feature_token(vdev, flags, arg, argsz);
case VFIO_DEVICE_FEATURE_DMA_BUF:
return vfio_pci_core_feature_dma_buf(vdev, flags, arg, argsz);
+ case VFIO_DEVICE_FEATURE_ZPCI_FMB_ENABLE:
+ return vfio_pci_zdev_feature_fmb_enable(vdev, flags, arg, argsz);
+ case VFIO_DEVICE_FEATURE_ZPCI_FMB_READ:
+ return vfio_pci_zdev_feature_fmb_read(vdev, flags, arg, argsz);
default:
return -ENOTTY;
}
diff --git a/drivers/vfio/pci/vfio_pci_priv.h b/drivers/vfio/pci/vfio_pci_priv.h
index fca9d0dfac90..b7db064a6a95 100644
--- a/drivers/vfio/pci/vfio_pci_priv.h
+++ b/drivers/vfio/pci/vfio_pci_priv.h
@@ -93,6 +93,10 @@ int vfio_pci_info_zdev_add_caps(struct vfio_pci_core_device *vdev,
struct vfio_info_cap *caps);
int vfio_pci_zdev_open_device(struct vfio_pci_core_device *vdev);
void vfio_pci_zdev_close_device(struct vfio_pci_core_device *vdev);
+int vfio_pci_zdev_feature_fmb_enable(struct vfio_pci_core_device *vdev, u32 flags,
+ void __user *arg, size_t argsz);
+int vfio_pci_zdev_feature_fmb_read(struct vfio_pci_core_device *vdev, u32 flags,
+ void __user *arg, size_t argsz);
#else
static inline int vfio_pci_info_zdev_add_caps(struct vfio_pci_core_device *vdev,
struct vfio_info_cap *caps)
@@ -107,6 +111,20 @@ static inline int vfio_pci_zdev_open_device(struct vfio_pci_core_device *vdev)
static inline void vfio_pci_zdev_close_device(struct vfio_pci_core_device *vdev)
{}
+
+static inline int vfio_pci_zdev_feature_fmb_enable(struct vfio_pci_core_device *vdev,
+ u32 flags, void __user *arg,
+ size_t argsz)
+{
+ return -ENOTTY;
+}
+
+static inline int vfio_pci_zdev_feature_fmb_read(struct vfio_pci_core_device *vdev,
+ u32 flags, void __user *arg,
+ size_t argsz)
+{
+ return -ENOTTY;
+}
#endif
static inline bool vfio_pci_is_vga(struct pci_dev *pdev)
diff --git a/drivers/vfio/pci/vfio_pci_zdev.c b/drivers/vfio/pci/vfio_pci_zdev.c
index 0990fdb146b7..09454495ee23 100644
--- a/drivers/vfio/pci/vfio_pci_zdev.c
+++ b/drivers/vfio/pci/vfio_pci_zdev.c
@@ -167,3 +167,60 @@ void vfio_pci_zdev_close_device(struct vfio_pci_core_device *vdev)
if (zpci_kvm_hook.kvm_unregister)
zpci_kvm_hook.kvm_unregister(zdev);
}
+
+int vfio_pci_zdev_feature_fmb_enable(struct vfio_pci_core_device *vdev, u32 flags,
+ void __user *arg, size_t argsz)
+{
+ struct zpci_dev *zdev;
+ struct vfio_device_feature_zpci_fmb_enable fmb_enable;
+ int ret;
+
+ ret = vfio_check_feature(flags, argsz, VFIO_DEVICE_FEATURE_SET, sizeof(fmb_enable));
+ if (ret != 1)
+ return ret;
+
+ zdev = to_zpci(vdev->pdev);
+ if (!zdev)
+ return -ENODEV;
+
+ guard(mutex)(&zdev->fmb_lock);
+
+ if (copy_from_user(&fmb_enable, arg, sizeof(fmb_enable)))
+ return -EFAULT;
+
+ if (fmb_enable.enabled)
+ return zpci_fmb_reenable_device(zdev);
+ return zpci_fmb_disable_device(zdev);
+}
+
+int vfio_pci_zdev_feature_fmb_read(struct vfio_pci_core_device *vdev, u32 flags,
+ void __user *arg, size_t argsz)
+{
+ struct zpci_dev *zdev;
+ struct vfio_device_feature_zpci_fmb_read fmb_read;
+ struct zpci_fmb fmb_temp = {0};
+ int ret;
+
+ ret = vfio_check_feature(flags, argsz, VFIO_DEVICE_FEATURE_GET, sizeof(fmb_read));
+ if (ret != 1)
+ return ret;
+
+ zdev = to_zpci(vdev->pdev);
+ if (!zdev)
+ return -ENODEV;
+
+ guard(mutex)(&zdev->fmb_lock);
+
+ if (!zdev->fmb)
+ return -ENOMSG;
+ if (copy_from_user(&fmb_read, arg, sizeof(fmb_read)))
+ return -EFAULT;
+ if (!fmb_read.data)
+ return -EINVAL;
+
+ memcpy(&fmb_temp, zdev->fmb, zdev->fmb_length);
+ if (copy_to_user(fmb_read.data, &fmb_temp, zdev->fmb_length))
+ return -EFAULT;
+
+ return 0;
+}
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index 5de618a3a5ee..3988e8690e0b 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -1534,6 +1534,35 @@ struct vfio_device_feature_dma_buf {
*/
#define VFIO_DEVICE_FEATURE_MIG_PRECOPY_INFOv2 12
+/**
+ * Upon VFIO_DEVICE_FEATURE_SET, enable or disable FMB for the VFIO zPCI device.
+ *
+ * enabled is treated as a bool, so any non-zero value evaluates to true. This
+ * feature fails on attempt to double enable/disable.
+ *
+ * Returns: 0 on success, -1 and errno set appropriately on error.
+ */
+#define VFIO_DEVICE_FEATURE_ZPCI_FMB_ENABLE 13
+
+struct vfio_device_feature_zpci_fmb_enable {
+ __u8 enabled;
+};
+
+/**
+ * Upon VFIO_DEVICE_FEATURE_GET, provide FMB passthrough for VFIO zPCI devices.
+ *
+ * The user-provided buffer must be at least fmb_length large, where fmb_length
+ * is reported in VFIO_DEVICE_INFO_CAP_ZPCI_BASE.
+ *
+ * Returns: 0 on success, -1 and errno set appropriately on error. errno==ENOMSG
+ * when the FMB is not enabled.
+ */
+#define VFIO_DEVICE_FEATURE_ZPCI_FMB_READ 14
+
+struct vfio_device_feature_zpci_fmb_read {
+ void __user *data;
+};
+
/* -------- API for Type1 VFIO IOMMU -------- */
/**
--
2.54.0
^ permalink raw reply related
* [PATCH v3 2/4] s390/pci: Preserve FMB state in device re-enablement
From: Omar Elghoul @ 2026-06-08 17:18 UTC (permalink / raw)
To: linux-s390, linux-kernel, kvm
Cc: oelghoul, hca, gor, agordeev, borntraeger, svens, schnelle,
mjrosato, alifm, farman, gbayer, alex
In-Reply-To: <20260608171850.62829-1-oelghoul@linux.ibm.com>
Introduce a function zpci_fmb_reenable_device() that checks for the state
of the FMB and reuses the same buffer where appropriate. If the FMB was not
previously enabled, enable it for the device. Call this function during a
zPCI device re-enablement, which in turn implicitly ensures that the FMB is
is enabled for host devices during their KVM registration.
Besides re-enabling the FMB itself in zpci_fmb_reenable_device() also clear
out the software counters, such that a program resetting an FMB sees all
counters start from zero as expected. Separate this clearing of software
counters out into zpci_fmb_clear_iommu_ctrs() and reuse it in
zpci_fmb_enable_device() and zpci_fmb_reenable_device(). Likewise separate
the FMB enable logic into zpci_fmb_do_enable() to be reused in the same two
functions.
Signed-off-by: Omar Elghoul <oelghoul@linux.ibm.com>
---
arch/s390/include/asm/pci.h | 1 +
arch/s390/pci/pci.c | 96 +++++++++++++++++++++++++++++--------
2 files changed, 78 insertions(+), 19 deletions(-)
diff --git a/arch/s390/include/asm/pci.h b/arch/s390/include/asm/pci.h
index 5dcf35f0f325..65014e52d559 100644
--- a/arch/s390/include/asm/pci.h
+++ b/arch/s390/include/asm/pci.h
@@ -323,6 +323,7 @@ void zpci_remove_parent_msi_domain(struct zpci_bus *zbus);
/* FMB */
int zpci_fmb_enable_device(struct zpci_dev *);
int zpci_fmb_disable_device(struct zpci_dev *);
+int zpci_fmb_reenable_device(struct zpci_dev *zdev);
/* Debug */
int zpci_debug_init(void);
diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c
index 2910d4038d39..652f0b7e8893 100644
--- a/arch/s390/pci/pci.c
+++ b/arch/s390/pci/pci.c
@@ -164,24 +164,10 @@ int zpci_unregister_ioat(struct zpci_dev *zdev, u8 dmaas)
return cc;
}
-/* Modify PCI: Set PCI function measurement parameters */
-int zpci_fmb_enable_device(struct zpci_dev *zdev)
+static void zpci_fmb_clear_iommu_ctrs(struct zpci_dev *zdev)
{
- u64 req = ZPCI_CREATE_REQ(zdev->fh, 0, ZPCI_MOD_FC_SET_MEASURE);
struct zpci_iommu_ctrs *ctrs;
- struct zpci_fib fib = {0};
- unsigned long flags;
- u8 cc, status;
-
- lockdep_assert_held(&zdev->fmb_lock);
-
- if (zdev->fmb || sizeof(*zdev->fmb) < zdev->fmb_length)
- return -EINVAL;
-
- zdev->fmb = kmem_cache_zalloc(zdev_fmb_cache, GFP_KERNEL);
- if (!zdev->fmb)
- return -ENOMEM;
- WARN_ON((u64) zdev->fmb & 0xf);
+ unsigned long flags = 0;
/* reset software counters */
spin_lock_irqsave(&zdev->dom_lock, flags);
@@ -194,17 +180,49 @@ int zpci_fmb_enable_device(struct zpci_dev *zdev)
atomic64_set(&ctrs->sync_rpcits, 0);
}
spin_unlock_irqrestore(&zdev->dom_lock, flags);
+}
+static int zpci_fmb_do_enable(struct zpci_dev *zdev)
+{
+ /* This helper assumes that zdev->fmb is already allocated and thus only
+ * takes care of the actual enablement.
+ */
+ u64 req = ZPCI_CREATE_REQ(zdev->fh, 0, ZPCI_MOD_FC_SET_MEASURE);
+ struct zpci_fib fib = {0};
+ u8 cc, status;
fib.fmb_addr = virt_to_phys(zdev->fmb);
fib.gd = zdev->gisa;
cc = zpci_mod_fc(req, &fib, &status);
- if (cc) {
+
+ return cc ? -EIO : 0;
+}
+
+/* Modify PCI: Set PCI function measurement parameters */
+int zpci_fmb_enable_device(struct zpci_dev *zdev)
+{
+ int rc;
+
+ lockdep_assert_held(&zdev->fmb_lock);
+
+ if (zdev->fmb || sizeof(*zdev->fmb) < zdev->fmb_length)
+ return -EINVAL;
+
+ zdev->fmb = kmem_cache_zalloc(zdev_fmb_cache, GFP_KERNEL);
+ if (!zdev->fmb)
+ return -ENOMEM;
+ WARN_ON((u64) zdev->fmb & 0xf);
+
+ zpci_fmb_clear_iommu_ctrs(zdev);
+
+ rc = zpci_fmb_do_enable(zdev);
+ if (rc) {
kmem_cache_free(zdev_fmb_cache, zdev->fmb);
zdev->fmb = NULL;
}
- return cc ? -EIO : 0;
+ return rc;
}
+EXPORT_SYMBOL_GPL(zpci_fmb_enable_device);
/* Modify PCI: Disable PCI function measurement */
int zpci_fmb_disable_device(struct zpci_dev *zdev)
@@ -231,6 +249,41 @@ int zpci_fmb_disable_device(struct zpci_dev *zdev)
}
return cc ? -EIO : 0;
}
+EXPORT_SYMBOL_GPL(zpci_fmb_disable_device);
+
+int zpci_fmb_reenable_device(struct zpci_dev *zdev)
+{
+ u64 req = ZPCI_CREATE_REQ(zdev->fh, 0, ZPCI_MOD_FC_SET_MEASURE);
+ struct zpci_fib fib = {0};
+ u8 cc, status;
+ int rc;
+
+ lockdep_assert_held(&zdev->fmb_lock);
+
+ if (!zdev->fmb)
+ return zpci_fmb_enable_device(zdev);
+
+ fib.gd = zdev->gisa;
+ cc = zpci_mod_fc(req, &fib, &status); /* Disable function measurement */
+
+ /* Unlike in zpci_fmb_disable_device(), cc == 3 is not a valid state here
+ * because we are re-enabling function measurement for the same function
+ * handle.
+ */
+ if (cc)
+ return -EIO;
+
+ zpci_fmb_clear_iommu_ctrs(zdev);
+
+ rc = zpci_fmb_do_enable(zdev);
+ if (rc) {
+ kmem_cache_free(zdev_fmb_cache, zdev->fmb);
+ zdev->fmb = NULL;
+ }
+
+ return rc;
+}
+EXPORT_SYMBOL_GPL(zpci_fmb_reenable_device);
static int zpci_cfg_load(struct zpci_dev *zdev, int offset, u32 *val, u8 len)
{
@@ -737,9 +790,14 @@ int zpci_reenable_device(struct zpci_dev *zdev)
}
rc = zpci_iommu_register_ioat(zdev, &status);
- if (rc)
+ if (rc) {
zpci_disable_device(zdev);
+ return rc;
+ }
+ mutex_lock(&zdev->fmb_lock);
+ zpci_fmb_reenable_device(zdev);
+ mutex_unlock(&zdev->fmb_lock);
return rc;
}
EXPORT_SYMBOL_GPL(zpci_reenable_device);
--
2.54.0
^ permalink raw reply related
* [PATCH v3 1/4] s390/pci: Hold fmb_lock when enabling or disabling PCI devices
From: Omar Elghoul @ 2026-06-08 17:18 UTC (permalink / raw)
To: linux-s390, linux-kernel, kvm
Cc: oelghoul, hca, gor, agordeev, borntraeger, svens, schnelle,
mjrosato, alifm, farman, gbayer, alex, stable
In-Reply-To: <20260608171850.62829-1-oelghoul@linux.ibm.com>
Ensure that fmb_lock is held by pcibios_enable_device() and
pcibios_disable_device() when calling zpci_fmb_enable_device() or
zpci_fmb_disable_device(), respectively. Additionally, assert that the
fmb_lock is held within the latter two functions to prevent future race
conditions regarding new callers.
Fixes: af0a8a8453f7 ("s390/pci: implement pcibios_add_device")
Fixes: 944239c59e93 ("s390/pci: implement pcibios_release_device")
Cc: stable@vger.kernel.org
Signed-off-by: Omar Elghoul <oelghoul@linux.ibm.com>
---
arch/s390/pci/pci.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c
index 39bd2adfc240..2910d4038d39 100644
--- a/arch/s390/pci/pci.c
+++ b/arch/s390/pci/pci.c
@@ -173,6 +173,8 @@ int zpci_fmb_enable_device(struct zpci_dev *zdev)
unsigned long flags;
u8 cc, status;
+ lockdep_assert_held(&zdev->fmb_lock);
+
if (zdev->fmb || sizeof(*zdev->fmb) < zdev->fmb_length)
return -EINVAL;
@@ -211,6 +213,8 @@ int zpci_fmb_disable_device(struct zpci_dev *zdev)
struct zpci_fib fib = {0};
u8 cc, status;
+ lockdep_assert_held(&zdev->fmb_lock);
+
if (!zdev->fmb)
return -EINVAL;
@@ -639,7 +643,9 @@ int pcibios_enable_device(struct pci_dev *pdev, int mask)
struct zpci_dev *zdev = to_zpci(pdev);
zpci_debug_init_device(zdev, dev_name(&pdev->dev));
+ mutex_lock(&zdev->fmb_lock);
zpci_fmb_enable_device(zdev);
+ mutex_unlock(&zdev->fmb_lock);
return pci_enable_resources(pdev, mask);
}
@@ -648,7 +654,9 @@ void pcibios_disable_device(struct pci_dev *pdev)
{
struct zpci_dev *zdev = to_zpci(pdev);
+ mutex_lock(&zdev->fmb_lock);
zpci_fmb_disable_device(zdev);
+ mutex_unlock(&zdev->fmb_lock);
zpci_debug_exit_device(zdev);
}
--
2.54.0
^ permalink raw reply related
* [PATCH v3 0/4] vfio-pci/zdev: Improved zPCI Function Measurement Support
From: Omar Elghoul @ 2026-06-08 17:18 UTC (permalink / raw)
To: linux-s390, linux-kernel, kvm
Cc: oelghoul, hca, gor, agordeev, borntraeger, svens, schnelle,
mjrosato, alifm, farman, gbayer, alex
Hi,
This patch series improves support for function measurement for zPCI
passthrough devices on s390x.
Changelog
=========
v2 -> v3:
* Patch 1/4 (new patch):
- Fix race conditions in pcibios_enable/disable_device() with regard to
the FMB enable/disable
- Assert that fmb_lock is held within zpci_fmb_enable_device() and
zpci_fmb_disable_device()
* Patch 2/4 (previously 1/3):
- Move the FMB enable logic into a static function zpci_fmb_do_enable()
to reduce code duplication between zpci_fmb_enable_device() and
zpci_fmb_reenable_device()
- Reword commit message to use the imperative voice more consistently
* Patch 3/4 (previously 2/3):
- Split the previous VFIO feature into a SET-only and a GET-only feature
for enabling/disabling and reading the FMB respectively
- Remove FMB definitions from the VFIO uAPI and instead treat it as an
opaque structure
* Patch 4/4 (previously 3/3):
- Clarify goto label name to reduce misunderstandings
v1 -> v2:
* Patch 1/3:
- Address a possible race condition in zpci_reenable_device() caused by
calling zpci_fmb_reenable_device() without holding fmb_lock
- Assert that fmb_lock is held within zpci_fmb_reenable_device()
* Patch 3/3:
- Address a possible race condition in pci_perf_seq_write() caused by
consuming zdev->kzdev without holding kzdev_lock
Motivation
==========
The firmware on s390x machines allows for tracking a variety of statistics
relating to zPCI devices in a function measurement block (FMB). However,
the kernel currently lacks a structured mechanism of sharing this
information with userspace, beyond /sys/kernel/debug/pci/ID/statistics.
This can lead to shortcomings when running a guest on KVM with PCI
passthrough devices, as QEMU is unable to provide an accurate FMB snapshot
to the guest.
Proposal
========
We propose adding a new VFIO device feature to zPCI passthrough devices,
allowing userspace programs to read the latest FMB snapshot as it is
written by the firmware. We ensure that function measurement enablement is
preserved across device resets on the host. Furthermore, we guard against
host tampering with the FMB via sysfs when the zPCI device is in
passthrough to protect the VM's state.
I'd appreciate some feedback on these patches.
Thanks in advance.
Omar Elghoul (4):
s390/pci: Hold fmb_lock when enabling or disabling PCI devices
s390/pci: Preserve FMB state in device re-enablement
vfio-pci/zdev: Add VFIO FMB device features
s390/pci: Fence FMB enable/disable via sysfs for passthrough devices
arch/s390/include/asm/pci.h | 1 +
arch/s390/pci/pci.c | 100 +++++++++++++++++++++++++------
arch/s390/pci/pci_debug.c | 11 +++-
drivers/vfio/pci/vfio_pci_core.c | 4 ++
drivers/vfio/pci/vfio_pci_priv.h | 18 ++++++
drivers/vfio/pci/vfio_pci_zdev.c | 57 ++++++++++++++++++
include/uapi/linux/vfio.h | 29 +++++++++
7 files changed, 202 insertions(+), 18 deletions(-)
--
2.54.0
^ permalink raw reply
* Re: [PATCH 2/3] vmsplice: make vmsplice a trivial wrapper for preadv2/pwritev2
From: Alexander Gordeev @ 2026-06-08 17:19 UTC (permalink / raw)
To: Askar Safin
Cc: linux-fsdevel, Christian Brauner, Alexander Viro, Jan Kara,
linux-kernel, linux-mm, linux-api, netdev, Linus Torvalds,
Matthew Wilcox, Jens Axboe, Christoph Hellwig, David Howells,
Andrew Morton, David Hildenbrand, Pedro Falcato, Miklos Szeredi,
patches, linux-s390, linux-next
In-Reply-To: <20260531010107.1953702-3-safinaskar@gmail.com>
On Sun, May 31, 2026 at 01:01:06AM +0000, Askar Safin wrote:
> vmsplice behavior on writable pipe became equivalent to pwritev2.
> vmsplice behavior on readable pipe already was nearly
> equivalent to preadv2, but I made this explicit. I. e. I made it
> obvious from code that vmsplice now is equivalent to preadv2/pwritev2.
>
> Also I moved vmsplice to fs/read_write.c, because now it arguably
> belongs there.
>
> Note that SPLICE_F_NONBLOCK behavior slightly changed: previously
> vmsplice ignored whether the pipe was opened with O_NONBLOCK, and mode
> of operation depended on whether SPLICE_F_NONBLOCK was passed only.
> Now the operation will be non-blocking if O_NONBLOCK was passed when
> opening *or* SPLICE_F_NONBLOCK was passed to vmsplice. Previous
> behavior was arguably buggy, and new behavior is arguably better.
>
> Now SPLICE_F_GIFT is always ignored by all 3 syscalls: splice, tee
> and vmsplice.
>
> Signed-off-by: Askar Safin <safinaskar@gmail.com>
> ---
> fs/read_write.c | 23 +++++
> fs/splice.c | 192 +--------------------------------------
> include/linux/skbuff.h | 4 +-
> include/linux/splice.h | 2 +-
> include/linux/syscalls.h | 4 +-
> 5 files changed, 29 insertions(+), 196 deletions(-)
Hi All,
This patch as commit e2c0b2368081b ("vmsplice: make vmsplice a trivial
wrapper for preadv2/pwritev2") in linux-next on s390 causes the selftest
tools/testing/selftests/mm/cow.c to hang:
# [RUN] vmsplice() + unmap in child ... with PTE-mapped THP (128 kB)
Recently there has been changes in THP area, so the problem is not
necessary linked to this patch per se.
Please, let me know if you need any additional information.
Thanks!
^ permalink raw reply
* Re: [PATCH] s390: Remove GENERIC_LOCKBREAK Kconfig option
From: Alexander Gordeev @ 2026-06-08 17:05 UTC (permalink / raw)
To: Heiko Carstens
Cc: Sven Schnelle, Vasily Gorbik, Christian Borntraeger,
Massimiliano Pellizzer, Peter Zijlstra, linux-kernel, linux-s390
In-Reply-To: <20260605153206.2397521-1-hca@linux.ibm.com>
On Fri, Jun 05, 2026 at 05:32:06PM +0200, Heiko Carstens wrote:
> s390 selects GENERIC_LOCKBREAK if PREEMPT is enabled. Reason is a historic
> 18 years old commit [1] which fixed a compile error for PREEMPT enabled
> kernels. Back than only PREEMPT_NONE and PREEMPT_VOLUNTARY kernels were
> considered to be important for s390. PREEMPT should "just work".
>
> However, since recently PREEMPT is always enabled [2], which also causes
> GENERIC_LOCKBREAK to be always enabled. For some workloads this leads to
> massive performance degradation; e.g. a simple kernel compile on machines
> with many CPUs may take up to four times longer.
>
> To fix this just remove the GENERIC_LOCKBREAK from s390's Kconfig, since
> the compile error from 18 years ago does not exist anymore.
>
> [1] commit b6b40c532a36 ("[S390] Define GENERIC_LOCKBREAK.")
> [2] commit 7dadeaa6e851 ("sched: Further restrict the preemption modes")
>
> Cc: stable@vger.kernel.org
> Reported-by: Massimiliano Pellizzer <massimiliano.pellizzer@canonical.com>
> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
> ---
> arch/s390/Kconfig | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> index ecbcbb781e40..9921a3772bf7 100644
> --- a/arch/s390/Kconfig
> +++ b/arch/s390/Kconfig
> @@ -29,9 +29,6 @@ config GENERIC_BUG
> config GENERIC_BUG_RELATIVE_POINTERS
> def_bool y
>
> -config GENERIC_LOCKBREAK
> - def_bool y if PREEMPTION
> -
> config AUDIT_ARCH
> def_bool y
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] s390: Remove GENERIC_LOCKBREAK Kconfig option
From: Sven Schnelle @ 2026-06-08 16:11 UTC (permalink / raw)
To: Heiko Carstens
Cc: Alexander Gordeev, Vasily Gorbik, Christian Borntraeger,
Massimiliano Pellizzer, Peter Zijlstra, linux-kernel, linux-s390
In-Reply-To: <20260605153206.2397521-1-hca@linux.ibm.com>
Heiko Carstens <hca@linux.ibm.com> writes:
> s390 selects GENERIC_LOCKBREAK if PREEMPT is enabled. Reason is a historic
> 18 years old commit [1] which fixed a compile error for PREEMPT enabled
> kernels. Back than only PREEMPT_NONE and PREEMPT_VOLUNTARY kernels were
> considered to be important for s390. PREEMPT should "just work".
>
> However, since recently PREEMPT is always enabled [2], which also causes
> GENERIC_LOCKBREAK to be always enabled. For some workloads this leads to
> massive performance degradation; e.g. a simple kernel compile on machines
> with many CPUs may take up to four times longer.
>
> To fix this just remove the GENERIC_LOCKBREAK from s390's Kconfig, since
> the compile error from 18 years ago does not exist anymore.
>
> [1] commit b6b40c532a36 ("[S390] Define GENERIC_LOCKBREAK.")
> [2] commit 7dadeaa6e851 ("sched: Further restrict the preemption modes")
>
> Cc: stable@vger.kernel.org
> Reported-by: Massimiliano Pellizzer <massimiliano.pellizzer@canonical.com>
> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
> ---
> arch/s390/Kconfig | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> index ecbcbb781e40..9921a3772bf7 100644
> --- a/arch/s390/Kconfig
> +++ b/arch/s390/Kconfig
> @@ -29,9 +29,6 @@ config GENERIC_BUG
> config GENERIC_BUG_RELATIVE_POINTERS
> def_bool y
>
> -config GENERIC_LOCKBREAK
> - def_bool y if PREEMPTION
> -
> config AUDIT_ARCH
> def_bool y
Reviewed-by: Sven Schnelle <svens@linux.ibm.com>
^ permalink raw reply
* Re: [PATCH] powerpc: Export set_memory_encrypted and set_memory_decrypted
From: T.J. Mercier @ 2026-06-08 16:04 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Sumit Semwal, Jiri Pirko, Maxime Ripard, Christoph Hellwig, maddy,
mpe, npiggin, chleroy, linuxppc-dev, lkp, linux-kernel, iommu,
linux-mm, agordeev, gerald.schaefer, linux-s390, Dan Williams,
Tom Lendacky, x86, Arnd Bergmann
In-Reply-To: <20260608152743.GD2764304@ziepe.ca>
On Mon, Jun 8, 2026 at 8:27 AM Jason Gunthorpe <jgg@ziepe.ca> wrote:
>
> On Mon, Jun 08, 2026 at 08:47:15PM +0530, Sumit Semwal wrote:
> > Hi Jason,
> >
> > On Thu, 4 Jun 2026 at 19:27, Jason Gunthorpe <jgg@ziepe.ca> wrote:
> > >
> > > On Thu, Jun 04, 2026 at 12:51:49PM +0530, Sumit Semwal wrote:
> > >
> > > > Given that Christoph's objection is not really about the modules part,
> > > > but that the set_memory_{encrypted,decrypted} should not be used here,
> > > > one option is to revert 78b30c50a7ac until that issue is sorted out?
> > >
> > > Please no, we have stuff already using this so it would be a
> > > functional regression. Revert making heaps into a module since that
> > > doesn't have a functional regression.
> >
> > Thanks for your comments.
> >
> > To me, it looks like while system and system_cc_shared heaps share a
> > lot of code, their user bases have different needs. It's apparent that
> > system_cc_heap users don't care about it being a module while system
> > heap users would very much like so.
> >
> > I also discussed this with Arnd, and he suggested we could rearrange
> > the code so that system_heap_cc_shared_priv depends on a new Kconfig
> > symbol like
> >
> > config DMABUF_HEAPS_CC_SYSTEM
> > bool "DMA-BUF System Heap for memory encryption"
> > depends on ARCH_HAS_MEM_ENCRYPT && DMABUF_HEAPS_SYSTEM=y
> >
> > This allows building both into the kernel or leave encryption choice
> > up to the consumers of the system heap.
> >
> > If this is agreeable to everyone, I can post Arnd's patch.
>
> Yeah, that's fine for me for now
>
> Jason
+1 SGTM
Thanks,
T.J.
^ permalink raw reply
* Re: [PATCH v5 0/6] s390: Enable Rust support and add required arch glue
From: Gary Guo @ 2026-06-08 15:48 UTC (permalink / raw)
To: Alexander Gordeev, Heiko Carstens
Cc: Jan Polensky, gor, ojeda, peterz, jpoimboe, jbaron, aliceryhl,
borntraeger, svens, boqun, gary, bjorn3_gh, lossin, a.hindborg,
tmgross, dakr, rostedt, ardb, linux-s390, rust-for-linux,
linux-kernel
In-Reply-To: <8f3c0ffc-adc3-493f-8347-9e7579f3cf99-agordeev@linux.ibm.com>
On Mon Jun 8, 2026 at 3:36 PM BST, Alexander Gordeev wrote:
> On Mon, Jun 08, 2026 at 04:21:22PM +0200, Heiko Carstens wrote:
>> I guess Alexander will pick this up and route this via s390.
>
> Yes, I applied and scheduled it for -rc7.
>
> Two new files fall under the Rust maintainers scope:
>
> rust/helpers/helpers.c | 1 +
> rust/helpers/string.c | 8 ++++++++
>
> Please, let me know if someone is against it.
> Otherwise, an ack would be ideal ;)
Thes string.c is missing __rust_helper and it is also missing a trailing
newline.
Sashiko's report is accurate here:
https://sashiko.dev/#/patchset/20260601174625.2910233-1-japo%40linux.ibm.com?part=4
Best,
Gary
>
> Thanks!
^ permalink raw reply
* Re: [PATCH] powerpc: Export set_memory_encrypted and set_memory_decrypted
From: Jason Gunthorpe @ 2026-06-08 15:27 UTC (permalink / raw)
To: Sumit Semwal, Jiri Pirko
Cc: Maxime Ripard, Jiri Pirko, Christoph Hellwig, T.J. Mercier, maddy,
mpe, npiggin, chleroy, linuxppc-dev, lkp, linux-kernel, iommu,
linux-mm, agordeev, gerald.schaefer, linux-s390, Dan Williams,
Tom Lendacky, x86, Arnd Bergmann
In-Reply-To: <CAO_48GH3NP09U6TdB5drbKY0TpwvtBXwrf=Jajsr5ttNbC_u9g@mail.gmail.com>
On Mon, Jun 08, 2026 at 08:47:15PM +0530, Sumit Semwal wrote:
> Hi Jason,
>
> On Thu, 4 Jun 2026 at 19:27, Jason Gunthorpe <jgg@ziepe.ca> wrote:
> >
> > On Thu, Jun 04, 2026 at 12:51:49PM +0530, Sumit Semwal wrote:
> >
> > > Given that Christoph's objection is not really about the modules part,
> > > but that the set_memory_{encrypted,decrypted} should not be used here,
> > > one option is to revert 78b30c50a7ac until that issue is sorted out?
> >
> > Please no, we have stuff already using this so it would be a
> > functional regression. Revert making heaps into a module since that
> > doesn't have a functional regression.
>
> Thanks for your comments.
>
> To me, it looks like while system and system_cc_shared heaps share a
> lot of code, their user bases have different needs. It's apparent that
> system_cc_heap users don't care about it being a module while system
> heap users would very much like so.
>
> I also discussed this with Arnd, and he suggested we could rearrange
> the code so that system_heap_cc_shared_priv depends on a new Kconfig
> symbol like
>
> config DMABUF_HEAPS_CC_SYSTEM
> bool "DMA-BUF System Heap for memory encryption"
> depends on ARCH_HAS_MEM_ENCRYPT && DMABUF_HEAPS_SYSTEM=y
>
> This allows building both into the kernel or leave encryption choice
> up to the consumers of the system heap.
>
> If this is agreeable to everyone, I can post Arnd's patch.
Yeah, that's fine for me for now
Jason
^ permalink raw reply
* Re: [PATCH] powerpc: Export set_memory_encrypted and set_memory_decrypted
From: Sumit Semwal @ 2026-06-08 15:17 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Maxime Ripard, Jiri Pirko, Christoph Hellwig, T.J. Mercier, maddy,
mpe, npiggin, chleroy, linuxppc-dev, lkp, linux-kernel, iommu,
linux-mm, agordeev, gerald.schaefer, linux-s390, Dan Williams,
Tom Lendacky, x86, Arnd Bergmann
In-Reply-To: <20260604135712.GV2487554@ziepe.ca>
Hi Jason,
On Thu, 4 Jun 2026 at 19:27, Jason Gunthorpe <jgg@ziepe.ca> wrote:
>
> On Thu, Jun 04, 2026 at 12:51:49PM +0530, Sumit Semwal wrote:
>
> > Given that Christoph's objection is not really about the modules part,
> > but that the set_memory_{encrypted,decrypted} should not be used here,
> > one option is to revert 78b30c50a7ac until that issue is sorted out?
>
> Please no, we have stuff already using this so it would be a
> functional regression. Revert making heaps into a module since that
> doesn't have a functional regression.
Thanks for your comments.
To me, it looks like while system and system_cc_shared heaps share a
lot of code, their user bases have different needs. It's apparent that
system_cc_heap users don't care about it being a module while system
heap users would very much like so.
I also discussed this with Arnd, and he suggested we could rearrange
the code so that system_heap_cc_shared_priv depends on a new Kconfig
symbol like
config DMABUF_HEAPS_CC_SYSTEM
bool "DMA-BUF System Heap for memory encryption"
depends on ARCH_HAS_MEM_ENCRYPT && DMABUF_HEAPS_SYSTEM=y
This allows building both into the kernel or leave encryption choice
up to the consumers of the system heap.
If this is agreeable to everyone, I can post Arnd's patch.
>
> Jason
Best,
Sumit.
^ permalink raw reply
page: next (older)
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox