* Re: [PATCH 4/8] gpu: nova-core: convert GC6 registers to kernel register macro
From: Alexandre Courbot @ 2026-03-19 14:19 UTC (permalink / raw)
To: Eliot Courtney
Cc: Danilo Krummrich, Alice Ryhl, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Miguel Ojeda,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Andreas Hindborg, Trevor Gross, John Hubbard, Alistair Popple,
Joel Fernandes, Timur Tabi, Zhi Wang, dri-devel, linux-kernel,
linux-riscv, linux-doc, rust-for-linux
In-Reply-To: <DH6E45B9EBWR.1MAR230QYC2HG@nvidia.com>
On Thu Mar 19, 2026 at 11:07 AM JST, Eliot Courtney wrote:
> On Wed Mar 18, 2026 at 5:06 PM JST, Alexandre Courbot wrote:
>> Convert all GC6 registers to use the kernel's register macro and update
>> the code accordingly.
>>
>> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
>> impl NV_PGC6_AON_SECURE_SCRATCH_GROUP_05_0_GFW_BOOT {
>> /// Returns `true` if GFW boot is completed.
>> @@ -252,16 +253,17 @@ pub(crate) fn completed(self) -> bool {
>> }
>> }
>>
>> -register!(NV_PGC6_AON_SECURE_SCRATCH_GROUP_42 @ 0x001183a4 {
>> - 31:0 value as u32;
>> -});
>> -
>> -register!(
>> - NV_USABLE_FB_SIZE_IN_MB => NV_PGC6_AON_SECURE_SCRATCH_GROUP_42,
>> - "Scratch group 42 register used as framebuffer size" {
>> - 31:0 value as u32, "Usable framebuffer size, in megabytes";
>> +nv_reg! {
>> + NV_PGC6_AON_SECURE_SCRATCH_GROUP_42 @ 0x001183a4 {
>> + 31:0 value;
>> }
>> -);
>> +
>> + /// Scratch group 42 register used as framebuffer size.
>> + NV_USABLE_FB_SIZE_IN_MB => NV_PGC6_AON_SECURE_SCRATCH_GROUP_42 {
>> + /// Usable framebuffer size, in megabytes.
>> + 31:0 value;
>> + }
>> +}
>
> This is not an issue with your series, but why do we have
> `NV_PGC6_AON_SECURE_SCRATCH_GROUP_42` which is aliased to
> `NV_USABLE_FB_SIZE_IN_MB` and not used for anything else?
This is just to follow the register definitions of OpenRM - the actual
register name is `SCRATCH_GROUP_42`, but we are using it in a given
software context where its role is reporting the size of the
framebuffer.
We could just define `NV_USABLE_FB_SIZE_IN_MB`, but that wouldn't
reflect the hardware manuals properly.
^ permalink raw reply
* Re: [PATCH 5/8] gpu: nova-core: convert FUSE registers to kernel register macro
From: Alexandre Courbot @ 2026-03-19 14:24 UTC (permalink / raw)
To: Eliot Courtney
Cc: Danilo Krummrich, Alice Ryhl, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Miguel Ojeda,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Andreas Hindborg, Trevor Gross, John Hubbard, Alistair Popple,
Joel Fernandes, Timur Tabi, Zhi Wang, dri-devel, linux-kernel,
linux-riscv, linux-doc, rust-for-linux
In-Reply-To: <DH6ECIKZRESY.D4VBM1STGPH@nvidia.com>
On Thu Mar 19, 2026 at 11:17 AM JST, Eliot Courtney wrote:
> On Wed Mar 18, 2026 at 5:06 PM JST, Alexandre Courbot wrote:
>> Convert all FUSE registers to use the kernel's register macro and update
>> the code accordingly.
>>
>> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
>> ---
>> drivers/gpu/nova-core/falcon/hal/ga102.rs | 20 +++++++++++------
>> drivers/gpu/nova-core/fb/hal/ga100.rs | 3 ++-
>> drivers/gpu/nova-core/fb/hal/tu102.rs | 3 ++-
>> drivers/gpu/nova-core/regs.rs | 36 ++++++++++++++++++-------------
>> 4 files changed, 39 insertions(+), 23 deletions(-)
>>
>> diff --git a/drivers/gpu/nova-core/falcon/hal/ga102.rs b/drivers/gpu/nova-core/falcon/hal/ga102.rs
>> index 8f62df10da0a..e3eb6189819f 100644
>> --- a/drivers/gpu/nova-core/falcon/hal/ga102.rs
>> +++ b/drivers/gpu/nova-core/falcon/hal/ga102.rs
>> @@ -4,7 +4,11 @@
>>
>> use kernel::{
>> device,
>> - io::poll::read_poll_timeout,
>> + io::{
>> + poll::read_poll_timeout,
>> + register::Array,
>> + Io, //
>> + },
>> prelude::*,
>> time::Delta, //
>> };
>> @@ -60,16 +64,20 @@ fn signature_reg_fuse_version_ga102(
>>
>> // `ucode_idx` is guaranteed to be in the range [0..15], making the `read` calls provable valid
>> // at build-time.
>> - let reg_fuse_version = if engine_id_mask & 0x0001 != 0 {
>> - regs::NV_FUSE_OPT_FPF_SEC2_UCODE1_VERSION::read(bar, ucode_idx).data()
>> + let reg_fuse_version: u16 = if engine_id_mask & 0x0001 != 0 {
>> + bar.read(regs::NV_FUSE_OPT_FPF_SEC2_UCODE1_VERSION::at(ucode_idx))
>> + .data()
>> } else if engine_id_mask & 0x0004 != 0 {
>> - regs::NV_FUSE_OPT_FPF_NVDEC_UCODE1_VERSION::read(bar, ucode_idx).data()
>> + bar.read(regs::NV_FUSE_OPT_FPF_NVDEC_UCODE1_VERSION::at(ucode_idx))
>> + .data()
>> } else if engine_id_mask & 0x0400 != 0 {
>> - regs::NV_FUSE_OPT_FPF_GSP_UCODE1_VERSION::read(bar, ucode_idx).data()
>> + bar.read(regs::NV_FUSE_OPT_FPF_GSP_UCODE1_VERSION::at(ucode_idx))
>> + .data()
>> } else {
>> dev_err!(dev, "unexpected engine_id_mask {:#x}\n", engine_id_mask);
>> return Err(EINVAL);
>> - };
>> + }
>> + .into();
>>
>> // TODO[NUMM]: replace with `last_set_bit` once it lands.
>> Ok(u16::BITS - reg_fuse_version.leading_zeros())
>> diff --git a/drivers/gpu/nova-core/fb/hal/ga100.rs b/drivers/gpu/nova-core/fb/hal/ga100.rs
>> index 629588c75778..1c03783cddef 100644
>> --- a/drivers/gpu/nova-core/fb/hal/ga100.rs
>> +++ b/drivers/gpu/nova-core/fb/hal/ga100.rs
>> @@ -40,7 +40,8 @@ pub(super) fn write_sysmem_flush_page_ga100(bar: &Bar0, addr: u64) {
>> }
>>
>> pub(super) fn display_enabled_ga100(bar: &Bar0) -> bool {
>> - !regs::ga100::NV_FUSE_STATUS_OPT_DISPLAY::read(bar).display_disabled()
>> + !bar.read(regs::ga100::NV_FUSE_STATUS_OPT_DISPLAY)
>> + .display_disabled()
>> }
>>
>> /// Shift applied to the sysmem address before it is written into
>> diff --git a/drivers/gpu/nova-core/fb/hal/tu102.rs b/drivers/gpu/nova-core/fb/hal/tu102.rs
>> index 515d50872224..281bb796e198 100644
>> --- a/drivers/gpu/nova-core/fb/hal/tu102.rs
>> +++ b/drivers/gpu/nova-core/fb/hal/tu102.rs
>> @@ -29,7 +29,8 @@ pub(super) fn write_sysmem_flush_page_gm107(bar: &Bar0, addr: u64) -> Result {
>> }
>>
>> pub(super) fn display_enabled_gm107(bar: &Bar0) -> bool {
>> - !regs::gm107::NV_FUSE_STATUS_OPT_DISPLAY::read(bar).display_disabled()
>> + !bar.read(regs::gm107::NV_FUSE_STATUS_OPT_DISPLAY)
>> + .display_disabled()
>> }
>>
>> pub(super) fn vidmem_size_gp102(bar: &Bar0) -> u64 {
>> diff --git a/drivers/gpu/nova-core/regs.rs b/drivers/gpu/nova-core/regs.rs
>> index 4439464aae4d..9682a94b8b77 100644
>> --- a/drivers/gpu/nova-core/regs.rs
>> +++ b/drivers/gpu/nova-core/regs.rs
>> @@ -294,17 +294,19 @@ pub(crate) fn vga_workspace_addr(self) -> Option<u64> {
>>
>> pub(crate) const NV_FUSE_OPT_FPF_SIZE: usize = 16;
>>
>> -register!(NV_FUSE_OPT_FPF_NVDEC_UCODE1_VERSION @ 0x00824100[NV_FUSE_OPT_FPF_SIZE] {
>> - 15:0 data as u16;
>> -});
>> +nv_reg! {
>> + NV_FUSE_OPT_FPF_NVDEC_UCODE1_VERSION[NV_FUSE_OPT_FPF_SIZE] @ 0x00824100 {
>> + 15:0 data;
>> + }
>>
>> -register!(NV_FUSE_OPT_FPF_SEC2_UCODE1_VERSION @ 0x00824140[NV_FUSE_OPT_FPF_SIZE] {
>> - 15:0 data as u16;
>> -});
>> + NV_FUSE_OPT_FPF_SEC2_UCODE1_VERSION[NV_FUSE_OPT_FPF_SIZE] @ 0x00824140 {
>> + 15:0 data;
>> + }
>>
>> -register!(NV_FUSE_OPT_FPF_GSP_UCODE1_VERSION @ 0x008241c0[NV_FUSE_OPT_FPF_SIZE] {
>> - 15:0 data as u16;
>> -});
>> + NV_FUSE_OPT_FPF_GSP_UCODE1_VERSION[NV_FUSE_OPT_FPF_SIZE] @ 0x008241c0 {
>> + 15:0 data;
>> + }
>> +}
>
> What about using data => u16 here (like below with => bool), then we can
> avoid the into()?.
Of course - I overlooked that, thanks for pointing it out.
^ permalink raw reply
* Re: [PATCH 7/8] gpu: nova-core: convert falcon registers to kernel register macro
From: Alexandre Courbot @ 2026-03-19 14:34 UTC (permalink / raw)
To: Eliot Courtney
Cc: Danilo Krummrich, Alice Ryhl, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Miguel Ojeda,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Andreas Hindborg, Trevor Gross, John Hubbard, Alistair Popple,
Joel Fernandes, Timur Tabi, Zhi Wang, dri-devel, linux-kernel,
linux-riscv, linux-doc, rust-for-linux
In-Reply-To: <DH6IJKX25H7H.28NWD4KJSXX73@nvidia.com>
On Thu Mar 19, 2026 at 2:35 PM JST, Eliot Courtney wrote:
> On Wed Mar 18, 2026 at 5:06 PM JST, Alexandre Courbot wrote:
>> Convert all PFALCON, PFALCON2 and PRISCV registers to use the kernel's
>> register macro and update the code accordingly.
>>
>> Because they rely on the same types to implement relative registers,
>> they need to be updated in lockstep.
>>
>> nova-core's local register macro is now unused, so remove it.
>>
>> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
>> ---
>> drivers/gpu/nova-core/falcon.rs | 333 +++++-----
>> drivers/gpu/nova-core/falcon/gsp.rs | 22 +-
>> drivers/gpu/nova-core/falcon/hal/ga102.rs | 55 +-
>> drivers/gpu/nova-core/falcon/hal/tu102.rs | 12 +-
>> drivers/gpu/nova-core/falcon/sec2.rs | 17 +-
>> drivers/gpu/nova-core/firmware/fwsec/bootloader.rs | 19 +-
>> drivers/gpu/nova-core/regs.rs | 350 +++++-----
>> drivers/gpu/nova-core/regs/macros.rs | 739 ---------------------
>> 8 files changed, 421 insertions(+), 1126 deletions(-)
>>
>> diff --git a/drivers/gpu/nova-core/falcon.rs b/drivers/gpu/nova-core/falcon.rs
>> index 4721865f59d9..90afef40acd0 100644
>> --- a/drivers/gpu/nova-core/falcon.rs
>> +++ b/drivers/gpu/nova-core/falcon.rs
>> @@ -14,9 +14,14 @@
>> DmaMask, //
>> },
>> io::{
>> - poll::read_poll_timeout, //
>> + poll::read_poll_timeout,
>> + register::{
>> + RegisterBase,
>> + WithBase, //
>> + },
>> Io,
>> },
>> + num::Bounded,
>> prelude::*,
>> sync::aref::ARef,
>> time::Delta,
>> @@ -33,7 +38,6 @@
>> IntoSafeCast, //
>> },
>> regs,
>> - regs::macros::RegisterBase, //
>> };
>>
>> pub(crate) mod gsp;
>> @@ -44,11 +48,14 @@
>> pub(crate) const MEM_BLOCK_ALIGNMENT: usize = 256;
>>
>> // TODO[FPRI]: Replace with `ToPrimitive`.
>> -macro_rules! impl_from_enum_to_u8 {
>> - ($enum_type:ty) => {
>> - impl From<$enum_type> for u8 {
>> +macro_rules! impl_from_enum_to_bounded {
>> + ($enum_type:ty, $length:literal) => {
>> + impl From<$enum_type> for Bounded<u32, $length> {
>> fn from(value: $enum_type) -> Self {
>> - value as u8
>> + // Shift the value left by the number of unused bits.
>> + let b = Bounded::<u32, 32>::from((value as u32) << (32 - $length));
>> + // Shift back right to create a `Bounded` of the expected width.
>> + b.shr::<{ 32 - $length }, $length>()
>> }
>> }
>> };
>
> This can silently truncate stuff if we typo the wrong bounded size.
> Any reason not to use `Bounded::from_expr(value as u32)` for this?
`from_expr` is tricky to use because it assumes the compiler optimizer
has enough information to guarantee that the set of possible values will
fit into the `Bounded` - and drops a very obscure build-time error if
the proof cannot be established. So it is really for obvious cases like
`if x < 0x10 { Bounded::<u8, 4>::new(x) }`.
Here we are converting from an enum, and in my experience `from_expr`
does work, but I still prefer to avoid it if we can. The bit-shake
method is another way of obtaining the right `Bounded` but in this case
you are right we can lose data - although the use is purely local, and
temporary until the `TryFrom` and `Into` derive macros [1] are
available.
The "correct" way to do this meanwhile would be to generate a match
statement handling all valid values, but this is a bit more intrusive
for something that is temporary.
[1] https://lore.kernel.org/all/20260129-try-from-into-macro-v5-0-dd011008118c@gmail.com/
>
>> diff --git a/drivers/gpu/nova-core/regs.rs b/drivers/gpu/nova-core/regs.rs
>> index 4ac4e9126db8..08d9a9697adc 100644
>> --- a/drivers/gpu/nova-core/regs.rs
>> +++ b/drivers/gpu/nova-core/regs.rs
>> @@ -1,13 +1,10 @@
>> // SPDX-License-Identifier: GPL-2.0
>>
>> -// Required to retain the original register names used by OpenRM, which are all capital snake case
>> -// but are mapped to types.
>> -#![allow(non_camel_case_types)]
>> -
>> -#[macro_use]
>> -pub(crate) mod macros;
>> -
>> use kernel::{
>> + io::{
>> + register::WithBase,
>> + Io, //
>> + },
>> prelude::*,
>> time, //
>> };
>> @@ -314,60 +311,147 @@ pub(crate) fn vga_workspace_addr(self) -> Option<u64> {
>>
>> // PFALCON
>>
>> -register!(NV_PFALCON_FALCON_IRQSCLR @ PFalconBase[0x00000004] {
>> - 4:4 halt as bool;
>> - 6:6 swgen0 as bool;
>> -});
>> +nv_reg! {
>> + NV_PFALCON_FALCON_IRQSCLR @ PFalconBase + 0x00000004 {
>> + 4:4 halt => bool;
>> + 6:6 swgen0 => bool;
>> + }
>>
>> -register!(NV_PFALCON_FALCON_MAILBOX0 @ PFalconBase[0x00000040] {
>> - 31:0 value as u32;
>> -});
>> + NV_PFALCON_FALCON_MAILBOX0 @ PFalconBase + 0x00000040 {
>> + 31:0 value => u32;
>> + }
>>
>> -register!(NV_PFALCON_FALCON_MAILBOX1 @ PFalconBase[0x00000044] {
>> - 31:0 value as u32;
>> -});
>> + NV_PFALCON_FALCON_MAILBOX1 @ PFalconBase + 0x00000044 {
>> + 31:0 value => u32;
>> + }
>>
>> -// Used to store version information about the firmware running
>> -// on the Falcon processor.
>> -register!(NV_PFALCON_FALCON_OS @ PFalconBase[0x00000080] {
>> - 31:0 value as u32;
>> -});
>> + /// Used to store version information about the firmware running
>> + /// on the Falcon processor.
>> + NV_PFALCON_FALCON_OS @ PFalconBase + 0x00000080 {
>> + 31:0 value => u32;
>> + }
>>
>> -register!(NV_PFALCON_FALCON_RM @ PFalconBase[0x00000084] {
>> - 31:0 value as u32;
>> -});
>> + NV_PFALCON_FALCON_RM @ PFalconBase + 0x00000084 {
>> + 31:0 value => u32;
>> + }
>>
>> -register!(NV_PFALCON_FALCON_HWCFG2 @ PFalconBase[0x000000f4] {
>> - 10:10 riscv as bool;
>> - 12:12 mem_scrubbing as bool, "Set to 0 after memory scrubbing is completed";
>> - 31:31 reset_ready as bool, "Signal indicating that reset is completed (GA102+)";
>> -});
>> + NV_PFALCON_FALCON_HWCFG2 @ PFalconBase + 0x000000f4 {
>> + 10:10 riscv => bool;
>> + /// Set to 0 after memory scrubbing is completed.
>> + 12:12 mem_scrubbing => bool;
>> + /// Signal indicating that reset is completed (GA102+).
>> + 31:31 reset_ready => bool;
>> + }
>>
>> -impl NV_PFALCON_FALCON_HWCFG2 {
>> - /// Returns `true` if memory scrubbing is completed.
>> - pub(crate) fn mem_scrubbing_done(self) -> bool {
>> - !self.mem_scrubbing()
>> + NV_PFALCON_FALCON_CPUCTL @ PFalconBase + 0x00000100 {
>> + 1:1 startcpu => bool;
>> + 4:4 halted => bool;
>> + 6:6 alias_en => bool;
>> + }
>> +
>> + NV_PFALCON_FALCON_BOOTVEC @ PFalconBase + 0x00000104 {
>> + 31:0 value => u32;
>> + }
>> +
>> + NV_PFALCON_FALCON_DMACTL @ PFalconBase + 0x0000010c {
>> + 0:0 require_ctx => bool;
>> + 1:1 dmem_scrubbing => bool;
>> + 2:2 imem_scrubbing => bool;
>> + 6:3 dmaq_num;
>> + 7:7 secure_stat => bool;
>> + }
>> +
>> + NV_PFALCON_FALCON_DMATRFBASE @ PFalconBase + 0x00000110 {
>> + 31:0 base => u32;
>> + }
>> +
>> + NV_PFALCON_FALCON_DMATRFMOFFS @ PFalconBase + 0x00000114 {
>> + 23:0 offs;
>> + }
>> +
>> + NV_PFALCON_FALCON_DMATRFCMD @ PFalconBase + 0x00000118 {
>> + 0:0 full => bool;
>> + 1:1 idle => bool;
>> + 3:2 sec;
>> + 4:4 imem => bool;
>> + 5:5 is_write => bool;
>> + 10:8 size ?=> DmaTrfCmdSize;
>> + 14:12 ctxdma;
>> + 16:16 set_dmtag;
>> + }
>> +
>> + NV_PFALCON_FALCON_DMATRFFBOFFS @ PFalconBase + 0x0000011c {
>> + 31:0 offs => u32;
>> + }
>> +
>> + NV_PFALCON_FALCON_DMATRFBASE1 @ PFalconBase + 0x00000128 {
>> + 8:0 base;
>> + }
>> +
>> + NV_PFALCON_FALCON_HWCFG1 @ PFalconBase + 0x0000012c {
>> + /// Core revision.
>> + 3:0 core_rev ?=> FalconCoreRev;
>> + /// Security model.
>> + 5:4 security_model ?=> FalconSecurityModel;
>> + /// Core revision subversion.
>> + 7:6 core_rev_subversion => FalconCoreRevSubversion;
>> + }
>> +
>> + NV_PFALCON_FALCON_CPUCTL_ALIAS @ PFalconBase + 0x00000130 {
>> + 1:1 startcpu => bool;
>> + }
>> +
>> + /// IMEM access control register. Up to 4 ports are available for IMEM access.
>> + NV_PFALCON_FALCON_IMEMC[4, stride = 16] @ PFalconBase + 0x00000180 {
>> + /// IMEM block and word offset.
>> + 15:0 offs;
>> + /// Auto-increment on write.
>> + 24:24 aincw => bool;
>> + /// Access secure IMEM.
>> + 28:28 secure => bool;
>> + }
>> +
>> + /// IMEM data register. Reading/writing this register accesses IMEM at the address
>> + /// specified by the corresponding IMEMC register.
>> + NV_PFALCON_FALCON_IMEMD[4, stride = 16] @ PFalconBase + 0x00000184 {
>> + 31:0 data;
>> + }
>> +
>> + /// IMEM tag register. Used to set the tag for the current IMEM block.
>> + NV_PFALCON_FALCON_IMEMT[4, stride = 16] @ PFalconBase + 0x00000188 {
>> + 15:0 tag;
>> + }
>> +
>> + /// DMEM access control register. Up to 8 ports are available for DMEM access.
>> + NV_PFALCON_FALCON_DMEMC[8, stride = 8] @ PFalconBase + 0x000001c0 {
>> + /// DMEM block and word offset.
>> + 15:0 offs;
>> + /// Auto-increment on write.
>> + 24:24 aincw => bool;
>> + }
>> +
>> + /// DMEM data register. Reading/writing this register accesses DMEM at the address
>> + /// specified by the corresponding DMEMC register.
>> + NV_PFALCON_FALCON_DMEMD[8, stride = 8] @ PFalconBase + 0x000001c4 {
>> + 31:0 data;
>> + }
>> +
>> + /// Actually known as `NV_PSEC_FALCON_ENGINE` and `NV_PGSP_FALCON_ENGINE` depending on the
>> + /// falcon instance.
>> + NV_PFALCON_FALCON_ENGINE @ PFalconBase + 0x000003c0 {
>> + 0:0 reset => bool;
>> + }
>> +
>> + NV_PFALCON_FBIF_TRANSCFG[8] @ PFalconBase + 0x00000600 {
>> + 1:0 target ?=> FalconFbifTarget;
>> + 2:2 mem_type => FalconFbifMemType;
>> + }
>> +
>> + NV_PFALCON_FBIF_CTL @ PFalconBase + 0x00000624 {
>> + 7:7 allow_phys_no_ctx => bool;
>> }
>> }
>>
>> -register!(NV_PFALCON_FALCON_CPUCTL @ PFalconBase[0x00000100] {
>> - 1:1 startcpu as bool;
>> - 4:4 halted as bool;
>> - 6:6 alias_en as bool;
>> -});
>> -
>> -register!(NV_PFALCON_FALCON_BOOTVEC @ PFalconBase[0x00000104] {
>> - 31:0 value as u32;
>> -});
>> -
>> -register!(NV_PFALCON_FALCON_DMACTL @ PFalconBase[0x0000010c] {
>> - 0:0 require_ctx as bool;
>> - 1:1 dmem_scrubbing as bool;
>> - 2:2 imem_scrubbing as bool;
>> - 6:3 dmaq_num as u8;
>> - 7:7 secure_stat as bool;
>> -});
>> -
>> impl NV_PFALCON_FALCON_DMACTL {
>> /// Returns `true` if memory scrubbing is completed.
>> pub(crate) fn mem_scrubbing_done(self) -> bool {
>> @@ -375,147 +459,81 @@ pub(crate) fn mem_scrubbing_done(self) -> bool {
>> }
>> }
>>
>> -register!(NV_PFALCON_FALCON_DMATRFBASE @ PFalconBase[0x00000110] {
>> - 31:0 base as u32;
>> -});
>> -
>> -register!(NV_PFALCON_FALCON_DMATRFMOFFS @ PFalconBase[0x00000114] {
>> - 23:0 offs as u32;
>> -});
>> -
>> -register!(NV_PFALCON_FALCON_DMATRFCMD @ PFalconBase[0x00000118] {
>> - 0:0 full as bool;
>> - 1:1 idle as bool;
>> - 3:2 sec as u8;
>> - 4:4 imem as bool;
>> - 5:5 is_write as bool;
>> - 10:8 size as u8 ?=> DmaTrfCmdSize;
>> - 14:12 ctxdma as u8;
>> - 16:16 set_dmtag as u8;
>> -});
>> -
>> impl NV_PFALCON_FALCON_DMATRFCMD {
>> /// Programs the `imem` and `sec` fields for the given FalconMem
>> pub(crate) fn with_falcon_mem(self, mem: FalconMem) -> Self {
>> - self.set_imem(mem != FalconMem::Dmem)
>> - .set_sec(if mem == FalconMem::ImemSecure { 1 } else { 0 })
>> + let this = self.with_imem(mem != FalconMem::Dmem);
>> +
>> + match mem {
>> + FalconMem::ImemSecure => this.with_const_sec::<1>(),
>> + _ => this.with_const_sec::<0>(),
>> + }
>> }
>> }
>>
>> -register!(NV_PFALCON_FALCON_DMATRFFBOFFS @ PFalconBase[0x0000011c] {
>> - 31:0 offs as u32;
>> -});
>> -
>> -register!(NV_PFALCON_FALCON_DMATRFBASE1 @ PFalconBase[0x00000128] {
>> - 8:0 base as u16;
>> -});
>> -
>> -register!(NV_PFALCON_FALCON_HWCFG1 @ PFalconBase[0x0000012c] {
>> - 3:0 core_rev as u8 ?=> FalconCoreRev, "Core revision";
>> - 5:4 security_model as u8 ?=> FalconSecurityModel, "Security model";
>> - 7:6 core_rev_subversion as u8 ?=> FalconCoreRevSubversion, "Core revision subversion";
>> -});
>> -
>> -register!(NV_PFALCON_FALCON_CPUCTL_ALIAS @ PFalconBase[0x00000130] {
>> - 1:1 startcpu as bool;
>> -});
>> -
>> -// IMEM access control register. Up to 4 ports are available for IMEM access.
>> -register!(NV_PFALCON_FALCON_IMEMC @ PFalconBase[0x00000180[4; 16]] {
>> - 15:0 offs as u16, "IMEM block and word offset";
>> - 24:24 aincw as bool, "Auto-increment on write";
>> - 28:28 secure as bool, "Access secure IMEM";
>> -});
>> -
>> -// IMEM data register. Reading/writing this register accesses IMEM at the address
>> -// specified by the corresponding IMEMC register.
>> -register!(NV_PFALCON_FALCON_IMEMD @ PFalconBase[0x00000184[4; 16]] {
>> - 31:0 data as u32;
>> -});
>> -
>> -// IMEM tag register. Used to set the tag for the current IMEM block.
>> -register!(NV_PFALCON_FALCON_IMEMT @ PFalconBase[0x00000188[4; 16]] {
>> - 15:0 tag as u16;
>> -});
>> -
>> -// DMEM access control register. Up to 8 ports are available for DMEM access.
>> -register!(NV_PFALCON_FALCON_DMEMC @ PFalconBase[0x000001c0[8; 8]] {
>> - 15:0 offs as u16, "DMEM block and word offset";
>> - 24:24 aincw as bool, "Auto-increment on write";
>> -});
>> -
>> -// DMEM data register. Reading/writing this register accesses DMEM at the address
>> -// specified by the corresponding DMEMC register.
>> -register!(NV_PFALCON_FALCON_DMEMD @ PFalconBase[0x000001c4[8; 8]] {
>> - 31:0 data as u32;
>> -});
>> -
>> -// Actually known as `NV_PSEC_FALCON_ENGINE` and `NV_PGSP_FALCON_ENGINE` depending on the falcon
>> -// instance.
>> -register!(NV_PFALCON_FALCON_ENGINE @ PFalconBase[0x000003c0] {
>> - 0:0 reset as bool;
>> -});
>> -
>> impl NV_PFALCON_FALCON_ENGINE {
>> /// Resets the falcon
>> pub(crate) fn reset_engine<E: FalconEngine>(bar: &Bar0) {
>> - Self::read(bar, &E::ID).set_reset(true).write(bar, &E::ID);
>> + bar.update(Self::of::<E>(), |r| r.with_reset(true));
>>
>> // TIMEOUT: falcon engine should not take more than 10us to reset.
>> time::delay::fsleep(time::Delta::from_micros(10));
>>
>> - Self::read(bar, &E::ID).set_reset(false).write(bar, &E::ID);
>> + bar.update(Self::of::<E>(), |r| r.with_reset(false));
>> }
>> }
>>
>> -register!(NV_PFALCON_FBIF_TRANSCFG @ PFalconBase[0x00000600[8]] {
>> - 1:0 target as u8 ?=> FalconFbifTarget;
>> - 2:2 mem_type as bool => FalconFbifMemType;
>> -});
>> -
>> -register!(NV_PFALCON_FBIF_CTL @ PFalconBase[0x00000624] {
>> - 7:7 allow_phys_no_ctx as bool;
>> -});
>> +impl NV_PFALCON_FALCON_HWCFG2 {
>> + /// Returns `true` if memory scrubbing is completed.
>> + pub(crate) fn mem_scrubbing_done(self) -> bool {
>> + !self.mem_scrubbing()
>> + }
>> +}
>>
>> /* PFALCON2 */
>>
>> -register!(NV_PFALCON2_FALCON_MOD_SEL @ PFalcon2Base[0x00000180] {
>> - 7:0 algo as u8 ?=> FalconModSelAlgo;
>> -});
>> +nv_reg! {
>> + NV_PFALCON2_FALCON_MOD_SEL @ PFalcon2Base + 0x00000180 {
>> + 7:0 algo ?=> FalconModSelAlgo;
>> + }
>>
>> -register!(NV_PFALCON2_FALCON_BROM_CURR_UCODE_ID @ PFalcon2Base[0x00000198] {
>> - 7:0 ucode_id as u8;
>> -});
>> + NV_PFALCON2_FALCON_BROM_CURR_UCODE_ID @ PFalcon2Base + 0x00000198 {
>> + 7:0 ucode_id => u8;
>> + }
>>
>> -register!(NV_PFALCON2_FALCON_BROM_ENGIDMASK @ PFalcon2Base[0x0000019c] {
>> - 31:0 value as u32;
>> -});
>> + NV_PFALCON2_FALCON_BROM_ENGIDMASK @ PFalcon2Base + 0x0000019c {
>> + 31:0 value => u32;
>> + }
>>
>> -// OpenRM defines this as a register array, but doesn't specify its size and only uses its first
>> -// element. Be conservative until we know the actual size or need to use more registers.
>> -register!(NV_PFALCON2_FALCON_BROM_PARAADDR @ PFalcon2Base[0x00000210[1]] {
>> - 31:0 value as u32;
>> -});
>> + /// OpenRM defines this as a register array, but doesn't specify its size and only uses its
>> + /// first element. Be conservative until we know the actual size or need to use more registers.
>> + NV_PFALCON2_FALCON_BROM_PARAADDR[1] @ PFalcon2Base + 0x00000210 {
>> + 31:0 value => u32;
>> + }
>> +}
>>
>> // PRISCV
>>
>> -// RISC-V status register for debug (Turing and GA100 only).
>> -// Reflects current RISC-V core status.
>> -register!(NV_PRISCV_RISCV_CORE_SWITCH_RISCV_STATUS @ PFalcon2Base[0x00000240] {
>> - 0:0 active_stat as bool, "RISC-V core active/inactive status";
>> -});
>> -
>> // GA102 and later
>> -register!(NV_PRISCV_RISCV_CPUCTL @ PFalcon2Base[0x00000388] {
>> - 0:0 halted as bool;
>> - 7:7 active_stat as bool;
>> -});
>> +nv_reg! {
>> + /// RISC-V status register for debug (Turing and GA100 only).
>> + /// Reflects current RISC-V core status.
>> + NV_PRISCV_RISCV_CORE_SWITCH_RISCV_STATUS @ PFalcon2Base + 0x00000240 {
>> + /// RISC-V core active/inactive status.
>> + 0:0 active_stat => bool;
>> + }
>
> The above comment says "GA102 and later" but right after it has
> "Turing and GA100 only" which seems incongruous.
Right, this comment was for `NV_PRISCV_RISCV_CPUCTL` but it likely had a
copy/paste accident.
^ permalink raw reply
* Re: [PATCH 1/8] gpu: nova-core: convert PMC registers to kernel register macro
From: Alexandre Courbot @ 2026-03-19 14:39 UTC (permalink / raw)
To: Gary Guo, Jesung Yang
Cc: Danilo Krummrich, Alice Ryhl, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Miguel Ojeda,
Boqun Feng, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, John Hubbard, Alistair Popple, Joel Fernandes,
Timur Tabi, Zhi Wang, Eliot Courtney, dri-devel, linux-kernel,
linux-riscv, linux-doc, rust-for-linux
In-Reply-To: <DH5XZP4LPOXG.XL69OTK91FIX@garyguo.net>
On Wed Mar 18, 2026 at 10:28 PM JST, Gary Guo wrote:
> On Wed Mar 18, 2026 at 8:05 AM GMT, Alexandre Courbot wrote:
>> Convert all PMC registers to use the kernel's register macro and update
>> the code accordingly.
>>
>> nova-core's registers have some constant properties (like a 32-bit size
>> and a crate visibility), so introduce the `nv_reg` macro to shorten
>> their declaration.
>>
>> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
>> ---
>> drivers/gpu/nova-core/falcon.rs | 7 ++--
>> drivers/gpu/nova-core/gpu.rs | 37 ++++++++++-----------
>> drivers/gpu/nova-core/regs.rs | 73 +++++++++++++++++++++++++++++++----------
>> 3 files changed, 78 insertions(+), 39 deletions(-)
>>
>> diff --git a/drivers/gpu/nova-core/falcon.rs b/drivers/gpu/nova-core/falcon.rs
>> index 7097a206ec3c..4721865f59d9 100644
>> --- a/drivers/gpu/nova-core/falcon.rs
>> +++ b/drivers/gpu/nova-core/falcon.rs
>> @@ -13,7 +13,10 @@
>> DmaAddress,
>> DmaMask, //
>> },
>> - io::poll::read_poll_timeout,
>> + io::{
>> + poll::read_poll_timeout, //
>> + Io,
>> + },
>> prelude::*,
>> sync::aref::ARef,
>> time::Delta,
>> @@ -532,7 +535,7 @@ pub(crate) fn reset(&self, bar: &Bar0) -> Result {
>> self.hal.reset_wait_mem_scrubbing(bar)?;
>>
>> regs::NV_PFALCON_FALCON_RM::default()
>> - .set_value(regs::NV_PMC_BOOT_0::read(bar).into())
>> + .set_value(bar.read(regs::NV_PMC_BOOT_0).into())
>> .write(bar, &E::ID);
>>
>> Ok(())
>> diff --git a/drivers/gpu/nova-core/gpu.rs b/drivers/gpu/nova-core/gpu.rs
>> index 8579d632e717..d81abc7de3d7 100644
>> --- a/drivers/gpu/nova-core/gpu.rs
>> +++ b/drivers/gpu/nova-core/gpu.rs
>> @@ -4,6 +4,8 @@
>> device,
>> devres::Devres,
>> fmt,
>> + io::Io,
>> + num::Bounded,
>> pci,
>> prelude::*,
>> sync::Arc, //
>> @@ -129,24 +131,18 @@ fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
>> }
>>
>> /// Enum representation of the GPU generation.
>> -///
>> -/// TODO: remove the `Default` trait implementation, and the `#[default]`
>> -/// attribute, once the register!() macro (which creates Architecture items) no
>> -/// longer requires it for read-only fields.
>> -#[derive(fmt::Debug, Default, Copy, Clone)]
>> -#[repr(u8)]
>> +#[derive(fmt::Debug, Copy, Clone)]
>> pub(crate) enum Architecture {
>> - #[default]
>> Turing = 0x16,
>> Ampere = 0x17,
>> Ada = 0x19,
>> }
>>
>> -impl TryFrom<u8> for Architecture {
>> +impl TryFrom<Bounded<u32, 6>> for Architecture {
>> type Error = Error;
>>
>> - fn try_from(value: u8) -> Result<Self> {
>> - match value {
>> + fn try_from(value: Bounded<u32, 6>) -> Result<Self> {
>> + match u8::from(value) {
>> 0x16 => Ok(Self::Turing),
>> 0x17 => Ok(Self::Ampere),
>> 0x19 => Ok(Self::Ada),
>> @@ -155,23 +151,26 @@ fn try_from(value: u8) -> Result<Self> {
>> }
>> }
>>
>> -impl From<Architecture> for u8 {
>> +impl From<Architecture> for Bounded<u32, 6> {
>> fn from(value: Architecture) -> Self {
>> - // CAST: `Architecture` is `repr(u8)`, so this cast is always lossless.
>> - value as u8
>> + match value {
>> + Architecture::Turing => Bounded::<u32, 6>::new::<0x16>(),
>> + Architecture::Ampere => Bounded::<u32, 6>::new::<0x17>(),
>> + Architecture::Ada => Bounded::<u32, 6>::new::<0x19>(),
>
> Yikes.. this looks ugly.
Very ugly. This should be replaced by the `TryFrom` and `Into` derive
macros soon enough though (adding Jesung for visibility).
Another temporary solution would be to use `Bounded::from_expr` - in
this case we can turn this into a single statement. But since it is not
strictly a case where we cannot do without it, I preferred to eschew it.
>
>> + }
>> }
>> }
>>
>> pub(crate) struct Revision {
>> - major: u8,
>> - minor: u8,
>> + major: Bounded<u8, 4>,
>> + minor: Bounded<u8, 4>,
>> }
>>
>> impl From<regs::NV_PMC_BOOT_42> for Revision {
>> fn from(boot0: regs::NV_PMC_BOOT_42) -> Self {
>> Self {
>> - major: boot0.major_revision(),
>> - minor: boot0.minor_revision(),
>> + major: boot0.major_revision().cast(),
>> + minor: boot0.minor_revision().cast(),
>> }
>> }
>> }
>> @@ -208,13 +207,13 @@ fn new(dev: &device::Device, bar: &Bar0) -> Result<Spec> {
>> // from an earlier (pre-Fermi) era, and then using boot42 to precisely identify the GPU.
>> // Somewhere in the Rubin timeframe, boot0 will no longer have space to add new GPU IDs.
>>
>> - let boot0 = regs::NV_PMC_BOOT_0::read(bar);
>> + let boot0 = bar.read(regs::NV_PMC_BOOT_0);
>>
>> if boot0.is_older_than_fermi() {
>> return Err(ENODEV);
>> }
>>
>> - let boot42 = regs::NV_PMC_BOOT_42::read(bar);
>> + let boot42 = bar.read(regs::NV_PMC_BOOT_42);
>> Spec::try_from(boot42).inspect_err(|_| {
>> dev_err!(dev, "Unsupported chipset: {}\n", boot42);
>> })
>> diff --git a/drivers/gpu/nova-core/regs.rs b/drivers/gpu/nova-core/regs.rs
>> index 53f412f0ca32..62c2065e63ef 100644
>> --- a/drivers/gpu/nova-core/regs.rs
>> +++ b/drivers/gpu/nova-core/regs.rs
>> @@ -35,20 +35,64 @@
>> num::FromSafeCast,
>> };
>>
>> +// All nova-core registers are 32-bit and `pub(crate)`. Wrap the `register!` macro to avoid
>> +// repeating this information for every register.
>> +macro_rules! nv_reg {
>> + (
>> + $(
>> + $(#[$attr:meta])* $name:ident $([ $size:expr $(, stride = $stride:expr)? ])?
>> + $(@ $offset:literal)?
>> + $(@ $base:ident + $base_offset:literal)?
>> + $(=> $alias:ident $(+ $alias_offset:ident)? $([$alias_idx:expr])? )?
>> + $(, $comment:literal)? { $($fields:tt)* }
>> + )*
>> + )=> {
>> + $(
>> + ::kernel::io::register!(
>> + @reg $(#[$attr])* pub(crate) $name(u32) $([$size $(, stride = $stride)?])?
>> + $(@ $offset)?
>> + $(@ $base + $base_offset)?
>> + $(=> $alias $(+ $alias_offset)? $([$alias_idx])? )?
>> + $(, $comment)? { $($fields)* }
>> + );
>> + )*
>> + };
>> +}
>> +
>> // PMC
>>
>> -register!(NV_PMC_BOOT_0 @ 0x00000000, "Basic revision information about the GPU" {
>> - 3:0 minor_revision as u8, "Minor revision of the chip";
>> - 7:4 major_revision as u8, "Major revision of the chip";
>> - 8:8 architecture_1 as u8, "MSB of the architecture";
>> - 23:20 implementation as u8, "Implementation version of the architecture";
>> - 28:24 architecture_0 as u8, "Lower bits of the architecture";
>> -});
>> +nv_reg! {
>> + /// Basic revision information about the GPU.
>> + NV_PMC_BOOT_0 @ 0x00000000 {
>> + /// Minor revision of the chip.
>> + 3:0 minor_revision;
>> + /// Major revision of the chip.
>> + 7:4 major_revision;
>> + /// MSB of the architecture.
>> + 8:8 architecture_1;
>> + /// Implementation version of the architecture.
>> + 23:20 implementation;
>> + /// Lower bits of the architecture.
>> + 28:24 architecture_0;
>> + }
>> +
>> + /// Extended architecture information.
>> + NV_PMC_BOOT_42 @ 0x00000a00 {
>> + /// Minor revision of the chip.
>> + 15:12 minor_revision;
>> + /// Major revision of the chip.
>> + 19:16 major_revision;
>> + /// Implementation version of the architecture.
>> + 23:20 implementation;
>> + /// Architecture value.
>> + 29:24 architecture ?=> Architecture;
>> + }
>> +}
>>
>> impl NV_PMC_BOOT_0 {
>> pub(crate) fn is_older_than_fermi(self) -> bool {
>> // From https://github.com/NVIDIA/open-gpu-doc/tree/master/manuals :
>> - const NV_PMC_BOOT_0_ARCHITECTURE_GF100: u8 = 0xc;
>> + const NV_PMC_BOOT_0_ARCHITECTURE_GF100: u32 = 0xc;
>>
>> // Older chips left arch1 zeroed out. That, combined with an arch0 value that is less than
>> // GF100, means "older than Fermi".
>> @@ -56,13 +100,6 @@ pub(crate) fn is_older_than_fermi(self) -> bool {
>> }
>> }
>>
>> -register!(NV_PMC_BOOT_42 @ 0x00000a00, "Extended architecture information" {
>> - 15:12 minor_revision as u8, "Minor revision of the chip";
>> - 19:16 major_revision as u8, "Major revision of the chip";
>> - 23:20 implementation as u8, "Implementation version of the architecture";
>> - 29:24 architecture as u8 ?=> Architecture, "Architecture value";
>> -});
>> -
>> impl NV_PMC_BOOT_42 {
>> /// Combines `architecture` and `implementation` to obtain a code unique to the chipset.
>> pub(crate) fn chipset(self) -> Result<Chipset> {
>> @@ -76,8 +113,8 @@ pub(crate) fn chipset(self) -> Result<Chipset> {
>>
>> /// Returns the raw architecture value from the register.
>> fn architecture_raw(self) -> u8 {
>> - ((self.0 >> Self::ARCHITECTURE_RANGE.start()) & ((1 << Self::ARCHITECTURE_RANGE.len()) - 1))
>> - as u8
>> + ((self.inner >> Self::ARCHITECTURE_RANGE.start())
>
> This should be using `self.into_raw()` rather than accessing the `inner` field
> directly (which should be considered impl detail of the macro).
Indeed - done.
^ permalink raw reply
* Re: [PATCH v2 11/16] staging: vme_user: replace deprecated mmap hook with mmap_prepare
From: Lorenzo Stoakes (Oracle) @ 2026-03-19 14:54 UTC (permalink / raw)
To: Suren Baghdasaryan
Cc: Andrew Morton, Jonathan Corbet, Clemens Ladisch, Arnd Bergmann,
Greg Kroah-Hartman, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Bodo Stroesser, Martin K . Petersen,
David Howells, Marc Dionne, Alexander Viro, Christian Brauner,
Jan Kara, David Hildenbrand, Liam R . Howlett, Vlastimil Babka,
Mike Rapoport, Michal Hocko, Jann Horn, Pedro Falcato,
linux-kernel, linux-doc, linux-hyperv, linux-stm32,
linux-arm-kernel, linux-mtd, linux-staging, linux-scsi,
target-devel, linux-afs, linux-fsdevel, linux-mm, Ryan Roberts
In-Reply-To: <CAJuCfpE5qZmi43EeZiRcy78pD6YvJb5n_xnoUJfwEjomowu0=A@mail.gmail.com>
On Tue, Mar 17, 2026 at 02:32:16PM -0700, Suren Baghdasaryan wrote:
> On Tue, Mar 17, 2026 at 2:26 PM Suren Baghdasaryan <surenb@google.com> wrote:
> >
> > On Mon, Mar 16, 2026 at 2:14 PM Lorenzo Stoakes (Oracle) <ljs@kernel.org> wrote:
> > >
> > > The f_op->mmap interface is deprecated, so update driver to use its
> > > successor, mmap_prepare.
> > >
> > > The driver previously used vm_iomap_memory(), so this change replaces it
> > > with its mmap_prepare equivalent, mmap_action_simple_ioremap().
> > >
> > > Functions that wrap mmap() are also converted to wrap mmap_prepare()
> > > instead.
> > >
> > > Also update the documentation accordingly.
> > >
> > > Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
> > > ---
> > > Documentation/driver-api/vme.rst | 2 +-
> > > drivers/staging/vme_user/vme.c | 20 +++++------
> > > drivers/staging/vme_user/vme.h | 2 +-
> > > drivers/staging/vme_user/vme_user.c | 51 +++++++++++++++++------------
> > > 4 files changed, 42 insertions(+), 33 deletions(-)
> > >
> > > diff --git a/Documentation/driver-api/vme.rst b/Documentation/driver-api/vme.rst
> > > index c0b475369de0..7111999abc14 100644
> > > --- a/Documentation/driver-api/vme.rst
> > > +++ b/Documentation/driver-api/vme.rst
> > > @@ -107,7 +107,7 @@ The function :c:func:`vme_master_read` can be used to read from and
> > >
> > > In addition to simple reads and writes, :c:func:`vme_master_rmw` is provided to
> > > do a read-modify-write transaction. Parts of a VME window can also be mapped
> > > -into user space memory using :c:func:`vme_master_mmap`.
> > > +into user space memory using :c:func:`vme_master_mmap_prepare`.
> > >
> > >
> > > Slave windows
> > > diff --git a/drivers/staging/vme_user/vme.c b/drivers/staging/vme_user/vme.c
> > > index f10a00c05f12..7220aba7b919 100644
> > > --- a/drivers/staging/vme_user/vme.c
> > > +++ b/drivers/staging/vme_user/vme.c
> > > @@ -735,9 +735,9 @@ unsigned int vme_master_rmw(struct vme_resource *resource, unsigned int mask,
> > > EXPORT_SYMBOL(vme_master_rmw);
> > >
> > > /**
> > > - * vme_master_mmap - Mmap region of VME master window.
> > > + * vme_master_mmap_prepare - Mmap region of VME master window.
> > > * @resource: Pointer to VME master resource.
> > > - * @vma: Pointer to definition of user mapping.
> > > + * @desc: Pointer to descriptor of user mapping.
> > > *
> > > * Memory map a region of the VME master window into user space.
> > > *
> > > @@ -745,12 +745,13 @@ EXPORT_SYMBOL(vme_master_rmw);
> > > * resource or -EFAULT if map exceeds window size. Other generic mmap
> > > * errors may also be returned.
> > > */
> > > -int vme_master_mmap(struct vme_resource *resource, struct vm_area_struct *vma)
> > > +int vme_master_mmap_prepare(struct vme_resource *resource,
> > > + struct vm_area_desc *desc)
> > > {
> > > + const unsigned long vma_size = vma_desc_size(desc);
> > > struct vme_bridge *bridge = find_bridge(resource);
> > > struct vme_master_resource *image;
> > > phys_addr_t phys_addr;
> > > - unsigned long vma_size;
> > >
> > > if (resource->type != VME_MASTER) {
> > > dev_err(bridge->parent, "Not a master resource\n");
> > > @@ -758,19 +759,18 @@ int vme_master_mmap(struct vme_resource *resource, struct vm_area_struct *vma)
> > > }
> > >
> > > image = list_entry(resource->entry, struct vme_master_resource, list);
> > > - phys_addr = image->bus_resource.start + (vma->vm_pgoff << PAGE_SHIFT);
> > > - vma_size = vma->vm_end - vma->vm_start;
> > > + phys_addr = image->bus_resource.start + (desc->pgoff << PAGE_SHIFT);
> > >
> > > if (phys_addr + vma_size > image->bus_resource.end + 1) {
> > > dev_err(bridge->parent, "Map size cannot exceed the window size\n");
> > > return -EFAULT;
> > > }
> > >
> > > - vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> > > -
> > > - return vm_iomap_memory(vma, phys_addr, vma->vm_end - vma->vm_start);
> > > + desc->page_prot = pgprot_noncached(desc->page_prot);
> > > + mmap_action_simple_ioremap(desc, phys_addr, vma_size);
> > > + return 0;
> > > }
> > > -EXPORT_SYMBOL(vme_master_mmap);
> > > +EXPORT_SYMBOL(vme_master_mmap_prepare);
> > >
> > > /**
> > > * vme_master_free - Free VME master window
> > > diff --git a/drivers/staging/vme_user/vme.h b/drivers/staging/vme_user/vme.h
> > > index 797e9940fdd1..b6413605ea49 100644
> > > --- a/drivers/staging/vme_user/vme.h
> > > +++ b/drivers/staging/vme_user/vme.h
> > > @@ -151,7 +151,7 @@ ssize_t vme_master_read(struct vme_resource *resource, void *buf, size_t count,
> > > ssize_t vme_master_write(struct vme_resource *resource, void *buf, size_t count, loff_t offset);
> > > unsigned int vme_master_rmw(struct vme_resource *resource, unsigned int mask, unsigned int compare,
> > > unsigned int swap, loff_t offset);
> > > -int vme_master_mmap(struct vme_resource *resource, struct vm_area_struct *vma);
> > > +int vme_master_mmap_prepare(struct vme_resource *resource, struct vm_area_desc *desc);
> > > void vme_master_free(struct vme_resource *resource);
> > >
> > > struct vme_resource *vme_dma_request(struct vme_dev *vdev, u32 route);
> > > diff --git a/drivers/staging/vme_user/vme_user.c b/drivers/staging/vme_user/vme_user.c
> > > index d95dd7d9190a..11e25c2f6b0a 100644
> > > --- a/drivers/staging/vme_user/vme_user.c
> > > +++ b/drivers/staging/vme_user/vme_user.c
> > > @@ -446,24 +446,14 @@ static void vme_user_vm_close(struct vm_area_struct *vma)
> > > kfree(vma_priv);
> > > }
> > >
> > > -static const struct vm_operations_struct vme_user_vm_ops = {
> > > - .open = vme_user_vm_open,
> > > - .close = vme_user_vm_close,
> > > -};
> > > -
> > > -static int vme_user_master_mmap(unsigned int minor, struct vm_area_struct *vma)
> > > +static int vme_user_vm_mapped(unsigned long start, unsigned long end, pgoff_t pgoff,
> > > + const struct file *file, void **vm_private_data)
> > > {
> > > - int err;
> > > + const unsigned int minor = iminor(file_inode(file));
> > > struct vme_user_vma_priv *vma_priv;
> > >
> > > mutex_lock(&image[minor].mutex);
> > >
> > > - err = vme_master_mmap(image[minor].resource, vma);
> > > - if (err) {
> > > - mutex_unlock(&image[minor].mutex);
> > > - return err;
> > > - }
> > > -
> >
> > Ok, this changes the set of the operations performed under image[minor].mutex.
> > Before we had:
> >
> > mutex_lock(&image[minor].mutex);
> > vme_master_mmap();
> > <some final adjustments>
> > mutex_unlock(&image[minor].mutex);
> >
> > Now we have:
> >
> > mutex_lock(&image[minor].mutex);
> > vme_master_mmap_prepare()
> > mutex_unlock(&image[minor].mutex);
> > vm_iomap_memory();
> > mutex_lock(&image[minor].mutex);
> > vme_user_vm_mapped(); // <some final adjustments>
> > mutex_unlock(&image[minor].mutex);
> >
> > I think as long as image[minor] does not change while we are not
> > holding the mutex we should be safe, and looking at the code it seems
> > to be the case. But I'm not familiar with this driver and might be
> > wrong. Worth double-checking.
The file is pinned for the duration, the mutex is associated with the file,
so there's no sane world in which that could be problematic.
Keeping in mind that we manipulate stuff on vme_user_vm_close() that
directly acceses image[minor] at an arbitary time.
>
> A side note: if we had to hold the mutex across all those operations I
> think we would need to take the mutex in the vm_ops->mmap_prepare and
> add a vm_ops->map_failed hook or something along that line to drop the
> mutex in case mmap_action_complete() fails. Not sure if we will have
> such cases though...
No, I don't want to do this if it can be at all avoided. You should in
nearly any sane circumstance be able to defer things until the mapped hook
anyway.
Also a merge can happen too after an .mmap_prepare, so we'd have to have
some 'success' hook and I'm just not going there it'll end up open to abuse
again.
(We do have success and error filtering hooks right now, sadly, but they're
really for hugetlb and I plan to find a way to get rid of them).
The mmap_prepare is meant to essentially be as stateless as possible.
Anyway I don't think it's relevant here.
>
> >
> > > vma_priv = kmalloc_obj(*vma_priv);
> > > if (!vma_priv) {
> > > mutex_unlock(&image[minor].mutex);
> > > @@ -472,22 +462,41 @@ static int vme_user_master_mmap(unsigned int minor, struct vm_area_struct *vma)
> > >
> > > vma_priv->minor = minor;
> > > refcount_set(&vma_priv->refcnt, 1);
> > > - vma->vm_ops = &vme_user_vm_ops;
> > > - vma->vm_private_data = vma_priv;
> > > -
> > > + *vm_private_data = vma_priv;
> > > image[minor].mmap_count++;
> > >
> > > mutex_unlock(&image[minor].mutex);
> > > -
> > > return 0;
> > > }
> > >
> > > -static int vme_user_mmap(struct file *file, struct vm_area_struct *vma)
> > > +static const struct vm_operations_struct vme_user_vm_ops = {
> > > + .mapped = vme_user_vm_mapped,
> > > + .open = vme_user_vm_open,
> > > + .close = vme_user_vm_close,
> > > +};
> > > +
> > > +static int vme_user_master_mmap_prepare(unsigned int minor,
> > > + struct vm_area_desc *desc)
> > > +{
> > > + int err;
> > > +
> > > + mutex_lock(&image[minor].mutex);
> > > +
> > > + err = vme_master_mmap_prepare(image[minor].resource, desc);
> > > + if (!err)
> > > + desc->vm_ops = &vme_user_vm_ops;
> > > +
> > > + mutex_unlock(&image[minor].mutex);
> > > + return err;
> > > +}
> > > +
> > > +static int vme_user_mmap_prepare(struct vm_area_desc *desc)
> > > {
> > > - unsigned int minor = iminor(file_inode(file));
> > > + const struct file *file = desc->file;
> > > + const unsigned int minor = iminor(file_inode(file));
> > >
> > > if (type[minor] == MASTER_MINOR)
> > > - return vme_user_master_mmap(minor, vma);
> > > + return vme_user_master_mmap_prepare(minor, desc);
> > >
> > > return -ENODEV;
> > > }
> > > @@ -498,7 +507,7 @@ static const struct file_operations vme_user_fops = {
> > > .llseek = vme_user_llseek,
> > > .unlocked_ioctl = vme_user_unlocked_ioctl,
> > > .compat_ioctl = compat_ptr_ioctl,
> > > - .mmap = vme_user_mmap,
> > > + .mmap_prepare = vme_user_mmap_prepare,
> > > };
> > >
> > > static int vme_user_match(struct vme_dev *vdev)
> > > --
> > > 2.53.0
> > >
Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH v2 15/16] mm: add mmap_action_map_kernel_pages[_full]()
From: Lorenzo Stoakes (Oracle) @ 2026-03-19 15:05 UTC (permalink / raw)
To: Suren Baghdasaryan
Cc: Andrew Morton, Jonathan Corbet, Clemens Ladisch, Arnd Bergmann,
Greg Kroah-Hartman, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Bodo Stroesser, Martin K . Petersen,
David Howells, Marc Dionne, Alexander Viro, Christian Brauner,
Jan Kara, David Hildenbrand, Liam R . Howlett, Vlastimil Babka,
Mike Rapoport, Michal Hocko, Jann Horn, Pedro Falcato,
linux-kernel, linux-doc, linux-hyperv, linux-stm32,
linux-arm-kernel, linux-mtd, linux-staging, linux-scsi,
target-devel, linux-afs, linux-fsdevel, linux-mm, Ryan Roberts
In-Reply-To: <CAJuCfpF6eS18HLgNvQtkLGd=7N0_L1JPmF0GzM-Z0QimRWT7AQ@mail.gmail.com>
On Wed, Mar 18, 2026 at 09:00:13AM -0700, Suren Baghdasaryan wrote:
> On Mon, Mar 16, 2026 at 2:14 PM Lorenzo Stoakes (Oracle) <ljs@kernel.org> wrote:
> >
> > A user can invoke mmap_action_map_kernel_pages() to specify that the
> > mapping should map kernel pages starting from desc->start of a specified
> > number of pages specified in an array.
> >
> > In order to implement this, adjust mmap_action_prepare() to be able to
> > return an error code, as it makes sense to assert that the specified
> > parameters are valid as quickly as possible as well as updating the VMA
> > flags to include VMA_MIXEDMAP_BIT as necessary.
> >
> > This provides an mmap_prepare equivalent of vm_insert_pages().
> >
> > We additionally update the existing vm_insert_pages() code to use
> > range_in_vma() and add a new range_in_vma_desc() helper function for the
> > mmap_prepare case, sharing the code between the two in range_is_subset().
> >
> > We add both mmap_action_map_kernel_pages() and
> > mmap_action_map_kernel_pages_full() to allow for both partial and full VMA
> > mappings.
> >
> > We also add mmap_action_map_kernel_pages_discontig() to allow for
> > discontiguous mapping of kernel pages should the need arise.
> >
> > We update the documentation to reflect the new features.
> >
> > Finally, we update the VMA tests accordingly to reflect the changes.
> >
> > Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
>
> With one nit,
> Reviewed-by: Suren Baghdasaryan <surenb@google.com>
Thanks!
>
> > ---
> > Documentation/filesystems/mmap_prepare.rst | 8 ++
> > include/linux/mm.h | 95 +++++++++++++++++++++-
> > include/linux/mm_types.h | 7 ++
> > mm/memory.c | 42 +++++++++-
> > mm/util.c | 6 ++
> > tools/testing/vma/include/dup.h | 7 ++
> > 6 files changed, 159 insertions(+), 6 deletions(-)
> >
> > diff --git a/Documentation/filesystems/mmap_prepare.rst b/Documentation/filesystems/mmap_prepare.rst
> > index be76ae475b9c..e810aa4134eb 100644
> > --- a/Documentation/filesystems/mmap_prepare.rst
> > +++ b/Documentation/filesystems/mmap_prepare.rst
> > @@ -156,5 +156,13 @@ pointer. These are:
> > * mmap_action_simple_ioremap() - Sets up an I/O remap from a specified
> > physical address and over a specified length.
> >
> > +* mmap_action_map_kernel_pages() - Maps a specified array of `struct page`
> > + pointers in the VMA from a specific offset.
> > +
> > +* mmap_action_map_kernel_pages_full() - Maps a specified array of `struct
> > + page` pointers over the entire VMA. The caller must ensure there are
> > + sufficient entries in the page array to cover the entire range of the
> > + described VMA.
> > +
> > **NOTE:** The ``action`` field should never normally be manipulated directly,
> > rather you ought to use one of these helpers.
> > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > index df8fa6e6402b..6f0a3edb24e1 100644
> > --- a/include/linux/mm.h
> > +++ b/include/linux/mm.h
> > @@ -2912,7 +2912,7 @@ static inline bool folio_maybe_mapped_shared(struct folio *folio)
> > * The caller must add any reference (e.g., from folio_try_get()) it might be
> > * holding itself to the result.
> > *
> > - * Returns the expected folio refcount.
> > + * Returns: the expected folio refcount.
>
> nit: I see both "Returns:" and "Return:" being used in the codebase
> but this header file uses "Return:", so for consistency you should
> probably do the same. This also applies to later instances in this
> patch.
Well here I'm just adding the colon, while I'm here (maybe have been an
update in response to feedback actualy).
And this function that's not part of my change already uses 'Returns' and
I'm pretty sure that's the correct form.
So I think not a big deal to keep using that?
>
> > */
> > static inline int folio_expected_ref_count(const struct folio *folio)
> > {
> > @@ -4364,6 +4364,45 @@ static inline void mmap_action_simple_ioremap(struct vm_area_desc *desc,
> > action->type = MMAP_SIMPLE_IO_REMAP;
> > }
> >
> > +/**
> > + * mmap_action_map_kernel_pages - helper for mmap_prepare hook to specify that
> > + * @num kernel pages contained in the @pages array should be mapped to userland
> > + * starting at virtual address @start.
> > + * @desc: The VMA descriptor for the VMA requiring kernel pags to be mapped.
> > + * @start: The virtual address from which to map them.
> > + * @pages: An array of struct page pointers describing the memory to map.
> > + * @nr_pages: The number of entries in the @pages aray.
> > + */
> > +static inline void mmap_action_map_kernel_pages(struct vm_area_desc *desc,
> > + unsigned long start, struct page **pages,
> > + unsigned long nr_pages)
> > +{
> > + struct mmap_action *action = &desc->action;
> > +
> > + action->type = MMAP_MAP_KERNEL_PAGES;
> > + action->map_kernel.start = start;
> > + action->map_kernel.pages = pages;
> > + action->map_kernel.nr_pages = nr_pages;
> > + action->map_kernel.pgoff = desc->pgoff;
> > +}
> > +
> > +/**
> > + * mmap_action_map_kernel_pages_full - helper for mmap_prepare hook to specify that
> > + * kernel pages contained in the @pages array should be mapped to userland
> > + * from @desc->start to @desc->end.
> > + * @desc: The VMA descriptor for the VMA requiring kernel pags to be mapped.
> > + * @pages: An array of struct page pointers describing the memory to map.
> > + *
> > + * The caller must ensure that @pages contains sufficient entries to cover the
> > + * entire range described by @desc.
> > + */
> > +static inline void mmap_action_map_kernel_pages_full(struct vm_area_desc *desc,
> > + struct page **pages)
> > +{
> > + mmap_action_map_kernel_pages(desc, desc->start, pages,
> > + vma_desc_pages(desc));
> > +}
> > +
> > int mmap_action_prepare(struct vm_area_desc *desc);
> > int mmap_action_complete(struct vm_area_struct *vma,
> > struct mmap_action *action);
> > @@ -4380,10 +4419,59 @@ static inline struct vm_area_struct *find_exact_vma(struct mm_struct *mm,
> > return vma;
> > }
> >
> > +/**
> > + * range_is_subset - Is the specified inner range a subset of the outer range?
> > + * @outer_start: The start of the outer range.
> > + * @outer_end: The exclusive end of the outer range.
> > + * @inner_start: The start of the inner range.
> > + * @inner_end: The exclusive end of the inner range.
> > + *
> > + * Returns: %true if [inner_start, inner_end) is a subset of [outer_start,
> > + * outer_end), otherwise %false.
> > + */
> > +static inline bool range_is_subset(unsigned long outer_start,
> > + unsigned long outer_end,
> > + unsigned long inner_start,
> > + unsigned long inner_end)
> > +{
> > + return outer_start <= inner_start && inner_end <= outer_end;
> > +}
> > +
> > +/**
> > + * range_in_vma - is the specified [@start, @end) range a subset of the VMA?
> > + * @vma: The VMA against which we want to check [@start, @end).
> > + * @start: The start of the range we wish to check.
> > + * @end: The exclusive end of the range we wish to check.
> > + *
> > + * Returns: %true if [@start, @end) is a subset of [@vma->vm_start,
> > + * @vma->vm_end), %false otherwise.
> > + */
> > static inline bool range_in_vma(const struct vm_area_struct *vma,
> > unsigned long start, unsigned long end)
> > {
> > - return (vma && vma->vm_start <= start && end <= vma->vm_end);
> > + if (!vma)
> > + return false;
> > +
> > + return range_is_subset(vma->vm_start, vma->vm_end, start, end);
> > +}
> > +
> > +/**
> > + * range_in_vma_desc - is the specified [@start, @end) range a subset of the VMA
> > + * described by @desc, a VMA descriptor?
> > + * @desc: The VMA descriptor against which we want to check [@start, @end).
> > + * @start: The start of the range we wish to check.
> > + * @end: The exclusive end of the range we wish to check.
> > + *
> > + * Returns: %true if [@start, @end) is a subset of [@desc->start, @desc->end),
> > + * %false otherwise.
> > + */
> > +static inline bool range_in_vma_desc(const struct vm_area_desc *desc,
> > + unsigned long start, unsigned long end)
> > +{
> > + if (!desc)
> > + return false;
> > +
> > + return range_is_subset(desc->start, desc->end, start, end);
> > }
> >
> > #ifdef CONFIG_MMU
> > @@ -4427,6 +4515,9 @@ int remap_pfn_range(struct vm_area_struct *vma, unsigned long addr,
> > int vm_insert_page(struct vm_area_struct *, unsigned long addr, struct page *);
> > int vm_insert_pages(struct vm_area_struct *vma, unsigned long addr,
> > struct page **pages, unsigned long *num);
> > +int map_kernel_pages_prepare(struct vm_area_desc *desc);
> > +int map_kernel_pages_complete(struct vm_area_struct *vma,
> > + struct mmap_action *action);
> > int vm_map_pages(struct vm_area_struct *vma, struct page **pages,
> > unsigned long num);
> > int vm_map_pages_zero(struct vm_area_struct *vma, struct page **pages,
> > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> > index 7538d64f8848..c46224020a46 100644
> > --- a/include/linux/mm_types.h
> > +++ b/include/linux/mm_types.h
> > @@ -815,6 +815,7 @@ enum mmap_action_type {
> > MMAP_REMAP_PFN, /* Remap PFN range. */
> > MMAP_IO_REMAP_PFN, /* I/O remap PFN range. */
> > MMAP_SIMPLE_IO_REMAP, /* I/O remap with guardrails. */
> > + MMAP_MAP_KERNEL_PAGES, /* Map kernel page range from array. */
> > };
> >
> > /*
> > @@ -833,6 +834,12 @@ struct mmap_action {
> > phys_addr_t start_phys_addr;
> > unsigned long size;
> > } simple_ioremap;
> > + struct {
> > + unsigned long start;
> > + struct page **pages;
> > + unsigned long nr_pages;
> > + pgoff_t pgoff;
> > + } map_kernel;
> > };
> > enum mmap_action_type type;
> >
> > diff --git a/mm/memory.c b/mm/memory.c
> > index f3f4046aee97..849d5d9eeb83 100644
> > --- a/mm/memory.c
> > +++ b/mm/memory.c
> > @@ -2484,13 +2484,14 @@ static int insert_pages(struct vm_area_struct *vma, unsigned long addr,
> > int vm_insert_pages(struct vm_area_struct *vma, unsigned long addr,
> > struct page **pages, unsigned long *num)
> > {
> > - const unsigned long end_addr = addr + (*num * PAGE_SIZE) - 1;
> > + const unsigned long nr_pages = *num;
> > + const unsigned long end = addr + PAGE_SIZE * nr_pages;
> >
> > - if (addr < vma->vm_start || end_addr >= vma->vm_end)
> > + if (!range_in_vma(vma, addr, end))
> > return -EFAULT;
> > if (!(vma->vm_flags & VM_MIXEDMAP)) {
> > - BUG_ON(mmap_read_trylock(vma->vm_mm));
> > - BUG_ON(vma->vm_flags & VM_PFNMAP);
> > + VM_WARN_ON_ONCE(mmap_read_trylock(vma->vm_mm));
> > + VM_WARN_ON_ONCE(vma->vm_flags & VM_PFNMAP);
> > vm_flags_set(vma, VM_MIXEDMAP);
> > }
> > /* Defer page refcount checking till we're about to map that page. */
> > @@ -2498,6 +2499,39 @@ int vm_insert_pages(struct vm_area_struct *vma, unsigned long addr,
> > }
> > EXPORT_SYMBOL(vm_insert_pages);
> >
> > +int map_kernel_pages_prepare(struct vm_area_desc *desc)
> > +{
> > + const struct mmap_action *action = &desc->action;
> > + const unsigned long addr = action->map_kernel.start;
> > + unsigned long nr_pages, end;
> > +
> > + if (!vma_desc_test(desc, VMA_MIXEDMAP_BIT)) {
> > + VM_WARN_ON_ONCE(mmap_read_trylock(desc->mm));
> > + VM_WARN_ON_ONCE(vma_desc_test(desc, VMA_PFNMAP_BIT));
> > + vma_desc_set_flags(desc, VMA_MIXEDMAP_BIT);
> > + }
> > +
> > + nr_pages = action->map_kernel.nr_pages;
> > + end = addr + PAGE_SIZE * nr_pages;
> > + if (!range_in_vma_desc(desc, addr, end))
> > + return -EFAULT;
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(map_kernel_pages_prepare);
> > +
> > +int map_kernel_pages_complete(struct vm_area_struct *vma,
> > + struct mmap_action *action)
> > +{
> > + unsigned long nr_pages;
> > +
> > + nr_pages = action->map_kernel.nr_pages;
> > + return insert_pages(vma, action->map_kernel.start,
> > + action->map_kernel.pages,
> > + &nr_pages, vma->vm_page_prot);
> > +}
> > +EXPORT_SYMBOL(map_kernel_pages_complete);
> > +
> > /**
> > * vm_insert_page - insert single page into user vma
> > * @vma: user vma to map to
> > diff --git a/mm/util.c b/mm/util.c
> > index a166c48fe894..dea590e7a26c 100644
> > --- a/mm/util.c
> > +++ b/mm/util.c
> > @@ -1441,6 +1441,8 @@ int mmap_action_prepare(struct vm_area_desc *desc)
> > return io_remap_pfn_range_prepare(desc);
> > case MMAP_SIMPLE_IO_REMAP:
> > return simple_ioremap_prepare(desc);
> > + case MMAP_MAP_KERNEL_PAGES:
> > + return map_kernel_pages_prepare(desc);
> > }
> >
> > WARN_ON_ONCE(1);
> > @@ -1472,6 +1474,9 @@ int mmap_action_complete(struct vm_area_struct *vma,
> > case MMAP_IO_REMAP_PFN:
> > err = io_remap_pfn_range_complete(vma, action);
> > break;
> > + case MMAP_MAP_KERNEL_PAGES:
> > + err = map_kernel_pages_complete(vma, action);
> > + break;
> > case MMAP_SIMPLE_IO_REMAP:
> > /*
> > * The simple I/O remap should have been delegated to an I/O
> > @@ -1494,6 +1499,7 @@ int mmap_action_prepare(struct vm_area_desc *desc)
> > case MMAP_REMAP_PFN:
> > case MMAP_IO_REMAP_PFN:
> > case MMAP_SIMPLE_IO_REMAP:
> > + case MMAP_MAP_KERNEL_PAGES:
> > WARN_ON_ONCE(1); /* nommu cannot handle these. */
> > break;
> > }
> > diff --git a/tools/testing/vma/include/dup.h b/tools/testing/vma/include/dup.h
> > index 6658df26698a..4407caf207ad 100644
> > --- a/tools/testing/vma/include/dup.h
> > +++ b/tools/testing/vma/include/dup.h
> > @@ -454,6 +454,7 @@ enum mmap_action_type {
> > MMAP_REMAP_PFN, /* Remap PFN range. */
> > MMAP_IO_REMAP_PFN, /* I/O remap PFN range. */
> > MMAP_SIMPLE_IO_REMAP, /* I/O remap with guardrails. */
> > + MMAP_MAP_KERNEL_PAGES, /* Map kernel page range from an array. */
> > };
> >
> > /*
> > @@ -472,6 +473,12 @@ struct mmap_action {
> > phys_addr_t start;
> > unsigned long len;
> > } simple_ioremap;
> > + struct {
> > + unsigned long start;
> > + struct page **pages;
> > + unsigned long num;
> > + pgoff_t pgoff;
> > + } map_kernel;
> > };
> > enum mmap_action_type type;
> >
> > --
> > 2.53.0
> >
^ permalink raw reply
* Re: [PATCH v2 12/16] mm: allow handling of stacked mmap_prepare hooks in more drivers
From: Lorenzo Stoakes (Oracle) @ 2026-03-19 15:10 UTC (permalink / raw)
To: Suren Baghdasaryan
Cc: Andrew Morton, Jonathan Corbet, Clemens Ladisch, Arnd Bergmann,
Greg Kroah-Hartman, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Bodo Stroesser, Martin K . Petersen,
David Howells, Marc Dionne, Alexander Viro, Christian Brauner,
Jan Kara, David Hildenbrand, Liam R . Howlett, Vlastimil Babka,
Mike Rapoport, Michal Hocko, Jann Horn, Pedro Falcato,
linux-kernel, linux-doc, linux-hyperv, linux-stm32,
linux-arm-kernel, linux-mtd, linux-staging, linux-scsi,
target-devel, linux-afs, linux-fsdevel, linux-mm, Ryan Roberts
In-Reply-To: <CAJuCfpFr8_uU28S=v7y74Opa4L_4s9J70NgUXg1WGmraDhsxRA@mail.gmail.com>
On Wed, Mar 18, 2026 at 08:33:28AM -0700, Suren Baghdasaryan wrote:
> On Mon, Mar 16, 2026 at 2:14 PM Lorenzo Stoakes (Oracle) <ljs@kernel.org> wrote:
> >
> > While the conversion of mmap hooks to mmap_prepare is underway, we wil
>
> nit: s/wil/will
Thanks, fixed.
>
> > encounter situations where mmap hooks need to invoke nested mmap_prepare
> > hooks.
> >
> > The nesting of mmap hooks is termed 'stacking'. In order to flexibly
> > facilitate the conversion of custom mmap hooks in drivers which stack, we
> > must split up the existing compat_vma_mapped() function into two separate
> > functions:
> >
> > * compat_set_desc_from_vma() - This allows the setting of a vm_area_desc
> > object's fields to the relevant fields of a VMA.
> >
> > * __compat_vma_mmap() - Once an mmap_prepare hook has been executed upon a
> > vm_area_desc object, this function performs any mmap actions specified by
> > the mmap_prepare hook and then invokes its vm_ops->mapped() hook if any
> > were specified.
> >
> > In ordinary cases, where a file's f_op->mmap_prepare() hook simply needs to
> > be invoked in a stacked mmap() hook, compat_vma_mmap() can be used.
> >
> > However some drivers define their own nested hooks, which are invoked in
> > turn by another hook.
> >
> > A concrete example is vmbus_channel->mmap_ring_buffer(), which is invoked
> > in turn by bin_attribute->mmap():
> >
> > vmbus_channel->mmap_ring_buffer() has a signature of:
> >
> > int (*mmap_ring_buffer)(struct vmbus_channel *channel,
> > struct vm_area_struct *vma);
> >
> > And bin_attribute->mmap() has a signature of:
> >
> > int (*mmap)(struct file *, struct kobject *,
> > const struct bin_attribute *attr,
> > struct vm_area_struct *vma);
> >
> > And so compat_vma_mmap() cannot be used here for incremental conversion of
> > hooks from mmap() to mmap_prepare().
> >
> > There are many such instances like this, where conversion to mmap_prepare
> > would otherwise cascade to a huge change set due to nesting of this kind.
> >
> > The changes in this patch mean we could now instead convert
> > vmbus_channel->mmap_ring_buffer() to
> > vmbus_channel->mmap_prepare_ring_buffer(), and implement something like:
> >
> > struct vm_area_desc desc;
> > int err;
> >
> > compat_set_desc_from_vm(&desc, file, vma);
> > err = channel->mmap_prepare_ring_buffer(channel, &desc);
> > if (err)
> > return err;
> >
> > return __compat_vma_mmap(&desc, vma);
> >
> > Allowing us to incrementally update this logic, and other logic like it.
>
> The way I understand this and the next 2 patches is that they are
> preperations for later replacement of mmap() with mmap_prepare() but
> they don't yet do that completely. Is that right?
> To clarify what I mean, in [1] for example, you are replacing struct
> uio_info.mmap with uio_info.mmap_prepare but it's still being called
> from uio_mmap(). IOW, you are not replacing uio_mmap with
> uio_mmap_prepare. Is that the next step that's not yet implemented?
Yeah, there were 12 more patches I didn't send :) because I feel they'd
make more sense separate and wanted to test/develop them more.
This is all laying the groundwork for having mmap_prepare DMA cache
mappings ultimately, while expanding functionality as we go.
The intent here though isn't _just_ that, it's more - in general - when we
have an e.g.:
int some_special_mmap(struct some_type *blah, struct file *filp /* sometimes */,
struct vm_area_struct *vma)
{
...
}
Or some say custom ops for something like this, where in the existing code
callers hook .mmap(), grab some specific struct (like a device pointer or a
state pointer) from the file private data and then delegate to another
helper.
In this situation, we are able to use the compatibility layer to change say
the ops to be .mmap_prepare instead while the overarching caller is .mmap.
This allows for iterative conversion to .mmap_prepare without having to
amend 100 files at once in a multi-thousand line patch touching dozens of
drivers or some hellish notion like that.
This is vital to sensibly being able to implement these changes bit-by-bit.
Cheers, Lorenzo
>
> [1] https://lore.kernel.org/all/892a8b32e5ef64c69239ccc2d1bd364716fd7fdf.1773695307.git.ljs@kernel.org/
>
> >
> > Unfortunately, as part of this change, we need to be able to flexibly
> > assign to the VMA descriptor, so have to remove some of the const
> > declarations within the structure.
> >
> > Also update the VMA tests to reflect the changes.
> >
> > Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
> > ---
> > include/linux/fs.h | 3 +
> > include/linux/mm_types.h | 4 +-
> > mm/util.c | 111 +++++++++++++++++++++++---------
> > mm/vma.h | 2 +-
> > tools/testing/vma/include/dup.h | 111 ++++++++++++++++++++------------
> > 5 files changed, 157 insertions(+), 74 deletions(-)
> >
> > diff --git a/include/linux/fs.h b/include/linux/fs.h
> > index c390f5c667e3..0bdccfa70b44 100644
> > --- a/include/linux/fs.h
> > +++ b/include/linux/fs.h
> > @@ -2058,6 +2058,9 @@ static inline bool can_mmap_file(struct file *file)
> > return true;
> > }
> >
> > +void compat_set_desc_from_vma(struct vm_area_desc *desc, const struct file *file,
> > + const struct vm_area_struct *vma);
> > +int __compat_vma_mmap(struct vm_area_desc *desc, struct vm_area_struct *vma);
> > int compat_vma_mmap(struct file *file, struct vm_area_struct *vma);
> > int __vma_check_mmap_hook(struct vm_area_struct *vma);
> >
> > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> > index 50685cf29792..7538d64f8848 100644
> > --- a/include/linux/mm_types.h
> > +++ b/include/linux/mm_types.h
> > @@ -891,8 +891,8 @@ static __always_inline bool vma_flags_empty(vma_flags_t *flags)
> > */
> > struct vm_area_desc {
> > /* Immutable state. */
> > - const struct mm_struct *const mm;
> > - struct file *const file; /* May vary from vm_file in stacked callers. */
> > + struct mm_struct *mm;
> > + struct file *file; /* May vary from vm_file in stacked callers. */
> > unsigned long start;
> > unsigned long end;
> >
> > diff --git a/mm/util.c b/mm/util.c
> > index aa92e471afe1..a166c48fe894 100644
> > --- a/mm/util.c
> > +++ b/mm/util.c
> > @@ -1163,34 +1163,38 @@ void flush_dcache_folio(struct folio *folio)
> > EXPORT_SYMBOL(flush_dcache_folio);
> > #endif
> >
> > -static int __compat_vma_mmap(struct file *file, struct vm_area_struct *vma)
> > +/**
> > + * compat_set_desc_from_vma() - assigns VMA descriptor @desc fields from a VMA.
> > + * @desc: A VMA descriptor whose fields need to be set.
> > + * @file: The file object describing the file being mmap()'d.
> > + * @vma: The VMA whose fields we wish to assign to @desc.
> > + *
> > + * This is a compatibility function to allow an mmap() hook to call
> > + * mmap_prepare() hooks when drivers nest these. This function specifically
> > + * allows the construction of a vm_area_desc value, @desc, from a VMA @vma for
> > + * the purposes of doing this.
> > + *
> > + * Once the conversion of drivers is complete this function will no longer be
> > + * required and will be removed.
> > + */
> > +void compat_set_desc_from_vma(struct vm_area_desc *desc,
> > + const struct file *file,
> > + const struct vm_area_struct *vma)
> > {
> > - struct vm_area_desc desc = {
> > - .mm = vma->vm_mm,
> > - .file = file,
> > - .start = vma->vm_start,
> > - .end = vma->vm_end,
> > -
> > - .pgoff = vma->vm_pgoff,
> > - .vm_file = vma->vm_file,
> > - .vma_flags = vma->flags,
> > - .page_prot = vma->vm_page_prot,
> > -
> > - .action.type = MMAP_NOTHING, /* Default */
> > - };
> > - int err;
> > + desc->mm = vma->vm_mm;
> > + desc->file = (struct file *)file;
> > + desc->start = vma->vm_start;
> > + desc->end = vma->vm_end;
> >
> > - err = vfs_mmap_prepare(file, &desc);
> > - if (err)
> > - return err;
> > + desc->pgoff = vma->vm_pgoff;
> > + desc->vm_file = vma->vm_file;
> > + desc->vma_flags = vma->flags;
> > + desc->page_prot = vma->vm_page_prot;
> >
> > - err = mmap_action_prepare(&desc);
> > - if (err)
> > - return err;
> > -
> > - set_vma_from_desc(vma, &desc);
> > - return mmap_action_complete(vma, &desc.action);
> > + /* Default. */
> > + desc->action.type = MMAP_NOTHING;
> > }
> > +EXPORT_SYMBOL(compat_set_desc_from_vma);
> >
> > static int __compat_vma_mapped(struct file *file, struct vm_area_struct *vma)
> > {
> > @@ -1211,6 +1215,49 @@ static int __compat_vma_mapped(struct file *file, struct vm_area_struct *vma)
> > return err;
> > }
> >
> > +/**
> > + * __compat_vma_mmap() - Similar to compat_vma_mmap(), only it allows
> > + * flexibility as to how the mmap_prepare callback is invoked, which is useful
> > + * for drivers which invoke nested mmap_prepare callbacks in an mmap() hook.
> > + * @desc: A VMA descriptor upon which an mmap_prepare() hook has already been
> > + * executed.
> > + * @vma: The VMA to which @desc should be applied.
> > + *
> > + * The function assumes that you have obtained a VMA descriptor @desc from
> > + * compt_set_desc_from_vma(), and already executed the mmap_prepare() hook upon
> > + * it.
> > + *
> > + * It then performs any specified mmap actions, and invokes the vm_ops->mapped()
> > + * hook if one is present.
> > + *
> > + * See the description of compat_vma_mmap() for more details.
> > + *
> > + * Once the conversion of drivers is complete this function will no longer be
> > + * required and will be removed.
> > + *
> > + * Returns: 0 on success or error.
> > + */
> > +int __compat_vma_mmap(struct vm_area_desc *desc,
> > + struct vm_area_struct *vma)
> > +{
> > + int err;
> > +
> > + /* Perform any preparatory tasks for mmap action. */
> > + err = mmap_action_prepare(desc);
> > + if (err)
> > + return err;
> > + /* Update the VMA from the descriptor. */
> > + compat_set_vma_from_desc(vma, desc);
> > + /* Complete any specified mmap actions. */
> > + err = mmap_action_complete(vma, &desc->action);
> > + if (err)
> > + return err;
> > +
> > + /* Invoke vm_ops->mapped callback. */
> > + return __compat_vma_mapped(desc->file, vma);
> > +}
> > +EXPORT_SYMBOL(__compat_vma_mmap);
> > +
> > /**
> > * compat_vma_mmap() - Apply the file's .mmap_prepare() hook to an
> > * existing VMA and execute any requested actions.
> > @@ -1218,10 +1265,10 @@ static int __compat_vma_mapped(struct file *file, struct vm_area_struct *vma)
> > * @vma: The VMA to apply the .mmap_prepare() hook to.
> > *
> > * Ordinarily, .mmap_prepare() is invoked directly upon mmap(). However, certain
> > - * stacked filesystems invoke a nested mmap hook of an underlying file.
> > + * stacked drivers invoke a nested mmap hook of an underlying file.
> > *
> > - * Until all filesystems are converted to use .mmap_prepare(), we must be
> > - * conservative and continue to invoke these stacked filesystems using the
> > + * Until all drivers are converted to use .mmap_prepare(), we must be
> > + * conservative and continue to invoke these stacked drivers using the
> > * deprecated .mmap() hook.
> > *
> > * However we have a problem if the underlying file system possesses an
> > @@ -1232,20 +1279,22 @@ static int __compat_vma_mapped(struct file *file, struct vm_area_struct *vma)
> > * establishes a struct vm_area_desc descriptor, passes to the underlying
> > * .mmap_prepare() hook and applies any changes performed by it.
> > *
> > - * Once the conversion of filesystems is complete this function will no longer
> > - * be required and will be removed.
> > + * Once the conversion of drivers is complete this function will no longer be
> > + * required and will be removed.
> > *
> > * Returns: 0 on success or error.
> > */
> > int compat_vma_mmap(struct file *file, struct vm_area_struct *vma)
> > {
> > + struct vm_area_desc desc;
> > int err;
> >
> > - err = __compat_vma_mmap(file, vma);
> > + compat_set_desc_from_vma(&desc, file, vma);
> > + err = vfs_mmap_prepare(file, &desc);
> > if (err)
> > return err;
> >
> > - return __compat_vma_mapped(file, vma);
> > + return __compat_vma_mmap(&desc, vma);
> > }
> > EXPORT_SYMBOL(compat_vma_mmap);
> >
> > diff --git a/mm/vma.h b/mm/vma.h
> > index adc18f7dd9f1..a76046c39b14 100644
> > --- a/mm/vma.h
> > +++ b/mm/vma.h
> > @@ -300,7 +300,7 @@ static inline int vma_iter_store_gfp(struct vma_iterator *vmi,
> > * f_op->mmap() but which might have an underlying file system which implements
> > * f_op->mmap_prepare().
> > */
> > -static inline void set_vma_from_desc(struct vm_area_struct *vma,
> > +static inline void compat_set_vma_from_desc(struct vm_area_struct *vma,
> > struct vm_area_desc *desc)
> > {
> > /*
> > diff --git a/tools/testing/vma/include/dup.h b/tools/testing/vma/include/dup.h
> > index 114daaef4f73..6658df26698a 100644
> > --- a/tools/testing/vma/include/dup.h
> > +++ b/tools/testing/vma/include/dup.h
> > @@ -519,8 +519,8 @@ enum vma_operation {
> > */
> > struct vm_area_desc {
> > /* Immutable state. */
> > - const struct mm_struct *const mm;
> > - struct file *const file; /* May vary from vm_file in stacked callers. */
> > + struct mm_struct *mm;
> > + struct file *file; /* May vary from vm_file in stacked callers. */
> > unsigned long start;
> > unsigned long end;
> >
> > @@ -1272,43 +1272,92 @@ static inline void vma_set_anonymous(struct vm_area_struct *vma)
> > }
> >
> > /* Declared in vma.h. */
> > -static inline void set_vma_from_desc(struct vm_area_struct *vma,
> > +static inline void compat_set_vma_from_desc(struct vm_area_struct *vma,
> > struct vm_area_desc *desc);
> >
> > -static inline int __compat_vma_mmap(const struct file_operations *f_op,
> > - struct file *file, struct vm_area_struct *vma)
> > +static inline void compat_set_desc_from_vma(struct vm_area_desc *desc,
> > + const struct file *file,
> > + const struct vm_area_struct *vma)
> > {
> > - struct vm_area_desc desc = {
> > - .mm = vma->vm_mm,
> > - .file = file,
> > - .start = vma->vm_start,
> > - .end = vma->vm_end,
> > + desc->mm = vma->vm_mm;
> > + desc->file = (struct file *)file;
> > + desc->start = vma->vm_start;
> > + desc->end = vma->vm_end;
> >
> > - .pgoff = vma->vm_pgoff,
> > - .vm_file = vma->vm_file,
> > - .vma_flags = vma->flags,
> > - .page_prot = vma->vm_page_prot,
> > + desc->pgoff = vma->vm_pgoff;
> > + desc->vm_file = vma->vm_file;
> > + desc->vma_flags = vma->flags;
> > + desc->page_prot = vma->vm_page_prot;
> >
> > - .action.type = MMAP_NOTHING, /* Default */
> > - };
> > + /* Default. */
> > + desc->action.type = MMAP_NOTHING;
> > +}
> > +
> > +static inline unsigned long vma_pages(const struct vm_area_struct *vma)
> > +{
> > + return (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
> > +}
> > +
> > +static inline void unmap_vma_locked(struct vm_area_struct *vma)
> > +{
> > + const size_t len = vma_pages(vma) << PAGE_SHIFT;
> > +
> > + mmap_assert_write_locked(vma->vm_mm);
> > + do_munmap(vma->vm_mm, vma->vm_start, len, NULL);
> > +}
> > +
> > +static inline int __compat_vma_mapped(struct file *file, struct vm_area_struct *vma)
> > +{
> > + const struct vm_operations_struct *vm_ops = vma->vm_ops;
> > int err;
> >
> > - err = f_op->mmap_prepare(&desc);
> > + if (!vm_ops->mapped)
> > + return 0;
> > +
> > + err = vm_ops->mapped(vma->vm_start, vma->vm_end, vma->vm_pgoff, file,
> > + &vma->vm_private_data);
> > if (err)
> > - return err;
> > + unmap_vma_locked(vma);
> > + return err;
> > +}
> >
> > - err = mmap_action_prepare(&desc);
> > +static inline int __compat_vma_mmap(struct vm_area_desc *desc,
> > + struct vm_area_struct *vma)
> > +{
> > + int err;
> > +
> > + /* Perform any preparatory tasks for mmap action. */
> > + err = mmap_action_prepare(desc);
> > + if (err)
> > + return err;
> > + /* Update the VMA from the descriptor. */
> > + compat_set_vma_from_desc(vma, desc);
> > + /* Complete any specified mmap actions. */
> > + err = mmap_action_complete(vma, &desc->action);
> > if (err)
> > return err;
> >
> > - set_vma_from_desc(vma, &desc);
> > - return mmap_action_complete(vma, &desc.action);
> > + /* Invoke vm_ops->mapped callback. */
> > + return __compat_vma_mapped(desc->file, vma);
> > +}
> > +
> > +static inline int vfs_mmap_prepare(struct file *file, struct vm_area_desc *desc)
> > +{
> > + return file->f_op->mmap_prepare(desc);
> > }
> >
> > static inline int compat_vma_mmap(struct file *file,
> > struct vm_area_struct *vma)
> > {
> > - return __compat_vma_mmap(file->f_op, file, vma);
> > + struct vm_area_desc desc;
> > + int err;
> > +
> > + compat_set_desc_from_vma(&desc, file, vma);
> > + err = vfs_mmap_prepare(file, &desc);
> > + if (err)
> > + return err;
> > +
> > + return __compat_vma_mmap(&desc, vma);
> > }
> >
> >
> > @@ -1318,11 +1367,6 @@ static inline void vma_iter_init(struct vma_iterator *vmi,
> > mas_init(&vmi->mas, &mm->mm_mt, addr);
> > }
> >
> > -static inline unsigned long vma_pages(struct vm_area_struct *vma)
> > -{
> > - return (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
> > -}
> > -
> > static inline void mmap_assert_locked(struct mm_struct *);
> > static inline struct vm_area_struct *find_vma_intersection(struct mm_struct *mm,
> > unsigned long start_addr,
> > @@ -1492,11 +1536,6 @@ static inline int vfs_mmap(struct file *file, struct vm_area_struct *vma)
> > return file->f_op->mmap(file, vma);
> > }
> >
> > -static inline int vfs_mmap_prepare(struct file *file, struct vm_area_desc *desc)
> > -{
> > - return file->f_op->mmap_prepare(desc);
> > -}
> > -
> > static inline void vma_set_file(struct vm_area_struct *vma, struct file *file)
> > {
> > /* Changing an anonymous vma with this is illegal */
> > @@ -1521,11 +1560,3 @@ static inline pgprot_t vma_get_page_prot(vma_flags_t vma_flags)
> >
> > return vm_get_page_prot(vm_flags);
> > }
> > -
> > -static inline void unmap_vma_locked(struct vm_area_struct *vma)
> > -{
> > - const size_t len = vma_pages(vma) << PAGE_SHIFT;
> > -
> > - mmap_assert_write_locked(vma->vm_mm);
> > - do_munmap(vma->vm_mm, vma->vm_start, len, NULL);
> > -}
> > --
> > 2.53.0
> >
^ permalink raw reply
* Re: [PATCH V7 03/19] dax: add fsdev.c driver for fs-dax on character dax
From: Jonathan Cameron @ 2026-03-19 15:11 UTC (permalink / raw)
To: John Groves
Cc: Ira Weiny, John Groves, Miklos Szeredi, Dan Williams,
Bernd Schubert, Alison Schofield, John Groves, John Groves,
Jonathan Corbet, Vishal Verma, Dave Jiang, Matthew Wilcox,
Jan Kara, Alexander Viro, David Hildenbrand, Christian Brauner,
Darrick J . Wong, Randy Dunlap, Jeff Layton, Amir Goldstein,
Stefan Hajnoczi, Joanne Koong, Josef Bacik, Bagas Sanjaya,
James Morse, Fuad Tabba, Sean Christopherson, Shivank Garg,
Ackerley Tng, Gregory Price, Aravind Ramesh, Ajay Joshi,
venkataravis@micron.com, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, nvdimm@lists.linux.dev,
linux-cxl@vger.kernel.org, linux-fsdevel@vger.kernel.org
In-Reply-To: <aZSoCIjbxKIqRZF4@groves.net>
On Tue, 17 Feb 2026 11:56:20 -0600
John Groves <John@groves.net> wrote:
> On 26/02/13 03:05PM, Ira Weiny wrote:
> > John Groves wrote:
> > > From: John Groves <john@groves.net>
> > >
> > > The new fsdev driver provides pages/folios initialized compatibly with
> > > fsdax - normal rather than devdax-style refcounting, and starting out
> > > with order-0 folios.
> > >
> > > When fsdev binds to a daxdev, it is usually (always?) switching from the
> > > devdax mode (device.c), which pre-initializes compound folios according
> > > to its alignment. Fsdev uses fsdev_clear_folio_state() to switch the
> > > folios into a fsdax-compatible state.
> > >
> > > A side effect of this is that raw mmap doesn't (can't?) work on an fsdev
> > > dax instance. Accordingly, The fsdev driver does not provide raw mmap -
> > > devices must be put in 'devdax' mode (drivers/dax/device.c) to get raw
> > > mmap capability.
> > >
> > > In this commit is just the framework, which remaps pages/folios compatibly
> > > with fsdax.
> > >
> > > Enabling dax changes:
> > >
> > > - bus.h: add DAXDRV_FSDEV_TYPE driver type
> > > - bus.c: allow DAXDRV_FSDEV_TYPE drivers to bind to daxdevs
> > > - dax.h: prototype inode_dax(), which fsdev needs
> > >
> > > Suggested-by: Dan Williams <dan.j.williams@intel.com>
> > > Suggested-by: Gregory Price <gourry@gourry.net>
> > > Signed-off-by: John Groves <john@groves.net>
> > > ---
> > > MAINTAINERS | 8 ++
> > > drivers/dax/Makefile | 6 ++
> > > drivers/dax/bus.c | 4 +
> > > drivers/dax/bus.h | 1 +
> > > drivers/dax/fsdev.c | 242 +++++++++++++++++++++++++++++++++++++++++++
> > > fs/dax.c | 1 +
> > > include/linux/dax.h | 5 +
> > > 7 files changed, 267 insertions(+)
> > > create mode 100644 drivers/dax/fsdev.c
> > >
> >
> > [snip]
> >
> > > +
> > > +static int fsdev_dax_probe(struct dev_dax *dev_dax)
> > > +{
> > > + struct dax_device *dax_dev = dev_dax->dax_dev;
> > > + struct device *dev = &dev_dax->dev;
> > > + struct dev_pagemap *pgmap;
> > > + u64 data_offset = 0;
> > > + struct inode *inode;
> > > + struct cdev *cdev;
> > > + void *addr;
> > > + int rc, i;
> > > +
> > > + if (static_dev_dax(dev_dax)) {
> > > + if (dev_dax->nr_range > 1) {
> > > + dev_warn(dev, "static pgmap / multi-range device conflict\n");
> > > + return -EINVAL;
> > > + }
> > > +
> > > + pgmap = dev_dax->pgmap;
> > > + } else {
> > > + size_t pgmap_size;
> > > +
> > > + if (dev_dax->pgmap) {
> > > + dev_warn(dev, "dynamic-dax with pre-populated page map\n");
> > > + return -EINVAL;
> > > + }
> > > +
> > > + pgmap_size = struct_size(pgmap, ranges, dev_dax->nr_range - 1);
> > > + pgmap = devm_kzalloc(dev, pgmap_size, GFP_KERNEL);
> > > + if (!pgmap)
> > > + return -ENOMEM;
> > > +
> > > + pgmap->nr_range = dev_dax->nr_range;
> > > + dev_dax->pgmap = pgmap;
> > > +
> > > + for (i = 0; i < dev_dax->nr_range; i++) {
> > > + struct range *range = &dev_dax->ranges[i].range;
> > > +
> > > + pgmap->ranges[i] = *range;
> > > + }
> > > + }
> > > +
> > > + for (i = 0; i < dev_dax->nr_range; i++) {
> > > + struct range *range = &dev_dax->ranges[i].range;
> > > +
> > > + if (!devm_request_mem_region(dev, range->start,
> > > + range_len(range), dev_name(dev))) {
> > > + dev_warn(dev, "mapping%d: %#llx-%#llx could not reserve range\n",
> > > + i, range->start, range->end);
> > > + return -EBUSY;
> > > + }
> > > + }
> >
> > All of the above code is AFAICT exactly the same as the dev_dax driver.
> > Isn't there a way to make this common?
> >
> > The rest of the common code is simple enough.
>
> dev_dax_probe() and fsdev_dax_probe() do indeed have some "same code" -
> range validity checking and pgmap setup, from the top of probe through
> the for loop above. After that they're different. Also, I just did a scan
> and the probe function seems like the only remaining common code between
> device.c and fsdev.c.
>
> These are separate kmods; that code could certainly be factored out and
> shared, but it would need to go somewhere common (maybe bus.c)?
Given I made a similar comment on new version. I'll reply here.
Could move it to core code, or if you want to keep stuff kmod, it's common
enough to have helper / library modules. They are non userselectable
Kconfig options that are selected by the visible parts that need them.
Then dependency management ensures the helper gets loaded first.
>
> So both device.c and fsdev.c would call bus.c:dax_prepare_pgmap() or
> some such.
>
> I feel like this might not be worth factoring out, but I'm happy to do it
> if you and/or the dax team prefer it factored out and shared.
I think I'd like to see what it looks like. Maybe as a series on top.
But not my area so over to Dax folk ;)
Jonathan
>
^ permalink raw reply
* [RFC net-next 15/15] Documentation: networking: add ipxlat translator guide
From: Ralf Lici @ 2026-03-19 15:12 UTC (permalink / raw)
To: netdev
Cc: Daniel Gröber, Antonio Quartulli, Ralf Lici, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Jonathan Corbet, Shuah Khan, linux-doc, linux-kernel
In-Reply-To: <20260319151230.655687-1-ralf@mandelbit.com>
From: Daniel Gröber <dxld@darkboxed.org>
Add user and reviewer documentation for the ipxlat virtual netdevice in
Documentation/networking/ipxlat.rst.
The document describes the datapath model, stateless IPv4/IPv6 address
translation rules, ICMP handling, control-plane configuration, and test
topology assumptions. It also records the intended runtime configuration
contract and current behavior limits so deployment expectations are
clear.
Signed-off-by: Daniel Gröber <dxld@darkboxed.org>
Signed-off-by: Ralf Lici <ralf@mandelbit.com>
---
Documentation/networking/ipxlat.rst | 190 ++++++++++++++++++++++++++++
1 file changed, 190 insertions(+)
create mode 100644 Documentation/networking/ipxlat.rst
diff --git a/Documentation/networking/ipxlat.rst b/Documentation/networking/ipxlat.rst
new file mode 100644
index 000000000000..5a0ad02c05be
--- /dev/null
+++ b/Documentation/networking/ipxlat.rst
@@ -0,0 +1,190 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright (C) 2026 Daniel Gröber <dxld@debian.org>
+
+==============================================
+IPXLAT - IPv6<>IPv4 IP/ICMP Translation (SIIT)
+==============================================
+
+ipxlat (``CONFIG_IPXLAT=y``) provides a virtual netdevice implementing
+stateless IP packet translation between IP versions 6 and 4. This is a
+building block for establishing layer 3 connectivity between otherwise
+uncommunicative IPv6-only and/or IPv4-only networks.
+
+
+Creation and Configuration Parameters
+=====================================
+
+An ipxlat netdevice can be created and configured using YNL like so::
+
+ $ ip link add siit0 type ipxlat
+
+ $ IID=$(cat /sys/class/net/siit0/ifindex)
+
+ $ ADDR_HEX=$(python3 -c 'import ipaddress,sys; \
+ print(ipaddress.IPv6Address(sys.argv[1]).packed.hex())' \
+ 64:ff9b:: | tee /dev/stderr)
+ 0064ff9b000000000000000000000000
+
+ $ ./tools/net/ynl/pyynl/cli.py --family ipxlat --json '{"ifindex": $IID, \
+ "config": {"xlat-prefix6": "'$HEX_ADDR'", "prefix-len": 96} }'
+
+(TODO: Once implemented) A ipxlat netdevice can be configured using
+iproute2::
+
+ $ ip link add siit0 type ipxlat [ OPTIONS ]
+
+ # where OPTIONS can include (TODO: iproute2 patch):
+ #
+ # prefix ADDR (default 64:ff9b::/96)
+ #
+ # lowest-ipv6-mtu MTU (default 1280)
+
+
+Introduction to Packet-level IPv6<>IPv4 Translation
+===================================================
+
+Translatable packets delivered into an ipxlat device as either of the IP
+protocol versions loop-back as the other. Untranslatable packets are
+rejected with ICMP errors of the same IP version as appropriate or dropped
+silently if required by RFC-SIIT_.
+
+.. _RFC-SIIT: https://datatracker.ietf.org/doc/html/rfc7915
+
+Supported upper layer protocols (TCP/UDP/ICMP) have their checksums
+recomputed as-needed as part of translation. Unsupported IP protocols
+(IPPROTO\_*) are passed through unmodified. This will make them fail at the
+receiver except in special cases.
+
+Differences in IP layer semantic concerns are handled using several
+different strategies, here we'll only give a high-level summary in the
+areas of most friction:
+ Fragmentation approach, Path MTU Discovery (PMTUD), IP Options and Extension
+ Headers.
+
+**Fragmentation Approach** (v4: on-path vs v6: end-to-end) is smoothed over by:
+ | 4->6: Fragmenting (DF=0) IPv4 packets when needed. See "lowest-ipv6-mtu".
+ | 6->4: Using on-path frag. down the line for v4 pkts smaller than 1260.
+ Details are tedious, check RFC-SIIT_.
+
+**PMTUD** is maintained by recalculating advised MTU values in ICMP
+PKT_TOO_BIG and FRAG_NEEDED messages as they're being translated. Taking
+into account the necessary header re-sizing and post-translation nexthop
+MTU in the main routing table.
+
+**IP Options and IPv6 Extension Headers** except the Fragment Header are
+dropped or ignored expept where more specific behaviour is specified in
+RFC-SIIT_.
+
+
+Address Translation
+-------------------
+
+The ipxlat address translation algorithm is stateless, per RFC-ADDR_, all
+possible IPv4 addressess are mapped one-to-one into the translation prefix,
+optionally including a non-standard "suffix". See `RFC-ADDR Section 2.2
+<https://datatracker.ietf.org/doc/html/rfc6052#section-2.2>`_.
+
+.. _RFC-ADDR: https://datatracker.ietf.org/doc/html/rfc6052
+
+IPv6 addressess outside this prefix are rejected with ICMPv6 errors with
+the notable exception of ICMPv6 errors originating from untranslatable
+source addressess. These are translated to be sourced from the IPv4 Dummy
+Address ``192.0.0.8`` (per I-D-dummy_) instead to maintain IPv4 traceroute
+visibility.
+
+.. _I-D-dummy:
+ https://datatracker.ietf.org/doc/draft-ietf-v6ops-icmpext-xlat-v6only-source/
+
+In a basic bidirectional 6<>4 connectivity scenario this means IPv6 hosts
+must be addressed wholly from inside the translation prefix and per
+RFC-ADDR_. Plain vanilla SLAAC doesn't cut it here, static addressing or
+DHCPv6 is needed, unless that is we introduce statefulnes (RFC-NAT64_) into
+the mix. See below on that.
+
+.. _RFC-NAT64: https://datatracker.ietf.org/doc/html/rfc6146
+
+
+Stateful Translation (NAT64)
+----------------------------
+
+Using NAT64 has several drawbacks, it's necessary only when your control
+over IPv4 or IPv6 addressing of hosts is limited.
+
+Using nftables we can turn a system into a stateful translator. For example
+to make the IPv4 internet reachable to a IPv6-only LAN having this system
+as it's default route, further assuming we have an IPv4 default route and
+``192.0.2.1/32`` is routed to this system::
+
+ $ ip link add siit0 type ipxlat
+ $ ip link set dev siit0 up
+ $ ip route 192.0.2.1/32 dev siit0
+ $ ip route 64:ff9b::/96 dev siit0
+ $ sysctl -w net.ipv4.conf.all.forwarding=1
+ $ sysctl -w net.ipv6.conf.all.forwarding=1
+ $ nft -f- <<EOF
+ table ip6 nat {
+ chain postrouting {
+ type nat hook postrouting priority filter; policy accept;
+ oifname "siit0" snat to 64:ff9b::c002:1 comment "::192.0.2.1"
+ }
+ }
+ table ip nat {
+ chain postrouting {
+ type nat hook postrouting priority filter; policy accept;
+ iifname "siit0" masquerade
+ }
+ }
+ EOF
+
+Note: Keep reading when replacing the 192.0.2.0/24 documentation
+placeholder with RFC 1918 "private IPv4" space.
+
+
+Translation Prefix Choice and Complications
+-------------------------------------------
+
+Several prefix sizes between /32 and /96 are supported by ipxlat. Using
+a /96 prefix is often convenient as it allows using the dotted quad IPv6
+notation, eg.: "64:ff9b::192.0.2.1". RFC-ADDR_ "3.3. Choice of Prefix for
+Stateless Translation Deployments" has more detailed recommendations.
+
+The "Well-Known Prefix" (WKP) 64:ff9b::/96, while a convenient and short
+choice for LANs, comes with some IETF baggage. As specified (at time of
+writing) addressess drawn from RFC 1918 "private IPv4" space "MUST NOT" be
+used with the WKP. While ipxlat does not enforce this other network
+elements may.
+
+If I-D-WKP-1918_ makes it through the IETF process this complication for
+the cautious network engineer may dissapear in the future.
+
+.. _I-D-WKP-1918:
+ https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-wkp-1918/
+
+In the meantime the newer and more lax prefix allocated by RFC-LWKP_ or an
+entirely Network-Specific Prefix may be a better fit. We'd recommend using
+the checksum-neutral ``64:ff9b:1:fffe::/96`` prefix from the larger /48
+allocation.
+
+.. _RFC-LWKP: https://datatracker.ietf.org/doc/html/rfc8215
+
+
+RFC Considerations for Userspace
+--------------------------------
+
+- Per `RFC 7915
+ <https://datatracker.ietf.org/doc/html/rfc7915#section-4.5>`_,
+ ipxlat SHOULD drop UDPv4 zero checksum packets, yet we chose to always
+ recalculate checksums for unfragmented packets.
+
+ If you want your translator to follow the SHOULD add a netfilter rule
+ dropping such packets. For example using ``nft(8)`` syntax::
+
+ nft add rule filter ip postrouting -- oifkind ipxlat udp checksum 0 log drop
+
+- Per `RFC 6146
+ <https://datatracker.ietf.org/doc/html/rfc6146#section-3.4>`_,
+ Fragmented UDPv4 zero checksum recalculation by reassembly is not
+ supported.
+
+- I-D-dummy_: Adding a Node Identity Object to for IPv4-side traceroute
+ disambiguation is not yet supported.
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 15/16] mm: add mmap_action_map_kernel_pages[_full]()
From: Suren Baghdasaryan @ 2026-03-19 15:14 UTC (permalink / raw)
To: Lorenzo Stoakes (Oracle)
Cc: Andrew Morton, Jonathan Corbet, Clemens Ladisch, Arnd Bergmann,
Greg Kroah-Hartman, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Bodo Stroesser, Martin K . Petersen,
David Howells, Marc Dionne, Alexander Viro, Christian Brauner,
Jan Kara, David Hildenbrand, Liam R . Howlett, Vlastimil Babka,
Mike Rapoport, Michal Hocko, Jann Horn, Pedro Falcato,
linux-kernel, linux-doc, linux-hyperv, linux-stm32,
linux-arm-kernel, linux-mtd, linux-staging, linux-scsi,
target-devel, linux-afs, linux-fsdevel, linux-mm, Ryan Roberts
In-Reply-To: <d877ee66-1ac9-4b1b-b860-6919dc58edfe@lucifer.local>
On Thu, Mar 19, 2026 at 8:05 AM Lorenzo Stoakes (Oracle) <ljs@kernel.org> wrote:
>
> On Wed, Mar 18, 2026 at 09:00:13AM -0700, Suren Baghdasaryan wrote:
> > On Mon, Mar 16, 2026 at 2:14 PM Lorenzo Stoakes (Oracle) <ljs@kernel.org> wrote:
> > >
> > > A user can invoke mmap_action_map_kernel_pages() to specify that the
> > > mapping should map kernel pages starting from desc->start of a specified
> > > number of pages specified in an array.
> > >
> > > In order to implement this, adjust mmap_action_prepare() to be able to
> > > return an error code, as it makes sense to assert that the specified
> > > parameters are valid as quickly as possible as well as updating the VMA
> > > flags to include VMA_MIXEDMAP_BIT as necessary.
> > >
> > > This provides an mmap_prepare equivalent of vm_insert_pages().
> > >
> > > We additionally update the existing vm_insert_pages() code to use
> > > range_in_vma() and add a new range_in_vma_desc() helper function for the
> > > mmap_prepare case, sharing the code between the two in range_is_subset().
> > >
> > > We add both mmap_action_map_kernel_pages() and
> > > mmap_action_map_kernel_pages_full() to allow for both partial and full VMA
> > > mappings.
> > >
> > > We also add mmap_action_map_kernel_pages_discontig() to allow for
> > > discontiguous mapping of kernel pages should the need arise.
> > >
> > > We update the documentation to reflect the new features.
> > >
> > > Finally, we update the VMA tests accordingly to reflect the changes.
> > >
> > > Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
> >
> > With one nit,
> > Reviewed-by: Suren Baghdasaryan <surenb@google.com>
>
> Thanks!
>
> >
> > > ---
> > > Documentation/filesystems/mmap_prepare.rst | 8 ++
> > > include/linux/mm.h | 95 +++++++++++++++++++++-
> > > include/linux/mm_types.h | 7 ++
> > > mm/memory.c | 42 +++++++++-
> > > mm/util.c | 6 ++
> > > tools/testing/vma/include/dup.h | 7 ++
> > > 6 files changed, 159 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/Documentation/filesystems/mmap_prepare.rst b/Documentation/filesystems/mmap_prepare.rst
> > > index be76ae475b9c..e810aa4134eb 100644
> > > --- a/Documentation/filesystems/mmap_prepare.rst
> > > +++ b/Documentation/filesystems/mmap_prepare.rst
> > > @@ -156,5 +156,13 @@ pointer. These are:
> > > * mmap_action_simple_ioremap() - Sets up an I/O remap from a specified
> > > physical address and over a specified length.
> > >
> > > +* mmap_action_map_kernel_pages() - Maps a specified array of `struct page`
> > > + pointers in the VMA from a specific offset.
> > > +
> > > +* mmap_action_map_kernel_pages_full() - Maps a specified array of `struct
> > > + page` pointers over the entire VMA. The caller must ensure there are
> > > + sufficient entries in the page array to cover the entire range of the
> > > + described VMA.
> > > +
> > > **NOTE:** The ``action`` field should never normally be manipulated directly,
> > > rather you ought to use one of these helpers.
> > > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > > index df8fa6e6402b..6f0a3edb24e1 100644
> > > --- a/include/linux/mm.h
> > > +++ b/include/linux/mm.h
> > > @@ -2912,7 +2912,7 @@ static inline bool folio_maybe_mapped_shared(struct folio *folio)
> > > * The caller must add any reference (e.g., from folio_try_get()) it might be
> > > * holding itself to the result.
> > > *
> > > - * Returns the expected folio refcount.
> > > + * Returns: the expected folio refcount.
> >
> > nit: I see both "Returns:" and "Return:" being used in the codebase
> > but this header file uses "Return:", so for consistency you should
> > probably do the same. This also applies to later instances in this
> > patch.
>
> Well here I'm just adding the colon, while I'm here (maybe have been an
> update in response to feedback actualy).
>
> And this function that's not part of my change already uses 'Returns' and
> I'm pretty sure that's the correct form.
>
> So I think not a big deal to keep using that?
Correct. Anything I mark as "nit:" is not critical and can be ignored.
>
> >
> > > */
> > > static inline int folio_expected_ref_count(const struct folio *folio)
> > > {
> > > @@ -4364,6 +4364,45 @@ static inline void mmap_action_simple_ioremap(struct vm_area_desc *desc,
> > > action->type = MMAP_SIMPLE_IO_REMAP;
> > > }
> > >
> > > +/**
> > > + * mmap_action_map_kernel_pages - helper for mmap_prepare hook to specify that
> > > + * @num kernel pages contained in the @pages array should be mapped to userland
> > > + * starting at virtual address @start.
> > > + * @desc: The VMA descriptor for the VMA requiring kernel pags to be mapped.
> > > + * @start: The virtual address from which to map them.
> > > + * @pages: An array of struct page pointers describing the memory to map.
> > > + * @nr_pages: The number of entries in the @pages aray.
> > > + */
> > > +static inline void mmap_action_map_kernel_pages(struct vm_area_desc *desc,
> > > + unsigned long start, struct page **pages,
> > > + unsigned long nr_pages)
> > > +{
> > > + struct mmap_action *action = &desc->action;
> > > +
> > > + action->type = MMAP_MAP_KERNEL_PAGES;
> > > + action->map_kernel.start = start;
> > > + action->map_kernel.pages = pages;
> > > + action->map_kernel.nr_pages = nr_pages;
> > > + action->map_kernel.pgoff = desc->pgoff;
> > > +}
> > > +
> > > +/**
> > > + * mmap_action_map_kernel_pages_full - helper for mmap_prepare hook to specify that
> > > + * kernel pages contained in the @pages array should be mapped to userland
> > > + * from @desc->start to @desc->end.
> > > + * @desc: The VMA descriptor for the VMA requiring kernel pags to be mapped.
> > > + * @pages: An array of struct page pointers describing the memory to map.
> > > + *
> > > + * The caller must ensure that @pages contains sufficient entries to cover the
> > > + * entire range described by @desc.
> > > + */
> > > +static inline void mmap_action_map_kernel_pages_full(struct vm_area_desc *desc,
> > > + struct page **pages)
> > > +{
> > > + mmap_action_map_kernel_pages(desc, desc->start, pages,
> > > + vma_desc_pages(desc));
> > > +}
> > > +
> > > int mmap_action_prepare(struct vm_area_desc *desc);
> > > int mmap_action_complete(struct vm_area_struct *vma,
> > > struct mmap_action *action);
> > > @@ -4380,10 +4419,59 @@ static inline struct vm_area_struct *find_exact_vma(struct mm_struct *mm,
> > > return vma;
> > > }
> > >
> > > +/**
> > > + * range_is_subset - Is the specified inner range a subset of the outer range?
> > > + * @outer_start: The start of the outer range.
> > > + * @outer_end: The exclusive end of the outer range.
> > > + * @inner_start: The start of the inner range.
> > > + * @inner_end: The exclusive end of the inner range.
> > > + *
> > > + * Returns: %true if [inner_start, inner_end) is a subset of [outer_start,
> > > + * outer_end), otherwise %false.
> > > + */
> > > +static inline bool range_is_subset(unsigned long outer_start,
> > > + unsigned long outer_end,
> > > + unsigned long inner_start,
> > > + unsigned long inner_end)
> > > +{
> > > + return outer_start <= inner_start && inner_end <= outer_end;
> > > +}
> > > +
> > > +/**
> > > + * range_in_vma - is the specified [@start, @end) range a subset of the VMA?
> > > + * @vma: The VMA against which we want to check [@start, @end).
> > > + * @start: The start of the range we wish to check.
> > > + * @end: The exclusive end of the range we wish to check.
> > > + *
> > > + * Returns: %true if [@start, @end) is a subset of [@vma->vm_start,
> > > + * @vma->vm_end), %false otherwise.
> > > + */
> > > static inline bool range_in_vma(const struct vm_area_struct *vma,
> > > unsigned long start, unsigned long end)
> > > {
> > > - return (vma && vma->vm_start <= start && end <= vma->vm_end);
> > > + if (!vma)
> > > + return false;
> > > +
> > > + return range_is_subset(vma->vm_start, vma->vm_end, start, end);
> > > +}
> > > +
> > > +/**
> > > + * range_in_vma_desc - is the specified [@start, @end) range a subset of the VMA
> > > + * described by @desc, a VMA descriptor?
> > > + * @desc: The VMA descriptor against which we want to check [@start, @end).
> > > + * @start: The start of the range we wish to check.
> > > + * @end: The exclusive end of the range we wish to check.
> > > + *
> > > + * Returns: %true if [@start, @end) is a subset of [@desc->start, @desc->end),
> > > + * %false otherwise.
> > > + */
> > > +static inline bool range_in_vma_desc(const struct vm_area_desc *desc,
> > > + unsigned long start, unsigned long end)
> > > +{
> > > + if (!desc)
> > > + return false;
> > > +
> > > + return range_is_subset(desc->start, desc->end, start, end);
> > > }
> > >
> > > #ifdef CONFIG_MMU
> > > @@ -4427,6 +4515,9 @@ int remap_pfn_range(struct vm_area_struct *vma, unsigned long addr,
> > > int vm_insert_page(struct vm_area_struct *, unsigned long addr, struct page *);
> > > int vm_insert_pages(struct vm_area_struct *vma, unsigned long addr,
> > > struct page **pages, unsigned long *num);
> > > +int map_kernel_pages_prepare(struct vm_area_desc *desc);
> > > +int map_kernel_pages_complete(struct vm_area_struct *vma,
> > > + struct mmap_action *action);
> > > int vm_map_pages(struct vm_area_struct *vma, struct page **pages,
> > > unsigned long num);
> > > int vm_map_pages_zero(struct vm_area_struct *vma, struct page **pages,
> > > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> > > index 7538d64f8848..c46224020a46 100644
> > > --- a/include/linux/mm_types.h
> > > +++ b/include/linux/mm_types.h
> > > @@ -815,6 +815,7 @@ enum mmap_action_type {
> > > MMAP_REMAP_PFN, /* Remap PFN range. */
> > > MMAP_IO_REMAP_PFN, /* I/O remap PFN range. */
> > > MMAP_SIMPLE_IO_REMAP, /* I/O remap with guardrails. */
> > > + MMAP_MAP_KERNEL_PAGES, /* Map kernel page range from array. */
> > > };
> > >
> > > /*
> > > @@ -833,6 +834,12 @@ struct mmap_action {
> > > phys_addr_t start_phys_addr;
> > > unsigned long size;
> > > } simple_ioremap;
> > > + struct {
> > > + unsigned long start;
> > > + struct page **pages;
> > > + unsigned long nr_pages;
> > > + pgoff_t pgoff;
> > > + } map_kernel;
> > > };
> > > enum mmap_action_type type;
> > >
> > > diff --git a/mm/memory.c b/mm/memory.c
> > > index f3f4046aee97..849d5d9eeb83 100644
> > > --- a/mm/memory.c
> > > +++ b/mm/memory.c
> > > @@ -2484,13 +2484,14 @@ static int insert_pages(struct vm_area_struct *vma, unsigned long addr,
> > > int vm_insert_pages(struct vm_area_struct *vma, unsigned long addr,
> > > struct page **pages, unsigned long *num)
> > > {
> > > - const unsigned long end_addr = addr + (*num * PAGE_SIZE) - 1;
> > > + const unsigned long nr_pages = *num;
> > > + const unsigned long end = addr + PAGE_SIZE * nr_pages;
> > >
> > > - if (addr < vma->vm_start || end_addr >= vma->vm_end)
> > > + if (!range_in_vma(vma, addr, end))
> > > return -EFAULT;
> > > if (!(vma->vm_flags & VM_MIXEDMAP)) {
> > > - BUG_ON(mmap_read_trylock(vma->vm_mm));
> > > - BUG_ON(vma->vm_flags & VM_PFNMAP);
> > > + VM_WARN_ON_ONCE(mmap_read_trylock(vma->vm_mm));
> > > + VM_WARN_ON_ONCE(vma->vm_flags & VM_PFNMAP);
> > > vm_flags_set(vma, VM_MIXEDMAP);
> > > }
> > > /* Defer page refcount checking till we're about to map that page. */
> > > @@ -2498,6 +2499,39 @@ int vm_insert_pages(struct vm_area_struct *vma, unsigned long addr,
> > > }
> > > EXPORT_SYMBOL(vm_insert_pages);
> > >
> > > +int map_kernel_pages_prepare(struct vm_area_desc *desc)
> > > +{
> > > + const struct mmap_action *action = &desc->action;
> > > + const unsigned long addr = action->map_kernel.start;
> > > + unsigned long nr_pages, end;
> > > +
> > > + if (!vma_desc_test(desc, VMA_MIXEDMAP_BIT)) {
> > > + VM_WARN_ON_ONCE(mmap_read_trylock(desc->mm));
> > > + VM_WARN_ON_ONCE(vma_desc_test(desc, VMA_PFNMAP_BIT));
> > > + vma_desc_set_flags(desc, VMA_MIXEDMAP_BIT);
> > > + }
> > > +
> > > + nr_pages = action->map_kernel.nr_pages;
> > > + end = addr + PAGE_SIZE * nr_pages;
> > > + if (!range_in_vma_desc(desc, addr, end))
> > > + return -EFAULT;
> > > +
> > > + return 0;
> > > +}
> > > +EXPORT_SYMBOL(map_kernel_pages_prepare);
> > > +
> > > +int map_kernel_pages_complete(struct vm_area_struct *vma,
> > > + struct mmap_action *action)
> > > +{
> > > + unsigned long nr_pages;
> > > +
> > > + nr_pages = action->map_kernel.nr_pages;
> > > + return insert_pages(vma, action->map_kernel.start,
> > > + action->map_kernel.pages,
> > > + &nr_pages, vma->vm_page_prot);
> > > +}
> > > +EXPORT_SYMBOL(map_kernel_pages_complete);
> > > +
> > > /**
> > > * vm_insert_page - insert single page into user vma
> > > * @vma: user vma to map to
> > > diff --git a/mm/util.c b/mm/util.c
> > > index a166c48fe894..dea590e7a26c 100644
> > > --- a/mm/util.c
> > > +++ b/mm/util.c
> > > @@ -1441,6 +1441,8 @@ int mmap_action_prepare(struct vm_area_desc *desc)
> > > return io_remap_pfn_range_prepare(desc);
> > > case MMAP_SIMPLE_IO_REMAP:
> > > return simple_ioremap_prepare(desc);
> > > + case MMAP_MAP_KERNEL_PAGES:
> > > + return map_kernel_pages_prepare(desc);
> > > }
> > >
> > > WARN_ON_ONCE(1);
> > > @@ -1472,6 +1474,9 @@ int mmap_action_complete(struct vm_area_struct *vma,
> > > case MMAP_IO_REMAP_PFN:
> > > err = io_remap_pfn_range_complete(vma, action);
> > > break;
> > > + case MMAP_MAP_KERNEL_PAGES:
> > > + err = map_kernel_pages_complete(vma, action);
> > > + break;
> > > case MMAP_SIMPLE_IO_REMAP:
> > > /*
> > > * The simple I/O remap should have been delegated to an I/O
> > > @@ -1494,6 +1499,7 @@ int mmap_action_prepare(struct vm_area_desc *desc)
> > > case MMAP_REMAP_PFN:
> > > case MMAP_IO_REMAP_PFN:
> > > case MMAP_SIMPLE_IO_REMAP:
> > > + case MMAP_MAP_KERNEL_PAGES:
> > > WARN_ON_ONCE(1); /* nommu cannot handle these. */
> > > break;
> > > }
> > > diff --git a/tools/testing/vma/include/dup.h b/tools/testing/vma/include/dup.h
> > > index 6658df26698a..4407caf207ad 100644
> > > --- a/tools/testing/vma/include/dup.h
> > > +++ b/tools/testing/vma/include/dup.h
> > > @@ -454,6 +454,7 @@ enum mmap_action_type {
> > > MMAP_REMAP_PFN, /* Remap PFN range. */
> > > MMAP_IO_REMAP_PFN, /* I/O remap PFN range. */
> > > MMAP_SIMPLE_IO_REMAP, /* I/O remap with guardrails. */
> > > + MMAP_MAP_KERNEL_PAGES, /* Map kernel page range from an array. */
> > > };
> > >
> > > /*
> > > @@ -472,6 +473,12 @@ struct mmap_action {
> > > phys_addr_t start;
> > > unsigned long len;
> > > } simple_ioremap;
> > > + struct {
> > > + unsigned long start;
> > > + struct page **pages;
> > > + unsigned long num;
> > > + pgoff_t pgoff;
> > > + } map_kernel;
> > > };
> > > enum mmap_action_type type;
> > >
> > > --
> > > 2.53.0
> > >
^ permalink raw reply
* Re: [PATCH v2 11/16] staging: vme_user: replace deprecated mmap hook with mmap_prepare
From: Suren Baghdasaryan @ 2026-03-19 15:19 UTC (permalink / raw)
To: Lorenzo Stoakes (Oracle)
Cc: Andrew Morton, Jonathan Corbet, Clemens Ladisch, Arnd Bergmann,
Greg Kroah-Hartman, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Bodo Stroesser, Martin K . Petersen,
David Howells, Marc Dionne, Alexander Viro, Christian Brauner,
Jan Kara, David Hildenbrand, Liam R . Howlett, Vlastimil Babka,
Mike Rapoport, Michal Hocko, Jann Horn, Pedro Falcato,
linux-kernel, linux-doc, linux-hyperv, linux-stm32,
linux-arm-kernel, linux-mtd, linux-staging, linux-scsi,
target-devel, linux-afs, linux-fsdevel, linux-mm, Ryan Roberts
In-Reply-To: <8cdad898-b306-40fe-a367-efe7147f83b9@lucifer.local>
On Thu, Mar 19, 2026 at 7:55 AM Lorenzo Stoakes (Oracle) <ljs@kernel.org> wrote:
>
> On Tue, Mar 17, 2026 at 02:32:16PM -0700, Suren Baghdasaryan wrote:
> > On Tue, Mar 17, 2026 at 2:26 PM Suren Baghdasaryan <surenb@google.com> wrote:
> > >
> > > On Mon, Mar 16, 2026 at 2:14 PM Lorenzo Stoakes (Oracle) <ljs@kernel.org> wrote:
> > > >
> > > > The f_op->mmap interface is deprecated, so update driver to use its
> > > > successor, mmap_prepare.
> > > >
> > > > The driver previously used vm_iomap_memory(), so this change replaces it
> > > > with its mmap_prepare equivalent, mmap_action_simple_ioremap().
> > > >
> > > > Functions that wrap mmap() are also converted to wrap mmap_prepare()
> > > > instead.
> > > >
> > > > Also update the documentation accordingly.
> > > >
> > > > Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
> > > > ---
> > > > Documentation/driver-api/vme.rst | 2 +-
> > > > drivers/staging/vme_user/vme.c | 20 +++++------
> > > > drivers/staging/vme_user/vme.h | 2 +-
> > > > drivers/staging/vme_user/vme_user.c | 51 +++++++++++++++++------------
> > > > 4 files changed, 42 insertions(+), 33 deletions(-)
> > > >
> > > > diff --git a/Documentation/driver-api/vme.rst b/Documentation/driver-api/vme.rst
> > > > index c0b475369de0..7111999abc14 100644
> > > > --- a/Documentation/driver-api/vme.rst
> > > > +++ b/Documentation/driver-api/vme.rst
> > > > @@ -107,7 +107,7 @@ The function :c:func:`vme_master_read` can be used to read from and
> > > >
> > > > In addition to simple reads and writes, :c:func:`vme_master_rmw` is provided to
> > > > do a read-modify-write transaction. Parts of a VME window can also be mapped
> > > > -into user space memory using :c:func:`vme_master_mmap`.
> > > > +into user space memory using :c:func:`vme_master_mmap_prepare`.
> > > >
> > > >
> > > > Slave windows
> > > > diff --git a/drivers/staging/vme_user/vme.c b/drivers/staging/vme_user/vme.c
> > > > index f10a00c05f12..7220aba7b919 100644
> > > > --- a/drivers/staging/vme_user/vme.c
> > > > +++ b/drivers/staging/vme_user/vme.c
> > > > @@ -735,9 +735,9 @@ unsigned int vme_master_rmw(struct vme_resource *resource, unsigned int mask,
> > > > EXPORT_SYMBOL(vme_master_rmw);
> > > >
> > > > /**
> > > > - * vme_master_mmap - Mmap region of VME master window.
> > > > + * vme_master_mmap_prepare - Mmap region of VME master window.
> > > > * @resource: Pointer to VME master resource.
> > > > - * @vma: Pointer to definition of user mapping.
> > > > + * @desc: Pointer to descriptor of user mapping.
> > > > *
> > > > * Memory map a region of the VME master window into user space.
> > > > *
> > > > @@ -745,12 +745,13 @@ EXPORT_SYMBOL(vme_master_rmw);
> > > > * resource or -EFAULT if map exceeds window size. Other generic mmap
> > > > * errors may also be returned.
> > > > */
> > > > -int vme_master_mmap(struct vme_resource *resource, struct vm_area_struct *vma)
> > > > +int vme_master_mmap_prepare(struct vme_resource *resource,
> > > > + struct vm_area_desc *desc)
> > > > {
> > > > + const unsigned long vma_size = vma_desc_size(desc);
> > > > struct vme_bridge *bridge = find_bridge(resource);
> > > > struct vme_master_resource *image;
> > > > phys_addr_t phys_addr;
> > > > - unsigned long vma_size;
> > > >
> > > > if (resource->type != VME_MASTER) {
> > > > dev_err(bridge->parent, "Not a master resource\n");
> > > > @@ -758,19 +759,18 @@ int vme_master_mmap(struct vme_resource *resource, struct vm_area_struct *vma)
> > > > }
> > > >
> > > > image = list_entry(resource->entry, struct vme_master_resource, list);
> > > > - phys_addr = image->bus_resource.start + (vma->vm_pgoff << PAGE_SHIFT);
> > > > - vma_size = vma->vm_end - vma->vm_start;
> > > > + phys_addr = image->bus_resource.start + (desc->pgoff << PAGE_SHIFT);
> > > >
> > > > if (phys_addr + vma_size > image->bus_resource.end + 1) {
> > > > dev_err(bridge->parent, "Map size cannot exceed the window size\n");
> > > > return -EFAULT;
> > > > }
> > > >
> > > > - vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> > > > -
> > > > - return vm_iomap_memory(vma, phys_addr, vma->vm_end - vma->vm_start);
> > > > + desc->page_prot = pgprot_noncached(desc->page_prot);
> > > > + mmap_action_simple_ioremap(desc, phys_addr, vma_size);
> > > > + return 0;
> > > > }
> > > > -EXPORT_SYMBOL(vme_master_mmap);
> > > > +EXPORT_SYMBOL(vme_master_mmap_prepare);
> > > >
> > > > /**
> > > > * vme_master_free - Free VME master window
> > > > diff --git a/drivers/staging/vme_user/vme.h b/drivers/staging/vme_user/vme.h
> > > > index 797e9940fdd1..b6413605ea49 100644
> > > > --- a/drivers/staging/vme_user/vme.h
> > > > +++ b/drivers/staging/vme_user/vme.h
> > > > @@ -151,7 +151,7 @@ ssize_t vme_master_read(struct vme_resource *resource, void *buf, size_t count,
> > > > ssize_t vme_master_write(struct vme_resource *resource, void *buf, size_t count, loff_t offset);
> > > > unsigned int vme_master_rmw(struct vme_resource *resource, unsigned int mask, unsigned int compare,
> > > > unsigned int swap, loff_t offset);
> > > > -int vme_master_mmap(struct vme_resource *resource, struct vm_area_struct *vma);
> > > > +int vme_master_mmap_prepare(struct vme_resource *resource, struct vm_area_desc *desc);
> > > > void vme_master_free(struct vme_resource *resource);
> > > >
> > > > struct vme_resource *vme_dma_request(struct vme_dev *vdev, u32 route);
> > > > diff --git a/drivers/staging/vme_user/vme_user.c b/drivers/staging/vme_user/vme_user.c
> > > > index d95dd7d9190a..11e25c2f6b0a 100644
> > > > --- a/drivers/staging/vme_user/vme_user.c
> > > > +++ b/drivers/staging/vme_user/vme_user.c
> > > > @@ -446,24 +446,14 @@ static void vme_user_vm_close(struct vm_area_struct *vma)
> > > > kfree(vma_priv);
> > > > }
> > > >
> > > > -static const struct vm_operations_struct vme_user_vm_ops = {
> > > > - .open = vme_user_vm_open,
> > > > - .close = vme_user_vm_close,
> > > > -};
> > > > -
> > > > -static int vme_user_master_mmap(unsigned int minor, struct vm_area_struct *vma)
> > > > +static int vme_user_vm_mapped(unsigned long start, unsigned long end, pgoff_t pgoff,
> > > > + const struct file *file, void **vm_private_data)
> > > > {
> > > > - int err;
> > > > + const unsigned int minor = iminor(file_inode(file));
> > > > struct vme_user_vma_priv *vma_priv;
> > > >
> > > > mutex_lock(&image[minor].mutex);
> > > >
> > > > - err = vme_master_mmap(image[minor].resource, vma);
> > > > - if (err) {
> > > > - mutex_unlock(&image[minor].mutex);
> > > > - return err;
> > > > - }
> > > > -
> > >
> > > Ok, this changes the set of the operations performed under image[minor].mutex.
> > > Before we had:
> > >
> > > mutex_lock(&image[minor].mutex);
> > > vme_master_mmap();
> > > <some final adjustments>
> > > mutex_unlock(&image[minor].mutex);
> > >
> > > Now we have:
> > >
> > > mutex_lock(&image[minor].mutex);
> > > vme_master_mmap_prepare()
> > > mutex_unlock(&image[minor].mutex);
> > > vm_iomap_memory();
> > > mutex_lock(&image[minor].mutex);
> > > vme_user_vm_mapped(); // <some final adjustments>
> > > mutex_unlock(&image[minor].mutex);
> > >
> > > I think as long as image[minor] does not change while we are not
> > > holding the mutex we should be safe, and looking at the code it seems
> > > to be the case. But I'm not familiar with this driver and might be
> > > wrong. Worth double-checking.
>
> The file is pinned for the duration, the mutex is associated with the file,
> so there's no sane world in which that could be problematic.
>
> Keeping in mind that we manipulate stuff on vme_user_vm_close() that
> directly acceses image[minor] at an arbitary time.
That was my understanding as well. Thanks for confirming.
>
> >
> > A side note: if we had to hold the mutex across all those operations I
> > think we would need to take the mutex in the vm_ops->mmap_prepare and
> > add a vm_ops->map_failed hook or something along that line to drop the
> > mutex in case mmap_action_complete() fails. Not sure if we will have
> > such cases though...
>
> No, I don't want to do this if it can be at all avoided. You should in
> nearly any sane circumstance be able to defer things until the mapped hook
> anyway.
>
> Also a merge can happen too after an .mmap_prepare, so we'd have to have
> some 'success' hook and I'm just not going there it'll end up open to abuse
> again.
>
> (We do have success and error filtering hooks right now, sadly, but they're
> really for hugetlb and I plan to find a way to get rid of them).
>
> The mmap_prepare is meant to essentially be as stateless as possible.
Yes, I also hope we won't encounter cases requiring us to keep any
state information between the mmap_prepare and mapped stages.
>
> Anyway I don't think it's relevant here.
>
> >
> > >
> > > > vma_priv = kmalloc_obj(*vma_priv);
> > > > if (!vma_priv) {
> > > > mutex_unlock(&image[minor].mutex);
> > > > @@ -472,22 +462,41 @@ static int vme_user_master_mmap(unsigned int minor, struct vm_area_struct *vma)
> > > >
> > > > vma_priv->minor = minor;
> > > > refcount_set(&vma_priv->refcnt, 1);
> > > > - vma->vm_ops = &vme_user_vm_ops;
> > > > - vma->vm_private_data = vma_priv;
> > > > -
> > > > + *vm_private_data = vma_priv;
> > > > image[minor].mmap_count++;
> > > >
> > > > mutex_unlock(&image[minor].mutex);
> > > > -
> > > > return 0;
> > > > }
> > > >
> > > > -static int vme_user_mmap(struct file *file, struct vm_area_struct *vma)
> > > > +static const struct vm_operations_struct vme_user_vm_ops = {
> > > > + .mapped = vme_user_vm_mapped,
> > > > + .open = vme_user_vm_open,
> > > > + .close = vme_user_vm_close,
> > > > +};
> > > > +
> > > > +static int vme_user_master_mmap_prepare(unsigned int minor,
> > > > + struct vm_area_desc *desc)
> > > > +{
> > > > + int err;
> > > > +
> > > > + mutex_lock(&image[minor].mutex);
> > > > +
> > > > + err = vme_master_mmap_prepare(image[minor].resource, desc);
> > > > + if (!err)
> > > > + desc->vm_ops = &vme_user_vm_ops;
> > > > +
> > > > + mutex_unlock(&image[minor].mutex);
> > > > + return err;
> > > > +}
> > > > +
> > > > +static int vme_user_mmap_prepare(struct vm_area_desc *desc)
> > > > {
> > > > - unsigned int minor = iminor(file_inode(file));
> > > > + const struct file *file = desc->file;
> > > > + const unsigned int minor = iminor(file_inode(file));
> > > >
> > > > if (type[minor] == MASTER_MINOR)
> > > > - return vme_user_master_mmap(minor, vma);
> > > > + return vme_user_master_mmap_prepare(minor, desc);
> > > >
> > > > return -ENODEV;
> > > > }
> > > > @@ -498,7 +507,7 @@ static const struct file_operations vme_user_fops = {
> > > > .llseek = vme_user_llseek,
> > > > .unlocked_ioctl = vme_user_unlocked_ioctl,
> > > > .compat_ioctl = compat_ptr_ioctl,
> > > > - .mmap = vme_user_mmap,
> > > > + .mmap_prepare = vme_user_mmap_prepare,
> > > > };
> > > >
> > > > static int vme_user_match(struct vme_dev *vdev)
> > > > --
> > > > 2.53.0
> > > >
>
> Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH v2 11/16] staging: vme_user: replace deprecated mmap hook with mmap_prepare
From: Suren Baghdasaryan @ 2026-03-19 15:19 UTC (permalink / raw)
To: Lorenzo Stoakes (Oracle)
Cc: Andrew Morton, Jonathan Corbet, Clemens Ladisch, Arnd Bergmann,
Greg Kroah-Hartman, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Bodo Stroesser, Martin K . Petersen,
David Howells, Marc Dionne, Alexander Viro, Christian Brauner,
Jan Kara, David Hildenbrand, Liam R . Howlett, Vlastimil Babka,
Mike Rapoport, Michal Hocko, Jann Horn, Pedro Falcato,
linux-kernel, linux-doc, linux-hyperv, linux-stm32,
linux-arm-kernel, linux-mtd, linux-staging, linux-scsi,
target-devel, linux-afs, linux-fsdevel, linux-mm, Ryan Roberts
In-Reply-To: <CAJuCfpHXqtxZr5s84jCcz513a2pgMeDoobsLBJH9pSON49cM+w@mail.gmail.com>
On Thu, Mar 19, 2026 at 8:19 AM Suren Baghdasaryan <surenb@google.com> wrote:
>
> On Thu, Mar 19, 2026 at 7:55 AM Lorenzo Stoakes (Oracle) <ljs@kernel.org> wrote:
> >
> > On Tue, Mar 17, 2026 at 02:32:16PM -0700, Suren Baghdasaryan wrote:
> > > On Tue, Mar 17, 2026 at 2:26 PM Suren Baghdasaryan <surenb@google.com> wrote:
> > > >
> > > > On Mon, Mar 16, 2026 at 2:14 PM Lorenzo Stoakes (Oracle) <ljs@kernel.org> wrote:
> > > > >
> > > > > The f_op->mmap interface is deprecated, so update driver to use its
> > > > > successor, mmap_prepare.
> > > > >
> > > > > The driver previously used vm_iomap_memory(), so this change replaces it
> > > > > with its mmap_prepare equivalent, mmap_action_simple_ioremap().
> > > > >
> > > > > Functions that wrap mmap() are also converted to wrap mmap_prepare()
> > > > > instead.
> > > > >
> > > > > Also update the documentation accordingly.
> > > > >
> > > > > Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
Reviewed-by: Suren Baghdasaryan <surenb@google.com>
> > > > > ---
> > > > > Documentation/driver-api/vme.rst | 2 +-
> > > > > drivers/staging/vme_user/vme.c | 20 +++++------
> > > > > drivers/staging/vme_user/vme.h | 2 +-
> > > > > drivers/staging/vme_user/vme_user.c | 51 +++++++++++++++++------------
> > > > > 4 files changed, 42 insertions(+), 33 deletions(-)
> > > > >
> > > > > diff --git a/Documentation/driver-api/vme.rst b/Documentation/driver-api/vme.rst
> > > > > index c0b475369de0..7111999abc14 100644
> > > > > --- a/Documentation/driver-api/vme.rst
> > > > > +++ b/Documentation/driver-api/vme.rst
> > > > > @@ -107,7 +107,7 @@ The function :c:func:`vme_master_read` can be used to read from and
> > > > >
> > > > > In addition to simple reads and writes, :c:func:`vme_master_rmw` is provided to
> > > > > do a read-modify-write transaction. Parts of a VME window can also be mapped
> > > > > -into user space memory using :c:func:`vme_master_mmap`.
> > > > > +into user space memory using :c:func:`vme_master_mmap_prepare`.
> > > > >
> > > > >
> > > > > Slave windows
> > > > > diff --git a/drivers/staging/vme_user/vme.c b/drivers/staging/vme_user/vme.c
> > > > > index f10a00c05f12..7220aba7b919 100644
> > > > > --- a/drivers/staging/vme_user/vme.c
> > > > > +++ b/drivers/staging/vme_user/vme.c
> > > > > @@ -735,9 +735,9 @@ unsigned int vme_master_rmw(struct vme_resource *resource, unsigned int mask,
> > > > > EXPORT_SYMBOL(vme_master_rmw);
> > > > >
> > > > > /**
> > > > > - * vme_master_mmap - Mmap region of VME master window.
> > > > > + * vme_master_mmap_prepare - Mmap region of VME master window.
> > > > > * @resource: Pointer to VME master resource.
> > > > > - * @vma: Pointer to definition of user mapping.
> > > > > + * @desc: Pointer to descriptor of user mapping.
> > > > > *
> > > > > * Memory map a region of the VME master window into user space.
> > > > > *
> > > > > @@ -745,12 +745,13 @@ EXPORT_SYMBOL(vme_master_rmw);
> > > > > * resource or -EFAULT if map exceeds window size. Other generic mmap
> > > > > * errors may also be returned.
> > > > > */
> > > > > -int vme_master_mmap(struct vme_resource *resource, struct vm_area_struct *vma)
> > > > > +int vme_master_mmap_prepare(struct vme_resource *resource,
> > > > > + struct vm_area_desc *desc)
> > > > > {
> > > > > + const unsigned long vma_size = vma_desc_size(desc);
> > > > > struct vme_bridge *bridge = find_bridge(resource);
> > > > > struct vme_master_resource *image;
> > > > > phys_addr_t phys_addr;
> > > > > - unsigned long vma_size;
> > > > >
> > > > > if (resource->type != VME_MASTER) {
> > > > > dev_err(bridge->parent, "Not a master resource\n");
> > > > > @@ -758,19 +759,18 @@ int vme_master_mmap(struct vme_resource *resource, struct vm_area_struct *vma)
> > > > > }
> > > > >
> > > > > image = list_entry(resource->entry, struct vme_master_resource, list);
> > > > > - phys_addr = image->bus_resource.start + (vma->vm_pgoff << PAGE_SHIFT);
> > > > > - vma_size = vma->vm_end - vma->vm_start;
> > > > > + phys_addr = image->bus_resource.start + (desc->pgoff << PAGE_SHIFT);
> > > > >
> > > > > if (phys_addr + vma_size > image->bus_resource.end + 1) {
> > > > > dev_err(bridge->parent, "Map size cannot exceed the window size\n");
> > > > > return -EFAULT;
> > > > > }
> > > > >
> > > > > - vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> > > > > -
> > > > > - return vm_iomap_memory(vma, phys_addr, vma->vm_end - vma->vm_start);
> > > > > + desc->page_prot = pgprot_noncached(desc->page_prot);
> > > > > + mmap_action_simple_ioremap(desc, phys_addr, vma_size);
> > > > > + return 0;
> > > > > }
> > > > > -EXPORT_SYMBOL(vme_master_mmap);
> > > > > +EXPORT_SYMBOL(vme_master_mmap_prepare);
> > > > >
> > > > > /**
> > > > > * vme_master_free - Free VME master window
> > > > > diff --git a/drivers/staging/vme_user/vme.h b/drivers/staging/vme_user/vme.h
> > > > > index 797e9940fdd1..b6413605ea49 100644
> > > > > --- a/drivers/staging/vme_user/vme.h
> > > > > +++ b/drivers/staging/vme_user/vme.h
> > > > > @@ -151,7 +151,7 @@ ssize_t vme_master_read(struct vme_resource *resource, void *buf, size_t count,
> > > > > ssize_t vme_master_write(struct vme_resource *resource, void *buf, size_t count, loff_t offset);
> > > > > unsigned int vme_master_rmw(struct vme_resource *resource, unsigned int mask, unsigned int compare,
> > > > > unsigned int swap, loff_t offset);
> > > > > -int vme_master_mmap(struct vme_resource *resource, struct vm_area_struct *vma);
> > > > > +int vme_master_mmap_prepare(struct vme_resource *resource, struct vm_area_desc *desc);
> > > > > void vme_master_free(struct vme_resource *resource);
> > > > >
> > > > > struct vme_resource *vme_dma_request(struct vme_dev *vdev, u32 route);
> > > > > diff --git a/drivers/staging/vme_user/vme_user.c b/drivers/staging/vme_user/vme_user.c
> > > > > index d95dd7d9190a..11e25c2f6b0a 100644
> > > > > --- a/drivers/staging/vme_user/vme_user.c
> > > > > +++ b/drivers/staging/vme_user/vme_user.c
> > > > > @@ -446,24 +446,14 @@ static void vme_user_vm_close(struct vm_area_struct *vma)
> > > > > kfree(vma_priv);
> > > > > }
> > > > >
> > > > > -static const struct vm_operations_struct vme_user_vm_ops = {
> > > > > - .open = vme_user_vm_open,
> > > > > - .close = vme_user_vm_close,
> > > > > -};
> > > > > -
> > > > > -static int vme_user_master_mmap(unsigned int minor, struct vm_area_struct *vma)
> > > > > +static int vme_user_vm_mapped(unsigned long start, unsigned long end, pgoff_t pgoff,
> > > > > + const struct file *file, void **vm_private_data)
> > > > > {
> > > > > - int err;
> > > > > + const unsigned int minor = iminor(file_inode(file));
> > > > > struct vme_user_vma_priv *vma_priv;
> > > > >
> > > > > mutex_lock(&image[minor].mutex);
> > > > >
> > > > > - err = vme_master_mmap(image[minor].resource, vma);
> > > > > - if (err) {
> > > > > - mutex_unlock(&image[minor].mutex);
> > > > > - return err;
> > > > > - }
> > > > > -
> > > >
> > > > Ok, this changes the set of the operations performed under image[minor].mutex.
> > > > Before we had:
> > > >
> > > > mutex_lock(&image[minor].mutex);
> > > > vme_master_mmap();
> > > > <some final adjustments>
> > > > mutex_unlock(&image[minor].mutex);
> > > >
> > > > Now we have:
> > > >
> > > > mutex_lock(&image[minor].mutex);
> > > > vme_master_mmap_prepare()
> > > > mutex_unlock(&image[minor].mutex);
> > > > vm_iomap_memory();
> > > > mutex_lock(&image[minor].mutex);
> > > > vme_user_vm_mapped(); // <some final adjustments>
> > > > mutex_unlock(&image[minor].mutex);
> > > >
> > > > I think as long as image[minor] does not change while we are not
> > > > holding the mutex we should be safe, and looking at the code it seems
> > > > to be the case. But I'm not familiar with this driver and might be
> > > > wrong. Worth double-checking.
> >
> > The file is pinned for the duration, the mutex is associated with the file,
> > so there's no sane world in which that could be problematic.
> >
> > Keeping in mind that we manipulate stuff on vme_user_vm_close() that
> > directly acceses image[minor] at an arbitary time.
>
> That was my understanding as well. Thanks for confirming.
>
> >
> > >
> > > A side note: if we had to hold the mutex across all those operations I
> > > think we would need to take the mutex in the vm_ops->mmap_prepare and
> > > add a vm_ops->map_failed hook or something along that line to drop the
> > > mutex in case mmap_action_complete() fails. Not sure if we will have
> > > such cases though...
> >
> > No, I don't want to do this if it can be at all avoided. You should in
> > nearly any sane circumstance be able to defer things until the mapped hook
> > anyway.
> >
> > Also a merge can happen too after an .mmap_prepare, so we'd have to have
> > some 'success' hook and I'm just not going there it'll end up open to abuse
> > again.
> >
> > (We do have success and error filtering hooks right now, sadly, but they're
> > really for hugetlb and I plan to find a way to get rid of them).
> >
> > The mmap_prepare is meant to essentially be as stateless as possible.
>
> Yes, I also hope we won't encounter cases requiring us to keep any
> state information between the mmap_prepare and mapped stages.
>
> >
> > Anyway I don't think it's relevant here.
> >
> > >
> > > >
> > > > > vma_priv = kmalloc_obj(*vma_priv);
> > > > > if (!vma_priv) {
> > > > > mutex_unlock(&image[minor].mutex);
> > > > > @@ -472,22 +462,41 @@ static int vme_user_master_mmap(unsigned int minor, struct vm_area_struct *vma)
> > > > >
> > > > > vma_priv->minor = minor;
> > > > > refcount_set(&vma_priv->refcnt, 1);
> > > > > - vma->vm_ops = &vme_user_vm_ops;
> > > > > - vma->vm_private_data = vma_priv;
> > > > > -
> > > > > + *vm_private_data = vma_priv;
> > > > > image[minor].mmap_count++;
> > > > >
> > > > > mutex_unlock(&image[minor].mutex);
> > > > > -
> > > > > return 0;
> > > > > }
> > > > >
> > > > > -static int vme_user_mmap(struct file *file, struct vm_area_struct *vma)
> > > > > +static const struct vm_operations_struct vme_user_vm_ops = {
> > > > > + .mapped = vme_user_vm_mapped,
> > > > > + .open = vme_user_vm_open,
> > > > > + .close = vme_user_vm_close,
> > > > > +};
> > > > > +
> > > > > +static int vme_user_master_mmap_prepare(unsigned int minor,
> > > > > + struct vm_area_desc *desc)
> > > > > +{
> > > > > + int err;
> > > > > +
> > > > > + mutex_lock(&image[minor].mutex);
> > > > > +
> > > > > + err = vme_master_mmap_prepare(image[minor].resource, desc);
> > > > > + if (!err)
> > > > > + desc->vm_ops = &vme_user_vm_ops;
> > > > > +
> > > > > + mutex_unlock(&image[minor].mutex);
> > > > > + return err;
> > > > > +}
> > > > > +
> > > > > +static int vme_user_mmap_prepare(struct vm_area_desc *desc)
> > > > > {
> > > > > - unsigned int minor = iminor(file_inode(file));
> > > > > + const struct file *file = desc->file;
> > > > > + const unsigned int minor = iminor(file_inode(file));
> > > > >
> > > > > if (type[minor] == MASTER_MINOR)
> > > > > - return vme_user_master_mmap(minor, vma);
> > > > > + return vme_user_master_mmap_prepare(minor, desc);
> > > > >
> > > > > return -ENODEV;
> > > > > }
> > > > > @@ -498,7 +507,7 @@ static const struct file_operations vme_user_fops = {
> > > > > .llseek = vme_user_llseek,
> > > > > .unlocked_ioctl = vme_user_unlocked_ioctl,
> > > > > .compat_ioctl = compat_ptr_ioctl,
> > > > > - .mmap = vme_user_mmap,
> > > > > + .mmap_prepare = vme_user_mmap_prepare,
> > > > > };
> > > > >
> > > > > static int vme_user_match(struct vme_dev *vdev)
> > > > > --
> > > > > 2.53.0
> > > > >
> >
> > Cheers, Lorenzo
^ permalink raw reply
* [PATCH v7 00/10] VMSCAPE optimization for BHI variant
From: Pawan Gupta @ 2026-03-19 15:40 UTC (permalink / raw)
To: x86, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Sean Christopherson, Borislav Petkov, Dave Hansen,
Peter Zijlstra, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, KP Singh, Jiri Olsa, David S. Miller,
David Laight, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
David Ahern, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, Stanislav Fomichev, Hao Luo,
Paolo Bonzini, Jonathan Corbet
Cc: linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf, netdev,
linux-doc
v7:
- s/This allows/Allow/ and s/This does adds/This adds/ in patch 1/10 commit
message (Borislav).
- Minimize register usage in BHB clearing seq. (David Laight)
- Instead of separate ecx/eax counters, use al/ah.
- Adjust the alignment of RET due to register size change.
- save/restore rax in the seq itself.
- Remove the save/restore of rax/rcx for BPF callers.
- Rename clear_bhb_loop() to clear_bhb_loop_nofence() to make it
obvious that the LFENCE is not part of the sequence (Borislav).
- Fix Kconfig: s/select/depends on/ HAVE_STATIC_CALL (PeterZ).
- Rebased to v7.0-rc4.
v6: https://lore.kernel.org/r/20251201-vmscape-bhb-v6-0-d610dd515714@linux.intel.com
- Remove semicolon at the end of asm in ALTERNATIVE (Uros).
- Fix build warning in vmscape_select_mitigation() (LKP).
- Rebased to v6.18.
v5: https://lore.kernel.org/r/20251126-vmscape-bhb-v5-2-02d66e423b00@linux.intel.com
- For BHI seq, limit runtime-patching to loop counts only (Dave).
Dropped 2 patches that moved the BHB seq to a macro.
- Remove redundant switch cases in vmscape_select_mitigation() (Nikolay).
- Improve commit message (Nikolay).
- Collected tags.
v4: https://lore.kernel.org/r/20251119-vmscape-bhb-v4-0-1adad4e69ddc@linux.intel.com
- Move LFENCE to the callsite, out of clear_bhb_loop(). (Dave)
- Make clear_bhb_loop() work for larger BHB. (Dave)
This now uses hardware enumeration to determine the BHB size to clear.
- Use write_ibpb() instead of indirect_branch_prediction_barrier() when
IBPB is known to be available. (Dave)
- Use static_call() to simplify mitigation at exit-to-userspace. (Dave)
- Refactor vmscape_select_mitigation(). (Dave)
- Fix vmscape=on which was wrongly behaving as AUTO. (Dave)
- Split the patches. (Dave)
- Patch 1-4 prepares for making the sequence flexible for VMSCAPE use.
- Patch 5 trivial rename of variable.
- Patch 6-8 prepares for deploying BHB mitigation for VMSCAPE.
- Patch 9 deploys the mitigation.
- Patch 10-11 fixes ON Vs AUTO mode.
v3: https://lore.kernel.org/r/20251027-vmscape-bhb-v3-0-5793c2534e93@linux.intel.com
- s/x86_pred_flush_pending/x86_predictor_flush_exit_to_user/ (Sean).
- Removed IBPB & BHB-clear mutual exclusion at exit-to-userspace.
- Collected tags.
v2: https://lore.kernel.org/r/20251015-vmscape-bhb-v2-0-91cbdd9c3a96@linux.intel.com
- Added check for IBPB feature in vmscape_select_mitigation(). (David)
- s/vmscape=auto/vmscape=on/ (David)
- Added patch to remove LFENCE from VMSCAPE BHB-clear sequence.
- Rebased to v6.18-rc1.
v1: https://lore.kernel.org/r/20250924-vmscape-bhb-v1-0-da51f0e1934d@linux.intel.com
Hi All,
These patches aim to improve the performance of a recent mitigation for
VMSCAPE[1] vulnerability. This improvement is relevant for BHI variant of
VMSCAPE that affect Alder Lake and newer processors.
The current mitigation approach uses IBPB on kvm-exit-to-userspace for all
affected range of CPUs. This is an overkill for CPUs that are only affected
by the BHI variant. On such CPUs clearing the branch history is sufficient
for VMSCAPE, and also more apt as the underlying issue is due to poisoned
branch history.
Below is the iPerf data for transfer between guest and host, comparing IBPB
and BHB-clear mitigation. BHB-clear shows performance improvement over IBPB
in most cases.
Platform: Emerald Rapids
Baseline: vmscape=off
Target: IBPB at VMexit-to-userspace Vs the new BHB-clear at
VMexit-to-userspace mitigation (both compared against baseline).
(pN = N parallel connections)
| iPerf user-net | IBPB | BHB Clear |
|----------------|---------|-----------|
| UDP 1-vCPU_p1 | -12.5% | 1.3% |
| TCP 1-vCPU_p1 | -10.4% | -1.5% |
| TCP 1-vCPU_p1 | -7.5% | -3.0% |
| UDP 4-vCPU_p16 | -3.7% | -3.7% |
| TCP 4-vCPU_p4 | -2.9% | -1.4% |
| UDP 4-vCPU_p4 | -0.6% | 0.0% |
| TCP 4-vCPU_p4 | 3.5% | 0.0% |
| iPerf bridge-net | IBPB | BHB Clear |
|------------------|---------|-----------|
| UDP 1-vCPU_p1 | -9.4% | -0.4% |
| TCP 1-vCPU_p1 | -3.9% | -0.5% |
| UDP 4-vCPU_p16 | -2.2% | -3.8% |
| TCP 4-vCPU_p4 | -1.0% | -1.0% |
| TCP 4-vCPU_p4 | 0.5% | 0.5% |
| UDP 4-vCPU_p4 | 0.0% | 0.9% |
| TCP 1-vCPU_p1 | 0.0% | 0.9% |
| iPerf vhost-net | IBPB | BHB Clear |
|-----------------|---------|-----------|
| UDP 1-vCPU_p1 | -4.3% | 1.0% |
| TCP 1-vCPU_p1 | -3.8% | -0.5% |
| TCP 1-vCPU_p1 | -2.7% | -0.7% |
| UDP 4-vCPU_p16 | -0.7% | -2.2% |
| TCP 4-vCPU_p4 | -0.4% | 0.8% |
| UDP 4-vCPU_p4 | 0.4% | -0.7% |
| TCP 4-vCPU_p4 | 0.0% | 0.6% |
[1] https://comsec.ethz.ch/research/microarch/vmscape-exposing-and-exploiting-incomplete-branch-predictor-isolation-in-cloud-environments/
---
Pawan Gupta (10):
x86/bhi: x86/vmscape: Move LFENCE out of clear_bhb_loop()
x86/bhi: Make clear_bhb_loop() effective on newer CPUs
x86/bhi: Rename clear_bhb_loop() to clear_bhb_loop_nofence()
x86/vmscape: Rename x86_ibpb_exit_to_user to x86_predictor_flush_exit_to_user
x86/vmscape: Move mitigation selection to a switch()
x86/vmscape: Use write_ibpb() instead of indirect_branch_prediction_barrier()
x86/vmscape: Use static_call() for predictor flush
x86/vmscape: Deploy BHB clearing mitigation
x86/vmscape: Fix conflicting attack-vector controls with =force
x86/vmscape: Add cmdline vmscape=on to override attack vector controls
Documentation/admin-guide/hw-vuln/vmscape.rst | 8 +++
Documentation/admin-guide/kernel-parameters.txt | 4 +-
arch/x86/Kconfig | 1 +
arch/x86/entry/entry_64.S | 34 +++++++----
arch/x86/include/asm/cpufeatures.h | 2 +-
arch/x86/include/asm/entry-common.h | 9 ++-
arch/x86/include/asm/nospec-branch.h | 13 +++--
arch/x86/kernel/cpu/bugs.c | 75 ++++++++++++++++++++-----
arch/x86/kvm/x86.c | 4 +-
arch/x86/net/bpf_jit_comp.c | 11 +---
10 files changed, 116 insertions(+), 45 deletions(-)
---
base-commit: f338e77383789c0cae23ca3d48adcc5e9e137e3c
change-id: 20250916-vmscape-bhb-d7d469977f2f
Best regards,
--
Pawan
^ permalink raw reply
* [PATCH v7 01/10] x86/bhi: x86/vmscape: Move LFENCE out of clear_bhb_loop()
From: Pawan Gupta @ 2026-03-19 15:40 UTC (permalink / raw)
To: x86, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Sean Christopherson, Borislav Petkov, Dave Hansen,
Peter Zijlstra, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, KP Singh, Jiri Olsa, David S. Miller,
David Laight, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
David Ahern, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, Stanislav Fomichev, Hao Luo,
Paolo Bonzini, Jonathan Corbet
Cc: linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf, netdev,
linux-doc
In-Reply-To: <20260319-vmscape-bhb-v7-0-b76a777a98af@linux.intel.com>
Currently, BHB clearing sequence is followed by an LFENCE to prevent
transient execution of subsequent indirect branches prematurely. However,
LFENCE barrier could be unnecessary in certain cases. For example, when
kernel is using BHI_DIS_S mitigation, and BHB clearing is only needed for
userspace. In such cases, LFENCE is redundant because ring transitions
would provide the necessary serialization.
Below is a quick recap of BHI mitigation options:
On Alder Lake and newer
- BHI_DIS_S: Hardware control to mitigate BHI in ring0. This has low
performance overhead.
- Long loop: Alternatively, longer version of BHB clearing sequence
can be used to mitigate BHI. It can also be used to mitigate
BHI variant of VMSCAPE. This is not yet implemented in
Linux.
On older CPUs
- Short loop: Clears BHB at kernel entry and VMexit. The "Long loop" is
effective on older CPUs as well, but should be avoided
because of unnecessary overhead.
On Alder Lake and newer CPUs, eIBRS isolates the indirect targets between
guest and host. But when affected by the BHI variant of VMSCAPE, a guest's
branch history may still influence indirect branches in userspace. This
also means the big hammer IBPB could be replaced with a cheaper option that
clears the BHB at exit-to-userspace after a VMexit.
In preparation for adding the support for BHB sequence (without LFENCE) on
newer CPUs, move the LFENCE to the caller side after clear_bhb_loop() is
executed. Allow callers to decide whether they need the LFENCE or
not. This adds a few extra bytes to the call sites, but it obviates
the need for multiple variants of clear_bhb_loop().
Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Nikolay Borisov <nik.borisov@suse.com>
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
---
arch/x86/entry/entry_64.S | 5 ++++-
arch/x86/include/asm/nospec-branch.h | 4 ++--
arch/x86/net/bpf_jit_comp.c | 2 ++
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 42447b1e1dff..3a180a36ca0e 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -1528,6 +1528,9 @@ SYM_CODE_END(rewind_stack_and_make_dead)
* refactored in the future if needed. The .skips are for safety, to ensure
* that all RETs are in the second half of a cacheline to mitigate Indirect
* Target Selection, rather than taking the slowpath via its_return_thunk.
+ *
+ * Note, callers should use a speculation barrier like LFENCE immediately after
+ * a call to this function to ensure BHB is cleared before indirect branches.
*/
SYM_FUNC_START(clear_bhb_loop)
ANNOTATE_NOENDBR
@@ -1562,7 +1565,7 @@ SYM_FUNC_START(clear_bhb_loop)
sub $1, %ecx
jnz 1b
.Lret2: RET
-5: lfence
+5:
pop %rbp
RET
SYM_FUNC_END(clear_bhb_loop)
diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h
index 4f4b5e8a1574..70b377fcbc1c 100644
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -331,11 +331,11 @@
#ifdef CONFIG_X86_64
.macro CLEAR_BRANCH_HISTORY
- ALTERNATIVE "", "call clear_bhb_loop", X86_FEATURE_CLEAR_BHB_LOOP
+ ALTERNATIVE "", "call clear_bhb_loop; lfence", X86_FEATURE_CLEAR_BHB_LOOP
.endm
.macro CLEAR_BRANCH_HISTORY_VMEXIT
- ALTERNATIVE "", "call clear_bhb_loop", X86_FEATURE_CLEAR_BHB_VMEXIT
+ ALTERNATIVE "", "call clear_bhb_loop; lfence", X86_FEATURE_CLEAR_BHB_VMEXIT
.endm
#else
#define CLEAR_BRANCH_HISTORY
diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
index e9b78040d703..63d6c9fa5e80 100644
--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c
@@ -1624,6 +1624,8 @@ static int emit_spectre_bhb_barrier(u8 **pprog, u8 *ip,
if (emit_call(&prog, func, ip))
return -EINVAL;
+ /* Don't speculate past this until BHB is cleared */
+ EMIT_LFENCE();
EMIT1(0x59); /* pop rcx */
EMIT1(0x58); /* pop rax */
}
--
2.34.1
^ permalink raw reply related
* [PATCH v7 02/10] x86/bhi: Make clear_bhb_loop() effective on newer CPUs
From: Pawan Gupta @ 2026-03-19 15:40 UTC (permalink / raw)
To: x86, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Sean Christopherson, Borislav Petkov, Dave Hansen,
Peter Zijlstra, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, KP Singh, Jiri Olsa, David S. Miller,
David Laight, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
David Ahern, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, Stanislav Fomichev, Hao Luo,
Paolo Bonzini, Jonathan Corbet
Cc: linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf, netdev,
linux-doc
In-Reply-To: <20260319-vmscape-bhb-v7-0-b76a777a98af@linux.intel.com>
As a mitigation for BHI, clear_bhb_loop() executes branches that overwrites
the Branch History Buffer (BHB). On Alder Lake and newer parts this
sequence is not sufficient because it doesn't clear enough entries. This
was not an issue because these CPUs have a hardware control (BHI_DIS_S)
that mitigates BHI in kernel.
BHI variant of VMSCAPE requires isolating branch history between guests and
userspace. Note that there is no equivalent hardware control for userspace.
To effectively isolate branch history on newer CPUs, clear_bhb_loop()
should execute sufficient number of branches to clear a larger BHB.
Dynamically set the loop count of clear_bhb_loop() such that it is
effective on newer CPUs too. Use the hardware control enumeration
X86_FEATURE_BHI_CTRL to select the appropriate loop count.
Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Nikolay Borisov <nik.borisov@suse.com>
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
---
arch/x86/entry/entry_64.S | 21 ++++++++++++++++-----
arch/x86/net/bpf_jit_comp.c | 7 -------
2 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 3a180a36ca0e..8128e00ca73f 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -1535,8 +1535,17 @@ SYM_CODE_END(rewind_stack_and_make_dead)
SYM_FUNC_START(clear_bhb_loop)
ANNOTATE_NOENDBR
push %rbp
+ /* BPF caller may require %rax to be preserved */
+ push %rax
mov %rsp, %rbp
- movl $5, %ecx
+
+ /*
+ * Between the long and short version of BHB clear sequence, just the
+ * loop count differs based on BHI_CTRL, see Intel's BHI guidance.
+ */
+ ALTERNATIVE "movb $5, %al", \
+ "movb $12, %al", X86_FEATURE_BHI_CTRL
+
ANNOTATE_INTRA_FUNCTION_CALL
call 1f
jmp 5f
@@ -1556,16 +1565,18 @@ SYM_FUNC_START(clear_bhb_loop)
* This should be ideally be: .skip 32 - (.Lret2 - 2f), 0xcc
* but some Clang versions (e.g. 18) don't like this.
*/
- .skip 32 - 18, 0xcc
-2: movl $5, %eax
+ .skip 32 - 14, 0xcc
+2: ALTERNATIVE "movb $5, %ah", \
+ "movb $7, %ah", X86_FEATURE_BHI_CTRL
3: jmp 4f
nop
-4: sub $1, %eax
+4: sub $1, %ah
jnz 3b
- sub $1, %ecx
+ sub $1, %al
jnz 1b
.Lret2: RET
5:
+ pop %rax
pop %rbp
RET
SYM_FUNC_END(clear_bhb_loop)
diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
index 63d6c9fa5e80..e2cceabb23e8 100644
--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c
@@ -1614,11 +1614,6 @@ static int emit_spectre_bhb_barrier(u8 **pprog, u8 *ip,
u8 *func;
if (cpu_feature_enabled(X86_FEATURE_CLEAR_BHB_LOOP)) {
- /* The clearing sequence clobbers eax and ecx. */
- EMIT1(0x50); /* push rax */
- EMIT1(0x51); /* push rcx */
- ip += 2;
-
func = (u8 *)clear_bhb_loop;
ip += x86_call_depth_emit_accounting(&prog, func, ip);
@@ -1626,8 +1621,6 @@ static int emit_spectre_bhb_barrier(u8 **pprog, u8 *ip,
return -EINVAL;
/* Don't speculate past this until BHB is cleared */
EMIT_LFENCE();
- EMIT1(0x59); /* pop rcx */
- EMIT1(0x58); /* pop rax */
}
/* Insert IBHF instruction */
if ((cpu_feature_enabled(X86_FEATURE_CLEAR_BHB_LOOP) &&
--
2.34.1
^ permalink raw reply related
* [PATCH v7 03/10] x86/bhi: Rename clear_bhb_loop() to clear_bhb_loop_nofence()
From: Pawan Gupta @ 2026-03-19 15:40 UTC (permalink / raw)
To: x86, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Sean Christopherson, Borislav Petkov, Dave Hansen,
Peter Zijlstra, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, KP Singh, Jiri Olsa, David S. Miller,
David Laight, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
David Ahern, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, Stanislav Fomichev, Hao Luo,
Paolo Bonzini, Jonathan Corbet
Cc: linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf, netdev,
linux-doc
In-Reply-To: <20260319-vmscape-bhb-v7-0-b76a777a98af@linux.intel.com>
To reflect the recent change that moved LFENCE to the caller side.
Suggested-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
---
arch/x86/entry/entry_64.S | 8 ++++----
arch/x86/include/asm/nospec-branch.h | 6 +++---
arch/x86/net/bpf_jit_comp.c | 2 +-
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 8128e00ca73f..e9b81b95fcc8 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -1532,7 +1532,7 @@ SYM_CODE_END(rewind_stack_and_make_dead)
* Note, callers should use a speculation barrier like LFENCE immediately after
* a call to this function to ensure BHB is cleared before indirect branches.
*/
-SYM_FUNC_START(clear_bhb_loop)
+SYM_FUNC_START(clear_bhb_loop_nofence)
ANNOTATE_NOENDBR
push %rbp
/* BPF caller may require %rax to be preserved */
@@ -1579,6 +1579,6 @@ SYM_FUNC_START(clear_bhb_loop)
pop %rax
pop %rbp
RET
-SYM_FUNC_END(clear_bhb_loop)
-EXPORT_SYMBOL_FOR_KVM(clear_bhb_loop)
-STACK_FRAME_NON_STANDARD(clear_bhb_loop)
+SYM_FUNC_END(clear_bhb_loop_nofence)
+EXPORT_SYMBOL_FOR_KVM(clear_bhb_loop_nofence)
+STACK_FRAME_NON_STANDARD(clear_bhb_loop_nofence)
diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h
index 70b377fcbc1c..0f5e6ed6c9c2 100644
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -331,11 +331,11 @@
#ifdef CONFIG_X86_64
.macro CLEAR_BRANCH_HISTORY
- ALTERNATIVE "", "call clear_bhb_loop; lfence", X86_FEATURE_CLEAR_BHB_LOOP
+ ALTERNATIVE "", "call clear_bhb_loop_nofence; lfence", X86_FEATURE_CLEAR_BHB_LOOP
.endm
.macro CLEAR_BRANCH_HISTORY_VMEXIT
- ALTERNATIVE "", "call clear_bhb_loop; lfence", X86_FEATURE_CLEAR_BHB_VMEXIT
+ ALTERNATIVE "", "call clear_bhb_loop_nofence; lfence", X86_FEATURE_CLEAR_BHB_VMEXIT
.endm
#else
#define CLEAR_BRANCH_HISTORY
@@ -389,7 +389,7 @@ extern void entry_untrain_ret(void);
extern void write_ibpb(void);
#ifdef CONFIG_X86_64
-extern void clear_bhb_loop(void);
+extern void clear_bhb_loop_nofence(void);
#endif
extern void (*x86_return_thunk)(void);
diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
index e2cceabb23e8..b57e9ab51c5d 100644
--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c
@@ -1614,7 +1614,7 @@ static int emit_spectre_bhb_barrier(u8 **pprog, u8 *ip,
u8 *func;
if (cpu_feature_enabled(X86_FEATURE_CLEAR_BHB_LOOP)) {
- func = (u8 *)clear_bhb_loop;
+ func = (u8 *)clear_bhb_loop_nofence;
ip += x86_call_depth_emit_accounting(&prog, func, ip);
if (emit_call(&prog, func, ip))
--
2.34.1
^ permalink raw reply related
* [PATCH v7 04/10] x86/vmscape: Rename x86_ibpb_exit_to_user to x86_predictor_flush_exit_to_user
From: Pawan Gupta @ 2026-03-19 15:41 UTC (permalink / raw)
To: x86, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Sean Christopherson, Borislav Petkov, Dave Hansen,
Peter Zijlstra, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, KP Singh, Jiri Olsa, David S. Miller,
David Laight, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
David Ahern, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, Stanislav Fomichev, Hao Luo,
Paolo Bonzini, Jonathan Corbet
Cc: linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf, netdev,
linux-doc
In-Reply-To: <20260319-vmscape-bhb-v7-0-b76a777a98af@linux.intel.com>
With the upcoming changes x86_ibpb_exit_to_user will also be used when BHB
clearing sequence is used. Rename it cover both the cases.
No functional change.
Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
---
arch/x86/include/asm/entry-common.h | 6 +++---
arch/x86/include/asm/nospec-branch.h | 2 +-
arch/x86/kernel/cpu/bugs.c | 4 ++--
arch/x86/kvm/x86.c | 2 +-
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/x86/include/asm/entry-common.h b/arch/x86/include/asm/entry-common.h
index ce3eb6d5fdf9..c45858db16c9 100644
--- a/arch/x86/include/asm/entry-common.h
+++ b/arch/x86/include/asm/entry-common.h
@@ -94,11 +94,11 @@ static inline void arch_exit_to_user_mode_prepare(struct pt_regs *regs,
*/
choose_random_kstack_offset(rdtsc());
- /* Avoid unnecessary reads of 'x86_ibpb_exit_to_user' */
+ /* Avoid unnecessary reads of 'x86_predictor_flush_exit_to_user' */
if (cpu_feature_enabled(X86_FEATURE_IBPB_EXIT_TO_USER) &&
- this_cpu_read(x86_ibpb_exit_to_user)) {
+ this_cpu_read(x86_predictor_flush_exit_to_user)) {
indirect_branch_prediction_barrier();
- this_cpu_write(x86_ibpb_exit_to_user, false);
+ this_cpu_write(x86_predictor_flush_exit_to_user, false);
}
}
#define arch_exit_to_user_mode_prepare arch_exit_to_user_mode_prepare
diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h
index 0f5e6ed6c9c2..0a55b1c64741 100644
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -533,7 +533,7 @@ void alternative_msr_write(unsigned int msr, u64 val, unsigned int feature)
: "memory");
}
-DECLARE_PER_CPU(bool, x86_ibpb_exit_to_user);
+DECLARE_PER_CPU(bool, x86_predictor_flush_exit_to_user);
static inline void indirect_branch_prediction_barrier(void)
{
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 83f51cab0b1e..47c020b80371 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -65,8 +65,8 @@ EXPORT_PER_CPU_SYMBOL_GPL(x86_spec_ctrl_current);
* be needed to before running userspace. That IBPB will flush the branch
* predictor content.
*/
-DEFINE_PER_CPU(bool, x86_ibpb_exit_to_user);
-EXPORT_PER_CPU_SYMBOL_GPL(x86_ibpb_exit_to_user);
+DEFINE_PER_CPU(bool, x86_predictor_flush_exit_to_user);
+EXPORT_PER_CPU_SYMBOL_GPL(x86_predictor_flush_exit_to_user);
u64 x86_pred_cmd __ro_after_init = PRED_CMD_IBPB;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index fd1c4a36b593..45d7cfedc507 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -11464,7 +11464,7 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
* may migrate to.
*/
if (cpu_feature_enabled(X86_FEATURE_IBPB_EXIT_TO_USER))
- this_cpu_write(x86_ibpb_exit_to_user, true);
+ this_cpu_write(x86_predictor_flush_exit_to_user, true);
/*
* Consume any pending interrupts, including the possible source of
--
2.34.1
^ permalink raw reply related
* [PATCH v7 05/10] x86/vmscape: Move mitigation selection to a switch()
From: Pawan Gupta @ 2026-03-19 15:41 UTC (permalink / raw)
To: x86, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Sean Christopherson, Borislav Petkov, Dave Hansen,
Peter Zijlstra, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, KP Singh, Jiri Olsa, David S. Miller,
David Laight, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
David Ahern, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, Stanislav Fomichev, Hao Luo,
Paolo Bonzini, Jonathan Corbet
Cc: linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf, netdev,
linux-doc
In-Reply-To: <20260319-vmscape-bhb-v7-0-b76a777a98af@linux.intel.com>
This ensures that all mitigation modes are explicitly handled, while
keeping the mitigation selection for each mode together. This also prepares
for adding BHB-clearing mitigation mode for VMSCAPE.
Reviewed-by: Nikolay Borisov <nik.borisov@suse.com>
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
---
arch/x86/kernel/cpu/bugs.c | 24 ++++++++++++++++++++----
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 47c020b80371..68e2df3e3bf5 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -3084,17 +3084,33 @@ early_param("vmscape", vmscape_parse_cmdline);
static void __init vmscape_select_mitigation(void)
{
- if (!boot_cpu_has_bug(X86_BUG_VMSCAPE) ||
- !boot_cpu_has(X86_FEATURE_IBPB)) {
+ if (!boot_cpu_has_bug(X86_BUG_VMSCAPE)) {
vmscape_mitigation = VMSCAPE_MITIGATION_NONE;
return;
}
- if (vmscape_mitigation == VMSCAPE_MITIGATION_AUTO) {
- if (should_mitigate_vuln(X86_BUG_VMSCAPE))
+ if ((vmscape_mitigation == VMSCAPE_MITIGATION_AUTO) &&
+ !should_mitigate_vuln(X86_BUG_VMSCAPE))
+ vmscape_mitigation = VMSCAPE_MITIGATION_NONE;
+
+ switch (vmscape_mitigation) {
+ case VMSCAPE_MITIGATION_NONE:
+ break;
+
+ case VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER:
+ if (!boot_cpu_has(X86_FEATURE_IBPB))
+ vmscape_mitigation = VMSCAPE_MITIGATION_NONE;
+ break;
+
+ case VMSCAPE_MITIGATION_AUTO:
+ if (boot_cpu_has(X86_FEATURE_IBPB))
vmscape_mitigation = VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER;
else
vmscape_mitigation = VMSCAPE_MITIGATION_NONE;
+ break;
+
+ default:
+ break;
}
}
--
2.34.1
^ permalink raw reply related
* [PATCH v7 06/10] x86/vmscape: Use write_ibpb() instead of indirect_branch_prediction_barrier()
From: Pawan Gupta @ 2026-03-19 15:41 UTC (permalink / raw)
To: x86, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Sean Christopherson, Borislav Petkov, Dave Hansen,
Peter Zijlstra, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, KP Singh, Jiri Olsa, David S. Miller,
David Laight, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
David Ahern, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, Stanislav Fomichev, Hao Luo,
Paolo Bonzini, Jonathan Corbet
Cc: linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf, netdev,
linux-doc
In-Reply-To: <20260319-vmscape-bhb-v7-0-b76a777a98af@linux.intel.com>
indirect_branch_prediction_barrier() is a wrapper to write_ibpb(), which
also checks if the CPU supports IBPB. For VMSCAPE, call to
indirect_branch_prediction_barrier() is only possible when CPU supports
IBPB.
Simply call write_ibpb() directly to avoid unnecessary alternative
patching.
Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Nikolay Borisov <nik.borisov@suse.com>
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
---
arch/x86/include/asm/entry-common.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/entry-common.h b/arch/x86/include/asm/entry-common.h
index c45858db16c9..78b143673ca7 100644
--- a/arch/x86/include/asm/entry-common.h
+++ b/arch/x86/include/asm/entry-common.h
@@ -97,7 +97,7 @@ static inline void arch_exit_to_user_mode_prepare(struct pt_regs *regs,
/* Avoid unnecessary reads of 'x86_predictor_flush_exit_to_user' */
if (cpu_feature_enabled(X86_FEATURE_IBPB_EXIT_TO_USER) &&
this_cpu_read(x86_predictor_flush_exit_to_user)) {
- indirect_branch_prediction_barrier();
+ write_ibpb();
this_cpu_write(x86_predictor_flush_exit_to_user, false);
}
}
--
2.34.1
^ permalink raw reply related
* [PATCH v7 07/10] x86/vmscape: Use static_call() for predictor flush
From: Pawan Gupta @ 2026-03-19 15:41 UTC (permalink / raw)
To: x86, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Sean Christopherson, Borislav Petkov, Dave Hansen,
Peter Zijlstra, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, KP Singh, Jiri Olsa, David S. Miller,
David Laight, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
David Ahern, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, Stanislav Fomichev, Hao Luo,
Paolo Bonzini, Jonathan Corbet
Cc: linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf, netdev,
linux-doc
In-Reply-To: <20260319-vmscape-bhb-v7-0-b76a777a98af@linux.intel.com>
Adding more mitigation options at exit-to-userspace for VMSCAPE would
usually require a series of checks to decide which mitigation to use. In
this case, the mitigation is done by calling a function, which is decided
at boot. So, adding more feature flags and multiple checks can be avoided
by using static_call() to the mitigating function.
Replace the flag-based mitigation selector with a static_call(). This also
frees the existing X86_FEATURE_IBPB_EXIT_TO_USER.
Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
---
arch/x86/Kconfig | 1 +
arch/x86/include/asm/cpufeatures.h | 2 +-
arch/x86/include/asm/entry-common.h | 7 +++----
arch/x86/include/asm/nospec-branch.h | 3 +++
arch/x86/kernel/cpu/bugs.c | 13 ++++++++++++-
arch/x86/kvm/x86.c | 2 +-
6 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index e2df1b147184..5b8def9ddb98 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2720,6 +2720,7 @@ config MITIGATION_TSA
config MITIGATION_VMSCAPE
bool "Mitigate VMSCAPE"
depends on KVM
+ depends on HAVE_STATIC_CALL
default y
help
Enable mitigation for VMSCAPE attacks. VMSCAPE is a hardware security
diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
index dbe104df339b..b4d529dd6d30 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -503,7 +503,7 @@
#define X86_FEATURE_TSA_SQ_NO (21*32+11) /* AMD CPU not vulnerable to TSA-SQ */
#define X86_FEATURE_TSA_L1_NO (21*32+12) /* AMD CPU not vulnerable to TSA-L1 */
#define X86_FEATURE_CLEAR_CPU_BUF_VM (21*32+13) /* Clear CPU buffers using VERW before VMRUN */
-#define X86_FEATURE_IBPB_EXIT_TO_USER (21*32+14) /* Use IBPB on exit-to-userspace, see VMSCAPE bug */
+/* Free */
#define X86_FEATURE_ABMC (21*32+15) /* Assignable Bandwidth Monitoring Counters */
#define X86_FEATURE_MSR_IMM (21*32+16) /* MSR immediate form instructions */
#define X86_FEATURE_SGX_EUPDATESVN (21*32+17) /* Support for ENCLS[EUPDATESVN] instruction */
diff --git a/arch/x86/include/asm/entry-common.h b/arch/x86/include/asm/entry-common.h
index 78b143673ca7..783e7cb50cae 100644
--- a/arch/x86/include/asm/entry-common.h
+++ b/arch/x86/include/asm/entry-common.h
@@ -4,6 +4,7 @@
#include <linux/randomize_kstack.h>
#include <linux/user-return-notifier.h>
+#include <linux/static_call_types.h>
#include <asm/nospec-branch.h>
#include <asm/io_bitmap.h>
@@ -94,10 +95,8 @@ static inline void arch_exit_to_user_mode_prepare(struct pt_regs *regs,
*/
choose_random_kstack_offset(rdtsc());
- /* Avoid unnecessary reads of 'x86_predictor_flush_exit_to_user' */
- if (cpu_feature_enabled(X86_FEATURE_IBPB_EXIT_TO_USER) &&
- this_cpu_read(x86_predictor_flush_exit_to_user)) {
- write_ibpb();
+ if (unlikely(this_cpu_read(x86_predictor_flush_exit_to_user))) {
+ static_call_cond(vmscape_predictor_flush)();
this_cpu_write(x86_predictor_flush_exit_to_user, false);
}
}
diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h
index 0a55b1c64741..e45e49f1e0c9 100644
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -542,6 +542,9 @@ static inline void indirect_branch_prediction_barrier(void)
:: "rax", "rcx", "rdx", "memory");
}
+#include <linux/static_call_types.h>
+DECLARE_STATIC_CALL(vmscape_predictor_flush, write_ibpb);
+
/* The Intel SPEC CTRL MSR base value cache */
extern u64 x86_spec_ctrl_base;
DECLARE_PER_CPU(u64, x86_spec_ctrl_current);
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 68e2df3e3bf5..b75eda114503 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -144,6 +144,17 @@ EXPORT_SYMBOL_GPL(cpu_buf_idle_clear);
*/
DEFINE_STATIC_KEY_FALSE(switch_mm_cond_l1d_flush);
+/*
+ * Controls CPU Fill buffer clear before VMenter. This is a subset of
+ * X86_FEATURE_CLEAR_CPU_BUF, and should only be enabled when KVM-only
+ * mitigation is required.
+ */
+DEFINE_STATIC_KEY_FALSE(cpu_buf_vm_clear);
+EXPORT_SYMBOL_GPL(cpu_buf_vm_clear);
+
+DEFINE_STATIC_CALL_NULL(vmscape_predictor_flush, write_ibpb);
+EXPORT_STATIC_CALL_GPL(vmscape_predictor_flush);
+
#undef pr_fmt
#define pr_fmt(fmt) "mitigations: " fmt
@@ -3129,7 +3140,7 @@ static void __init vmscape_update_mitigation(void)
static void __init vmscape_apply_mitigation(void)
{
if (vmscape_mitigation == VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER)
- setup_force_cpu_cap(X86_FEATURE_IBPB_EXIT_TO_USER);
+ static_call_update(vmscape_predictor_flush, write_ibpb);
}
#undef pr_fmt
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 45d7cfedc507..5582056b2fa1 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -11463,7 +11463,7 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
* set for the CPU that actually ran the guest, and not the CPU that it
* may migrate to.
*/
- if (cpu_feature_enabled(X86_FEATURE_IBPB_EXIT_TO_USER))
+ if (static_call_query(vmscape_predictor_flush))
this_cpu_write(x86_predictor_flush_exit_to_user, true);
/*
--
2.34.1
^ permalink raw reply related
* [PATCH v7 08/10] x86/vmscape: Deploy BHB clearing mitigation
From: Pawan Gupta @ 2026-03-19 15:42 UTC (permalink / raw)
To: x86, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Sean Christopherson, Borislav Petkov, Dave Hansen,
Peter Zijlstra, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, KP Singh, Jiri Olsa, David S. Miller,
David Laight, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
David Ahern, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, Stanislav Fomichev, Hao Luo,
Paolo Bonzini, Jonathan Corbet
Cc: linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf, netdev,
linux-doc
In-Reply-To: <20260319-vmscape-bhb-v7-0-b76a777a98af@linux.intel.com>
IBPB mitigation for VMSCAPE is an overkill on CPUs that are only affected
by the BHI variant of VMSCAPE. On such CPUs, eIBRS already provides
indirect branch isolation between guest and host userspace. However, branch
history from guest may also influence the indirect branches in host
userspace.
To mitigate the BHI aspect, use the BHB clearing sequence.
Reviewed-by: Nikolay Borisov <nik.borisov@suse.com>
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
---
Documentation/admin-guide/hw-vuln/vmscape.rst | 4 ++++
arch/x86/include/asm/nospec-branch.h | 2 ++
arch/x86/kernel/cpu/bugs.c | 28 ++++++++++++++++++++-------
3 files changed, 27 insertions(+), 7 deletions(-)
diff --git a/Documentation/admin-guide/hw-vuln/vmscape.rst b/Documentation/admin-guide/hw-vuln/vmscape.rst
index d9b9a2b6c114..dc63a0bac03d 100644
--- a/Documentation/admin-guide/hw-vuln/vmscape.rst
+++ b/Documentation/admin-guide/hw-vuln/vmscape.rst
@@ -86,6 +86,10 @@ The possible values in this file are:
run a potentially malicious guest and issues an IBPB before the first
exit to userspace after VM-exit.
+ * 'Mitigation: Clear BHB before exit to userspace':
+
+ As above, conditional BHB clearing mitigation is enabled.
+
* 'Mitigation: IBPB on VMEXIT':
IBPB is issued on every VM-exit. This occurs when other mitigations like
diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h
index e45e49f1e0c9..7be812a73326 100644
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -390,6 +390,8 @@ extern void write_ibpb(void);
#ifdef CONFIG_X86_64
extern void clear_bhb_loop_nofence(void);
+#else
+static inline void clear_bhb_loop_nofence(void) {}
#endif
extern void (*x86_return_thunk)(void);
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index b75eda114503..444b41302533 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -61,9 +61,8 @@ DEFINE_PER_CPU(u64, x86_spec_ctrl_current);
EXPORT_PER_CPU_SYMBOL_GPL(x86_spec_ctrl_current);
/*
- * Set when the CPU has run a potentially malicious guest. An IBPB will
- * be needed to before running userspace. That IBPB will flush the branch
- * predictor content.
+ * Set when the CPU has run a potentially malicious guest. Indicates that a
+ * branch predictor flush is needed before running userspace.
*/
DEFINE_PER_CPU(bool, x86_predictor_flush_exit_to_user);
EXPORT_PER_CPU_SYMBOL_GPL(x86_predictor_flush_exit_to_user);
@@ -3061,13 +3060,15 @@ enum vmscape_mitigations {
VMSCAPE_MITIGATION_AUTO,
VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER,
VMSCAPE_MITIGATION_IBPB_ON_VMEXIT,
+ VMSCAPE_MITIGATION_BHB_CLEAR_EXIT_TO_USER,
};
static const char * const vmscape_strings[] = {
- [VMSCAPE_MITIGATION_NONE] = "Vulnerable",
+ [VMSCAPE_MITIGATION_NONE] = "Vulnerable",
/* [VMSCAPE_MITIGATION_AUTO] */
- [VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER] = "Mitigation: IBPB before exit to userspace",
- [VMSCAPE_MITIGATION_IBPB_ON_VMEXIT] = "Mitigation: IBPB on VMEXIT",
+ [VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER] = "Mitigation: IBPB before exit to userspace",
+ [VMSCAPE_MITIGATION_IBPB_ON_VMEXIT] = "Mitigation: IBPB on VMEXIT",
+ [VMSCAPE_MITIGATION_BHB_CLEAR_EXIT_TO_USER] = "Mitigation: Clear BHB before exit to userspace",
};
static enum vmscape_mitigations vmscape_mitigation __ro_after_init =
@@ -3114,7 +3115,17 @@ static void __init vmscape_select_mitigation(void)
break;
case VMSCAPE_MITIGATION_AUTO:
- if (boot_cpu_has(X86_FEATURE_IBPB))
+ /*
+ * CPUs with BHI_CTRL(ADL and newer) can avoid the IBPB and use
+ * BHB clear sequence. These CPUs are only vulnerable to the BHI
+ * variant of the VMSCAPE attack, and thus they do not require a
+ * full predictor flush.
+ *
+ * Note, in 32-bit mode BHB clear sequence is not supported.
+ */
+ if (boot_cpu_has(X86_FEATURE_BHI_CTRL) && IS_ENABLED(CONFIG_X86_64))
+ vmscape_mitigation = VMSCAPE_MITIGATION_BHB_CLEAR_EXIT_TO_USER;
+ else if (boot_cpu_has(X86_FEATURE_IBPB))
vmscape_mitigation = VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER;
else
vmscape_mitigation = VMSCAPE_MITIGATION_NONE;
@@ -3141,6 +3152,8 @@ static void __init vmscape_apply_mitigation(void)
{
if (vmscape_mitigation == VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER)
static_call_update(vmscape_predictor_flush, write_ibpb);
+ else if (vmscape_mitigation == VMSCAPE_MITIGATION_BHB_CLEAR_EXIT_TO_USER)
+ static_call_update(vmscape_predictor_flush, clear_bhb_loop_nofence);
}
#undef pr_fmt
@@ -3232,6 +3245,7 @@ void cpu_bugs_smt_update(void)
break;
case VMSCAPE_MITIGATION_IBPB_ON_VMEXIT:
case VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER:
+ case VMSCAPE_MITIGATION_BHB_CLEAR_EXIT_TO_USER:
/*
* Hypervisors can be attacked across-threads, warn for SMT when
* STIBP is not already enabled system-wide.
--
2.34.1
^ permalink raw reply related
* [PATCH v7 09/10] x86/vmscape: Fix conflicting attack-vector controls with =force
From: Pawan Gupta @ 2026-03-19 15:42 UTC (permalink / raw)
To: x86, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Sean Christopherson, Borislav Petkov, Dave Hansen,
Peter Zijlstra, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, KP Singh, Jiri Olsa, David S. Miller,
David Laight, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
David Ahern, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, Stanislav Fomichev, Hao Luo,
Paolo Bonzini, Jonathan Corbet
Cc: linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf, netdev,
linux-doc
In-Reply-To: <20260319-vmscape-bhb-v7-0-b76a777a98af@linux.intel.com>
vmscape=force option currently defaults to AUTO mitigation. This is not
correct because attack-vector controls overrides a mitigation in AUTO mode.
This prevents a user from being able to force VMSCAPE mitigation when it
conflicts with attack-vector controls.
Kernel should deploy a forced mitigation irrespective of attack vectors.
Instead of AUTO, use VMSCAPE_MITIGATION_ON that wins over attack-vector
controls.
Reviewed-by: Nikolay Borisov <nik.borisov@suse.com>
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
---
arch/x86/kernel/cpu/bugs.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 444b41302533..aa4a727f0abf 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -3058,6 +3058,7 @@ static void __init srso_apply_mitigation(void)
enum vmscape_mitigations {
VMSCAPE_MITIGATION_NONE,
VMSCAPE_MITIGATION_AUTO,
+ VMSCAPE_MITIGATION_ON,
VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER,
VMSCAPE_MITIGATION_IBPB_ON_VMEXIT,
VMSCAPE_MITIGATION_BHB_CLEAR_EXIT_TO_USER,
@@ -3066,6 +3067,7 @@ enum vmscape_mitigations {
static const char * const vmscape_strings[] = {
[VMSCAPE_MITIGATION_NONE] = "Vulnerable",
/* [VMSCAPE_MITIGATION_AUTO] */
+ /* [VMSCAPE_MITIGATION_ON] */
[VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER] = "Mitigation: IBPB before exit to userspace",
[VMSCAPE_MITIGATION_IBPB_ON_VMEXIT] = "Mitigation: IBPB on VMEXIT",
[VMSCAPE_MITIGATION_BHB_CLEAR_EXIT_TO_USER] = "Mitigation: Clear BHB before exit to userspace",
@@ -3085,7 +3087,7 @@ static int __init vmscape_parse_cmdline(char *str)
vmscape_mitigation = VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER;
} else if (!strcmp(str, "force")) {
setup_force_cpu_bug(X86_BUG_VMSCAPE);
- vmscape_mitigation = VMSCAPE_MITIGATION_AUTO;
+ vmscape_mitigation = VMSCAPE_MITIGATION_ON;
} else {
pr_err("Ignoring unknown vmscape=%s option.\n", str);
}
@@ -3115,6 +3117,7 @@ static void __init vmscape_select_mitigation(void)
break;
case VMSCAPE_MITIGATION_AUTO:
+ case VMSCAPE_MITIGATION_ON:
/*
* CPUs with BHI_CTRL(ADL and newer) can avoid the IBPB and use
* BHB clear sequence. These CPUs are only vulnerable to the BHI
@@ -3242,6 +3245,7 @@ void cpu_bugs_smt_update(void)
switch (vmscape_mitigation) {
case VMSCAPE_MITIGATION_NONE:
case VMSCAPE_MITIGATION_AUTO:
+ case VMSCAPE_MITIGATION_ON:
break;
case VMSCAPE_MITIGATION_IBPB_ON_VMEXIT:
case VMSCAPE_MITIGATION_IBPB_EXIT_TO_USER:
--
2.34.1
^ permalink raw reply related
* [PATCH v7 10/10] x86/vmscape: Add cmdline vmscape=on to override attack vector controls
From: Pawan Gupta @ 2026-03-19 15:42 UTC (permalink / raw)
To: x86, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Sean Christopherson, Borislav Petkov, Dave Hansen,
Peter Zijlstra, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, KP Singh, Jiri Olsa, David S. Miller,
David Laight, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
David Ahern, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, Stanislav Fomichev, Hao Luo,
Paolo Bonzini, Jonathan Corbet
Cc: linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf, netdev,
linux-doc
In-Reply-To: <20260319-vmscape-bhb-v7-0-b76a777a98af@linux.intel.com>
In general, individual mitigation controls can be used to override the
attack vector controls. But, nothing exists to select BHB clearing
mitigation for VMSCAPE. The =force option comes close, but with a
side-effect of also forcibly setting the bug, hence deploying the
mitigation on unaffected parts too.
Add a new cmdline option vmscape=on to enable the mitigation based on the
VMSCAPE variant the CPU is affected by.
Reviewed-by: Nikolay Borisov <nik.borisov@suse.com>
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
---
Documentation/admin-guide/hw-vuln/vmscape.rst | 4 ++++
Documentation/admin-guide/kernel-parameters.txt | 4 +++-
arch/x86/kernel/cpu/bugs.c | 2 ++
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/hw-vuln/vmscape.rst b/Documentation/admin-guide/hw-vuln/vmscape.rst
index dc63a0bac03d..580f288ae8bf 100644
--- a/Documentation/admin-guide/hw-vuln/vmscape.rst
+++ b/Documentation/admin-guide/hw-vuln/vmscape.rst
@@ -112,3 +112,7 @@ The mitigation can be controlled via the ``vmscape=`` command line parameter:
Force vulnerability detection and mitigation even on processors that are
not known to be affected.
+
+ * ``vmscape=on``:
+
+ Choose the mitigation based on the VMSCAPE variant the CPU is affected by.
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 03a550630644..1068569be5cf 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -8378,9 +8378,11 @@ Kernel parameters
off - disable the mitigation
ibpb - use Indirect Branch Prediction Barrier
- (IBPB) mitigation (default)
+ (IBPB) mitigation
force - force vulnerability detection even on
unaffected processors
+ on - (default) selects IBPB or BHB clear
+ mitigation based on CPU
vsyscall= [X86-64,EARLY]
Controls the behavior of vsyscalls (i.e. calls to
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index aa4a727f0abf..d3fa6c2ad341 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -3088,6 +3088,8 @@ static int __init vmscape_parse_cmdline(char *str)
} else if (!strcmp(str, "force")) {
setup_force_cpu_bug(X86_BUG_VMSCAPE);
vmscape_mitigation = VMSCAPE_MITIGATION_ON;
+ } else if (!strcmp(str, "on")) {
+ vmscape_mitigation = VMSCAPE_MITIGATION_ON;
} else {
pr_err("Ignoring unknown vmscape=%s option.\n", str);
}
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v9 1/7] arm64/acpi: Add acpi_get_cpu_uid() and switch arm_cspmu to use it
From: Punit Agrawal @ 2026-03-19 15:46 UTC (permalink / raw)
To: Chengwen Feng
Cc: Bjorn Helgaas, Catalin Marinas, Will Deacon, Rafael J . Wysocki,
Jonathan Corbet, Shuah Khan, Huacai Chen, WANG Xuerui,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H . Peter Anvin, Juergen Gross, Boris Ostrovsky, Len Brown,
Sunil V L, Mark Rutland, Jonathan Cameron, Kees Cook, Yanteng Si,
Sean Christopherson, Kai Huang, Tom Lendacky, Thomas Huth,
Thorsten Blum, Kevin Loughlin, Zheyun Shen, Peter Zijlstra,
Pawan Gupta, Xin Li, Ahmed S . Darwish, Sohil Mehta,
Ilkka Koskinen, Robin Murphy, James Clark, Besar Wicaksono, Ma Ke,
Wei Huang, Andy Gospodarek, Somnath Kotur, punit.agrawal,
guohanjun, suzuki.poulose, ryan.roberts, chenl311, masahiroy,
wangyuquan1236, anshuman.khandual, heinrich.schuchardt,
Eric.VanTassell, wangzhou1, wanghuiqiang, liuyonglong, linux-pci,
linux-doc, linux-kernel, linux-arm-kernel, loongarch, linux-riscv,
xen-devel, linux-acpi, linux-perf-users, stable
In-Reply-To: <20260319065735.45954-2-fengchengwen@huawei.com>
Chengwen Feng <fengchengwen@huawei.com> writes:
> Add arch-specific acpi_get_cpu_uid() for arm64, and update dependent
> code:
> - Declare acpi_get_cpu_uid() in arch/arm64/include/asm/acpi.h
> - Implement acpi_get_cpu_uid() with input parameter validation
> - Replace get_acpi_id_for_cpu() with acpi_get_cpu_uid() in
> drivers/perf/arm_cspmu/arm_cspmu.c
> - Reimplement get_cpu_for_acpi_id() based on acpi_get_cpu_uid() (to
> align with new interface) and move its implementation next to
> acpi_get_cpu_uid()
There is no benefit in describing the code changes like this in the
commit log. It makes it hard to follow the intent of the patch.
> This is the first step towards unifying ACPI CPU UID retrieval interface
> across architectures, while adding input validation for robustness.
I would simplify the commit log to something along the lines of -
As a step towards unifying the interface for retrieving ACPI CPU uid
across architectures, introduce a new function
acpi_get_cpu_uid(). While at it, also add input validation to make
the code more robust.
Just my 2c.
The code changes looks fine.
> Cc: stable@vger.kernel.org
> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> ---
> arch/arm64/include/asm/acpi.h | 14 ++------------
> arch/arm64/kernel/acpi.c | 30 ++++++++++++++++++++++++++++++
> drivers/perf/arm_cspmu/arm_cspmu.c | 6 ++++--
> 3 files changed, 36 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index c07a58b96329..2219a3301e72 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -118,18 +118,8 @@ static inline u32 get_acpi_id_for_cpu(unsigned int cpu)
> {
> return acpi_cpu_get_madt_gicc(cpu)->uid;
> }
> -
> -static inline int get_cpu_for_acpi_id(u32 uid)
> -{
> - int cpu;
> -
> - for (cpu = 0; cpu < nr_cpu_ids; cpu++)
> - if (acpi_cpu_get_madt_gicc(cpu) &&
> - uid == get_acpi_id_for_cpu(cpu))
> - return cpu;
> -
> - return -EINVAL;
> -}
> +int acpi_get_cpu_uid(unsigned int cpu, u32 *uid);
> +int get_cpu_for_acpi_id(u32 uid);
>
> static inline void arch_fix_phys_package_id(int num, u32 slot) { }
> void __init acpi_init_cpus(void);
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index af90128cfed5..24b9d934be54 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -458,3 +458,33 @@ int acpi_unmap_cpu(int cpu)
> }
> EXPORT_SYMBOL(acpi_unmap_cpu);
> #endif /* CONFIG_ACPI_HOTPLUG_CPU */
> +
> +int acpi_get_cpu_uid(unsigned int cpu, u32 *uid)
> +{
> + struct acpi_madt_generic_interrupt *gicc;
> +
> + if (cpu >= nr_cpu_ids)
> + return -EINVAL;
> +
> + gicc = acpi_cpu_get_madt_gicc(cpu);
> + if (!gicc)
> + return -ENODEV;
> +
> + *uid = gicc->uid;
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(acpi_get_cpu_uid);
> +
> +int get_cpu_for_acpi_id(u32 uid)
> +{
> + u32 cpu_uid;
> + int ret;
> +
> + for (int cpu = 0; cpu < nr_cpu_ids; cpu++) {
> + ret = acpi_get_cpu_uid(cpu, &cpu_uid);
> + if (ret == 0 && uid == cpu_uid)
> + return cpu;
> + }
> +
> + return -EINVAL;
> +}
> diff --git a/drivers/perf/arm_cspmu/arm_cspmu.c b/drivers/perf/arm_cspmu/arm_cspmu.c
> index 34430b68f602..ed72c3d1f796 100644
> --- a/drivers/perf/arm_cspmu/arm_cspmu.c
> +++ b/drivers/perf/arm_cspmu/arm_cspmu.c
> @@ -1107,15 +1107,17 @@ static int arm_cspmu_acpi_get_cpus(struct arm_cspmu *cspmu)
> {
> struct acpi_apmt_node *apmt_node;
> int affinity_flag;
> + u32 cpu_uid;
> int cpu;
> + int ret;
>
> apmt_node = arm_cspmu_apmt_node(cspmu->dev);
> affinity_flag = apmt_node->flags & ACPI_APMT_FLAGS_AFFINITY;
>
> if (affinity_flag == ACPI_APMT_FLAGS_AFFINITY_PROC) {
> for_each_possible_cpu(cpu) {
> - if (apmt_node->proc_affinity ==
> - get_acpi_id_for_cpu(cpu)) {
> + ret = acpi_get_cpu_uid(cpu, &cpu_uid);
> + if (ret == 0 && apmt_node->proc_affinity == cpu_uid) {
> cpumask_set_cpu(cpu, &cspmu->associated_cpus);
> break;
> }
I think cspmu changes go via a separate pull request. You might have to
split this change into a separate commit.
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH net-next v2 08/13] bnxt: use snapshot in bnxt_cfg_rx_mode
From: Stanislav Fomichev @ 2026-03-19 15:54 UTC (permalink / raw)
To: Loktionov, Aleksandr
Cc: Stanislav Fomichev, netdev@vger.kernel.org, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
horms@kernel.org, corbet@lwn.net, skhan@linuxfoundation.org,
andrew+netdev@lunn.ch, michael.chan@broadcom.com,
pavan.chebbi@broadcom.com, Nguyen, Anthony L, Kitszel, Przemyslaw,
saeedm@nvidia.com, tariqt@nvidia.com, mbloch@nvidia.com,
alexanderduyck@fb.com, kernel-team@meta.com,
johannes@sipsolutions.net, sd@queasysnail.net, jianbol@nvidia.com,
dtatulea@nvidia.com, mohsin.bashr@gmail.com, Keller, Jacob E,
willemb@google.com, skhawaja@google.com, bestswngs@gmail.com,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
intel-wired-lan@lists.osuosl.org, linux-rdma@vger.kernel.org,
linux-wireless@vger.kernel.org, linux-kselftest@vger.kernel.org,
leon@kernel.org
In-Reply-To: <IA3PR11MB89866985981DB64EFEBDF0ACE54FA@IA3PR11MB8986.namprd11.prod.outlook.com>
On 03/19, Loktionov, Aleksandr wrote:
>
>
> > -----Original Message-----
> > From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> > Of Stanislav Fomichev
> > Sent: Wednesday, March 18, 2026 4:03 PM
> > To: netdev@vger.kernel.org
> > Cc: davem@davemloft.net; edumazet@google.com; kuba@kernel.org;
> > pabeni@redhat.com; horms@kernel.org; corbet@lwn.net;
> > skhan@linuxfoundation.org; andrew+netdev@lunn.ch;
> > michael.chan@broadcom.com; pavan.chebbi@broadcom.com; Nguyen, Anthony
> > L <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw
> > <przemyslaw.kitszel@intel.com>; saeedm@nvidia.com; tariqt@nvidia.com;
> > mbloch@nvidia.com; alexanderduyck@fb.com; kernel-team@meta.com;
> > johannes@sipsolutions.net; sd@queasysnail.net; jianbol@nvidia.com;
> > dtatulea@nvidia.com; sdf@fomichev.me; mohsin.bashr@gmail.com; Keller,
> > Jacob E <jacob.e.keller@intel.com>; willemb@google.com;
> > skhawaja@google.com; bestswngs@gmail.com; linux-doc@vger.kernel.org;
> > linux-kernel@vger.kernel.org; intel-wired-lan@lists.osuosl.org; linux-
> > rdma@vger.kernel.org; linux-wireless@vger.kernel.org; linux-
> > kselftest@vger.kernel.org; leon@kernel.org
> > Subject: [Intel-wired-lan] [PATCH net-next v2 08/13] bnxt: use
> > snapshot in bnxt_cfg_rx_mode
> >
> > With the introduction of ndo_set_rx_mode_async (as discussed in [0])
> > we can call bnxt_cfg_rx_mode directly. Convert bnxt_cfg_rx_mode to use
> > uc/mc snapshots and move its call in bnxt_sp_task to the section that
> > resets BNXT_STATE_IN_SP_TASK. Switch to direct call in
> > bnxt_set_rx_mode.
> >
> > 0:
> > https://lore.kernel.org/netdev/CACKFLi=5vj8hPqEUKDd8RTw3au5G+zRgQEqjF+
> > 6NZnyoNm90KA@mail.gmail.com/
> >
> > Cc: Michael Chan <michael.chan@broadcom.com>
> > Cc: Pavan Chebbi <pavan.chebbi@broadcom.com>
> > Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
> > ---
> > drivers/net/ethernet/broadcom/bnxt/bnxt.c | 24 ++++++++++++++--------
> > -
> > 1 file changed, 15 insertions(+), 9 deletions(-)
>
> ...
>
> > -static int bnxt_cfg_rx_mode(struct bnxt *bp)
> > +static int bnxt_cfg_rx_mode(struct bnxt *bp, struct
> > netdev_hw_addr_list *uc,
> > + struct netdev_hw_addr_list *mc)
> > {
> > struct net_device *dev = bp->dev;
> > struct bnxt_vnic_info *vnic = &bp-
> > >vnic_info[BNXT_VNIC_DEFAULT];
> > @@ -13623,7 +13625,7 @@ static int bnxt_cfg_rx_mode(struct bnxt *bp)
> > bool uc_update;
> >
> > netif_addr_lock_bh(dev);
> > - uc_update = bnxt_uc_list_updated(bp, &dev->uc);
> > + uc_update = bnxt_uc_list_updated(bp, uc);
> > netif_addr_unlock_bh(dev);
> >
> > if (!uc_update)
> > @@ -13642,7 +13644,7 @@ static int bnxt_cfg_rx_mode(struct bnxt *bp)
> > if (netdev_uc_count(dev) > (BNXT_MAX_UC_ADDRS - 1)) {
> > vnic->rx_mask |=
> > CFA_L2_SET_RX_MASK_REQ_MASK_PROMISCUOUS;
> This limit check uses the live device list, dev->uc.
> In the new async model, the live list can differ from the snapshot.
Oh, yes, good catch! Will do s/netdev_uc_count/netdev_hw_addr_list_count(uc).
^ permalink raw reply
page: next (older) | prev (newer) | latest
- 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