* [PATCH v2 03/15] Drivers: hv: Move vmbus_handler to common code
From: Naman Jain @ 2026-04-23 12:41 UTC (permalink / raw)
To: K . Y . Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Catalin Marinas, Will Deacon, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H . Peter Anvin, Arnd Bergmann,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Michael Kelley
Cc: Marc Zyngier, Timothy Hayes, Lorenzo Pieralisi, Sascha Bischoff,
mrigendrachaubey, Naman Jain, linux-hyperv, linux-arm-kernel,
linux-kernel, linux-arch, linux-riscv, vdso, ssengar
In-Reply-To: <20260423124206.2410879-1-namjain@linux.microsoft.com>
Move the vmbus_handler global variable and hv_setup_vmbus_handler()/
hv_remove_vmbus_handler() from arch/x86 to drivers/hv/hv_common.c.
hv_setup_vmbus_handler() is called unconditionally in vmbus_bus_init()
and works for both x86 (sysvec handler) and arm64 (vmbus_percpu_isr).
This eliminates the need for separate percpu vmbus handler setup
functions and __weak stubs, that are needed for adding ARM64 support
in MSHV_VTL driver where we need to set a custom per-cpu vmbus handler.
Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
---
arch/x86/kernel/cpu/mshyperv.c | 12 ------------
drivers/hv/hv_common.c | 9 +++++++--
drivers/hv/vmbus_drv.c | 17 +++++++++--------
include/asm-generic/mshyperv.h | 1 +
4 files changed, 17 insertions(+), 22 deletions(-)
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 89a2eb8a0722..68706ff5880e 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -145,7 +145,6 @@ void hv_set_msr(unsigned int reg, u64 value)
EXPORT_SYMBOL_GPL(hv_set_msr);
static void (*mshv_handler)(void);
-static void (*vmbus_handler)(void);
static void (*hv_stimer0_handler)(void);
static void (*hv_kexec_handler)(void);
static void (*hv_crash_handler)(struct pt_regs *regs);
@@ -172,17 +171,6 @@ void hv_setup_mshv_handler(void (*handler)(void))
mshv_handler = handler;
}
-void hv_setup_vmbus_handler(void (*handler)(void))
-{
- vmbus_handler = handler;
-}
-
-void hv_remove_vmbus_handler(void)
-{
- /* We have no way to deallocate the interrupt gate */
- vmbus_handler = NULL;
-}
-
/*
* Routines to do per-architecture handling of stimer0
* interrupts when in Direct Mode
diff --git a/drivers/hv/hv_common.c b/drivers/hv/hv_common.c
index e8633bc51d56..eb7b0028b45d 100644
--- a/drivers/hv/hv_common.c
+++ b/drivers/hv/hv_common.c
@@ -758,13 +758,18 @@ bool __weak hv_isolation_type_tdx(void)
}
EXPORT_SYMBOL_GPL(hv_isolation_type_tdx);
-void __weak hv_setup_vmbus_handler(void (*handler)(void))
+void (*vmbus_handler)(void);
+EXPORT_SYMBOL_GPL(vmbus_handler);
+
+void hv_setup_vmbus_handler(void (*handler)(void))
{
+ vmbus_handler = handler;
}
EXPORT_SYMBOL_GPL(hv_setup_vmbus_handler);
-void __weak hv_remove_vmbus_handler(void)
+void hv_remove_vmbus_handler(void)
{
+ vmbus_handler = NULL;
}
EXPORT_SYMBOL_GPL(hv_remove_vmbus_handler);
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index bc4fc1951ae1..052ca8b11cee 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -1415,7 +1415,8 @@ EXPORT_SYMBOL_FOR_MODULES(vmbus_isr, "mshv_vtl");
static irqreturn_t vmbus_percpu_isr(int irq, void *dev_id)
{
- vmbus_isr();
+ if (vmbus_handler)
+ vmbus_handler();
return IRQ_HANDLED;
}
@@ -1517,8 +1518,10 @@ static int vmbus_bus_init(void)
vmbus_irq_initialized = true;
}
+ hv_setup_vmbus_handler(vmbus_isr);
+
if (vmbus_irq == -1) {
- hv_setup_vmbus_handler(vmbus_isr);
+ /* x86: sysvec handler uses vmbus_handler directly */
} else {
ret = request_percpu_irq(vmbus_irq, vmbus_percpu_isr,
"Hyper-V VMbus", &vmbus_evt);
@@ -1553,9 +1556,8 @@ static int vmbus_bus_init(void)
return 0;
err_connect:
- if (vmbus_irq == -1)
- hv_remove_vmbus_handler();
- else
+ hv_remove_vmbus_handler();
+ if (vmbus_irq != -1)
free_percpu_irq(vmbus_irq, &vmbus_evt);
err_setup:
if (IS_ENABLED(CONFIG_PREEMPT_RT) && vmbus_irq_initialized) {
@@ -3026,9 +3028,8 @@ static void __exit vmbus_exit(void)
vmbus_connection.conn_state = DISCONNECTED;
hv_stimer_global_cleanup();
vmbus_disconnect();
- if (vmbus_irq == -1)
- hv_remove_vmbus_handler();
- else
+ hv_remove_vmbus_handler();
+ if (vmbus_irq != -1)
free_percpu_irq(vmbus_irq, &vmbus_evt);
if (IS_ENABLED(CONFIG_PREEMPT_RT) && vmbus_irq_initialized) {
smpboot_unregister_percpu_thread(&vmbus_irq_threads);
diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyperv.h
index 2810aa05dc73..db183c8cfb95 100644
--- a/include/asm-generic/mshyperv.h
+++ b/include/asm-generic/mshyperv.h
@@ -179,6 +179,7 @@ static inline u64 hv_generate_guest_id(u64 kernel_version)
int hv_get_hypervisor_version(union hv_hypervisor_version_info *info);
+extern void (*vmbus_handler)(void);
void hv_setup_vmbus_handler(void (*handler)(void));
void hv_remove_vmbus_handler(void);
void hv_setup_stimer0_handler(void (*handler)(void));
--
2.43.0
^ permalink raw reply related
* [PATCH v2 04/15] mshv_vtl: Refactor the driver for ARM64 support to be added
From: Naman Jain @ 2026-04-23 12:41 UTC (permalink / raw)
To: K . Y . Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Catalin Marinas, Will Deacon, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H . Peter Anvin, Arnd Bergmann,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Michael Kelley
Cc: Marc Zyngier, Timothy Hayes, Lorenzo Pieralisi, Sascha Bischoff,
mrigendrachaubey, Naman Jain, linux-hyperv, linux-arm-kernel,
linux-kernel, linux-arch, linux-riscv, vdso, ssengar
In-Reply-To: <20260423124206.2410879-1-namjain@linux.microsoft.com>
Refactor MSHV_VTL driver to move some of the x86 specific code to arch
specific files, and add corresponding functions for arm64.
Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
Reviewed-by: Roman Kisel <vdso@mailbox.org>
Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
---
arch/arm64/include/asm/mshyperv.h | 10 +++
arch/x86/hyperv/hv_vtl.c | 98 ++++++++++++++++++++++++++++
arch/x86/include/asm/mshyperv.h | 1 +
drivers/hv/mshv_vtl_main.c | 102 +-----------------------------
4 files changed, 111 insertions(+), 100 deletions(-)
diff --git a/arch/arm64/include/asm/mshyperv.h b/arch/arm64/include/asm/mshyperv.h
index b721d3134ab6..585b23a26f1b 100644
--- a/arch/arm64/include/asm/mshyperv.h
+++ b/arch/arm64/include/asm/mshyperv.h
@@ -60,6 +60,16 @@ static inline u64 hv_get_non_nested_msr(unsigned int reg)
ARM_SMCCC_SMC_64, \
ARM_SMCCC_OWNER_VENDOR_HYP, \
HV_SMCCC_FUNC_NUMBER)
+#ifdef CONFIG_HYPERV_VTL_MODE
+/*
+ * Get/Set the register. If the function returns `1`, that must be done via
+ * a hypercall. Returning `0` means success.
+ */
+static inline int hv_vtl_get_set_reg(struct hv_register_assoc *regs, bool set, bool shared)
+{
+ return 1;
+}
+#endif
#include <asm-generic/mshyperv.h>
diff --git a/arch/x86/hyperv/hv_vtl.c b/arch/x86/hyperv/hv_vtl.c
index 9b6a9bc4ab76..09d81f9b853c 100644
--- a/arch/x86/hyperv/hv_vtl.c
+++ b/arch/x86/hyperv/hv_vtl.c
@@ -17,6 +17,8 @@
#include <asm/realmode.h>
#include <asm/reboot.h>
#include <asm/smap.h>
+#include <uapi/asm/mtrr.h>
+#include <asm/debugreg.h>
#include <linux/export.h>
#include <../kernel/smpboot.h>
#include "../../kernel/fpu/legacy.h"
@@ -281,3 +283,99 @@ void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0)
kernel_fpu_end();
}
EXPORT_SYMBOL(mshv_vtl_return_call);
+
+/* Static table mapping register names to their corresponding actions */
+static const struct {
+ enum hv_register_name reg_name;
+ int debug_reg_num; /* -1 if not a debug register */
+ u32 msr_addr; /* 0 if not an MSR */
+} reg_table[] = {
+ /* Debug registers */
+ {HV_X64_REGISTER_DR0, 0, 0},
+ {HV_X64_REGISTER_DR1, 1, 0},
+ {HV_X64_REGISTER_DR2, 2, 0},
+ {HV_X64_REGISTER_DR3, 3, 0},
+ {HV_X64_REGISTER_DR6, 6, 0},
+ /* MTRR MSRs */
+ {HV_X64_REGISTER_MSR_MTRR_CAP, -1, MSR_MTRRcap},
+ {HV_X64_REGISTER_MSR_MTRR_DEF_TYPE, -1, MSR_MTRRdefType},
+ {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE0, -1, MTRRphysBase_MSR(0)},
+ {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE1, -1, MTRRphysBase_MSR(1)},
+ {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE2, -1, MTRRphysBase_MSR(2)},
+ {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE3, -1, MTRRphysBase_MSR(3)},
+ {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE4, -1, MTRRphysBase_MSR(4)},
+ {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE5, -1, MTRRphysBase_MSR(5)},
+ {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE6, -1, MTRRphysBase_MSR(6)},
+ {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE7, -1, MTRRphysBase_MSR(7)},
+ {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE8, -1, MTRRphysBase_MSR(8)},
+ {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE9, -1, MTRRphysBase_MSR(9)},
+ {HV_X64_REGISTER_MSR_MTRR_PHYS_BASEA, -1, MTRRphysBase_MSR(0xa)},
+ {HV_X64_REGISTER_MSR_MTRR_PHYS_BASEB, -1, MTRRphysBase_MSR(0xb)},
+ {HV_X64_REGISTER_MSR_MTRR_PHYS_BASEC, -1, MTRRphysBase_MSR(0xc)},
+ {HV_X64_REGISTER_MSR_MTRR_PHYS_BASED, -1, MTRRphysBase_MSR(0xd)},
+ {HV_X64_REGISTER_MSR_MTRR_PHYS_BASEE, -1, MTRRphysBase_MSR(0xe)},
+ {HV_X64_REGISTER_MSR_MTRR_PHYS_BASEF, -1, MTRRphysBase_MSR(0xf)},
+ {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK0, -1, MTRRphysMask_MSR(0)},
+ {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK1, -1, MTRRphysMask_MSR(1)},
+ {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK2, -1, MTRRphysMask_MSR(2)},
+ {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK3, -1, MTRRphysMask_MSR(3)},
+ {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK4, -1, MTRRphysMask_MSR(4)},
+ {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK5, -1, MTRRphysMask_MSR(5)},
+ {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK6, -1, MTRRphysMask_MSR(6)},
+ {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK7, -1, MTRRphysMask_MSR(7)},
+ {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK8, -1, MTRRphysMask_MSR(8)},
+ {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK9, -1, MTRRphysMask_MSR(9)},
+ {HV_X64_REGISTER_MSR_MTRR_PHYS_MASKA, -1, MTRRphysMask_MSR(0xa)},
+ {HV_X64_REGISTER_MSR_MTRR_PHYS_MASKB, -1, MTRRphysMask_MSR(0xb)},
+ {HV_X64_REGISTER_MSR_MTRR_PHYS_MASKC, -1, MTRRphysMask_MSR(0xc)},
+ {HV_X64_REGISTER_MSR_MTRR_PHYS_MASKD, -1, MTRRphysMask_MSR(0xd)},
+ {HV_X64_REGISTER_MSR_MTRR_PHYS_MASKE, -1, MTRRphysMask_MSR(0xe)},
+ {HV_X64_REGISTER_MSR_MTRR_PHYS_MASKF, -1, MTRRphysMask_MSR(0xf)},
+ {HV_X64_REGISTER_MSR_MTRR_FIX64K00000, -1, MSR_MTRRfix64K_00000},
+ {HV_X64_REGISTER_MSR_MTRR_FIX16K80000, -1, MSR_MTRRfix16K_80000},
+ {HV_X64_REGISTER_MSR_MTRR_FIX16KA0000, -1, MSR_MTRRfix16K_A0000},
+ {HV_X64_REGISTER_MSR_MTRR_FIX4KC0000, -1, MSR_MTRRfix4K_C0000},
+ {HV_X64_REGISTER_MSR_MTRR_FIX4KC8000, -1, MSR_MTRRfix4K_C8000},
+ {HV_X64_REGISTER_MSR_MTRR_FIX4KD0000, -1, MSR_MTRRfix4K_D0000},
+ {HV_X64_REGISTER_MSR_MTRR_FIX4KD8000, -1, MSR_MTRRfix4K_D8000},
+ {HV_X64_REGISTER_MSR_MTRR_FIX4KE0000, -1, MSR_MTRRfix4K_E0000},
+ {HV_X64_REGISTER_MSR_MTRR_FIX4KE8000, -1, MSR_MTRRfix4K_E8000},
+ {HV_X64_REGISTER_MSR_MTRR_FIX4KF0000, -1, MSR_MTRRfix4K_F0000},
+ {HV_X64_REGISTER_MSR_MTRR_FIX4KF8000, -1, MSR_MTRRfix4K_F8000},
+};
+
+int hv_vtl_get_set_reg(struct hv_register_assoc *regs, bool set, bool shared)
+{
+ u64 *reg64;
+ enum hv_register_name gpr_name;
+ int i;
+
+ gpr_name = regs->name;
+ reg64 = ®s->value.reg64;
+
+ /* Search for the register in the table */
+ for (i = 0; i < ARRAY_SIZE(reg_table); i++) {
+ if (reg_table[i].reg_name != gpr_name)
+ continue;
+ if (reg_table[i].debug_reg_num != -1) {
+ /* Handle debug registers */
+ if (gpr_name == HV_X64_REGISTER_DR6 && !shared)
+ goto hypercall;
+ if (set)
+ native_set_debugreg(reg_table[i].debug_reg_num, *reg64);
+ else
+ *reg64 = native_get_debugreg(reg_table[i].debug_reg_num);
+ } else {
+ /* Handle MSRs */
+ if (set)
+ wrmsrl(reg_table[i].msr_addr, *reg64);
+ else
+ rdmsrl(reg_table[i].msr_addr, *reg64);
+ }
+ return 0;
+ }
+
+hypercall:
+ return 1;
+}
+EXPORT_SYMBOL(hv_vtl_get_set_reg);
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index 95b452387969..08278547b84c 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -290,6 +290,7 @@ void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0);
void mshv_vtl_return_call_init(u64 vtl_return_offset);
void mshv_vtl_return_hypercall(void);
void __mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0);
+int hv_vtl_get_set_reg(struct hv_register_assoc *regs, bool set, bool shared);
#else
static inline void __init hv_vtl_init_platform(void) {}
static inline int __init hv_vtl_early_init(void) { return 0; }
diff --git a/drivers/hv/mshv_vtl_main.c b/drivers/hv/mshv_vtl_main.c
index 5856975f32e1..b607b6e7e121 100644
--- a/drivers/hv/mshv_vtl_main.c
+++ b/drivers/hv/mshv_vtl_main.c
@@ -19,10 +19,8 @@
#include <linux/poll.h>
#include <linux/file.h>
#include <linux/vmalloc.h>
-#include <asm/debugreg.h>
#include <asm/mshyperv.h>
#include <trace/events/ipi.h>
-#include <uapi/asm/mtrr.h>
#include <uapi/linux/mshv.h>
#include <hyperv/hvhdk.h>
@@ -505,102 +503,6 @@ static int mshv_vtl_ioctl_set_poll_file(struct mshv_vtl_set_poll_file __user *us
return 0;
}
-/* Static table mapping register names to their corresponding actions */
-static const struct {
- enum hv_register_name reg_name;
- int debug_reg_num; /* -1 if not a debug register */
- u32 msr_addr; /* 0 if not an MSR */
-} reg_table[] = {
- /* Debug registers */
- {HV_X64_REGISTER_DR0, 0, 0},
- {HV_X64_REGISTER_DR1, 1, 0},
- {HV_X64_REGISTER_DR2, 2, 0},
- {HV_X64_REGISTER_DR3, 3, 0},
- {HV_X64_REGISTER_DR6, 6, 0},
- /* MTRR MSRs */
- {HV_X64_REGISTER_MSR_MTRR_CAP, -1, MSR_MTRRcap},
- {HV_X64_REGISTER_MSR_MTRR_DEF_TYPE, -1, MSR_MTRRdefType},
- {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE0, -1, MTRRphysBase_MSR(0)},
- {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE1, -1, MTRRphysBase_MSR(1)},
- {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE2, -1, MTRRphysBase_MSR(2)},
- {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE3, -1, MTRRphysBase_MSR(3)},
- {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE4, -1, MTRRphysBase_MSR(4)},
- {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE5, -1, MTRRphysBase_MSR(5)},
- {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE6, -1, MTRRphysBase_MSR(6)},
- {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE7, -1, MTRRphysBase_MSR(7)},
- {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE8, -1, MTRRphysBase_MSR(8)},
- {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE9, -1, MTRRphysBase_MSR(9)},
- {HV_X64_REGISTER_MSR_MTRR_PHYS_BASEA, -1, MTRRphysBase_MSR(0xa)},
- {HV_X64_REGISTER_MSR_MTRR_PHYS_BASEB, -1, MTRRphysBase_MSR(0xb)},
- {HV_X64_REGISTER_MSR_MTRR_PHYS_BASEC, -1, MTRRphysBase_MSR(0xc)},
- {HV_X64_REGISTER_MSR_MTRR_PHYS_BASED, -1, MTRRphysBase_MSR(0xd)},
- {HV_X64_REGISTER_MSR_MTRR_PHYS_BASEE, -1, MTRRphysBase_MSR(0xe)},
- {HV_X64_REGISTER_MSR_MTRR_PHYS_BASEF, -1, MTRRphysBase_MSR(0xf)},
- {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK0, -1, MTRRphysMask_MSR(0)},
- {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK1, -1, MTRRphysMask_MSR(1)},
- {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK2, -1, MTRRphysMask_MSR(2)},
- {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK3, -1, MTRRphysMask_MSR(3)},
- {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK4, -1, MTRRphysMask_MSR(4)},
- {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK5, -1, MTRRphysMask_MSR(5)},
- {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK6, -1, MTRRphysMask_MSR(6)},
- {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK7, -1, MTRRphysMask_MSR(7)},
- {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK8, -1, MTRRphysMask_MSR(8)},
- {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK9, -1, MTRRphysMask_MSR(9)},
- {HV_X64_REGISTER_MSR_MTRR_PHYS_MASKA, -1, MTRRphysMask_MSR(0xa)},
- {HV_X64_REGISTER_MSR_MTRR_PHYS_MASKB, -1, MTRRphysMask_MSR(0xb)},
- {HV_X64_REGISTER_MSR_MTRR_PHYS_MASKC, -1, MTRRphysMask_MSR(0xc)},
- {HV_X64_REGISTER_MSR_MTRR_PHYS_MASKD, -1, MTRRphysMask_MSR(0xd)},
- {HV_X64_REGISTER_MSR_MTRR_PHYS_MASKE, -1, MTRRphysMask_MSR(0xe)},
- {HV_X64_REGISTER_MSR_MTRR_PHYS_MASKF, -1, MTRRphysMask_MSR(0xf)},
- {HV_X64_REGISTER_MSR_MTRR_FIX64K00000, -1, MSR_MTRRfix64K_00000},
- {HV_X64_REGISTER_MSR_MTRR_FIX16K80000, -1, MSR_MTRRfix16K_80000},
- {HV_X64_REGISTER_MSR_MTRR_FIX16KA0000, -1, MSR_MTRRfix16K_A0000},
- {HV_X64_REGISTER_MSR_MTRR_FIX4KC0000, -1, MSR_MTRRfix4K_C0000},
- {HV_X64_REGISTER_MSR_MTRR_FIX4KC8000, -1, MSR_MTRRfix4K_C8000},
- {HV_X64_REGISTER_MSR_MTRR_FIX4KD0000, -1, MSR_MTRRfix4K_D0000},
- {HV_X64_REGISTER_MSR_MTRR_FIX4KD8000, -1, MSR_MTRRfix4K_D8000},
- {HV_X64_REGISTER_MSR_MTRR_FIX4KE0000, -1, MSR_MTRRfix4K_E0000},
- {HV_X64_REGISTER_MSR_MTRR_FIX4KE8000, -1, MSR_MTRRfix4K_E8000},
- {HV_X64_REGISTER_MSR_MTRR_FIX4KF0000, -1, MSR_MTRRfix4K_F0000},
- {HV_X64_REGISTER_MSR_MTRR_FIX4KF8000, -1, MSR_MTRRfix4K_F8000},
-};
-
-static int mshv_vtl_get_set_reg(struct hv_register_assoc *regs, bool set)
-{
- u64 *reg64;
- enum hv_register_name gpr_name;
- int i;
-
- gpr_name = regs->name;
- reg64 = ®s->value.reg64;
-
- /* Search for the register in the table */
- for (i = 0; i < ARRAY_SIZE(reg_table); i++) {
- if (reg_table[i].reg_name != gpr_name)
- continue;
- if (reg_table[i].debug_reg_num != -1) {
- /* Handle debug registers */
- if (gpr_name == HV_X64_REGISTER_DR6 &&
- !mshv_vsm_capabilities.dr6_shared)
- goto hypercall;
- if (set)
- native_set_debugreg(reg_table[i].debug_reg_num, *reg64);
- else
- *reg64 = native_get_debugreg(reg_table[i].debug_reg_num);
- } else {
- /* Handle MSRs */
- if (set)
- wrmsrl(reg_table[i].msr_addr, *reg64);
- else
- rdmsrl(reg_table[i].msr_addr, *reg64);
- }
- return 0;
- }
-
-hypercall:
- return 1;
-}
-
static void mshv_vtl_return(struct mshv_vtl_cpu_context *vtl0)
{
struct hv_vp_assist_page *hvp;
@@ -720,7 +622,7 @@ mshv_vtl_ioctl_get_regs(void __user *user_args)
sizeof(reg)))
return -EFAULT;
- ret = mshv_vtl_get_set_reg(®, false);
+ ret = hv_vtl_get_set_reg(®, false, mshv_vsm_capabilities.dr6_shared);
if (!ret)
goto copy_args; /* No need of hypercall */
ret = vtl_get_vp_register(®);
@@ -751,7 +653,7 @@ mshv_vtl_ioctl_set_regs(void __user *user_args)
if (copy_from_user(®, (void __user *)args.regs_ptr, sizeof(reg)))
return -EFAULT;
- ret = mshv_vtl_get_set_reg(®, true);
+ ret = hv_vtl_get_set_reg(®, true, mshv_vsm_capabilities.dr6_shared);
if (!ret)
return ret; /* No need of hypercall */
ret = vtl_set_vp_register(®);
--
2.43.0
^ permalink raw reply related
* [PATCH v2 05/15] Drivers: hv: Export vmbus_interrupt for mshv_vtl module
From: Naman Jain @ 2026-04-23 12:41 UTC (permalink / raw)
To: K . Y . Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Catalin Marinas, Will Deacon, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H . Peter Anvin, Arnd Bergmann,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Michael Kelley
Cc: Marc Zyngier, Timothy Hayes, Lorenzo Pieralisi, Sascha Bischoff,
mrigendrachaubey, Naman Jain, linux-hyperv, linux-arm-kernel,
linux-kernel, linux-arch, linux-riscv, vdso, ssengar
In-Reply-To: <20260423124206.2410879-1-namjain@linux.microsoft.com>
vmbus_interrupt is used in mshv_vtl_main.c to set the SINT vector.
When CONFIG_MSHV_VTL=m and CONFIG_HYPERV_VMBUS=y (built-in), the module
cannot access vmbus_interrupt at load time since it is not exported.
Export it using EXPORT_SYMBOL_FOR_MODULES consistent with the existing
pattern used for vmbus_isr.
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Reviewed-by: Roman Kisel <vdso@mailbox.org>
Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
---
drivers/hv/vmbus_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 052ca8b11cee..047ad2848782 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -57,6 +57,7 @@ static DEFINE_PER_CPU(long, vmbus_evt);
/* Values parsed from ACPI DSDT */
int vmbus_irq;
int vmbus_interrupt;
+EXPORT_SYMBOL_FOR_MODULES(vmbus_interrupt, "mshv_vtl");
/*
* If the Confidential VMBus is used, the data on the "wire" is not
--
2.43.0
^ permalink raw reply related
* [PATCH v2 06/15] mshv_vtl: Make sint vector architecture neutral
From: Naman Jain @ 2026-04-23 12:41 UTC (permalink / raw)
To: K . Y . Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Catalin Marinas, Will Deacon, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H . Peter Anvin, Arnd Bergmann,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Michael Kelley
Cc: Marc Zyngier, Timothy Hayes, Lorenzo Pieralisi, Sascha Bischoff,
mrigendrachaubey, Naman Jain, linux-hyperv, linux-arm-kernel,
linux-kernel, linux-arch, linux-riscv, vdso, ssengar
In-Reply-To: <20260423124206.2410879-1-namjain@linux.microsoft.com>
Generalize Synthetic interrupt source vector (sint) to use
vmbus_interrupt variable instead, which automatically takes care of
architectures where HYPERVISOR_CALLBACK_VECTOR is not present (arm64).
Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Reviewed-by: Roman Kisel <vdso@mailbox.org>
Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
---
drivers/hv/mshv_vtl_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hv/mshv_vtl_main.c b/drivers/hv/mshv_vtl_main.c
index b607b6e7e121..91517b45d526 100644
--- a/drivers/hv/mshv_vtl_main.c
+++ b/drivers/hv/mshv_vtl_main.c
@@ -234,7 +234,7 @@ static void mshv_vtl_synic_enable_regs(unsigned int cpu)
union hv_synic_sint sint;
sint.as_uint64 = 0;
- sint.vector = HYPERVISOR_CALLBACK_VECTOR;
+ sint.vector = vmbus_interrupt;
sint.masked = false;
sint.auto_eoi = hv_recommend_using_aeoi();
@@ -753,7 +753,7 @@ static void mshv_vtl_synic_mask_vmbus_sint(void *info)
const u8 *mask = info;
sint.as_uint64 = 0;
- sint.vector = HYPERVISOR_CALLBACK_VECTOR;
+ sint.vector = vmbus_interrupt;
sint.masked = (*mask != 0);
sint.auto_eoi = hv_recommend_using_aeoi();
--
2.43.0
^ permalink raw reply related
* [PATCH v2 08/15] Drivers: hv: Move hv_call_(get|set)_vp_registers() declarations
From: Naman Jain @ 2026-04-23 12:41 UTC (permalink / raw)
To: K . Y . Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Catalin Marinas, Will Deacon, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H . Peter Anvin, Arnd Bergmann,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Michael Kelley
Cc: Marc Zyngier, Timothy Hayes, Lorenzo Pieralisi, Sascha Bischoff,
mrigendrachaubey, Naman Jain, linux-hyperv, linux-arm-kernel,
linux-kernel, linux-arch, linux-riscv, vdso, ssengar
In-Reply-To: <20260423124206.2410879-1-namjain@linux.microsoft.com>
Move hv_call_get_vp_registers() and hv_call_set_vp_registers()
declarations from drivers/hv/mshv.h to include/asm-generic/mshyperv.h.
These functions are defined in mshv_common.c and are going to be called
from both drivers/hv/ and arch/x86/hyperv/hv_vtl.c. The latter never
included mshv.h, relying on implicit declaration visibility. Moving the
declarations to the arch-generic Hyper-V header makes them properly
visible to all architecture-specific callers.
Provide static inline stubs returning -EOPNOTSUPP when neither
CONFIG_MSHV_ROOT nor CONFIG_MSHV_VTL is enabled.
Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
---
drivers/hv/mshv.h | 8 --------
include/asm-generic/mshyperv.h | 26 ++++++++++++++++++++++++++
2 files changed, 26 insertions(+), 8 deletions(-)
diff --git a/drivers/hv/mshv.h b/drivers/hv/mshv.h
index d4813df92b9c..0fcb7f9ba6a9 100644
--- a/drivers/hv/mshv.h
+++ b/drivers/hv/mshv.h
@@ -14,14 +14,6 @@
memchr_inv(&((STRUCT).MEMBER), \
0, sizeof_field(typeof(STRUCT), MEMBER))
-int hv_call_get_vp_registers(u32 vp_index, u64 partition_id, u16 count,
- union hv_input_vtl input_vtl,
- struct hv_register_assoc *registers);
-
-int hv_call_set_vp_registers(u32 vp_index, u64 partition_id, u16 count,
- union hv_input_vtl input_vtl,
- struct hv_register_assoc *registers);
-
int hv_call_get_partition_property(u64 partition_id, u64 property_code,
u64 *property_value);
diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyperv.h
index 8cdf2a9fbdfb..ef0b9466808c 100644
--- a/include/asm-generic/mshyperv.h
+++ b/include/asm-generic/mshyperv.h
@@ -394,6 +394,32 @@ static inline int hv_deposit_memory(u64 partition_id, u64 status)
return hv_deposit_memory_node(NUMA_NO_NODE, partition_id, status);
}
+#if IS_ENABLED(CONFIG_MSHV_ROOT) || IS_ENABLED(CONFIG_MSHV_VTL)
+int hv_call_get_vp_registers(u32 vp_index, u64 partition_id, u16 count,
+ union hv_input_vtl input_vtl,
+ struct hv_register_assoc *registers);
+
+int hv_call_set_vp_registers(u32 vp_index, u64 partition_id, u16 count,
+ union hv_input_vtl input_vtl,
+ struct hv_register_assoc *registers);
+#else
+static inline int hv_call_get_vp_registers(u32 vp_index, u64 partition_id,
+ u16 count,
+ union hv_input_vtl input_vtl,
+ struct hv_register_assoc *registers)
+{
+ return -EOPNOTSUPP;
+}
+
+static inline int hv_call_set_vp_registers(u32 vp_index, u64 partition_id,
+ u16 count,
+ union hv_input_vtl input_vtl,
+ struct hv_register_assoc *registers)
+{
+ return -EOPNOTSUPP;
+}
+#endif /* CONFIG_MSHV_ROOT || CONFIG_MSHV_VTL */
+
#if IS_ENABLED(CONFIG_HYPERV_VTL_MODE)
u8 __init get_vtl(void);
void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0);
--
2.43.0
^ permalink raw reply related
* [PATCH v2 07/15] arm64: hyperv: Add support for mshv_vtl_return_call
From: Naman Jain @ 2026-04-23 12:41 UTC (permalink / raw)
To: K . Y . Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Catalin Marinas, Will Deacon, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H . Peter Anvin, Arnd Bergmann,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Michael Kelley
Cc: Marc Zyngier, Timothy Hayes, Lorenzo Pieralisi, Sascha Bischoff,
mrigendrachaubey, Naman Jain, linux-hyperv, linux-arm-kernel,
linux-kernel, linux-arch, linux-riscv, vdso, ssengar
In-Reply-To: <20260423124206.2410879-1-namjain@linux.microsoft.com>
Add the arm64 variant of mshv_vtl_return_call() to support the MSHV_VTL
driver on arm64. This function enables the transition between Virtual
Trust Levels (VTLs) in MSHV_VTL when the kernel acts as a paravisor.
Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
Reviewed-by: Roman Kisel <vdso@mailbox.org>
Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
---
arch/arm64/hyperv/Makefile | 1 +
arch/arm64/hyperv/hv_vtl.c | 158 ++++++++++++++++++++++++++++++
arch/arm64/include/asm/mshyperv.h | 13 +++
arch/x86/include/asm/mshyperv.h | 2 -
drivers/hv/mshv_vtl.h | 3 +
include/asm-generic/mshyperv.h | 2 +
6 files changed, 177 insertions(+), 2 deletions(-)
create mode 100644 arch/arm64/hyperv/hv_vtl.c
diff --git a/arch/arm64/hyperv/Makefile b/arch/arm64/hyperv/Makefile
index 87c31c001da9..9701a837a6e1 100644
--- a/arch/arm64/hyperv/Makefile
+++ b/arch/arm64/hyperv/Makefile
@@ -1,2 +1,3 @@
# SPDX-License-Identifier: GPL-2.0
obj-y := hv_core.o mshyperv.o
+obj-$(CONFIG_HYPERV_VTL_MODE) += hv_vtl.o
diff --git a/arch/arm64/hyperv/hv_vtl.c b/arch/arm64/hyperv/hv_vtl.c
new file mode 100644
index 000000000000..59cbeb74e7b9
--- /dev/null
+++ b/arch/arm64/hyperv/hv_vtl.c
@@ -0,0 +1,158 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2026, Microsoft, Inc.
+ *
+ * Authors:
+ * Roman Kisel <romank@linux.microsoft.com>
+ * Naman Jain <namjain@linux.microsoft.com>
+ */
+
+#include <asm/mshyperv.h>
+#include <asm/neon.h>
+#include <linux/export.h>
+
+void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0)
+{
+ struct user_fpsimd_state fpsimd_state;
+ u64 base_ptr = (u64)vtl0->x;
+
+ /*
+ * Obtain the CPU FPSIMD registers for VTL context switch.
+ * This saves the current task's FP/NEON state and allows us to
+ * safely load VTL0's FP/NEON context for the hypercall.
+ */
+ kernel_neon_begin(&fpsimd_state);
+
+ /*
+ * VTL switch for ARM64 platform - managing VTL0's CPU context.
+ * We explicitly use the stack to save the base pointer, and use x16
+ * as our working register for accessing the context structure.
+ *
+ * Register Handling:
+ * - X0-X17: Saved/restored (general-purpose, shared for VTL communication)
+ * - X18: NOT touched - hypervisor-managed per-VTL (platform register)
+ * - X19-X30: Saved/restored (part of VTL0's execution context)
+ * - Q0-Q31: Saved/restored (128-bit NEON/floating-point registers, shared)
+ * - SP: Not in structure, hypervisor-managed per-VTL
+ *
+ * X29 (FP) and X30 (LR) are in the structure and must be saved/restored
+ * as part of VTL0's complete execution state.
+ */
+ asm __volatile__ (
+ /* Save base pointer to stack explicitly, then load into x16 */
+ "str %0, [sp, #-16]!\n\t" /* Push base pointer onto stack */
+ "mov x16, %0\n\t" /* Load base pointer into x16 */
+ /* Volatile registers (Windows ARM64 ABI: x0-x17) */
+ "ldp x0, x1, [x16]\n\t"
+ "ldp x2, x3, [x16, #(2*8)]\n\t"
+ "ldp x4, x5, [x16, #(4*8)]\n\t"
+ "ldp x6, x7, [x16, #(6*8)]\n\t"
+ "ldp x8, x9, [x16, #(8*8)]\n\t"
+ "ldp x10, x11, [x16, #(10*8)]\n\t"
+ "ldp x12, x13, [x16, #(12*8)]\n\t"
+ "ldp x14, x15, [x16, #(14*8)]\n\t"
+ /* x16 will be loaded last, after saving base pointer */
+ "ldr x17, [x16, #(17*8)]\n\t"
+ /* x18 is hypervisor-managed per-VTL - DO NOT LOAD */
+
+ /* General-purpose registers: x19-x30 */
+ "ldp x19, x20, [x16, #(19*8)]\n\t"
+ "ldp x21, x22, [x16, #(21*8)]\n\t"
+ "ldp x23, x24, [x16, #(23*8)]\n\t"
+ "ldp x25, x26, [x16, #(25*8)]\n\t"
+ "ldp x27, x28, [x16, #(27*8)]\n\t"
+
+ /* Frame pointer and link register */
+ "ldp x29, x30, [x16, #(29*8)]\n\t"
+
+ /* Shared NEON/FP registers: Q0-Q31 (128-bit) */
+ "ldp q0, q1, [x16, #(32*8)]\n\t"
+ "ldp q2, q3, [x16, #(32*8 + 2*16)]\n\t"
+ "ldp q4, q5, [x16, #(32*8 + 4*16)]\n\t"
+ "ldp q6, q7, [x16, #(32*8 + 6*16)]\n\t"
+ "ldp q8, q9, [x16, #(32*8 + 8*16)]\n\t"
+ "ldp q10, q11, [x16, #(32*8 + 10*16)]\n\t"
+ "ldp q12, q13, [x16, #(32*8 + 12*16)]\n\t"
+ "ldp q14, q15, [x16, #(32*8 + 14*16)]\n\t"
+ "ldp q16, q17, [x16, #(32*8 + 16*16)]\n\t"
+ "ldp q18, q19, [x16, #(32*8 + 18*16)]\n\t"
+ "ldp q20, q21, [x16, #(32*8 + 20*16)]\n\t"
+ "ldp q22, q23, [x16, #(32*8 + 22*16)]\n\t"
+ "ldp q24, q25, [x16, #(32*8 + 24*16)]\n\t"
+ "ldp q26, q27, [x16, #(32*8 + 26*16)]\n\t"
+ "ldp q28, q29, [x16, #(32*8 + 28*16)]\n\t"
+ "ldp q30, q31, [x16, #(32*8 + 30*16)]\n\t"
+
+ /* Now load x16 itself */
+ "ldr x16, [x16, #(16*8)]\n\t"
+
+ /* Return to the lower VTL */
+ "hvc #3\n\t"
+
+ /* Save context after return - reload base pointer from stack */
+ "stp x16, x17, [sp, #-16]!\n\t" /* Save x16, x17 temporarily */
+ "ldr x16, [sp, #16]\n\t" /* Reload base pointer (skip saved x16,x17) */
+
+ /* Volatile registers */
+ "stp x0, x1, [x16]\n\t"
+ "stp x2, x3, [x16, #(2*8)]\n\t"
+ "stp x4, x5, [x16, #(4*8)]\n\t"
+ "stp x6, x7, [x16, #(6*8)]\n\t"
+ "stp x8, x9, [x16, #(8*8)]\n\t"
+ "stp x10, x11, [x16, #(10*8)]\n\t"
+ "stp x12, x13, [x16, #(12*8)]\n\t"
+ "stp x14, x15, [x16, #(14*8)]\n\t"
+ "ldp x0, x1, [sp], #16\n\t" /* Recover saved x16, x17 */
+ "stp x0, x1, [x16, #(16*8)]\n\t"
+ /* x18 is hypervisor-managed - DO NOT SAVE */
+
+ /* General-purpose registers: x19-x30 */
+ "stp x19, x20, [x16, #(19*8)]\n\t"
+ "stp x21, x22, [x16, #(21*8)]\n\t"
+ "stp x23, x24, [x16, #(23*8)]\n\t"
+ "stp x25, x26, [x16, #(25*8)]\n\t"
+ "stp x27, x28, [x16, #(27*8)]\n\t"
+ "stp x29, x30, [x16, #(29*8)]\n\t" /* Frame pointer and link register */
+
+ /* Shared NEON/FP registers: Q0-Q31 (128-bit) */
+ "stp q0, q1, [x16, #(32*8)]\n\t"
+ "stp q2, q3, [x16, #(32*8 + 2*16)]\n\t"
+ "stp q4, q5, [x16, #(32*8 + 4*16)]\n\t"
+ "stp q6, q7, [x16, #(32*8 + 6*16)]\n\t"
+ "stp q8, q9, [x16, #(32*8 + 8*16)]\n\t"
+ "stp q10, q11, [x16, #(32*8 + 10*16)]\n\t"
+ "stp q12, q13, [x16, #(32*8 + 12*16)]\n\t"
+ "stp q14, q15, [x16, #(32*8 + 14*16)]\n\t"
+ "stp q16, q17, [x16, #(32*8 + 16*16)]\n\t"
+ "stp q18, q19, [x16, #(32*8 + 18*16)]\n\t"
+ "stp q20, q21, [x16, #(32*8 + 20*16)]\n\t"
+ "stp q22, q23, [x16, #(32*8 + 22*16)]\n\t"
+ "stp q24, q25, [x16, #(32*8 + 24*16)]\n\t"
+ "stp q26, q27, [x16, #(32*8 + 26*16)]\n\t"
+ "stp q28, q29, [x16, #(32*8 + 28*16)]\n\t"
+ "stp q30, q31, [x16, #(32*8 + 30*16)]\n\t"
+
+ /* Clean up stack - pop base pointer */
+ "add sp, sp, #16\n\t"
+
+ : /* No outputs */
+ : /* Input */ "r"(base_ptr)
+ : /* Clobber list - x16 used as base, x18 is hypervisor-managed (not touched) */
+ "memory", "cc",
+ "x0", "x1", "x2", "x3", "x4", "x5",
+ "x6", "x7", "x8", "x9", "x10", "x11", "x12", "x13",
+ "x14", "x15", "x16", "x17", "x19", "x20", "x21",
+ "x22", "x23", "x24", "x25", "x26", "x27", "x28",
+ "x29", "x30",
+ "v0", "v1", "v2", "v3", "v4", "v5", "v6", "v7",
+ "v8", "v9", "v10", "v11", "v12", "v13", "v14", "v15",
+ "v16", "v17", "v18", "v19", "v20", "v21", "v22", "v23",
+ "v24", "v25", "v26", "v27", "v28", "v29", "v30", "v31");
+
+ /*
+ * Restore the task's FP/SIMD state and return CPU FPSIMD registers
+ * back to normal kernel use.
+ */
+ kernel_neon_end(&fpsimd_state);
+}
+EXPORT_SYMBOL(mshv_vtl_return_call);
diff --git a/arch/arm64/include/asm/mshyperv.h b/arch/arm64/include/asm/mshyperv.h
index 585b23a26f1b..9eb0e5999f29 100644
--- a/arch/arm64/include/asm/mshyperv.h
+++ b/arch/arm64/include/asm/mshyperv.h
@@ -60,6 +60,18 @@ static inline u64 hv_get_non_nested_msr(unsigned int reg)
ARM_SMCCC_SMC_64, \
ARM_SMCCC_OWNER_VENDOR_HYP, \
HV_SMCCC_FUNC_NUMBER)
+
+struct mshv_vtl_cpu_context {
+/*
+ * x18 is managed by the hypervisor. It won't be reloaded from this array.
+ * It is included here for convenience in array indexing.
+ * 'rsvd' field serves as alignment padding so q[] starts at offset 32*8=256.
+ */
+ __u64 x[31];
+ __u64 rsvd;
+ __uint128_t q[32];
+};
+
#ifdef CONFIG_HYPERV_VTL_MODE
/*
* Get/Set the register. If the function returns `1`, that must be done via
@@ -69,6 +81,7 @@ static inline int hv_vtl_get_set_reg(struct hv_register_assoc *regs, bool set, b
{
return 1;
}
+
#endif
#include <asm-generic/mshyperv.h>
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index 08278547b84c..b4d80c9a673a 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -286,7 +286,6 @@ struct mshv_vtl_cpu_context {
#ifdef CONFIG_HYPERV_VTL_MODE
void __init hv_vtl_init_platform(void);
int __init hv_vtl_early_init(void);
-void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0);
void mshv_vtl_return_call_init(u64 vtl_return_offset);
void mshv_vtl_return_hypercall(void);
void __mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0);
@@ -294,7 +293,6 @@ int hv_vtl_get_set_reg(struct hv_register_assoc *regs, bool set, bool shared);
#else
static inline void __init hv_vtl_init_platform(void) {}
static inline int __init hv_vtl_early_init(void) { return 0; }
-static inline void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0) {}
static inline void mshv_vtl_return_call_init(u64 vtl_return_offset) {}
static inline void mshv_vtl_return_hypercall(void) {}
static inline void __mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0) {}
diff --git a/drivers/hv/mshv_vtl.h b/drivers/hv/mshv_vtl.h
index a6eea52f7aa2..103f07371f3f 100644
--- a/drivers/hv/mshv_vtl.h
+++ b/drivers/hv/mshv_vtl.h
@@ -22,4 +22,7 @@ struct mshv_vtl_run {
char vtl_ret_actions[MSHV_MAX_RUN_MSG_SIZE];
};
+static_assert(sizeof(struct mshv_vtl_cpu_context) <= 1024,
+ "struct mshv_vtl_cpu_context exceeds reserved space in struct mshv_vtl_run");
+
#endif /* _MSHV_VTL_H */
diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyperv.h
index db183c8cfb95..8cdf2a9fbdfb 100644
--- a/include/asm-generic/mshyperv.h
+++ b/include/asm-generic/mshyperv.h
@@ -396,8 +396,10 @@ static inline int hv_deposit_memory(u64 partition_id, u64 status)
#if IS_ENABLED(CONFIG_HYPERV_VTL_MODE)
u8 __init get_vtl(void);
+void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0);
#else
static inline u8 get_vtl(void) { return 0; }
+static inline void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0) {}
#endif
#endif
--
2.43.0
^ permalink raw reply related
* [PATCH v2 09/15] Drivers: hv: mshv_vtl: Move hv_vtl_configure_reg_page() to x86
From: Naman Jain @ 2026-04-23 12:41 UTC (permalink / raw)
To: K . Y . Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Catalin Marinas, Will Deacon, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H . Peter Anvin, Arnd Bergmann,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Michael Kelley
Cc: Marc Zyngier, Timothy Hayes, Lorenzo Pieralisi, Sascha Bischoff,
mrigendrachaubey, Naman Jain, linux-hyperv, linux-arm-kernel,
linux-kernel, linux-arch, linux-riscv, vdso, ssengar
In-Reply-To: <20260423124206.2410879-1-namjain@linux.microsoft.com>
Move hv_vtl_configure_reg_page() from drivers/hv/mshv_vtl_main.c to
arch/x86/hyperv/hv_vtl.c. The register page overlay is an x86-specific
feature that uses HV_X64_REGISTER_REG_PAGE, so its configuration belongs
in architecture-specific code.
Move struct mshv_vtl_per_cpu and union hv_synic_overlay_page_msr to
include/asm-generic/mshyperv.h so they are visible to both arch and
driver code.
Change the return type from void to bool so the caller can determine
whether the register page was successfully configured and set
mshv_has_reg_page accordingly.
Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
---
arch/x86/hyperv/hv_vtl.c | 32 ++++++++++++++++++++++
drivers/hv/mshv_vtl_main.c | 49 +++-------------------------------
include/asm-generic/mshyperv.h | 17 ++++++++++++
3 files changed, 53 insertions(+), 45 deletions(-)
diff --git a/arch/x86/hyperv/hv_vtl.c b/arch/x86/hyperv/hv_vtl.c
index 09d81f9b853c..f3ffb6a7cb2d 100644
--- a/arch/x86/hyperv/hv_vtl.c
+++ b/arch/x86/hyperv/hv_vtl.c
@@ -20,6 +20,7 @@
#include <uapi/asm/mtrr.h>
#include <asm/debugreg.h>
#include <linux/export.h>
+#include <linux/hyperv.h>
#include <../kernel/smpboot.h>
#include "../../kernel/fpu/legacy.h"
@@ -259,6 +260,37 @@ int __init hv_vtl_early_init(void)
return 0;
}
+static const union hv_input_vtl input_vtl_zero;
+
+bool hv_vtl_configure_reg_page(struct mshv_vtl_per_cpu *per_cpu)
+{
+ struct hv_register_assoc reg_assoc = {};
+ union hv_synic_overlay_page_msr overlay = {};
+ struct page *reg_page;
+
+ reg_page = alloc_page(GFP_KERNEL | __GFP_ZERO | __GFP_RETRY_MAYFAIL);
+ if (!reg_page) {
+ WARN(1, "failed to allocate register page\n");
+ return false;
+ }
+
+ overlay.enabled = 1;
+ overlay.pfn = page_to_hvpfn(reg_page);
+ reg_assoc.name = HV_X64_REGISTER_REG_PAGE;
+ reg_assoc.value.reg64 = overlay.as_uint64;
+
+ if (hv_call_set_vp_registers(HV_VP_INDEX_SELF, HV_PARTITION_ID_SELF,
+ 1, input_vtl_zero, ®_assoc)) {
+ WARN(1, "failed to setup register page\n");
+ __free_page(reg_page);
+ return false;
+ }
+
+ per_cpu->reg_page = reg_page;
+ return true;
+}
+EXPORT_SYMBOL_GPL(hv_vtl_configure_reg_page);
+
DEFINE_STATIC_CALL_NULL(__mshv_vtl_return_hypercall, void (*)(void));
void mshv_vtl_return_call_init(u64 vtl_return_offset)
diff --git a/drivers/hv/mshv_vtl_main.c b/drivers/hv/mshv_vtl_main.c
index 91517b45d526..c79d24317b8e 100644
--- a/drivers/hv/mshv_vtl_main.c
+++ b/drivers/hv/mshv_vtl_main.c
@@ -78,21 +78,6 @@ struct mshv_vtl {
u64 id;
};
-struct mshv_vtl_per_cpu {
- struct mshv_vtl_run *run;
- struct page *reg_page;
-};
-
-/* SYNIC_OVERLAY_PAGE_MSR - internal, identical to hv_synic_simp */
-union hv_synic_overlay_page_msr {
- u64 as_uint64;
- struct {
- u64 enabled: 1;
- u64 reserved: 11;
- u64 pfn: 52;
- } __packed;
-};
-
static struct mutex mshv_vtl_poll_file_lock;
static union hv_register_vsm_page_offsets mshv_vsm_page_offsets;
static union hv_register_vsm_capabilities mshv_vsm_capabilities;
@@ -201,34 +186,6 @@ static struct page *mshv_vtl_cpu_reg_page(int cpu)
return *per_cpu_ptr(&mshv_vtl_per_cpu.reg_page, cpu);
}
-static void mshv_vtl_configure_reg_page(struct mshv_vtl_per_cpu *per_cpu)
-{
- struct hv_register_assoc reg_assoc = {};
- union hv_synic_overlay_page_msr overlay = {};
- struct page *reg_page;
-
- reg_page = alloc_page(GFP_KERNEL | __GFP_ZERO | __GFP_RETRY_MAYFAIL);
- if (!reg_page) {
- WARN(1, "failed to allocate register page\n");
- return;
- }
-
- overlay.enabled = 1;
- overlay.pfn = page_to_hvpfn(reg_page);
- reg_assoc.name = HV_X64_REGISTER_REG_PAGE;
- reg_assoc.value.reg64 = overlay.as_uint64;
-
- if (hv_call_set_vp_registers(HV_VP_INDEX_SELF, HV_PARTITION_ID_SELF,
- 1, input_vtl_zero, ®_assoc)) {
- WARN(1, "failed to setup register page\n");
- __free_page(reg_page);
- return;
- }
-
- per_cpu->reg_page = reg_page;
- mshv_has_reg_page = true;
-}
-
static void mshv_vtl_synic_enable_regs(unsigned int cpu)
{
union hv_synic_sint sint;
@@ -329,8 +286,10 @@ static int mshv_vtl_alloc_context(unsigned int cpu)
if (!per_cpu->run)
return -ENOMEM;
- if (mshv_vsm_capabilities.intercept_page_available)
- mshv_vtl_configure_reg_page(per_cpu);
+ if (mshv_vsm_capabilities.intercept_page_available) {
+ if (hv_vtl_configure_reg_page(per_cpu))
+ mshv_has_reg_page = true;
+ }
mshv_vtl_synic_enable_regs(cpu);
diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyperv.h
index ef0b9466808c..9e86178c182e 100644
--- a/include/asm-generic/mshyperv.h
+++ b/include/asm-generic/mshyperv.h
@@ -420,12 +420,29 @@ static inline int hv_call_set_vp_registers(u32 vp_index, u64 partition_id,
}
#endif /* CONFIG_MSHV_ROOT || CONFIG_MSHV_VTL */
+struct mshv_vtl_per_cpu {
+ struct mshv_vtl_run *run;
+ struct page *reg_page;
+};
+
#if IS_ENABLED(CONFIG_HYPERV_VTL_MODE)
+/* SYNIC_OVERLAY_PAGE_MSR - internal, identical to hv_synic_simp */
+union hv_synic_overlay_page_msr {
+ u64 as_uint64;
+ struct {
+ u64 enabled: 1;
+ u64 reserved: 11;
+ u64 pfn: 52;
+ } __packed;
+};
+
u8 __init get_vtl(void);
void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0);
+bool hv_vtl_configure_reg_page(struct mshv_vtl_per_cpu *per_cpu);
#else
static inline u8 get_vtl(void) { return 0; }
static inline void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0) {}
+static inline bool hv_vtl_configure_reg_page(struct mshv_vtl_per_cpu *per_cpu) { return false; }
#endif
#endif
--
2.43.0
^ permalink raw reply related
* [PATCH v2 10/15] arm64: hyperv: Add hv_vtl_configure_reg_page() stub
From: Naman Jain @ 2026-04-23 12:42 UTC (permalink / raw)
To: K . Y . Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Catalin Marinas, Will Deacon, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H . Peter Anvin, Arnd Bergmann,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Michael Kelley
Cc: Marc Zyngier, Timothy Hayes, Lorenzo Pieralisi, Sascha Bischoff,
mrigendrachaubey, Naman Jain, linux-hyperv, linux-arm-kernel,
linux-kernel, linux-arch, linux-riscv, vdso, ssengar
In-Reply-To: <20260423124206.2410879-1-namjain@linux.microsoft.com>
ARM64 does not support the register page overlay, so provide a stub
that returns false. This pairs with the preceding commit that moved
hv_vtl_configure_reg_page() out of common code into architecture-
specific files.
Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
---
arch/arm64/hyperv/hv_vtl.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/hyperv/hv_vtl.c b/arch/arm64/hyperv/hv_vtl.c
index 59cbeb74e7b9..e07f6a865350 100644
--- a/arch/arm64/hyperv/hv_vtl.c
+++ b/arch/arm64/hyperv/hv_vtl.c
@@ -156,3 +156,10 @@ void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0)
kernel_neon_end(&fpsimd_state);
}
EXPORT_SYMBOL(mshv_vtl_return_call);
+
+bool hv_vtl_configure_reg_page(struct mshv_vtl_per_cpu *per_cpu)
+{
+ pr_debug("Register page not supported on ARM64\n");
+ return false;
+}
+EXPORT_SYMBOL_GPL(hv_vtl_configure_reg_page);
--
2.43.0
^ permalink raw reply related
* [PATCH v2 11/15] mshv_vtl: Let userspace do VSM configuration
From: Naman Jain @ 2026-04-23 12:42 UTC (permalink / raw)
To: K . Y . Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Catalin Marinas, Will Deacon, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H . Peter Anvin, Arnd Bergmann,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Michael Kelley
Cc: Marc Zyngier, Timothy Hayes, Lorenzo Pieralisi, Sascha Bischoff,
mrigendrachaubey, Naman Jain, linux-hyperv, linux-arm-kernel,
linux-kernel, linux-arch, linux-riscv, vdso, ssengar
In-Reply-To: <20260423124206.2410879-1-namjain@linux.microsoft.com>
The kernel currently sets the VSM configuration register, thereby
imposing certain VSM configuration on the userspace (OpenVMM).
The userspace (OpenVMM) has the capability to configure this register,
and it is already doing it using the generic hypercall interface.
The configuration can vary based on the use case or architectures, so
let userspace take care of configuring it and remove this logic in the
kernel driver.
Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Reviewed-by: Roman Kisel <vdso@mailbox.org>
Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
---
drivers/hv/mshv_vtl_main.c | 29 -----------------------------
1 file changed, 29 deletions(-)
diff --git a/drivers/hv/mshv_vtl_main.c b/drivers/hv/mshv_vtl_main.c
index c79d24317b8e..4c9ae65ad3e8 100644
--- a/drivers/hv/mshv_vtl_main.c
+++ b/drivers/hv/mshv_vtl_main.c
@@ -222,30 +222,6 @@ static int mshv_vtl_get_vsm_regs(void)
return ret;
}
-static int mshv_vtl_configure_vsm_partition(struct device *dev)
-{
- union hv_register_vsm_partition_config config;
- struct hv_register_assoc reg_assoc;
-
- config.as_uint64 = 0;
- config.default_vtl_protection_mask = HV_MAP_GPA_PERMISSIONS_MASK;
- config.enable_vtl_protection = 1;
- config.zero_memory_on_reset = 1;
- config.intercept_vp_startup = 1;
- config.intercept_cpuid_unimplemented = 1;
-
- if (mshv_vsm_capabilities.intercept_page_available) {
- dev_dbg(dev, "using intercept page\n");
- config.intercept_page = 1;
- }
-
- reg_assoc.name = HV_REGISTER_VSM_PARTITION_CONFIG;
- reg_assoc.value.reg64 = config.as_uint64;
-
- return hv_call_set_vp_registers(HV_VP_INDEX_SELF, HV_PARTITION_ID_SELF,
- 1, input_vtl_zero, ®_assoc);
-}
-
static void mshv_vtl_vmbus_isr(void)
{
struct hv_per_cpu_context *per_cpu;
@@ -1168,11 +1144,6 @@ static int __init mshv_vtl_init(void)
ret = -ENODEV;
goto free_dev;
}
- if (mshv_vtl_configure_vsm_partition(dev)) {
- dev_emerg(dev, "VSM configuration failed !!\n");
- ret = -ENODEV;
- goto free_dev;
- }
mshv_vtl_return_call_init(mshv_vsm_page_offsets.vtl_return_offset);
ret = hv_vtl_setup_synic();
--
2.43.0
^ permalink raw reply related
* [PATCH v2 12/15] mshv_vtl: Move VSM code page offset logic to x86 files
From: Naman Jain @ 2026-04-23 12:42 UTC (permalink / raw)
To: K . Y . Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Catalin Marinas, Will Deacon, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H . Peter Anvin, Arnd Bergmann,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Michael Kelley
Cc: Marc Zyngier, Timothy Hayes, Lorenzo Pieralisi, Sascha Bischoff,
mrigendrachaubey, Naman Jain, linux-hyperv, linux-arm-kernel,
linux-kernel, linux-arch, linux-riscv, vdso, ssengar
In-Reply-To: <20260423124206.2410879-1-namjain@linux.microsoft.com>
The VSM code page offset register (HV_REGISTER_VSM_CODE_PAGE_OFFSETS)
is x86 specific, its value configures the static call used to return
to VTL0 via the hypercall page. Move the register read from the common
mshv_vtl_get_vsm_regs() into the x86 mshv_vtl_return_call_init(),
which is the sole consumer of the offset.
Change mshv_vtl_return_call_init() from taking a u64 parameter
to taking no arguments, and rename mshv_vtl_get_vsm_regs() to
mshv_vtl_get_vsm_cap_reg() since it now only fetches
HV_REGISTER_VSM_CAPABILITIES.
No functional change on x86. This prepares the common driver code for
ARM64 where VSM code page offsets do not apply.
Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
---
arch/x86/hyperv/hv_vtl.c | 19 +++++++++++++++++--
arch/x86/include/asm/mshyperv.h | 4 ++--
drivers/hv/mshv_vtl_main.c | 24 +++++++++++++-----------
3 files changed, 32 insertions(+), 15 deletions(-)
diff --git a/arch/x86/hyperv/hv_vtl.c b/arch/x86/hyperv/hv_vtl.c
index f3ffb6a7cb2d..7c10b34cf8a4 100644
--- a/arch/x86/hyperv/hv_vtl.c
+++ b/arch/x86/hyperv/hv_vtl.c
@@ -293,10 +293,25 @@ EXPORT_SYMBOL_GPL(hv_vtl_configure_reg_page);
DEFINE_STATIC_CALL_NULL(__mshv_vtl_return_hypercall, void (*)(void));
-void mshv_vtl_return_call_init(u64 vtl_return_offset)
+int mshv_vtl_return_call_init(void)
{
+ struct hv_register_assoc vsm_pg_offset_reg;
+ union hv_register_vsm_page_offsets offsets;
+ int ret;
+
+ vsm_pg_offset_reg.name = HV_REGISTER_VSM_CODE_PAGE_OFFSETS;
+
+ ret = hv_call_get_vp_registers(HV_VP_INDEX_SELF, HV_PARTITION_ID_SELF,
+ 1, input_vtl_zero, &vsm_pg_offset_reg);
+ if (ret)
+ return ret;
+
+ offsets.as_uint64 = vsm_pg_offset_reg.value.reg64;
+
static_call_update(__mshv_vtl_return_hypercall,
- (void *)((u8 *)hv_hypercall_pg + vtl_return_offset));
+ (void *)((u8 *)hv_hypercall_pg + offsets.vtl_return_offset));
+
+ return 0;
}
EXPORT_SYMBOL(mshv_vtl_return_call_init);
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index b4d80c9a673a..b48f115c1292 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -286,14 +286,14 @@ struct mshv_vtl_cpu_context {
#ifdef CONFIG_HYPERV_VTL_MODE
void __init hv_vtl_init_platform(void);
int __init hv_vtl_early_init(void);
-void mshv_vtl_return_call_init(u64 vtl_return_offset);
+int mshv_vtl_return_call_init(void);
void mshv_vtl_return_hypercall(void);
void __mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0);
int hv_vtl_get_set_reg(struct hv_register_assoc *regs, bool set, bool shared);
#else
static inline void __init hv_vtl_init_platform(void) {}
static inline int __init hv_vtl_early_init(void) { return 0; }
-static inline void mshv_vtl_return_call_init(u64 vtl_return_offset) {}
+static inline int mshv_vtl_return_call_init(void) { return 0; }
static inline void mshv_vtl_return_hypercall(void) {}
static inline void __mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0) {}
#endif
diff --git a/drivers/hv/mshv_vtl_main.c b/drivers/hv/mshv_vtl_main.c
index 4c9ae65ad3e8..be498c9234fd 100644
--- a/drivers/hv/mshv_vtl_main.c
+++ b/drivers/hv/mshv_vtl_main.c
@@ -79,7 +79,6 @@ struct mshv_vtl {
};
static struct mutex mshv_vtl_poll_file_lock;
-static union hv_register_vsm_page_offsets mshv_vsm_page_offsets;
static union hv_register_vsm_capabilities mshv_vsm_capabilities;
static DEFINE_PER_CPU(struct mshv_vtl_poll_file, mshv_vtl_poll_file);
@@ -203,21 +202,19 @@ static void mshv_vtl_synic_enable_regs(unsigned int cpu)
/* VTL2 Host VSP SINT is (un)masked when the user mode requests that */
}
-static int mshv_vtl_get_vsm_regs(void)
+static int mshv_vtl_get_vsm_cap_reg(void)
{
- struct hv_register_assoc registers[2];
- int ret, count = 2;
+ struct hv_register_assoc vsm_capability_reg;
+ int ret;
- registers[0].name = HV_REGISTER_VSM_CODE_PAGE_OFFSETS;
- registers[1].name = HV_REGISTER_VSM_CAPABILITIES;
+ vsm_capability_reg.name = HV_REGISTER_VSM_CAPABILITIES;
ret = hv_call_get_vp_registers(HV_VP_INDEX_SELF, HV_PARTITION_ID_SELF,
- count, input_vtl_zero, registers);
+ 1, input_vtl_zero, &vsm_capability_reg);
if (ret)
return ret;
- mshv_vsm_page_offsets.as_uint64 = registers[0].value.reg64;
- mshv_vsm_capabilities.as_uint64 = registers[1].value.reg64;
+ mshv_vsm_capabilities.as_uint64 = vsm_capability_reg.value.reg64;
return ret;
}
@@ -1139,13 +1136,18 @@ static int __init mshv_vtl_init(void)
tasklet_init(&msg_dpc, mshv_vtl_sint_on_msg_dpc, 0);
init_waitqueue_head(&fd_wait_queue);
- if (mshv_vtl_get_vsm_regs()) {
+ if (mshv_vtl_get_vsm_cap_reg()) {
dev_emerg(dev, "Unable to get VSM capabilities !!\n");
ret = -ENODEV;
goto free_dev;
}
- mshv_vtl_return_call_init(mshv_vsm_page_offsets.vtl_return_offset);
+ ret = mshv_vtl_return_call_init();
+ if (ret) {
+ dev_err(dev, "mshv_vtl_return_call_init failed: %d\n", ret);
+ goto free_dev;
+ }
+
ret = hv_vtl_setup_synic();
if (ret)
goto free_dev;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 13/15] mshv_vtl: Add remaining support for arm64
From: Naman Jain @ 2026-04-23 12:42 UTC (permalink / raw)
To: K . Y . Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Catalin Marinas, Will Deacon, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H . Peter Anvin, Arnd Bergmann,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Michael Kelley
Cc: Marc Zyngier, Timothy Hayes, Lorenzo Pieralisi, Sascha Bischoff,
mrigendrachaubey, Naman Jain, linux-hyperv, linux-arm-kernel,
linux-kernel, linux-arch, linux-riscv, vdso, ssengar
In-Reply-To: <20260423124206.2410879-1-namjain@linux.microsoft.com>
Add necessary support to make MSHV_VTL work for arm64 architecture.
* Add stub implementation for mshv_vtl_return_call_init() as it's not
required for arm64
* Handle hugepage functions by config checks, as it's x86 specific
* fpu/legacy.h header inclusion was required when x86 assembly code
was present here, it got left when the code was moved to arch files.
Remove it now (unrelated to arm64)
Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
---
arch/arm64/include/asm/mshyperv.h | 2 ++
drivers/hv/mshv_vtl_main.c | 4 ++--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/mshyperv.h b/arch/arm64/include/asm/mshyperv.h
index 9eb0e5999f29..6f668ec68b2f 100644
--- a/arch/arm64/include/asm/mshyperv.h
+++ b/arch/arm64/include/asm/mshyperv.h
@@ -82,6 +82,8 @@ static inline int hv_vtl_get_set_reg(struct hv_register_assoc *regs, bool set, b
return 1;
}
+/* Stubbed for arm64 */
+static inline int mshv_vtl_return_call_init(void) { return 0; }
#endif
#include <asm-generic/mshyperv.h>
diff --git a/drivers/hv/mshv_vtl_main.c b/drivers/hv/mshv_vtl_main.c
index be498c9234fd..d5308956dfb6 100644
--- a/drivers/hv/mshv_vtl_main.c
+++ b/drivers/hv/mshv_vtl_main.c
@@ -23,8 +23,6 @@
#include <trace/events/ipi.h>
#include <uapi/linux/mshv.h>
#include <hyperv/hvhdk.h>
-
-#include "../../kernel/fpu/legacy.h"
#include "mshv.h"
#include "mshv_vtl.h"
#include "hyperv_vmbus.h"
@@ -1077,10 +1075,12 @@ static vm_fault_t mshv_vtl_low_huge_fault(struct vm_fault *vmf, unsigned int ord
ret = vmf_insert_pfn_pmd(vmf, pfn, vmf->flags & FAULT_FLAG_WRITE);
return ret;
+#if defined(CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD)
case PUD_ORDER:
if (can_fault(vmf, PUD_SIZE, &pfn))
ret = vmf_insert_pfn_pud(vmf, pfn, vmf->flags & FAULT_FLAG_WRITE);
return ret;
+#endif
default:
return VM_FAULT_SIGBUS;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 14/15] Drivers: hv: Add 4K page dependency in MSHV_VTL
From: Naman Jain @ 2026-04-23 12:42 UTC (permalink / raw)
To: K . Y . Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Catalin Marinas, Will Deacon, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H . Peter Anvin, Arnd Bergmann,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Michael Kelley
Cc: Marc Zyngier, Timothy Hayes, Lorenzo Pieralisi, Sascha Bischoff,
mrigendrachaubey, Naman Jain, linux-hyperv, linux-arm-kernel,
linux-kernel, linux-arch, linux-riscv, vdso, ssengar
In-Reply-To: <20260423124206.2410879-1-namjain@linux.microsoft.com>
Add a dependency on 4K page size in Kconfig of MSHV_VTL
to support any assumptions that may be present in the code.
x86 anyways supports 4K page size only, and for arm64, higher
page size support is not validated. Remove this dependency as
and when this feature is supported.
Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
---
drivers/hv/Kconfig | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
index 7937ac0cbd0f..115821cc535c 100644
--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -96,6 +96,11 @@ config MSHV_VTL
# MTRRs are controlled by VTL0, and are not specific to individual VTLs.
# Therefore, do not attempt to access or modify MTRRs here.
depends on !MTRR
+ # The hypervisor interface operates on 4k pages. Enforcing it here
+ # simplifies many assumptions in the mshv_vtl code.
+ # VTL0 VMs can still support higher page size in ARM64 and is not limited
+ # by this setting.
+ depends on PAGE_SIZE_4KB
select CPUMASK_OFFSTACK
select VIRT_XFER_TO_GUEST_WORK
default n
--
2.43.0
^ permalink raw reply related
* [PATCH v2 15/15] Drivers: hv: Add ARM64 support for MSHV_VTL in Kconfig
From: Naman Jain @ 2026-04-23 12:42 UTC (permalink / raw)
To: K . Y . Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Catalin Marinas, Will Deacon, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H . Peter Anvin, Arnd Bergmann,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Michael Kelley
Cc: Marc Zyngier, Timothy Hayes, Lorenzo Pieralisi, Sascha Bischoff,
mrigendrachaubey, Naman Jain, linux-hyperv, linux-arm-kernel,
linux-kernel, linux-arch, linux-riscv, vdso, ssengar
In-Reply-To: <20260423124206.2410879-1-namjain@linux.microsoft.com>
Enable ARM64 support in MSHV_VTL Kconfig now that all the necessary
support is present.
Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Reviewed-by: Roman Kisel <vdso@mailbox.org>
Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
---
drivers/hv/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
index 115821cc535c..0bec3bc81a1a 100644
--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -87,7 +87,7 @@ config MSHV_ROOT
config MSHV_VTL
tristate "Microsoft Hyper-V VTL driver"
- depends on X86_64 && HYPERV_VTL_MODE
+ depends on (X86_64 || ARM64) && HYPERV_VTL_MODE
depends on HYPERV_VMBUS
# Mapping VTL0 memory to a userspace process in VTL2 is supported in OpenHCL.
# VTL2 for OpenHCL makes use of Huge Pages to improve performance on VMs,
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] cpu/hotplug: Fix NULL kobject warning in cpuhp_smt_enable()
From: Jinjie Ruan @ 2026-04-23 12:46 UTC (permalink / raw)
To: Catalin Marinas
Cc: tglx, peterz, sudeep.holla, yangyicong, dietmar.eggemann,
Jonathan.Cameron, linux-kernel, James Morse, linux-arm-kernel
In-Reply-To: <aeOd0Ndec2rQe2J8@arm.com>
On 4/18/2026 11:05 PM, Catalin Marinas wrote:
> On Sat, Apr 18, 2026 at 12:55:22PM +0100, Catalin Marinas wrote:
>> On Fri, Apr 17, 2026 at 03:55:34PM +0800, Jinjie Ruan wrote:
>>> When booting with `maxcpus` greater than the number of present CPUs (e.g.,
>>> QEMU -smp cpus=4,maxcpus=8), some CPUs are marked as 'present' but have not
>>> yet been registered via register_cpu(). Consequently, the per-cpu device
>>> objects for these CPUs are not yet initialized.
> [...]
>> Another option would have been to avoid marking such CPUs present but I
>> think this will break other things. Yet another option is to register
>> all CPU devices even if they never come up (like maxcpus greater than
>> actual CPUs).
>
> Something like below, untested (and I don't claim I properly understand
> this code; just lots of tokens used trying to make sense of it ;))
>
> ------------------------8<-------------------------
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index a9d884fd1d00..4c0a5ed906ea 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -448,12 +448,14 @@ int acpi_map_cpu(acpi_handle handle, phys_cpuid_t physid, u32 apci_id,
> return *pcpu;
> }
>
> + set_cpu_present(*pcpu, true);
> return 0;
> }
> EXPORT_SYMBOL(acpi_map_cpu);
>
> int acpi_unmap_cpu(int cpu)
> {
> + set_cpu_present(cpu, false);
This logic, where we set 'present' in acpi_map_cpu() and clear it in
acpi_unmap_cpu(), seems to align with how x86 does it.
acpi_map_cpu()
-> topology_hotplug_apic()
-> topo_set_cpuids()
-> set_cpu_present(cpu, true)
acpi_unmap_cpu()
-> topology_hotunplug_apic(cpu)
-> set_cpu_present(cpu, false)
Should we consider moving the setting/clearing of the 'present' bit into
the generic ACPI code (e.g., within the success path of acpi_map_cpu)?
This would ensure consistency across architectures and prevent new
implementations from missing these critical state updates.
> return 0;
> }
> EXPORT_SYMBOL(acpi_unmap_cpu);
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index 1aa324104afb..751a74d997e1 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -510,8 +510,10 @@ int arch_register_cpu(int cpu)
> struct cpu *c = &per_cpu(cpu_devices, cpu);
>
> if (!acpi_disabled && !acpi_handle &&
> - IS_ENABLED(CONFIG_ACPI_HOTPLUG_CPU))
> + IS_ENABLED(CONFIG_ACPI_HOTPLUG_CPU)) {
> + set_cpu_present(cpu, false);
> return -EPROBE_DEFER;
> + }
>
> #ifdef CONFIG_ACPI_HOTPLUG_CPU
> /* For now block anything that looks like physical CPU Hotplug */
>
^ permalink raw reply
* Re: [RFC PATCH v2 1/4] security: ima: call ima_init() again at late_initcall_sync for defered TPM
From: Jonathan McDowell @ 2026-04-23 12:53 UTC (permalink / raw)
To: Yeoreum Yun
Cc: Mimi Zohar, linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm, paul, jmorris, serge, roberto.sassu,
dmitry.kasatkin, eric.snowberg, jarkko, jgg, sudeep.holla, maz,
oupton, joey.gouly, suzuki.poulose, yuzenghui, catalin.marinas,
will, noodles, sebastianene
In-Reply-To: <aeoRxWPyOHGJd+Jh@e129823.arm.com>
On Thu, Apr 23, 2026 at 01:34:13PM +0100, Yeoreum Yun wrote:
>> > On Thu, 2026-04-23 at 06:55 +0100, Yeoreum Yun wrote:
>> > > > On Wed, 2026-04-22 at 20:41 +0100, Yeoreum Yun wrote:
>> > > > > > Hi Mimi,
>> > > > > >
>> > > > > > > On Wed, 2026-04-22 at 17:24 +0100, Yeoreum Yun wrote:
>> > > > > > > > To generate the boot_aggregate log in the IMA subsystem with TPM PCR values,
>> > > > > > > > the TPM driver must be built as built-in and
>> > > > > > > > must be probed before the IMA subsystem is initialized.
>> > > > > > > >
>> > > > > > > > However, when the TPM device operates over the FF-A protocol using
>> > > > > > > > the CRB interface, probing fails and returns -EPROBE_DEFER if
>> > > > > > > > the tpm_crb_ffa device — an FF-A device that provides the communication
>> > > > > > > > interface to the tpm_crb driver — has not yet been probed.
>> > > > > > > >
>> > > > > > > > To ensure the TPM device operating over the FF-A protocol with
>> > > > > > > > the CRB interface is probed before IMA initialization,
>> > > > > > > > the following conditions must be met:
>> > > > > > > >
>> > > > > > > > 1. The corresponding ffa_device must be registered,
>> > > > > > > > which is done via ffa_init().
>> > > > > > > >
>> > > > > > > > 2. The tpm_crb_driver must successfully probe this device via
>> > > > > > > > tpm_crb_ffa_init().
>> > > > > > > >
>> > > > > > > > 3. The tpm_crb driver using CRB over FF-A can then
>> > > > > > > > be probed successfully. (See crb_acpi_add() and
>> > > > > > > > tpm_crb_ffa_init() for reference.)
>> > > > > > > >
>> > > > > > > > Unfortunately, ffa_init(), tpm_crb_ffa_init(), and crb_acpi_driver_init() are
>> > > > > > > > all registered with device_initcall, which means crb_acpi_driver_init() may
>> > > > > > > > be invoked before ffa_init() and tpm_crb_ffa_init() are completed.
>> > > > > > > >
>> > > > > > > > When this occurs, probing the TPM device is deferred.
>> > > > > > > > However, the deferred probe can happen after the IMA subsystem
>> > > > > > > > has already been initialized, since IMA initialization is performed
>> > > > > > > > during late_initcall, and deferred_probe_initcall() is performed
>> > > > > > > > at the same level.
>> > > > > > > >
>> > > > > > > > To resolve this, call ima_init() again at late_inicall_sync level
>> > > > > > > > so that let IMA not miss TPM PCR value when generating boot_aggregate
>> > > > > > > > log though TPM device presents in the system.
>> > > > > > > >
>> > > > > > > > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
>> > > > > > >
>> > > > > > > A lot of change for just detecting whether ima_init() is being called on
>> > > > > > > late_initcall or late_initcall_sync(), without any explanation for all the other
>> > > > > > > changes (e.g. ima_init_core).
>> > > > > > >
>> > > > > > > Please just limit the change to just calling ima_init() twice.
>> > > > > >
>> > > > > > My concern is that ima_update_policy_flags() will be called
>> > > > > > when ima_init() is deferred -- not initialised anything.
>> > > > > > though functionally, it might be okay however,
>> > > > > > I think ima_update_policy_flags() and notifier should work after ima_init()
>> > > > > > works logically.
>> > > > > >
>> > > > > > This change I think not much quite a lot. just wrapper ima_init() with
>> > > > > > ima_init_core() with some error handling.
>> > > > > >
>> > > > > > Am I missing something?
>> > > > >
>> > > > > Also, if we handle in ima_init() only, but it failed with other reason,
>> > > > > we shouldn't call again ima_init() in the late_initcall_sync.
>> > > > >
>> > > > > To handle this, It wouldn't do in the ima_init() but we need to handle
>> > > > > it by caller of ima_init().
>> > > >
>> > > > Only tpm_default_chip() is being called to set the ima_tpm_chip. On failure,
>> > > > instead of going into TPM-bypass mode, return immediately. There are no calls
>> > > > to anything else. Just call ima_init() a second time.
>> > >
>> > > I’m not fully convinced this is sufficient.
>> > >
>> > > What I meant is the case where ima_init() fails due to other
>> > > initialisation steps, not only tpm_default_chip() (e.g. ima_fs_init()).
>> >
>> > The purpose of THIS patch is to add late_initcall_sync, when the TPM is not
>> > available at late_initcall. This would be classified as a bug fix and would be
>> > backported. No other changes should be included in this patch.
>>
>> Okay.
>>
>> > >
>> > > I’d also like to ask again whether it is fine to call
>> > > ima_update_policy_flags() and keep the notifier registered in the
>> > > deferred TPM case. While this may be functionally acceptable, it seems
>> > > logically questionable to do so when ima_init() has not completed.
>> >
>> > Other than extending the TPM, IMA should behave exactly the same whether there
>> > is a TPM or goes into TPM-bypass mode.
>> >
>> > >
>> > > There is also a possibility that a deferred case ultimately fails (e.g.
>> > > deferred at late_initcall, but then failing at late_initcall_sync
>> > > for another reason, even while entering TPM bypass mode). In that case,
>> > > it seems more appropriate to handle this state in the caller of
>> > > ima_init(), rather than inside ima_init() itself.
>> >
>> > If the TPM isn't found at late_initcall_sync(), then IMA should go into TPM-
>> > bypass mode. Please don't make any other changes to the existing IMA behavior
>> > and hide it here behind the late_initcall_sync change.
>>
>> Okay. you're talking called ima_update_policy_flags() at late_initcall
>> wouldn't be not a problem even in case of late_initcall_sync's ima_init()
>> get failed with "TPM-bypass mode".
>>
>> I see then, I'll make a patch simpler then.
>
>But I think in case of below situation:
> - late_initcall's first ima_init() is deferred.
> - late_initcall_sync try again but failed and try again with
> CONFIG_IMA_DEFAULT_HASH.
>
>I would like to sustain init_ima_core to reduce the same code repeat
>in late_initcall_sync.
I think what Mimi's proposing is:
If we're in late_initcall, and the TPM isn't available, return
immediately with an error (the EPROBE_DEFER?), don't do any init.
If we're in late_initcall_sync, either we're already initialised, so do
return and nothing, or run through the entire flow, even if the TPM
isn't unavailable.
So ima_init() just needs to know a) if it's in the sync or non-sync mode
and b) for the sync mode, if we've already done the init at
non-sync.
J.
--
... I'm not popular enough to be different.
^ permalink raw reply
* Re: [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere
From: Mathieu Desnoyers @ 2026-04-23 12:53 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Jinjie Ruan, linux-man, Thomas Gleixner, Mark Rutland,
Mathias Stearn, Catalin Marinas, Will Deacon, Boqun Feng,
Paul E. McKenney, Chris Kennelly, regressions, linux-kernel,
linux-arm-kernel, Peter Zijlstra, Ingo Molnar, Blake Oler,
Michael Jeanson
In-Reply-To: <CACT4Y+bMH+q2C7Xg9oHRP5ZbmvLpMpYzrdAd7B6XoXYc8=22sQ@mail.gmail.com>
On 2026-04-23 08:36, Dmitry Vyukov wrote:
> On Thu, 23 Apr 2026 at 14:29, Mathieu Desnoyers
> <mathieu.desnoyers@efficios.com> wrote:
>>
>> On 2026-04-23 01:53, Dmitry Vyukov wrote:
>> [...]
>>> +linux-man
>>>
>>> This part of the rseq man page needs to be fixed as well I think. The
>>> kernel no longer reliably provides clearing of rseq_cs on preemption,
>>> right?
>>>
>>> https://git.kernel.org/pub/scm/libs/librseq/librseq.git/tree/doc/man/rseq.2#n241
>>
>> I'm maintaining this manual page in librseq.
>>
>>>
>>> "and set to NULL by the kernel when it restarts an assembly
>>> instruction sequence block,
>>> as well as when the kernel detects that it is preempting or delivering
>>> a signal outside of the range targeted by the rseq_cs."
>>
>> I think you got two things confused here.
>>
>> 1) There is currently a bug on arm64 where it fails to honor the
>> rseq ABI contract wrt critical section abort. AFAIU there is a
>> fix proposed for this.
>>
>> 2) Thomas relaxed the implementation of cpu_id_start field updates
>> so it only stores to the rseq area when the current cpu actually
>> changes (migration).
>>
>> So AFAIU the statement in the man page is still fine. It's just arm64
>> that needs fixing.
>
>
> My understanding was that due to the ev->user_irq check here:
>
> +static __always_inline void rseq_sched_switch_event(struct task_struct *t)
> ...
> + bool raise = (ev->user_irq | ev->ids_changed) & ev->has_rseq;
> +
> + if (raise) {
> + ev->sched_switch = true;
> + rseq_raise_notify_resume(t);
> + }
>
> There won't be any rseq-related processing for threads preempted in
> syscalls, which means that rseq_cs won't be NULLed for threads
> preempted inside of syscalls.
Let's see if I understand your concern correctly. Scenario:
A thread is within a rseq critical section. It exits the critical
section without clearing the rseq_cs pointer, expecting the kernel
to lazily clear the rseq_cs pointer eventually when it detects that
it's not nested on top of the userspace critical section anymore.
It then calls a system call _outside_ of the rseq critical section,
but with rseq_cs pointer set. Based on the rseq man page wording,
it would then expect the preemption within the system call to guarantee
clearing that that pointer.
Here is the relevant comment block in the man page:
Updated by user-space, which sets the address of the cur‐
rently active rseq_cs at the beginning of assembly instruc‐
tion sequence block, and set to NULL by the kernel when it
restarts an assembly instruction sequence block, as well as
>>>>>>>>>
when the kernel detects that it is preempting or delivering
a signal outside of the range targeted by the rseq_cs.
>>>>>>>>>
^^^ this
The whole point about lazy-clearing of rseq_cs is that it _may_ happen when
the kernel preempts or delivers a signal (or at any point really), but it's
just an optimization.
Updating the manual page with this wording would match the intent:
Updated by user-space, which sets the address of the cur‐
rently active rseq_cs at the beginning of assembly instruc‐
tion sequence block, and set to NULL by the kernel when it
restarts an assembly instruction sequence block. May be set
to NULL by the kernel when it detects that the current
instruction pointer is outside of the range targeted by
the rseq_cs.
Also needs to be set to NULL by user-space before reclaim‐
ing memory that contains the targeted struct rseq_cs.
Thoughts ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
^ permalink raw reply
* Re: [PATCH v13 0/4] Enable Remote GPIO over RPMSG on i.MX Platform
From: Mathieu Poirier @ 2026-04-23 12:53 UTC (permalink / raw)
To: Shenwei Wang, Andrew Lunn
Cc: Linus Walleij, Bartosz Golaszewski, Jonathan Corbet, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Frank Li,
Sascha Hauer, Shuah Khan, linux-gpio, linux-doc, linux-kernel,
Pengutronix Kernel Team, Fabio Estevam, Peng Fan, devicetree,
linux-remoteproc, imx, linux-arm-kernel, linux-imx
In-Reply-To: <20260422212849.1240591-1-shenwei.wang@nxp.com>
Once again Andrew Lunn was left out.
On Wed, 22 Apr 2026 at 15:29, Shenwei Wang <shenwei.wang@nxp.com> wrote:
>
> Support the remote devices on the remote processor via the RPMSG bus on
> i.MX platform.
>
> Changes in v13:
> - drop the support for legacy NXP firmware.
> - remove the fixed_up hooks from the rpmsg gpio driver.
> - code cleanup.
>
> Changes in v12:
> - Fixed the "underline" warning reported by Randy.
>
> Changes in v11:
> - Expand RPMSG for the first time per Shuah's review comment.
>
> Changes in v10:
> - Update gpio-rpmsg.rst according to Daniel Baluta's review comments.
> - Add a kernel CONFIG for fixed up handlers and only enable it on
> i.MX products.
> - Fixed bugs reported by kernel test robot.
>
> Changes in v9:
> - Reuse the gpio-virtio design for command and IRQ type definitions.
> - Remove msg_id, version, and vendor fields from the generic protocol.
> - Add fixed-up handlers to support legacy firmware.
>
> Changes in v8:
> - Add "depends on REMOTEPROC" in Kconfig to fix the build error reported
> by the kernel test robot.
> - Move the .rst patch before the .yaml patch.
> - Handle the "ngpios" DT property based on Andrew's feedback.
>
> Changes in v7:
> - Reworked the driver to use the rpmsg_driver framework instead of
> platform_driver, based on feedback from Bjorn and Arnaud.
> - Updated gpio-rpmsg.yaml and imx_rproc.yaml according to comments from
> Rob and Arnaud.
> - Further refinements to gpio-rpmsg.yaml per Arnaud's feedback.
>
> Changes in v6:
> - make the driver more generic with the actions below:
> rename the driver file to gpio-rpmsg.c
> remove the imx related info in the function and variable names
> rename the imx_rpmsg.h to rpdev_info.h
> create a gpio-rpmsg.yaml and refer it in imx_rproc.yaml
> - update the gpio-rpmsg.rst according to the feedback from Andrew and
> move the source file to driver-api/gpio
> - fix the bug reported by Zhongqiu Han
> - remove the I2C related info
>
> Changes in v5:
> - move the gpio-rpmsg.rst from admin-guide to staging directory after
> discussion with Randy Dunlap.
> - add include files with some code improvements per Bartosz's comments.
>
> Changes in v4:
> - add a documentation to describe the transport protocol per Andrew's
> comments.
> - add a new handler to get the gpio direction.
>
> Changes in v3:
> - fix various format issue and return value check per Peng 's review
> comments.
> - add the logic to also populate the subnodes which are not in the
> device map per Arnaud's request. (in imx_rproc.c)
> - update the yaml per Frank's review comments.
>
> Changes in v2:
> - re-implemented the gpio driver per Linus Walleij's feedback by using
> GPIOLIB_IRQCHIP helper library.
> - fix various format issue per Mathieu/Peng 's review comments.
> - update the yaml doc per Rob's feedback
>
> Shenwei Wang (4):
> docs: driver-api: gpio: rpmsg gpio driver over rpmsg bus
> dt-bindings: remoteproc: imx_rproc: Add "rpmsg" subnode support
> gpio: rpmsg: add generic rpmsg GPIO driver
> arm64: dts: imx8ulp: Add rpmsg node under imx_rproc
>
> .../devicetree/bindings/gpio/gpio-rpmsg.yaml | 55 ++
> .../bindings/remoteproc/fsl,imx-rproc.yaml | 53 ++
> Documentation/driver-api/gpio/gpio-rpmsg.rst | 266 ++++++++
> Documentation/driver-api/gpio/index.rst | 1 +
> arch/arm64/boot/dts/freescale/imx8ulp.dtsi | 25 +
> drivers/gpio/Kconfig | 17 +
> drivers/gpio/Makefile | 1 +
> drivers/gpio/gpio-rpmsg.c | 573 ++++++++++++++++++
> 8 files changed, 991 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gpio/gpio-rpmsg.yaml
> create mode 100644 Documentation/driver-api/gpio/gpio-rpmsg.rst
> create mode 100644 drivers/gpio/gpio-rpmsg.c
>
> --
> 2.43.0
>
^ permalink raw reply
* Re: [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere
From: Mathieu Desnoyers @ 2026-04-23 12:54 UTC (permalink / raw)
To: Alejandro Colomar, Dmitry Vyukov
Cc: Jinjie Ruan, linux-man, Thomas Gleixner, Mark Rutland,
Mathias Stearn, Catalin Marinas, Will Deacon, Boqun Feng,
Paul E. McKenney, Chris Kennelly, regressions, linux-kernel,
linux-arm-kernel, Peter Zijlstra, Ingo Molnar, Blake Oler,
Michael Jeanson
In-Reply-To: <aeoLLMcxtqShSOxs@devuan>
On 2026-04-23 08:11, Alejandro Colomar wrote:
[...]
>>
>> +linux-man
>>
>> This part of the rseq man page needs to be fixed as well I think. The
>> kernel no longer reliably provides clearing of rseq_cs on preemption,
>> right?
>>
>> https://git.kernel.org/pub/scm/libs/librseq/librseq.git/tree/doc/man/rseq.2#n241
>
> +Michael Jeanson
>
> That page seems to be maintained separately, as part of the librseq
> project.
Yes, I maintain the librseq project, thanks Alejandro!
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
^ permalink raw reply
* Re: [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere
From: Dmitry Vyukov @ 2026-04-23 12:58 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: Jinjie Ruan, linux-man, Thomas Gleixner, Mark Rutland,
Mathias Stearn, Catalin Marinas, Will Deacon, Boqun Feng,
Paul E. McKenney, Chris Kennelly, regressions, linux-kernel,
linux-arm-kernel, Peter Zijlstra, Ingo Molnar, Blake Oler,
Michael Jeanson
In-Reply-To: <84e0a8f6-c24c-469a-82a4-e82e33b764b4@efficios.com>
On Thu, 23 Apr 2026 at 14:53, Mathieu Desnoyers
<mathieu.desnoyers@efficios.com> wrote:
>
> On 2026-04-23 08:36, Dmitry Vyukov wrote:
> > On Thu, 23 Apr 2026 at 14:29, Mathieu Desnoyers
> > <mathieu.desnoyers@efficios.com> wrote:
> >>
> >> On 2026-04-23 01:53, Dmitry Vyukov wrote:
> >> [...]
> >>> +linux-man
> >>>
> >>> This part of the rseq man page needs to be fixed as well I think. The
> >>> kernel no longer reliably provides clearing of rseq_cs on preemption,
> >>> right?
> >>>
> >>> https://git.kernel.org/pub/scm/libs/librseq/librseq.git/tree/doc/man/rseq.2#n241
> >>
> >> I'm maintaining this manual page in librseq.
> >>
> >>>
> >>> "and set to NULL by the kernel when it restarts an assembly
> >>> instruction sequence block,
> >>> as well as when the kernel detects that it is preempting or delivering
> >>> a signal outside of the range targeted by the rseq_cs."
> >>
> >> I think you got two things confused here.
> >>
> >> 1) There is currently a bug on arm64 where it fails to honor the
> >> rseq ABI contract wrt critical section abort. AFAIU there is a
> >> fix proposed for this.
> >>
> >> 2) Thomas relaxed the implementation of cpu_id_start field updates
> >> so it only stores to the rseq area when the current cpu actually
> >> changes (migration).
> >>
> >> So AFAIU the statement in the man page is still fine. It's just arm64
> >> that needs fixing.
> >
> >
> > My understanding was that due to the ev->user_irq check here:
> >
> > +static __always_inline void rseq_sched_switch_event(struct task_struct *t)
> > ...
> > + bool raise = (ev->user_irq | ev->ids_changed) & ev->has_rseq;
> > +
> > + if (raise) {
> > + ev->sched_switch = true;
> > + rseq_raise_notify_resume(t);
> > + }
> >
> > There won't be any rseq-related processing for threads preempted in
> > syscalls, which means that rseq_cs won't be NULLed for threads
> > preempted inside of syscalls.
>
> Let's see if I understand your concern correctly. Scenario:
>
> A thread is within a rseq critical section. It exits the critical
> section without clearing the rseq_cs pointer, expecting the kernel
> to lazily clear the rseq_cs pointer eventually when it detects that
> it's not nested on top of the userspace critical section anymore.
> It then calls a system call _outside_ of the rseq critical section,
> but with rseq_cs pointer set. Based on the rseq man page wording,
> it would then expect the preemption within the system call to guarantee
> clearing that that pointer.
Yes, this is the scenario I had in mind.
> Here is the relevant comment block in the man page:
>
> Updated by user-space, which sets the address of the cur‐
> rently active rseq_cs at the beginning of assembly instruc‐
> tion sequence block, and set to NULL by the kernel when it
> restarts an assembly instruction sequence block, as well as
> >>>>>>>>>
> when the kernel detects that it is preempting or delivering
> a signal outside of the range targeted by the rseq_cs.
> >>>>>>>>>
> ^^^ this
>
> The whole point about lazy-clearing of rseq_cs is that it _may_ happen when
> the kernel preempts or delivers a signal (or at any point really), but it's
> just an optimization.
>
> Updating the manual page with this wording would match the intent:
>
> Updated by user-space, which sets the address of the cur‐
> rently active rseq_cs at the beginning of assembly instruc‐
> tion sequence block, and set to NULL by the kernel when it
> restarts an assembly instruction sequence block. May be set
> to NULL by the kernel when it detects that the current
> instruction pointer is outside of the range targeted by
> the rseq_cs.
> Also needs to be set to NULL by user-space before reclaim‐
> ing memory that contains the targeted struct rseq_cs.
>
> Thoughts ?
>
> Thanks,
>
> Mathieu
>
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> https://www.efficios.com
^ permalink raw reply
* Re: [RFC PATCH v2 1/4] security: ima: call ima_init() again at late_initcall_sync for defered TPM
From: Yeoreum Yun @ 2026-04-23 13:07 UTC (permalink / raw)
To: Jonathan McDowell
Cc: Mimi Zohar, linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm, paul, jmorris, serge, roberto.sassu,
dmitry.kasatkin, eric.snowberg, jarkko, jgg, sudeep.holla, maz,
oupton, joey.gouly, suzuki.poulose, yuzenghui, catalin.marinas,
will, noodles, sebastianene
In-Reply-To: <aeoWO2Cwo04YYu2l@earth.li>
Hi,
> > > > On Thu, 2026-04-23 at 06:55 +0100, Yeoreum Yun wrote:
> > > > > > On Wed, 2026-04-22 at 20:41 +0100, Yeoreum Yun wrote:
> > > > > > > > Hi Mimi,
> > > > > > > >
> > > > > > > > > On Wed, 2026-04-22 at 17:24 +0100, Yeoreum Yun wrote:
> > > > > > > > > > To generate the boot_aggregate log in the IMA subsystem with TPM PCR values,
> > > > > > > > > > the TPM driver must be built as built-in and
> > > > > > > > > > must be probed before the IMA subsystem is initialized.
> > > > > > > > > >
> > > > > > > > > > However, when the TPM device operates over the FF-A protocol using
> > > > > > > > > > the CRB interface, probing fails and returns -EPROBE_DEFER if
> > > > > > > > > > the tpm_crb_ffa device — an FF-A device that provides the communication
> > > > > > > > > > interface to the tpm_crb driver — has not yet been probed.
> > > > > > > > > >
> > > > > > > > > > To ensure the TPM device operating over the FF-A protocol with
> > > > > > > > > > the CRB interface is probed before IMA initialization,
> > > > > > > > > > the following conditions must be met:
> > > > > > > > > >
> > > > > > > > > > 1. The corresponding ffa_device must be registered,
> > > > > > > > > > which is done via ffa_init().
> > > > > > > > > >
> > > > > > > > > > 2. The tpm_crb_driver must successfully probe this device via
> > > > > > > > > > tpm_crb_ffa_init().
> > > > > > > > > >
> > > > > > > > > > 3. The tpm_crb driver using CRB over FF-A can then
> > > > > > > > > > be probed successfully. (See crb_acpi_add() and
> > > > > > > > > > tpm_crb_ffa_init() for reference.)
> > > > > > > > > >
> > > > > > > > > > Unfortunately, ffa_init(), tpm_crb_ffa_init(), and crb_acpi_driver_init() are
> > > > > > > > > > all registered with device_initcall, which means crb_acpi_driver_init() may
> > > > > > > > > > be invoked before ffa_init() and tpm_crb_ffa_init() are completed.
> > > > > > > > > >
> > > > > > > > > > When this occurs, probing the TPM device is deferred.
> > > > > > > > > > However, the deferred probe can happen after the IMA subsystem
> > > > > > > > > > has already been initialized, since IMA initialization is performed
> > > > > > > > > > during late_initcall, and deferred_probe_initcall() is performed
> > > > > > > > > > at the same level.
> > > > > > > > > >
> > > > > > > > > > To resolve this, call ima_init() again at late_inicall_sync level
> > > > > > > > > > so that let IMA not miss TPM PCR value when generating boot_aggregate
> > > > > > > > > > log though TPM device presents in the system.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> > > > > > > > >
> > > > > > > > > A lot of change for just detecting whether ima_init() is being called on
> > > > > > > > > late_initcall or late_initcall_sync(), without any explanation for all the other
> > > > > > > > > changes (e.g. ima_init_core).
> > > > > > > > >
> > > > > > > > > Please just limit the change to just calling ima_init() twice.
> > > > > > > >
> > > > > > > > My concern is that ima_update_policy_flags() will be called
> > > > > > > > when ima_init() is deferred -- not initialised anything.
> > > > > > > > though functionally, it might be okay however,
> > > > > > > > I think ima_update_policy_flags() and notifier should work after ima_init()
> > > > > > > > works logically.
> > > > > > > >
> > > > > > > > This change I think not much quite a lot. just wrapper ima_init() with
> > > > > > > > ima_init_core() with some error handling.
> > > > > > > >
> > > > > > > > Am I missing something?
> > > > > > >
> > > > > > > Also, if we handle in ima_init() only, but it failed with other reason,
> > > > > > > we shouldn't call again ima_init() in the late_initcall_sync.
> > > > > > >
> > > > > > > To handle this, It wouldn't do in the ima_init() but we need to handle
> > > > > > > it by caller of ima_init().
> > > > > >
> > > > > > Only tpm_default_chip() is being called to set the ima_tpm_chip. On failure,
> > > > > > instead of going into TPM-bypass mode, return immediately. There are no calls
> > > > > > to anything else. Just call ima_init() a second time.
> > > > >
> > > > > I’m not fully convinced this is sufficient.
> > > > >
> > > > > What I meant is the case where ima_init() fails due to other
> > > > > initialisation steps, not only tpm_default_chip() (e.g. ima_fs_init()).
> > > >
> > > > The purpose of THIS patch is to add late_initcall_sync, when the TPM is not
> > > > available at late_initcall. This would be classified as a bug fix and would be
> > > > backported. No other changes should be included in this patch.
> > >
> > > Okay.
> > >
> > > > >
> > > > > I’d also like to ask again whether it is fine to call
> > > > > ima_update_policy_flags() and keep the notifier registered in the
> > > > > deferred TPM case. While this may be functionally acceptable, it seems
> > > > > logically questionable to do so when ima_init() has not completed.
> > > >
> > > > Other than extending the TPM, IMA should behave exactly the same whether there
> > > > is a TPM or goes into TPM-bypass mode.
> > > >
> > > > >
> > > > > There is also a possibility that a deferred case ultimately fails (e.g.
> > > > > deferred at late_initcall, but then failing at late_initcall_sync
> > > > > for another reason, even while entering TPM bypass mode). In that case,
> > > > > it seems more appropriate to handle this state in the caller of
> > > > > ima_init(), rather than inside ima_init() itself.
> > > >
> > > > If the TPM isn't found at late_initcall_sync(), then IMA should go into TPM-
> > > > bypass mode. Please don't make any other changes to the existing IMA behavior
> > > > and hide it here behind the late_initcall_sync change.
> > >
> > > Okay. you're talking called ima_update_policy_flags() at late_initcall
> > > wouldn't be not a problem even in case of late_initcall_sync's ima_init()
> > > get failed with "TPM-bypass mode".
> > >
> > > I see then, I'll make a patch simpler then.
> >
> > But I think in case of below situation:
> > - late_initcall's first ima_init() is deferred.
> > - late_initcall_sync try again but failed and try again with
> > CONFIG_IMA_DEFAULT_HASH.
> >
> > I would like to sustain init_ima_core to reduce the same code repeat
> > in late_initcall_sync.
>
> I think what Mimi's proposing is:
>
> If we're in late_initcall, and the TPM isn't available, return immediately
> with an error (the EPROBE_DEFER?), don't do any init.
>
> If we're in late_initcall_sync, either we're already initialised, so do
> return and nothing, or run through the entire flow, even if the TPM isn't
> unavailable.
>
> So ima_init() just needs to know a) if it's in the sync or non-sync mode and
> b) for the sync mode, if we've already done the init at
> non-sync.
But think think about when "late_initcall_sync" happens.
In case of it, whether TPM present or by-pass mode, if it failed,
it try again with the DEFAULT_HASH if hash isn't use DEFAULT one
(e.x. user set boot arguments hash_setup=md5).
IOW, late_initcall_sync should call twice just like former code do this.
I mean to wrap this duplication of code with init_core_ima().
so that int late_initcall_sync in case of deferred case to try agina
ima_init() with the DEFAULT HASH.
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [PATCH RFC 2/2] clk: scmi: Add support for two #clock-cells to pass rate rounding mode
From: Peng Fan @ 2026-04-23 13:12 UTC (permalink / raw)
To: Sudeep Holla
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Cristian Marussi, linux-kernel, linux-clk,
devicetree, arm-scmi, linux-arm-kernel, Peng Fan
In-Reply-To: <20260423-pompous-hissing-tanuki-16c5f6@sudeepholla>
On Thu, Apr 23, 2026 at 09:25:42AM +0100, Sudeep Holla wrote:
>On Thu, Apr 23, 2026 at 09:17:47AM +0800, Peng Fan wrote:
[...]
>>
>> My question is: if the firmware were to select divider 3 and produce
>> 96,333,333 Hz (only ~0.13% higher than the request), would that be
>> considered a violation of ROUND_DOWN semantics, or is ROUND_DOWN intended
>> to select the closest achievable output frequency rather than enforcing
>> a strict inequality against the requested rate?
>>
>
>We can change the driver to default to ROUND_AUTO if that helps. I fully
>understand the default ROUND_DOWN is not good but if firmware can't handle
>your use case with ROUND_AUTO, it is firmware issue.
Thanks for the suggestion.
Switching the default to ROUND_AUTO could indeed resolve the video clock
configuration issue we are seeing.
I understand the concern that if firmware cannot handle a given use-case
correctly with ROUND_AUTO, then it is fundamentally a firmware issue rather
than something to be worked around in the OS.
I will check internally with our firmware team to confirm whether using
ROUND_AUTO as the default is safe and applicable for all clocks supported
on our platforms.
Thanks,
Peng
>
>--
>Regards,
>Sudeep
^ permalink raw reply
* Re: [PATCH 2/4] arm64: dts: imx95: switch usb3 controller to flattened model
From: Xu Yang @ 2026-04-23 13:17 UTC (permalink / raw)
To: Peng Fan
Cc: Frank Li, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Jun Li
In-Reply-To: <PAXPR04MB845957613BCD5E86D96FA4E3882A2@PAXPR04MB8459.eurprd04.prod.outlook.com>
On Thu, Apr 23, 2026 at 12:07:42PM +0000, Peng Fan wrote:
> > Subject: Re: [PATCH 2/4] arm64: dts: imx95: switch usb3 controller to
> > flattened model
> >
> > On Tue, Apr 21, 2026 at 11:53:12PM -0400, Frank Li wrote:
> > > On Tue, Apr 21, 2026 at 06:55:01PM +0800, Xu Yang wrote:
> > > > Switch to use flattened model for USB3 controller. To enable USB
> > > > controller with restricted DMA access range to work correctly, add
> > a
> > > > pseudo simple-bus to constrain the dma address.
> > >
> > > i.mx95 should fix >4G dma space's problem. Does it impact other no-
> > nxp
> > > boards?
> >
> > Yes, i.MX95 has fixed >3G address DMA access problem.
> >
> > It's another issue. HSIO domain only support 36 bit bus access. If not
> > use smmu, no any issue. If use smmu, it will allocate memory space of
> > 36 bit < iova < 48bit.
> > HSIO can't handle this case.
>
> If using smmu, iova will be in range {36bit, 48bit}? How?
Yes, if use smmu and not set dma-range:
[ 3.139529] dwc3 4c100000.usb: dwc3_alloc_one_event_buffer evt->dma:0x0000fffffffff000 len:4096
if use smmu and set dma-range:
[ 3.136849] dwc3 4c100000.usb: dwc3_alloc_one_event_buffer evt->dma:0x0000000ffffff000 len:4096
Thanks,
Xu Yang
^ permalink raw reply
* Re: [PATCH v5 3/4] clk: keystone: sci-clk: add restore_context() operation
From: Thomas Richard @ 2026-04-23 13:35 UTC (permalink / raw)
To: Brian Masney
Cc: Nishanth Menon, Tero Kristo, Santosh Shilimkar, Michael Turquette,
Stephen Boyd, Gregory CLEMENT, richard.genoud, Udit Kumar,
Prasanth Mantena, Abhash Kumar, Thomas Petazzoni,
linux-arm-kernel, linux-kernel, linux-clk, Dhruva Gole
In-Reply-To: <adbXBwKC_cNxGlpr@redhat.com>
Hello Brian,
On 4/9/26 12:30 AM, Brian Masney wrote:
> Hi Thomas,
>
> On Tue, Apr 07, 2026 at 04:25:08PM +0200, Thomas Richard (TI) wrote:
>> Implement the restore_context() operation to restore the clock rate and the
>> clock parent state. The clock rate is saved in sci_clk struct during
>> set_rate() operation. The parent index is saved in sci_clk struct during
>> set_parent() operation. During clock registration, the core retrieves each
>> clock’s parent using get_parent() operation to ensure the internal clock
>> tree reflects the actual hardware state, including any configurations made
>> by the bootloader. So we also save the parent index in get_parent().
>>
>> Reviewed-by: Dhruva Gole <d-gole@ti.com>
>> Signed-off-by: Thomas Richard (TI) <thomas.richard@bootlin.com>
>> ---
>> drivers/clk/keystone/sci-clk.c | 42 ++++++++++++++++++++++++++++++++++--------
>> 1 file changed, 34 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/clk/keystone/sci-clk.c b/drivers/clk/keystone/sci-clk.c
>> index 9d5071223f4c..428050a05de3 100644
>> --- a/drivers/clk/keystone/sci-clk.c
>> +++ b/drivers/clk/keystone/sci-clk.c
>> @@ -47,6 +47,8 @@ struct sci_clk_provider {
>> * @node: Link for handling clocks probed via DT
>> * @cached_req: Cached requested freq for determine rate calls
>> * @cached_res: Cached result freq for determine rate calls
>> + * @parent_id: Parent index for this clock
>> + * @rate: Clock rate
>> */
>> struct sci_clk {
>> struct clk_hw hw;
>> @@ -58,6 +60,8 @@ struct sci_clk {
>> struct list_head node;
>> unsigned long cached_req;
>> unsigned long cached_res;
>> + u8 parent_id;
>> + unsigned long rate;
>> };
>>
>> #define to_sci_clk(_hw) container_of(_hw, struct sci_clk, hw)
>> @@ -210,10 +214,16 @@ static int sci_clk_set_rate(struct clk_hw *hw, unsigned long rate,
>> unsigned long parent_rate)
>> {
>> struct sci_clk *clk = to_sci_clk(hw);
>> + int ret;
>> +
>> + ret = clk->provider->ops->set_freq(clk->provider->sci, clk->dev_id,
>> + clk->clk_id, rate / 10 * 9, rate,
>> + rate / 10 * 11);
>>
>> - return clk->provider->ops->set_freq(clk->provider->sci, clk->dev_id,
>> - clk->clk_id, rate / 10 * 9, rate,
>> - rate / 10 * 11);
>> + if (!ret)
>> + clk->rate = rate;
>> +
>> + return ret;
>> }
>
> Should the computed rate from sci_clk_recalc_rate() be saved as well?
Yes you're right. As recal_rate() is called for each clock at
registration, I'll be able to restore rate for all configured clocks
including the ones which were configured by the bootloader but not by Linux.
>
>>
>> /**
>> @@ -237,9 +247,9 @@ static u8 sci_clk_get_parent(struct clk_hw *hw)
>> return 0;
>> }
>>
>> - parent_id = parent_id - clk->clk_id - 1;
>> + clk->parent_id = (u8)(parent_id - clk->clk_id - 1);
>>
>> - return (u8)parent_id;
>> + return clk->parent_id;
>> }
>>
>> /**
>> @@ -252,12 +262,27 @@ static u8 sci_clk_get_parent(struct clk_hw *hw)
>> static int sci_clk_set_parent(struct clk_hw *hw, u8 index)
>> {
>> struct sci_clk *clk = to_sci_clk(hw);
>> + int ret;
>>
>> clk->cached_req = 0;
>>
>> - return clk->provider->ops->set_parent(clk->provider->sci, clk->dev_id,
>> - clk->clk_id,
>> - index + 1 + clk->clk_id);
>> + ret = clk->provider->ops->set_parent(clk->provider->sci, clk->dev_id,
>> + clk->clk_id,
>> + index + 1 + clk->clk_id);
>> + if (!ret)
>> + clk->parent_id = index;
>> +
>> + return ret;
>> +}
>> +
>> +static void sci_clk_restore_context(struct clk_hw *hw)
>> +{
>> + struct sci_clk *clk = to_sci_clk(hw);
>> +
>> + sci_clk_set_parent(hw, clk->parent_id);
>
> Are all of these clocks muxes?
Not all.
I will check if the clock has more than one parent before to call
set_parent().
Best Regards,
Thomas
^ permalink raw reply
* Re: [RFC PATCH v2 1/4] security: ima: call ima_init() again at late_initcall_sync for defered TPM
From: Mimi Zohar @ 2026-04-23 13:43 UTC (permalink / raw)
To: Jonathan McDowell, Yeoreum Yun
Cc: linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm, paul, jmorris, serge, roberto.sassu,
dmitry.kasatkin, eric.snowberg, jarkko, jgg, sudeep.holla, maz,
oupton, joey.gouly, suzuki.poulose, yuzenghui, catalin.marinas,
will, noodles, sebastianene
In-Reply-To: <aeoWO2Cwo04YYu2l@earth.li>
On Thu, 2026-04-23 at 13:53 +0100, Jonathan McDowell wrote:
> On Thu, Apr 23, 2026 at 01:34:13PM +0100, Yeoreum Yun wrote:
> > > > On Thu, 2026-04-23 at 06:55 +0100, Yeoreum Yun wrote:
> > > > > > On Wed, 2026-04-22 at 20:41 +0100, Yeoreum Yun wrote:
> > > > > > > > Hi Mimi,
> > > > > > > >
> > > > > > > > > On Wed, 2026-04-22 at 17:24 +0100, Yeoreum Yun wrote:
> > > > > > > > > > To generate the boot_aggregate log in the IMA subsystem with TPM PCR values,
> > > > > > > > > > the TPM driver must be built as built-in and
> > > > > > > > > > must be probed before the IMA subsystem is initialized.
> > > > > > > > > >
> > > > > > > > > > However, when the TPM device operates over the FF-A protocol using
> > > > > > > > > > the CRB interface, probing fails and returns -EPROBE_DEFER if
> > > > > > > > > > the tpm_crb_ffa device — an FF-A device that provides the communication
> > > > > > > > > > interface to the tpm_crb driver — has not yet been probed.
> > > > > > > > > >
> > > > > > > > > > To ensure the TPM device operating over the FF-A protocol with
> > > > > > > > > > the CRB interface is probed before IMA initialization,
> > > > > > > > > > the following conditions must be met:
> > > > > > > > > >
> > > > > > > > > > 1. The corresponding ffa_device must be registered,
> > > > > > > > > > which is done via ffa_init().
> > > > > > > > > >
> > > > > > > > > > 2. The tpm_crb_driver must successfully probe this device via
> > > > > > > > > > tpm_crb_ffa_init().
> > > > > > > > > >
> > > > > > > > > > 3. The tpm_crb driver using CRB over FF-A can then
> > > > > > > > > > be probed successfully. (See crb_acpi_add() and
> > > > > > > > > > tpm_crb_ffa_init() for reference.)
> > > > > > > > > >
> > > > > > > > > > Unfortunately, ffa_init(), tpm_crb_ffa_init(), and crb_acpi_driver_init() are
> > > > > > > > > > all registered with device_initcall, which means crb_acpi_driver_init() may
> > > > > > > > > > be invoked before ffa_init() and tpm_crb_ffa_init() are completed.
> > > > > > > > > >
> > > > > > > > > > When this occurs, probing the TPM device is deferred.
> > > > > > > > > > However, the deferred probe can happen after the IMA subsystem
> > > > > > > > > > has already been initialized, since IMA initialization is performed
> > > > > > > > > > during late_initcall, and deferred_probe_initcall() is performed
> > > > > > > > > > at the same level.
> > > > > > > > > >
> > > > > > > > > > To resolve this, call ima_init() again at late_inicall_sync level
> > > > > > > > > > so that let IMA not miss TPM PCR value when generating boot_aggregate
> > > > > > > > > > log though TPM device presents in the system.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> > > > > > > > >
> > > > > > > > > A lot of change for just detecting whether ima_init() is being called on
> > > > > > > > > late_initcall or late_initcall_sync(), without any explanation for all the other
> > > > > > > > > changes (e.g. ima_init_core).
> > > > > > > > >
> > > > > > > > > Please just limit the change to just calling ima_init() twice.
> > > > > > > >
> > > > > > > > My concern is that ima_update_policy_flags() will be called
> > > > > > > > when ima_init() is deferred -- not initialised anything.
> > > > > > > > though functionally, it might be okay however,
> > > > > > > > I think ima_update_policy_flags() and notifier should work after ima_init()
> > > > > > > > works logically.
> > > > > > > >
> > > > > > > > This change I think not much quite a lot. just wrapper ima_init() with
> > > > > > > > ima_init_core() with some error handling.
> > > > > > > >
> > > > > > > > Am I missing something?
> > > > > > >
> > > > > > > Also, if we handle in ima_init() only, but it failed with other reason,
> > > > > > > we shouldn't call again ima_init() in the late_initcall_sync.
> > > > > > >
> > > > > > > To handle this, It wouldn't do in the ima_init() but we need to handle
> > > > > > > it by caller of ima_init().
> > > > > >
> > > > > > Only tpm_default_chip() is being called to set the ima_tpm_chip. On failure,
> > > > > > instead of going into TPM-bypass mode, return immediately. There are no calls
> > > > > > to anything else. Just call ima_init() a second time.
> > > > >
> > > > > I’m not fully convinced this is sufficient.
> > > > >
> > > > > What I meant is the case where ima_init() fails due to other
> > > > > initialisation steps, not only tpm_default_chip() (e.g. ima_fs_init()).
> > > >
> > > > The purpose of THIS patch is to add late_initcall_sync, when the TPM is not
> > > > available at late_initcall. This would be classified as a bug fix and would be
> > > > backported. No other changes should be included in this patch.
> > >
> > > Okay.
> > >
> > > > >
> > > > > I’d also like to ask again whether it is fine to call
> > > > > ima_update_policy_flags() and keep the notifier registered in the
> > > > > deferred TPM case. While this may be functionally acceptable, it seems
> > > > > logically questionable to do so when ima_init() has not completed.
> > > >
> > > > Other than extending the TPM, IMA should behave exactly the same whether there
> > > > is a TPM or goes into TPM-bypass mode.
> > > >
> > > > >
> > > > > There is also a possibility that a deferred case ultimately fails (e.g.
> > > > > deferred at late_initcall, but then failing at late_initcall_sync
> > > > > for another reason, even while entering TPM bypass mode). In that case,
> > > > > it seems more appropriate to handle this state in the caller of
> > > > > ima_init(), rather than inside ima_init() itself.
> > > >
> > > > If the TPM isn't found at late_initcall_sync(), then IMA should go into TPM-
> > > > bypass mode. Please don't make any other changes to the existing IMA behavior
> > > > and hide it here behind the late_initcall_sync change.
> > >
> > > Okay. you're talking called ima_update_policy_flags() at late_initcall
> > > wouldn't be not a problem even in case of late_initcall_sync's ima_init()
> > > get failed with "TPM-bypass mode".
> > >
> > > I see then, I'll make a patch simpler then.
> >
> > But I think in case of below situation:
> > - late_initcall's first ima_init() is deferred.
> > - late_initcall_sync try again but failed and try again with
> > CONFIG_IMA_DEFAULT_HASH.
> >
> > I would like to sustain init_ima_core to reduce the same code repeat
> > in late_initcall_sync.
>
> I think what Mimi's proposing is:
>
> If we're in late_initcall, and the TPM isn't available, return
> immediately with an error (the EPROBE_DEFER?), don't do any init.
>
> If we're in late_initcall_sync, either we're already initialised, so do
> return and nothing, or run through the entire flow, even if the TPM
> isn't unavailable.
>
> So ima_init() just needs to know a) if it's in the sync or non-sync mode
> and b) for the sync mode, if we've already done the init at
> non-sync.
Thanks, Jonathan. That is exactly what I'm suggesting. Any other changes
should not be included in this patch. Since Yeoreum is not hearing me, feel
free to post a patch.
Mimi
^ permalink raw reply
* Re: [PATCH v2 00/15] var-som-6ul: improve support for variants
From: Hugo Villeneuve @ 2026-04-23 13:44 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: robh, krzk+dt, conor+dt, andrzej.hajda, neil.armstrong, rfoss,
Laurent.pinchart, jonas, jernej.skrabec, maarten.lankhorst,
mripard, tzimmermann, airlied, simona, Frank.Li, s.hauer, kernel,
festevam, shawnguo, laurent.pinchart+renesas, antonin.godard,
devicetree, linux-kernel, dri-devel, imx, linux-arm-kernel,
Hugo Villeneuve
In-Reply-To: <20260305180651.1827087-1-hugo@hugovil.com>
On Thu, 5 Mar 2026 13:06:15 -0500
Hugo Villeneuve <hugo@hugovil.com> wrote:
> From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
>
> Hello,
> this patch series improves support for Variscite VAR-SOM-6UL based boards.
Hi,
simple ping to know if anything is missing for this series to be
applied/picked-up?
Hugo.
>
> The first two patches fix DT/dmesg warnings.
>
> The next patches fix the incorrect use of VAR-SOM-MX6UL to refer to the
> VAR-SOM-6UL.
>
> The next patches add support for the imx6ull CPU variant of the VAR-SOM-6UL.
>
> Then improves/fixes the following features/options that are currently not
> working on the concerto EVK board:
> - ethernet ports ENET1
> - LVDS display panel
> - Wifi/Bt
>
> Note that the previous configuration of the optional Wifi/Bluetooth module
> was copied from the original Variscite kernel tree, and required custom
> shell scripts to properly configure the Wifi/Bluetooth module.
>
> Also factor out optional features into separate DTSI include files, so it will
> be easier to support them for other boards, and to make sure they are not
> unconditionnally enabled.
>
> I have tested these changes on a Variscite concerto EVK board using a
> VAR-SOM-6UL with the following options:
> - EC (ethernet phy on SOM)
> - LD (LVDS encoder assembled on SOM)
> - WBD (Wi-Fi 802.11 ac/a/b/g/n and Bluetooth 5.2/BLE on SOM)
> Result of tests:
> - Both ethernet ports Ok
> - LVDS display panel Ok
> - Wifi/Bt Ok
>
> Also tested on a custom board with a VAR-SOM-6UL SOM (will be submitted in
> a future series).
>
> Thank you.
>
> Link: [v1] https://lore.kernel.org/all/20260302190953.669325-1-hugo@hugovil.com/
>
> Changes for v2:
> - Place imx6ull-var-som-concerto.dtb in alphabetical order (Frank)
> - s/include/dtsi in commit msgs (Frank)
> - Clarify and improve patches to change VAR-SOM-MX6UL (Krzysztof)
> - Collect tags for some acked patches (Krzysztof)
> - Reorder pinctrl_gpio_leds in separate patch (Frank)
> - Improve git commit messages ((Frank)/Krzysztof)
>
> Hugo Villeneuve (15):
> ARM: dts: imx6ul-var-som: fix warning for non-existent dc-supply
> property
> ARM: dts: imx6ul-var-som: fix warning for boolean property with a
> value
> ARM: dts: imx6ul-var-som: change incorrect VAR-SOM-MX6UL references
> dt-bindings: arm: fsl: change incorrect VAR-SOM-MX6UL references
> dt-bindings: arm: fsl: add variscite,var-som-imx6ull
> ARM: dts: imx6ul-var-som: Factor out common parts for all CPU variants
> ARM: dts: imx6ul-var-som-concerto: Factor out common parts for all CPU
> variants
> ARM: dts: imx6ul-var-som-concerto: order DT properties
> ARM: dts: imx6ul-var-som: factor out SD card support
> ARM: dts: imx6ul-var-som: add proper Wifi and Bluetooth support
> ARM: dts: imx6ul-var-som: factor out ENET2 ethernet support
> ARM: dts: imx6ul-var-som: add support for EC configuration option
> (ENET1)
> ARM: dts: imx6ul-var-som: factor out audio support
> dt-bindings: display/lvds-codec: add ti,sn65lvds93
> ARM: dts: imx6ul-var-som: add support for LVDS display panel
>
> .../devicetree/bindings/arm/fsl.yaml | 8 +-
> .../bindings/display/bridge/lvds-codec.yaml | 1 +
> arch/arm/boot/dts/nxp/imx/Makefile | 3 +
> .../dts/nxp/imx/imx6ul-var-som-audio.dtsi | 30 ++
> ...ar-som.dtsi => imx6ul-var-som-common.dtsi} | 140 +++-----
> ...ts => imx6ul-var-som-concerto-common.dtsi} | 159 ++-------
> .../nxp/imx/imx6ul-var-som-concerto-full.dts | 22 ++
> .../dts/nxp/imx/imx6ul-var-som-concerto.dts | 318 +-----------------
> .../dts/nxp/imx/imx6ul-var-som-enet1.dtsi | 44 +++
> .../dts/nxp/imx/imx6ul-var-som-enet2.dtsi | 79 +++++
> .../nxp/imx/imx6ul-var-som-lvds-panel.dtsi | 112 ++++++
> .../boot/dts/nxp/imx/imx6ul-var-som-sd.dtsi | 27 ++
> .../boot/dts/nxp/imx/imx6ul-var-som-wifi.dtsi | 75 +++++
> arch/arm/boot/dts/nxp/imx/imx6ul-var-som.dtsi | 219 +-----------
> .../nxp/imx/imx6ull-var-som-concerto-full.dts | 22 ++
> .../dts/nxp/imx/imx6ull-var-som-concerto.dts | 21 ++
> .../arm/boot/dts/nxp/imx/imx6ull-var-som.dtsi | 36 ++
> 17 files changed, 575 insertions(+), 741 deletions(-)
> create mode 100644 arch/arm/boot/dts/nxp/imx/imx6ul-var-som-audio.dtsi
> copy arch/arm/boot/dts/nxp/imx/{imx6ul-var-som.dtsi => imx6ul-var-som-common.dtsi} (60%)
> copy arch/arm/boot/dts/nxp/imx/{imx6ul-var-som-concerto.dts => imx6ul-var-som-concerto-common.dtsi} (50%)
> create mode 100644 arch/arm/boot/dts/nxp/imx/imx6ul-var-som-concerto-full.dts
> create mode 100644 arch/arm/boot/dts/nxp/imx/imx6ul-var-som-enet1.dtsi
> create mode 100644 arch/arm/boot/dts/nxp/imx/imx6ul-var-som-enet2.dtsi
> create mode 100644 arch/arm/boot/dts/nxp/imx/imx6ul-var-som-lvds-panel.dtsi
> create mode 100644 arch/arm/boot/dts/nxp/imx/imx6ul-var-som-sd.dtsi
> create mode 100644 arch/arm/boot/dts/nxp/imx/imx6ul-var-som-wifi.dtsi
> create mode 100644 arch/arm/boot/dts/nxp/imx/imx6ull-var-som-concerto-full.dts
> create mode 100644 arch/arm/boot/dts/nxp/imx/imx6ull-var-som-concerto.dts
> create mode 100644 arch/arm/boot/dts/nxp/imx/imx6ull-var-som.dtsi
>
>
> base-commit: c107785c7e8dbabd1c18301a1c362544b5786282
> --
> 2.47.3
>
>
--
Hugo Villeneuve
^ 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