* [PATCH v2 3/4] x86/vmware: Report guest crash to the hypervisor
From: Alexey Makhalov @ 2026-03-09 23:52 UTC (permalink / raw)
To: x86, virtualization, bp, hpa, dave.hansen, mingo, tglx
Cc: ajay.kaher, brennan.lamoreaux, bo.gan, bcm-kernel-feedback-list,
linux-kernel, kas, rick.p.edgecombe, linux-coco, Alexey Makhalov
In-Reply-To: <20260309235250.2611115-1-alexey.makhalov@broadcom.com>
Register the guest crash reporter to panic_notifier_list,
which will be called at panic time. Guest crash reporter
will report the crash to the hypervisor through
a hypercall.
Co-developed-by: Brennan Lamoreaux <brennan.lamoreaux@broadcom.com>
Signed-off-by: Brennan Lamoreaux <brennan.lamoreaux@broadcom.com>
Signed-off-by: Alexey Makhalov <alexey.makhalov@broadcom.com>
---
arch/x86/include/asm/vmware.h | 1 +
arch/x86/kernel/cpu/vmware.c | 21 +++++++++++++++++++++
2 files changed, 22 insertions(+)
diff --git a/arch/x86/include/asm/vmware.h b/arch/x86/include/asm/vmware.h
index c23164503e54..bf6141353774 100644
--- a/arch/x86/include/asm/vmware.h
+++ b/arch/x86/include/asm/vmware.h
@@ -97,6 +97,7 @@
#define VMWARE_CMD_GETHZ 45
#define VMWARE_CMD_GETVCPU_INFO 68
#define VMWARE_CMD_STEALCLOCK 91
+#define VMWARE_CMD_REPORTGUESTCRASH 102
/*
* Hypercall command mask:
* bits [6:0] command, range [0, 127]
diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c
index 9955f2ea0c84..c631e577348a 100644
--- a/arch/x86/kernel/cpu/vmware.c
+++ b/arch/x86/kernel/cpu/vmware.c
@@ -31,6 +31,7 @@
#include <linux/static_call.h>
#include <linux/sched/cputime.h>
#include <linux/kmsg_dump.h>
+#include <linux/panic_notifier.h>
#include <asm/div64.h>
#include <asm/x86_init.h>
#include <asm/hypervisor.h>
@@ -451,6 +452,24 @@ static void __init vmware_paravirt_ops_setup(void)
#define vmware_paravirt_ops_setup() do {} while (0)
#endif
+static int vmware_report_guest_crash(struct notifier_block *self,
+ unsigned long action, void *data)
+{
+ vmware_hypercall1(VMWARE_CMD_REPORTGUESTCRASH, 0);
+ return 0;
+}
+
+static struct notifier_block guest_crash_reporter = {
+ .notifier_call = vmware_report_guest_crash
+};
+
+static int __init register_guest_crash_reporter(void)
+{
+ atomic_notifier_chain_register(&panic_notifier_list,
+ &guest_crash_reporter);
+
+ return 0;
+}
/*
* VMware hypervisor takes care of exporting a reliable TSC to the guest.
* Still, due to timing difference when running on virtual cpus, the TSC can
@@ -545,6 +564,8 @@ static void __init vmware_platform_setup(void)
vmware_set_capabilities();
kmsg_dump_register(&kmsg_dumper);
+
+ register_guest_crash_reporter();
}
static u8 __init get_hypercall_mode(void)
--
2.43.7
^ permalink raw reply related
* [PATCH v2 2/4] x86/vmware: Log kmsg dump on panic
From: Alexey Makhalov @ 2026-03-09 23:52 UTC (permalink / raw)
To: x86, virtualization, bp, hpa, dave.hansen, mingo, tglx
Cc: ajay.kaher, brennan.lamoreaux, bo.gan, bcm-kernel-feedback-list,
linux-kernel, kas, rick.p.edgecombe, linux-coco, Alexey Makhalov
In-Reply-To: <20260309235250.2611115-1-alexey.makhalov@broadcom.com>
Improve debugability of VMware Linux guests by dumping
kernel messages during a panic to VM log file (vmware.log).
Co-developed-by: Bo Gan <bo.gan@broadcom.com>
Signed-off-by: Bo Gan <bo.gan@broadcom.com>
Signed-off-by: Alexey Makhalov <alexey.makhalov@broadcom.com>
---
arch/x86/include/asm/vmware.h | 1 +
arch/x86/kernel/cpu/vmware.c | 132 ++++++++++++++++++++++++++++++++++
2 files changed, 133 insertions(+)
diff --git a/arch/x86/include/asm/vmware.h b/arch/x86/include/asm/vmware.h
index 6a084e088b30..c23164503e54 100644
--- a/arch/x86/include/asm/vmware.h
+++ b/arch/x86/include/asm/vmware.h
@@ -93,6 +93,7 @@
#define VMWARE_HYPERVISOR_MAGIC 0x564d5868U
#define VMWARE_CMD_GETVERSION 10
+#define VMWARE_CMD_MESSAGE 30
#define VMWARE_CMD_GETHZ 45
#define VMWARE_CMD_GETVCPU_INFO 68
#define VMWARE_CMD_STEALCLOCK 91
diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c
index 93acd3414e37..9955f2ea0c84 100644
--- a/arch/x86/kernel/cpu/vmware.c
+++ b/arch/x86/kernel/cpu/vmware.c
@@ -30,6 +30,7 @@
#include <linux/reboot.h>
#include <linux/static_call.h>
#include <linux/sched/cputime.h>
+#include <linux/kmsg_dump.h>
#include <asm/div64.h>
#include <asm/x86_init.h>
#include <asm/hypervisor.h>
@@ -211,6 +212,13 @@ static unsigned long vmware_get_tsc_khz(void)
return vmware_tsc_khz;
}
+static void kmsg_dumper_vmware_log(struct kmsg_dumper *dumper,
+ struct kmsg_dump_detail *detail);
+
+static struct kmsg_dumper kmsg_dumper = {
+ .dump = kmsg_dumper_vmware_log
+};
+
#ifdef CONFIG_PARAVIRT
static struct cyc2ns_data vmware_cyc2ns __ro_after_init;
static bool vmw_sched_clock __initdata = true;
@@ -535,6 +543,8 @@ static void __init vmware_platform_setup(void)
#endif
vmware_set_capabilities();
+
+ kmsg_dump_register(&kmsg_dumper);
}
static u8 __init get_hypercall_mode(void)
@@ -630,3 +640,125 @@ const __initconst struct hypervisor_x86 x86_hyper_vmware = {
.runtime.sev_es_hcall_finish = vmware_sev_es_hcall_finish,
#endif
};
+
+#define VMWARE_HB_CMD_MESSAGE 0
+#define MESSAGE_STATUS_SUCCESS (0x01 << 16)
+#define MESSAGE_STATUS_CPT (0x10 << 16)
+#define MESSAGE_STATUS_HB (0x80 << 16)
+
+#define RPCI_PROTOCOL_NUM 0x49435052 /* 'RPCI' */
+#define GUESTMSG_FLAG_COOKIE 0x80000000
+
+#define MESSAGE_TYPE_OPEN (0 << 16)
+#define MESSAGE_TYPE_SENDSIZE (1 << 16)
+#define MESSAGE_TYPE_SEND (2 << 16)
+#define MESSAGE_TYPE_CLOSE (6 << 16)
+
+struct vmw_msg {
+ u32 id;
+ u32 cookie_high;
+ u32 cookie_low;
+};
+
+static int
+vmware_log_open(struct vmw_msg *msg)
+{
+ u32 info;
+
+ vmware_hypercall6(VMWARE_CMD_MESSAGE | MESSAGE_TYPE_OPEN,
+ RPCI_PROTOCOL_NUM | GUESTMSG_FLAG_COOKIE,
+ 0, &info, &msg->id, &msg->cookie_high,
+ &msg->cookie_low);
+
+ if ((info & MESSAGE_STATUS_SUCCESS) == 0)
+ return 1;
+
+ msg->id &= 0xffff0000UL;
+ return 0;
+}
+
+static int
+vmware_log_close(struct vmw_msg *msg)
+{
+ u32 info;
+
+ vmware_hypercall5(VMWARE_CMD_MESSAGE | MESSAGE_TYPE_CLOSE, 0, msg->id,
+ msg->cookie_high, msg->cookie_low, &info);
+
+ if ((info & MESSAGE_STATUS_SUCCESS) == 0)
+ return 1;
+ return 0;
+}
+
+static int
+vmware_log_send(struct vmw_msg *msg, const char *string)
+{
+ u32 info;
+ u32 len = strlen(string);
+
+retry:
+ vmware_hypercall5(VMWARE_CMD_MESSAGE | MESSAGE_TYPE_SENDSIZE, len,
+ msg->id, msg->cookie_high, msg->cookie_low, &info);
+
+ if (!(info & MESSAGE_STATUS_SUCCESS))
+ return 1;
+
+ /* HB port can't access encrypted memory. */
+ if (!cc_platform_has(CC_ATTR_MEM_ENCRYPT) && (info & MESSAGE_STATUS_HB)) {
+ vmware_hypercall_hb_out(
+ VMWARE_HB_CMD_MESSAGE | MESSAGE_STATUS_SUCCESS,
+ len, msg->id, (uintptr_t) string, msg->cookie_low,
+ msg->cookie_high, &info);
+ } else {
+ do {
+ u32 word;
+ size_t s = min_t(u32, len, sizeof(word));
+
+ memcpy(&word, string, s);
+ len -= s;
+ string += s;
+
+ vmware_hypercall5(VMWARE_CMD_MESSAGE | MESSAGE_TYPE_SEND,
+ word, msg->id, msg->cookie_high,
+ msg->cookie_low, &info);
+ } while (len && (info & MESSAGE_STATUS_SUCCESS));
+ }
+
+ if ((info & MESSAGE_STATUS_SUCCESS) == 0) {
+ if (info & MESSAGE_STATUS_CPT)
+ /* A checkpoint occurred. Retry. */
+ goto retry;
+ return 1;
+ }
+ return 0;
+}
+STACK_FRAME_NON_STANDARD(vmware_log_send);
+
+/*
+ * kmsg_dumper_vmware_log - dumps kmsg to vmware.log file on the host
+ */
+static void kmsg_dumper_vmware_log(struct kmsg_dumper *dumper,
+ struct kmsg_dump_detail *detail)
+{
+ struct vmw_msg msg;
+ struct kmsg_dump_iter iter;
+ static char line[1024];
+ size_t len = 0;
+
+ /* Line prefix to send to VM log file. */
+ line[0] = 'l';
+ line[1] = 'o';
+ line[2] = 'g';
+ line[3] = ' ';
+
+ kmsg_dump_rewind(&iter);
+ while (kmsg_dump_get_line(&iter, true, line + 4, sizeof(line) - 4,
+ &len)) {
+ line[len + 4] = '\0';
+ if (vmware_log_open(&msg))
+ return;
+ if (vmware_log_send(&msg, line))
+ return;
+ vmware_log_close(&msg);
+ }
+}
--
2.43.7
^ permalink raw reply related
* [PATCH v2 1/4] x86/vmware: Introduce common vmware_hypercall()
From: Alexey Makhalov @ 2026-03-09 23:52 UTC (permalink / raw)
To: x86, virtualization, bp, hpa, dave.hansen, mingo, tglx
Cc: ajay.kaher, brennan.lamoreaux, bo.gan, bcm-kernel-feedback-list,
linux-kernel, kas, rick.p.edgecombe, linux-coco, Alexey Makhalov,
Linus Torvalds
In-Reply-To: <20260309235250.2611115-1-alexey.makhalov@broadcom.com>
Introduce vmware_hypercall(), a unified low-bandwidth VMware hypercall
API, and convert the static inlines vmware_hypercallX() family into thin
wrappers on top of it.
vmware_hypercall() is implemented as a static call with four backend
implementations: backdoor, vmcall, vmmcall, and tdxcall. All share the
same logical API but differ in their underlying register mappings.
By updating the static call target early during boot, before the first
hypercall is issued, the !alternatives_patched case no longer needs to
be handled. This allows removal of vmware_hypercall_slow().
The new API implements the widest practical hypercall use case: up to
six input and six output arguments. While this may be slightly less
efficient due to clobbering all six registers and moving unused
arguments - it avoids subtle ABI issues, including cases where other
hypervisors implementing VMware hypercalls corrupt registers.
See QEMU issue #3293 ("vmmouse driver corrupts upper 32 bits of
registers on x86-64") for an example of such behavior.
Additionally, enhance the VMware hypercall ABI documentation in
<asm/vmware.h>.
Link: https://gitlab.com/qemu-project/qemu/-/issues/3293
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Alexey Makhalov <alexey.makhalov@broadcom.com>
---
arch/x86/include/asm/vmware.h | 274 ++++++++++++++-------------------
arch/x86/kernel/cpu/vmware.c | 276 +++++++++++++++++++---------------
2 files changed, 267 insertions(+), 283 deletions(-)
diff --git a/arch/x86/include/asm/vmware.h b/arch/x86/include/asm/vmware.h
index 4220dae14a2d..6a084e088b30 100644
--- a/arch/x86/include/asm/vmware.h
+++ b/arch/x86/include/asm/vmware.h
@@ -3,48 +3,84 @@
#define _ASM_X86_VMWARE_H
#include <asm/cpufeatures.h>
-#include <asm/alternative.h>
#include <linux/stringify.h>
+#include <linux/static_call.h>
/*
* VMware hypercall ABI.
*
- * - Low bandwidth (LB) hypercalls (I/O port based, vmcall and vmmcall)
- * have up to 6 input and 6 output arguments passed and returned using
- * registers: %eax (arg0), %ebx (arg1), %ecx (arg2), %edx (arg3),
- * %esi (arg4), %edi (arg5).
- * The following input arguments must be initialized by the caller:
- * arg0 - VMWARE_HYPERVISOR_MAGIC
- * arg2 - Hypercall command
- * arg3 bits [15:0] - Port number, LB and direction flags
+ * - Low bandwidth (LB) hypercalls: I/O port based (aka backdoor), vmcall and
+ * vmmcall have up to 6 input and 6 output on registers arguments, with the
+ * register mapping:
+ * +------+----------------------------------------+-----------------+
+ * | Reg | Input argument | Output argument |
+ * +======+========================================+=================+
+ * | %eax | VMWARE_HYPERVISOR_MAGIC | out0 |
+ * +------+----------------------------------------+-----------------+
+ * | %ebx | (in1) | out1 |
+ * +------+----------------------------------------+-----------------+
+ * | %ecx | (cmd) - Hypercall command | out2 |
+ * +------+----------------------------------------+-----------------+
+ * | %edx | Bits [15:0] - Port number for backdoor | out3 |
+ * | | Zero for vmcall/vmmcall | |
+ * | | Bits [31:16] - (in3) | |
+ * +------+----------------------------------------+-----------------+
+ * | %esi | (in4) | out4 |
+ * +------+----------------------------------------+-----------------+
+ * | %edi | (in5) | out5 |
+ * +------+----------------------------------------+-----------------+
*
- * - Low bandwidth TDX hypercalls (x86_64 only) are similar to LB
- * hypercalls. They also have up to 6 input and 6 output on registers
- * arguments, with different argument to register mapping:
- * %r12 (arg0), %rbx (arg1), %r13 (arg2), %rdx (arg3),
- * %rsi (arg4), %rdi (arg5).
+ * - Low bandwidth TDX hypercalls (x86_64 only) are similar to LB hypercalls.
+ * They also have up to 6 input and 6 output on registers arguments, with
+ * different argument to register mapping:
+ * +------+----------------------------------------+-----------------+
+ * | Reg | Input argument | Output argument |
+ * +======+========================================+=================+
+ * | %r12 | VMWARE_HYPERVISOR_MAGIC | out0 |
+ * +------+----------------------------------------+-----------------+
+ * | %ebx | (in1) | out1 |
+ * +------+----------------------------------------+-----------------+
+ * | %r13 | (cmd) - Hypercall command | out2 |
+ * +------+----------------------------------------+-----------------+
+ * | %edx | Bits [15:0] - Must be zero | out3 |
+ * | | Bits [31:16] - (in3) | |
+ * +------+----------------------------------------+-----------------+
+ * | %esi | (in4) | out4 |
+ * +------+----------------------------------------+-----------------+
+ * | %edi | (in5) | out5 |
+ * +------+----------------------------------------+-----------------+
*
- * - High bandwidth (HB) hypercalls are I/O port based only. They have
- * up to 7 input and 7 output arguments passed and returned using
- * registers: %eax (arg0), %ebx (arg1), %ecx (arg2), %edx (arg3),
- * %esi (arg4), %edi (arg5), %ebp (arg6).
- * The following input arguments must be initialized by the caller:
- * arg0 - VMWARE_HYPERVISOR_MAGIC
- * arg1 - Hypercall command
- * arg3 bits [15:0] - Port number, HB and direction flags
+ * - High bandwidth (HB) hypercalls are I/O port based only. They have up to 7
+ * input and 7 output on reegister arguments with the following mapping:
+ * +------+----------------------------------------+-----------------+
+ * | Reg | Input argument | Output argument |
+ * +======+========================================+=================+
+ * | %eax | VMWARE_HYPERVISOR_MAGIC | out0 |
+ * +------+----------------------------------------+-----------------+
+ * | %ebx | (cmd) - Hypercall command | out1 |
+ * +------+----------------------------------------+-----------------+
+ * | %ebx | (in2) | out2 |
+ * +------+----------------------------------------+-----------------+
+ * | %edx | Bits [15:0] - Port number and HB flag | out3 |
+ * | | Bits [31:16] - (in3) | |
+ * +------+----------------------------------------+-----------------+
+ * | %esi | (in4) | out4 |
+ * +------+----------------------------------------+-----------------+
+ * | %edi | (in5) | out5 |
+ * +------+----------------------------------------+-----------------+
+ * | %ebp | (in6) | out6 |
+ * +------+----------------------------------------+-----------------+
*
- * For compatibility purposes, x86_64 systems use only lower 32 bits
- * for input and output arguments.
+ * For compatibility purposes, x86_64 systems use only lower 32 bits for input
+ * and output arguments.
*
- * The hypercall definitions differ in the low word of the %edx (arg3)
- * in the following way: the old I/O port based interface uses the port
- * number to distinguish between high- and low bandwidth versions, and
- * uses IN/OUT instructions to define transfer direction.
+ * The hypercall definitions differ in the low word of the %edx (arg3) in the
+ * following way: the old I/O port based interface uses the port number, the
+ * bandwidth mode flag, and uses IN/OUT instructions to define transfer
+ * direction.
*
- * The new vmcall interface instead uses a set of flags to select
- * bandwidth mode and transfer direction. The flags should be loaded
- * into arg3 by any user and are automatically replaced by the port
- * number if the I/O port method is used.
+ * The new vmcall interface instead uses a set of flags to select bandwidth
+ * mode and transfer direction.
*/
#define VMWARE_HYPERVISOR_HB BIT(0)
@@ -70,103 +106,64 @@
#define CPUID_VMWARE_FEATURES_ECX_VMMCALL BIT(0)
#define CPUID_VMWARE_FEATURES_ECX_VMCALL BIT(1)
-extern unsigned long vmware_hypercall_slow(unsigned long cmd,
- unsigned long in1, unsigned long in3,
- unsigned long in4, unsigned long in5,
- u32 *out1, u32 *out2, u32 *out3,
- u32 *out4, u32 *out5);
-
#define VMWARE_TDX_VENDOR_LEAF 0x1af7e4909ULL
#define VMWARE_TDX_HCALL_FUNC 1
-extern unsigned long vmware_tdx_hypercall(unsigned long cmd,
- unsigned long in1, unsigned long in3,
- unsigned long in4, unsigned long in5,
- u32 *out1, u32 *out2, u32 *out3,
- u32 *out4, u32 *out5);
+unsigned long dummy_vmware_hypercall(unsigned long cmd,
+ unsigned long in1, unsigned long in3,
+ unsigned long in4, unsigned long in5,
+ u32 *out1, u32 *out2, u32 *out3,
+ u32 *out4, u32 *out5);
/*
- * The low bandwidth call. The low word of %edx is presumed to have OUT bit
- * set. The high word of %edx may contain input data from the caller.
+ * Low bandwidth (LB) VMware hypercall.
+ *
+ * It is backed by the backdoor, vmcall, vmmcall or tdx call implementation.
+ *
+ * Use inX/outX arguments naming as the register mappings vary between
+ * different implementations. See VMware hypercall ABI above.
+ * These 10 arguments could be nicely wrapped in in/out structures, but it
+ * will introduce unnecessary structs copy in vmware_tdx_hypercall().
+ *
+ * NOTE:
+ * Do not merge vmware_{backdoor,vmcall,vmmcall}_hypercall implementations
+ * using alternative instructions. Such patching mechanism can not be used
+ * in vmware_hypercall path, as the first hypercall will be called much
+ * before the apply_alternatives(). See vmware_platform_setup().
*/
-#define VMWARE_HYPERCALL \
- ALTERNATIVE_2("movw %[port], %%dx\n\t" \
- "inl (%%dx), %%eax", \
- "vmcall", X86_FEATURE_VMCALL, \
- "vmmcall", X86_FEATURE_VMW_VMMCALL)
+DECLARE_STATIC_CALL(vmware_hypercall, dummy_vmware_hypercall);
+/*
+ * Set of commonly used vmware_hypercallX functions - wrappers on top of the
+ * vmware_hypercall.
+ */
static inline
unsigned long vmware_hypercall1(unsigned long cmd, unsigned long in1)
{
- unsigned long out0;
-
- if (cpu_feature_enabled(X86_FEATURE_TDX_GUEST))
- return vmware_tdx_hypercall(cmd, in1, 0, 0, 0,
- NULL, NULL, NULL, NULL, NULL);
-
- if (unlikely(!alternatives_patched) && !__is_defined(MODULE))
- return vmware_hypercall_slow(cmd, in1, 0, 0, 0,
- NULL, NULL, NULL, NULL, NULL);
+ u32 out1, out2, out3, out4, out5;
- asm_inline volatile (VMWARE_HYPERCALL
- : "=a" (out0)
- : [port] "i" (VMWARE_HYPERVISOR_PORT),
- "a" (VMWARE_HYPERVISOR_MAGIC),
- "b" (in1),
- "c" (cmd),
- "d" (0)
- : "cc", "memory");
- return out0;
+ return static_call_mod(vmware_hypercall)(cmd, in1, 0, 0, 0,
+ &out1, &out2, &out3, &out4, &out5);
}
static inline
unsigned long vmware_hypercall3(unsigned long cmd, unsigned long in1,
u32 *out1, u32 *out2)
{
- unsigned long out0;
-
- if (cpu_feature_enabled(X86_FEATURE_TDX_GUEST))
- return vmware_tdx_hypercall(cmd, in1, 0, 0, 0,
- out1, out2, NULL, NULL, NULL);
-
- if (unlikely(!alternatives_patched) && !__is_defined(MODULE))
- return vmware_hypercall_slow(cmd, in1, 0, 0, 0,
- out1, out2, NULL, NULL, NULL);
+ u32 out3, out4, out5;
- asm_inline volatile (VMWARE_HYPERCALL
- : "=a" (out0), "=b" (*out1), "=c" (*out2)
- : [port] "i" (VMWARE_HYPERVISOR_PORT),
- "a" (VMWARE_HYPERVISOR_MAGIC),
- "b" (in1),
- "c" (cmd),
- "d" (0)
- : "di", "si", "cc", "memory");
- return out0;
+ return static_call_mod(vmware_hypercall)(cmd, in1, 0, 0, 0,
+ out1, out2, &out3, &out4, &out5);
}
static inline
unsigned long vmware_hypercall4(unsigned long cmd, unsigned long in1,
u32 *out1, u32 *out2, u32 *out3)
{
- unsigned long out0;
-
- if (cpu_feature_enabled(X86_FEATURE_TDX_GUEST))
- return vmware_tdx_hypercall(cmd, in1, 0, 0, 0,
- out1, out2, out3, NULL, NULL);
-
- if (unlikely(!alternatives_patched) && !__is_defined(MODULE))
- return vmware_hypercall_slow(cmd, in1, 0, 0, 0,
- out1, out2, out3, NULL, NULL);
+ u32 out4, out5;
- asm_inline volatile (VMWARE_HYPERCALL
- : "=a" (out0), "=b" (*out1), "=c" (*out2), "=d" (*out3)
- : [port] "i" (VMWARE_HYPERVISOR_PORT),
- "a" (VMWARE_HYPERVISOR_MAGIC),
- "b" (in1),
- "c" (cmd),
- "d" (0)
- : "di", "si", "cc", "memory");
- return out0;
+ return static_call_mod(vmware_hypercall)(cmd, in1, 0, 0, 0,
+ out1, out2, out3, &out4, &out5);
}
static inline
@@ -174,27 +171,10 @@ unsigned long vmware_hypercall5(unsigned long cmd, unsigned long in1,
unsigned long in3, unsigned long in4,
unsigned long in5, u32 *out2)
{
- unsigned long out0;
-
- if (cpu_feature_enabled(X86_FEATURE_TDX_GUEST))
- return vmware_tdx_hypercall(cmd, in1, in3, in4, in5,
- NULL, out2, NULL, NULL, NULL);
+ u32 out1, out3, out4, out5;
- if (unlikely(!alternatives_patched) && !__is_defined(MODULE))
- return vmware_hypercall_slow(cmd, in1, in3, in4, in5,
- NULL, out2, NULL, NULL, NULL);
-
- asm_inline volatile (VMWARE_HYPERCALL
- : "=a" (out0), "=c" (*out2)
- : [port] "i" (VMWARE_HYPERVISOR_PORT),
- "a" (VMWARE_HYPERVISOR_MAGIC),
- "b" (in1),
- "c" (cmd),
- "d" (in3),
- "S" (in4),
- "D" (in5)
- : "cc", "memory");
- return out0;
+ return static_call_mod(vmware_hypercall)(cmd, in1, in3, in4, in5,
+ &out1, out2, &out3, &out4, &out5);
}
static inline
@@ -202,26 +182,10 @@ unsigned long vmware_hypercall6(unsigned long cmd, unsigned long in1,
unsigned long in3, u32 *out2,
u32 *out3, u32 *out4, u32 *out5)
{
- unsigned long out0;
-
- if (cpu_feature_enabled(X86_FEATURE_TDX_GUEST))
- return vmware_tdx_hypercall(cmd, in1, in3, 0, 0,
- NULL, out2, out3, out4, out5);
+ u32 out1;
- if (unlikely(!alternatives_patched) && !__is_defined(MODULE))
- return vmware_hypercall_slow(cmd, in1, in3, 0, 0,
- NULL, out2, out3, out4, out5);
-
- asm_inline volatile (VMWARE_HYPERCALL
- : "=a" (out0), "=c" (*out2), "=d" (*out3), "=S" (*out4),
- "=D" (*out5)
- : [port] "i" (VMWARE_HYPERVISOR_PORT),
- "a" (VMWARE_HYPERVISOR_MAGIC),
- "b" (in1),
- "c" (cmd),
- "d" (in3)
- : "cc", "memory");
- return out0;
+ return static_call_mod(vmware_hypercall)(cmd, in1, in3, 0, 0,
+ &out1, out2, out3, out4, out5);
}
static inline
@@ -230,27 +194,10 @@ unsigned long vmware_hypercall7(unsigned long cmd, unsigned long in1,
unsigned long in5, u32 *out1,
u32 *out2, u32 *out3)
{
- unsigned long out0;
-
- if (cpu_feature_enabled(X86_FEATURE_TDX_GUEST))
- return vmware_tdx_hypercall(cmd, in1, in3, in4, in5,
- out1, out2, out3, NULL, NULL);
+ u32 out4, out5;
- if (unlikely(!alternatives_patched) && !__is_defined(MODULE))
- return vmware_hypercall_slow(cmd, in1, in3, in4, in5,
- out1, out2, out3, NULL, NULL);
-
- asm_inline volatile (VMWARE_HYPERCALL
- : "=a" (out0), "=b" (*out1), "=c" (*out2), "=d" (*out3)
- : [port] "i" (VMWARE_HYPERVISOR_PORT),
- "a" (VMWARE_HYPERVISOR_MAGIC),
- "b" (in1),
- "c" (cmd),
- "d" (in3),
- "S" (in4),
- "D" (in5)
- : "cc", "memory");
- return out0;
+ return static_call_mod(vmware_hypercall)(cmd, in1, in3, in4, in5,
+ out1, out2, out3, &out4, &out5);
}
#ifdef CONFIG_X86_64
@@ -322,6 +269,5 @@ unsigned long vmware_hypercall_hb_in(unsigned long cmd, unsigned long in2,
return out0;
}
#undef VMW_BP_CONSTRAINT
-#undef VMWARE_HYPERCALL
#endif
diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c
index a3e6936839b1..93acd3414e37 100644
--- a/arch/x86/kernel/cpu/vmware.c
+++ b/arch/x86/kernel/cpu/vmware.c
@@ -64,70 +64,140 @@ struct vmware_steal_time {
};
static unsigned long vmware_tsc_khz __ro_after_init;
-static u8 vmware_hypercall_mode __ro_after_init;
-
-unsigned long vmware_hypercall_slow(unsigned long cmd,
- unsigned long in1, unsigned long in3,
- unsigned long in4, unsigned long in5,
- u32 *out1, u32 *out2, u32 *out3,
- u32 *out4, u32 *out5)
-{
- unsigned long out0, rbx, rcx, rdx, rsi, rdi;
-
- switch (vmware_hypercall_mode) {
- case CPUID_VMWARE_FEATURES_ECX_VMCALL:
- asm_inline volatile ("vmcall"
- : "=a" (out0), "=b" (rbx), "=c" (rcx),
- "=d" (rdx), "=S" (rsi), "=D" (rdi)
- : "a" (VMWARE_HYPERVISOR_MAGIC),
- "b" (in1),
- "c" (cmd),
- "d" (in3),
- "S" (in4),
- "D" (in5)
- : "cc", "memory");
- break;
- case CPUID_VMWARE_FEATURES_ECX_VMMCALL:
- asm_inline volatile ("vmmcall"
- : "=a" (out0), "=b" (rbx), "=c" (rcx),
- "=d" (rdx), "=S" (rsi), "=D" (rdi)
- : "a" (VMWARE_HYPERVISOR_MAGIC),
- "b" (in1),
- "c" (cmd),
- "d" (in3),
- "S" (in4),
- "D" (in5)
- : "cc", "memory");
- break;
- default:
- asm_inline volatile ("movw %[port], %%dx; inl (%%dx), %%eax"
- : "=a" (out0), "=b" (rbx), "=c" (rcx),
- "=d" (rdx), "=S" (rsi), "=D" (rdi)
- : [port] "i" (VMWARE_HYPERVISOR_PORT),
- "a" (VMWARE_HYPERVISOR_MAGIC),
- "b" (in1),
- "c" (cmd),
- "d" (in3),
- "S" (in4),
- "D" (in5)
- : "cc", "memory");
- break;
- }
+static u8 vmware_hypercall_mode __initdata;
+
+static unsigned long vmware_backdoor_hypercall(unsigned long cmd,
+ unsigned long in1, unsigned long in3,
+ unsigned long in4, unsigned long in5,
+ u32 *out1, u32 *out2, u32 *out3,
+ u32 *out4, u32 *out5)
+{
+ unsigned long out0;
+
+ /* The low word of in3(%edx) must have the backdoor port number */
+ in3 = (in3 & ~0xffff) | VMWARE_HYPERVISOR_PORT;
+
+ asm_inline volatile ("inl (%%dx), %%eax"
+ : "=a" (out0), "=b" (*out1), "=c" (*out2),
+ "=d" (*out3), "=S" (*out4), "=D" (*out5)
+ : "a" (VMWARE_HYPERVISOR_MAGIC),
+ "b" (in1),
+ "c" (cmd),
+ "d" (in3),
+ "S" (in4),
+ "D" (in5)
+ : "cc", "memory");
- if (out1)
- *out1 = rbx;
- if (out2)
- *out2 = rcx;
- if (out3)
- *out3 = rdx;
- if (out4)
- *out4 = rsi;
- if (out5)
- *out5 = rdi;
+ return out0;
+}
+
+static unsigned long vmware_vmcall_hypercall(unsigned long cmd,
+ unsigned long in1, unsigned long in3,
+ unsigned long in4, unsigned long in5,
+ u32 *out1, u32 *out2, u32 *out3,
+ u32 *out4, u32 *out5)
+{
+ unsigned long out0;
+
+ /* The low word of in3(%edx) must be zero: LB, IN */
+ in3 &= ~0xffff;
+
+ asm_inline volatile ("vmcall"
+ : "=a" (out0), "=b" (*out1), "=c" (*out2),
+ "=d" (*out3), "=S" (*out4), "=D" (*out5)
+ : "a" (VMWARE_HYPERVISOR_MAGIC),
+ "b" (in1),
+ "c" (cmd),
+ "d" (in3),
+ "S" (in4),
+ "D" (in5)
+ : "cc", "memory");
return out0;
}
+static unsigned long vmware_vmmcall_hypercall(unsigned long cmd,
+ unsigned long in1, unsigned long in3,
+ unsigned long in4, unsigned long in5,
+ u32 *out1, u32 *out2, u32 *out3,
+ u32 *out4, u32 *out5)
+{
+ unsigned long out0;
+
+ /* The low word of in3(%edx) must be zero: LB, IN */
+ in3 &= ~0xffff;
+
+ asm_inline volatile ("vmmcall"
+ : "=a" (out0), "=b" (*out1), "=c" (*out2),
+ "=d" (*out3), "=S" (*out4), "=D" (*out5)
+ : "a" (VMWARE_HYPERVISOR_MAGIC),
+ "b" (in1),
+ "c" (cmd),
+ "d" (in3),
+ "S" (in4),
+ "D" (in5)
+ : "cc", "memory");
+
+ return out0;
+}
+
+/*
+ * TDCALL[TDG.VP.VMCALL] uses %rax (arg0) and %rcx (arg2). Therefore,
+ * we remap those registers to %r12 and %r13, respectively.
+ */
+static unsigned long vmware_tdx_hypercall(unsigned long cmd,
+ unsigned long in1, unsigned long in3,
+ unsigned long in4, unsigned long in5,
+ u32 *out1, u32 *out2, u32 *out3,
+ u32 *out4, u32 *out5)
+{
+#ifdef CONFIG_INTEL_TDX_GUEST
+ struct tdx_module_args args = {};
+
+ if (!hypervisor_is_type(X86_HYPER_VMWARE)) {
+ pr_warn_once("Incorrect usage\n");
+ return ULONG_MAX;
+ }
+
+ if (cmd & ~VMWARE_CMD_MASK) {
+ pr_warn_once("Out of range command %lx\n", cmd);
+ return ULONG_MAX;
+ }
+
+ args.rbx = in1;
+ /* The low word of in3(%rdx) must be zero: LB, IN */
+ args.rdx = in3 & ~0xffff;
+ args.rsi = in4;
+ args.rdi = in5;
+ args.r10 = VMWARE_TDX_VENDOR_LEAF;
+ args.r11 = VMWARE_TDX_HCALL_FUNC;
+ args.r12 = VMWARE_HYPERVISOR_MAGIC;
+ args.r13 = cmd;
+ /* CPL */
+ args.r15 = 0;
+
+ __tdx_hypercall(&args);
+
+ *out1 = args.rbx;
+ *out2 = args.r13;
+ *out3 = args.rdx;
+ *out4 = args.rsi;
+ *out5 = args.rdi;
+
+ return args.r12;
+#else
+ return ULONG_MAX;
+#endif
+}
+
+
+DEFINE_STATIC_CALL(vmware_hypercall, vmware_backdoor_hypercall);
+EXPORT_STATIC_CALL_GPL(vmware_hypercall);
+
+/*
+ * Perform backdoor probbing of the hypervisor when
+ * X86_FEATURE_HYPERVISOR bit is not set.
+ */
static inline int __vmware_platform(void)
{
u32 eax, ebx, ecx;
@@ -397,11 +467,35 @@ static void __init vmware_set_capabilities(void)
setup_force_cpu_cap(X86_FEATURE_VMW_VMMCALL);
}
+static void __init vmware_select_hypercall(void)
+{
+ char *mode;
+
+ if (IS_ENABLED(CONFIG_INTEL_TDX_GUEST) &&
+ cpu_feature_enabled(X86_FEATURE_TDX_GUEST)) {
+ static_call_update(vmware_hypercall, vmware_tdx_hypercall);
+ mode = "tdcall";
+ } else if (vmware_hypercall_mode == CPUID_VMWARE_FEATURES_ECX_VMCALL) {
+ static_call_update(vmware_hypercall, vmware_vmcall_hypercall);
+ mode = "vmcall";
+ } else if (vmware_hypercall_mode == CPUID_VMWARE_FEATURES_ECX_VMMCALL) {
+ static_call_update(vmware_hypercall, vmware_vmmcall_hypercall);
+ mode = "vmmcall";
+ } else {
+ mode = "backdoor";
+ }
+
+ pr_info("hypercall mode: %s\n", mode);
+}
+
static void __init vmware_platform_setup(void)
{
u32 eax, ebx, ecx;
u64 lpj, tsc_khz;
+ /* Update vmware_hypercall() before the first use. */
+ vmware_select_hypercall();
+
eax = vmware_hypercall3(VMWARE_CMD_GETHZ, UINT_MAX, &ebx, &ecx);
if (ebx != UINT_MAX) {
@@ -443,7 +537,7 @@ static void __init vmware_platform_setup(void)
vmware_set_capabilities();
}
-static u8 __init vmware_select_hypercall(void)
+static u8 __init get_hypercall_mode(void)
{
int eax, ebx, ecx, edx;
@@ -456,8 +550,8 @@ static u8 __init vmware_select_hypercall(void)
* While checking the dmi string information, just checking the product
* serial key should be enough, as this will always have a VMware
* specific string when running under VMware hypervisor.
- * If !boot_cpu_has(X86_FEATURE_HYPERVISOR), vmware_hypercall_mode
- * intentionally defaults to 0.
+ * If !boot_cpu_has(X86_FEATURE_HYPERVISOR), __vmware_platform()
+ * intentionally defaults to backdoor hypercall.
*/
static u32 __init vmware_platform(void)
{
@@ -470,11 +564,7 @@ static u32 __init vmware_platform(void)
if (!memcmp(hyper_vendor_id, "VMwareVMware", 12)) {
if (eax >= CPUID_VMWARE_FEATURES_LEAF)
vmware_hypercall_mode =
- vmware_select_hypercall();
-
- pr_info("hypercall mode: 0x%02x\n",
- (unsigned int) vmware_hypercall_mode);
-
+ get_hypercall_mode();
return CPUID_VMWARE_INFO_LEAF;
}
} else if (dmi_available && dmi_name_in_serial("VMware") &&
@@ -494,58 +584,6 @@ static bool __init vmware_legacy_x2apic_available(void)
(eax & GETVCPU_INFO_LEGACY_X2APIC);
}
-#ifdef CONFIG_INTEL_TDX_GUEST
-/*
- * TDCALL[TDG.VP.VMCALL] uses %rax (arg0) and %rcx (arg2). Therefore,
- * we remap those registers to %r12 and %r13, respectively.
- */
-unsigned long vmware_tdx_hypercall(unsigned long cmd,
- unsigned long in1, unsigned long in3,
- unsigned long in4, unsigned long in5,
- u32 *out1, u32 *out2, u32 *out3,
- u32 *out4, u32 *out5)
-{
- struct tdx_module_args args = {};
-
- if (!hypervisor_is_type(X86_HYPER_VMWARE)) {
- pr_warn_once("Incorrect usage\n");
- return ULONG_MAX;
- }
-
- if (cmd & ~VMWARE_CMD_MASK) {
- pr_warn_once("Out of range command %lx\n", cmd);
- return ULONG_MAX;
- }
-
- args.rbx = in1;
- args.rdx = in3;
- args.rsi = in4;
- args.rdi = in5;
- args.r10 = VMWARE_TDX_VENDOR_LEAF;
- args.r11 = VMWARE_TDX_HCALL_FUNC;
- args.r12 = VMWARE_HYPERVISOR_MAGIC;
- args.r13 = cmd;
- /* CPL */
- args.r15 = 0;
-
- __tdx_hypercall(&args);
-
- if (out1)
- *out1 = args.rbx;
- if (out2)
- *out2 = args.r13;
- if (out3)
- *out3 = args.rdx;
- if (out4)
- *out4 = args.rsi;
- if (out5)
- *out5 = args.rdi;
-
- return args.r12;
-}
-EXPORT_SYMBOL_GPL(vmware_tdx_hypercall);
-#endif
-
#ifdef CONFIG_AMD_MEM_ENCRYPT
static void vmware_sev_es_hcall_prepare(struct ghcb *ghcb,
struct pt_regs *regs)
--
2.43.7
^ permalink raw reply related
* [PATCH v2 0/4] x86/vmware: Hypercall refactoring and improved guest support
From: Alexey Makhalov @ 2026-03-09 23:52 UTC (permalink / raw)
To: x86, virtualization, bp, hpa, dave.hansen, mingo, tglx
Cc: ajay.kaher, brennan.lamoreaux, bo.gan, bcm-kernel-feedback-list,
linux-kernel, kas, rick.p.edgecombe, linux-coco, Alexey Makhalov
In-Reply-To: <20260307004238.1181299-1-alexey.makhalov@broadcom.com>
This series improves VMware guest support on x86 by refactoring the
hypercall infrastructure and adding better crash diagnostics, along
with encrypted guest support for the steal time clock.
The first patch introduces a common vmware_hypercall() backend selected
via static calls. It consolidates the existing hypercall mechanisms
(backdoor, VMCALL/VMMCALL, and TDX) behind a single interface and
selects the optimal implementation at boot. This reduces duplication
and simplifies future extensions.
Building on top of the new hypercall infrastructure, the next two
patches improve post-mortem debugging of VMware guests. They export
panic information to the hypervisor by dumping kernel messages to the
VM vmware.log on the host and explicitly reporting guest crash event
to the hypervisor.
The final patch adds support for encrypted guests by ensuring that the
shared memory used for the steal time clock is mapped as decrypted
before being shared with the hypervisor. This enables steal time
accounting to function correctly when guest memory encryption is
enabled.
Patch overview:
1. x86/vmware: Introduce common vmware_hypercall
* Consolidate hypercall implementations behind a common API
* Select backend via static_call at boot
2. x86/vmware: Log kmsg dump on panic
* Register a kmsg dumper
* Export panic logs to the host
3. x86/vmware: Report guest crash to the hypervisor
* Register a panic notifier
* Notify the hypervisor about guest crashes
4. x86/vmware: Support steal time clock for encrypted guests
* Mark shared steal time memory as decrypted early in boot
Changelog:
V1 -> V2
* Fix compilation warnings in patch 2 "x86/vmware: Log kmsg dump on panic"
reported by kernel test robot <lkp@intel.com>
Alexey Makhalov (4):
x86/vmware: Introduce common vmware_hypercall()
x86/vmware: Log kmsg dump on panic
x86/vmware: Report guest crash to the hypervisor
x86/vmware: Support steal time clock for encrypted guests
arch/x86/include/asm/vmware.h | 276 ++++++++------------
arch/x86/kernel/cpu/vmware.c | 470 +++++++++++++++++++++++++---------
2 files changed, 463 insertions(+), 283 deletions(-)
base-commit: 7d08a6ad25f85c9bb7d0382142838cb54713f1a3
--
2.43.7
^ permalink raw reply
* Re: [PATCH net-next v3 1/2] dma-mapping: introduce DMA_ATTR_CC_DECRYPTED for pre-decrypted memory
From: Jiri Pirko @ 2026-03-09 17:51 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Leon Romanovsky, dri-devel, linaro-mm-sig, iommu, linux-media,
sumit.semwal, benjamin.gaignard, Brian.Starkey, jstultz,
tjmercier, christian.koenig, m.szyprowski, robin.murphy,
sean.anderson, ptesarik, catalin.marinas, aneesh.kumar,
suzuki.poulose, steven.price, thomas.lendacky, john.allen,
ashish.kalra, suravee.suthikulpanit, linux-coco
In-Reply-To: <20260309151857.GO1687929@ziepe.ca>
Mon, Mar 09, 2026 at 04:18:57PM +0100, jgg@ziepe.ca wrote:
>On Mon, Mar 09, 2026 at 04:02:33PM +0200, Leon Romanovsky wrote:
>> On Mon, Mar 09, 2026 at 10:15:30AM -0300, Jason Gunthorpe wrote:
>> > On Sun, Mar 08, 2026 at 12:19:48PM +0200, Leon Romanovsky wrote:
>> >
>> > > > +/*
>> > > > + * DMA_ATTR_CC_DECRYPTED: Indicates memory that has been explicitly decrypted
>> > > > + * (shared) for confidential computing guests. The caller must have
>> > > > + * called set_memory_decrypted(). A struct page is required.
>> > > > + */
>> > > > +#define DMA_ATTR_CC_DECRYPTED (1UL << 12)
>> > >
>> > > While adding the new attribute is fine, I would expect additional checks in
>> > > dma_map_phys() to ensure the attribute cannot be misused. For example,
>> > > WARN_ON(attrs & (DMA_ATTR_CC_DECRYPTED | DMA_ATTR_MMIO)), along with a check
>> > > that we are taking the direct path only.
>> >
>> > DECRYPYED and MMIO is something that needs to work, VFIO (inside a
>> > TVM) should be using that combination.
>>
>> So this sentence "A struct page is required" from the comment above is
>> not accurate.
>
>It would be clearer to say "Unless DMA_ATTR_MMIO is provided a struct
>page is required"
>
>We need to audit if that works properly, IIRC it does, but I don't
>remember.. Jiri?
How can you do set_memory_decrypted if you don't have page/folio ?
^ permalink raw reply
* Re: [PATCH v2 05/19] device core: Autoprobe considered harmful?
From: Jonathan Cameron @ 2026-03-09 16:58 UTC (permalink / raw)
To: Dan Williams
Cc: linux-coco, linux-pci, gregkh, aik, aneesh.kumar, yilun.xu,
bhelgaas, alistair23, lukas, jgg, Christoph Hellwig,
Marek Szyprowski, Robin Murphy, Roman Kisel, Samuel Ortiz,
Rafael J. Wysocki, Danilo Krummrich
In-Reply-To: <20260303000207.1836586-6-dan.j.williams@intel.com>
On Mon, 2 Mar 2026 16:01:53 -0800
Dan Williams <dan.j.williams@intel.com> wrote:
> The threat model of PCI Trusted Execution Environment Device Interface
> Security Protocol (TDISP), is that an adversary may be impersonating the
> device's identity, redirecting the device's MMIO interface, and/or
> snooping/manipulating the physical link. Outside of PCI TDISP, PCI ATS
> (that allows IOMMU bypass) comes to mind as another threat vector that
> warrants additional device verification beyond whether ACPI enumerates the
> device as "internal" [1].
>
> The process of verifying a device ranges from the traditional default
> "accept everything" to gathering signed evidence from a locked device,
> shipping it to a relying party and acting on that disposition. That policy
> belongs in userspace. A natural way for userspace to get a control point
> for verifying a device before use is when the driver for the device comes
> from a module.
>
> For deployments that are concerned about adversarial devices, introduce a
> mechanism to disable autoprobe. When a driver originates from a module,
> consult that driver's autoprobe policy at initial device or driver attach.
>
> Note that with TDISP, unaccepted devices do not have access to private
> memory (so called "T=0" mode). However, a deployment may still not want to
> operate more than a handful of boot devices until confirming the system
> device topology with a verifier.
>
> Yes, this is a security vs convenience tradeoff. Yes, devices with
> non-modular drivers are out of scope. Yes, there are known regression cases
> for subsystems where device objects are expected to auto-attach outside of
> fatal probe failure. For navigating regressions, a per-module "autoprobe"
> option is included to allow fine grained policy.
>
> Cc: Christoph Hellwig <hch@lst.de>
> Cc: Jason Gunthorpe <jgg@nvidia.com>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Roman Kisel <romank@linux.microsoft.com>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Samuel Ortiz <sameo@rivosinc.com>
> Cc: Alexey Kardashevskiy <aik@amd.com>
> Cc: Xu Yilun <yilun.xu@linux.intel.com>
> Cc: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> Cc: Danilo Krummrich <dakr@kernel.org>
> Link: http://lore.kernel.org/6971b9406d069_1d33100df@dwillia2-mobl4.notmuch [1]
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Approach seems reasonable to me.
A few trivial things inline.
Jonathan
> ---
> drivers/base/Kconfig | 24 ++++++++++++++++++++++++
> Documentation/ABI/stable/sysfs-module | 10 ++++++++++
> drivers/base/base.h | 1 +
> include/linux/module.h | 14 ++++++++++++++
> drivers/base/bus.c | 7 ++++++-
> drivers/base/dd.c | 26 +++++++++++++++++++++++---
> kernel/module/main.c | 13 +++++++++++++
> 7 files changed, 91 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
> index d4743bf978ec..7c1da5df9745 100644
> --- a/drivers/base/Kconfig
> +++ b/drivers/base/Kconfig
> @@ -253,4 +253,28 @@ config CONFIDENTIAL_DEVICES
> depends on ARCH_HAS_CC_PLATFORM
> bool
>
> +config MODULES_AUTOPROBE
> + bool "Automatic probe of drivers from modules"
> + default y
> + help
> + Say Y for the typical and traditional Linux behavior of automatically
> + attaching devices to drivers when a module is loaded.
> +
> + Say N to opt into a threat model where userspace verification of a
> + device is required before driver attach. This includes Confidential
> + Computing use cases where the device needs to have its configuration
> + locked and verified by a relying party. It also includes use cases
> + like leaving devices with Address Translation (IOMMU protection
> + bypass) capability disabled until userspace attests the device and
> + binds a driver.
> +
> + This default value can be overridden by the "autoprobe" module option.
> + Note that some subsystems may not be prepared for autoprobe to be
> + disabled, take care to test your selected drivers. Built-in drivers are
Stray extra space.
> + unaffected by this policy and will autoprobe unless the bus itself has
> + disabled autoprobe.
> +
> + If in doubt, say Y. The N case is only for expert configurations, and
> + selective "autoprobe=0" in modprobe policy is the common expectation.
> +
> endmenu
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index 349f31bedfa1..926e120b3cc4 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -917,6 +917,12 @@ struct device_attach_data {
> * driver, we'll encounter one that requests asynchronous probing.
> */
> bool have_async;
> +
> + /*
> + * On initial device arrival driver attach is subject to
> + * driver_autoprobe() policy.
> + */
> + bool initial_probe;
I'm not sure 'initial' naming works. How does that work with drivers that
have not autobound anyway? E.g. VFIO.
Seems they'll be fine even if it is their initial probe. Also the
deferred cases remain 'initial' for repeated probing.
Why not stick to the auto probing terminology here?
There is clearly history of this naming though in device_initial_probe()
So maybe that name is fine...
> };
>
>
^ permalink raw reply
* Re: [PATCH v2 03/19] device core: Introduce confidential device acceptance
From: Jonathan Cameron @ 2026-03-09 16:42 UTC (permalink / raw)
To: Dan Williams
Cc: linux-coco, linux-pci, gregkh, aik, aneesh.kumar, yilun.xu,
bhelgaas, alistair23, lukas, jgg, Christoph Hellwig,
Jason Gunthorpe, Marek Szyprowski, Robin Murphy, Roman Kisel,
Samuel Ortiz, Rafael J. Wysocki, Danilo Krummrich
In-Reply-To: <20260303000207.1836586-4-dan.j.williams@intel.com>
On Mon, 2 Mar 2026 16:01:51 -0800
Dan Williams <dan.j.williams@intel.com> wrote:
> An "accepted" device is one that is allowed to access private memory within
> a Trusted Computing Boundary (TCB). The concept of "acceptance" is distinct
> from other device properties like usb_device::authorized, or
> tb_switch::authorized. The entry to the accepted state is a violent
> operation in which the device will reject MMIO requests that are not
> encrypted, and the device enters a new IOMMU protection domain to allow it
> to access addresses that were previously off-limits.
>
> Subsystems like the DMA mapping layer, that need to modify their behavior
> based on the accept state, may only have access to the base 'struct
> device'. It is also likely that the concept of TCB acceptance grows beyond
> PCI devices over time. For these reasons, introduce the concept of
> acceptance in 'struct device_private' which is device common, but only
> suitable for buses and built-in infrastructure to consume.
>
> Cc: Christoph Hellwig <hch@lst.de>
> Cc: Jason Gunthorpe <jgg@ziepe.ca>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Roman Kisel <romank@linux.microsoft.com>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Samuel Ortiz <sameo@rivosinc.com>
> Cc: Alexey Kardashevskiy <aik@amd.com>
> Cc: Xu Yilun <yilun.xu@linux.intel.com>
> Cc: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> Cc: Danilo Krummrich <dakr@kernel.org>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Seems reasonable to me.
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
^ permalink raw reply
* Re: [PATCH v2 02/19] device core: Fix kernel-doc warnings in base.h
From: Jonathan Cameron @ 2026-03-09 16:39 UTC (permalink / raw)
To: Dan Williams
Cc: linux-coco, linux-pci, gregkh, aik, aneesh.kumar, yilun.xu,
bhelgaas, alistair23, lukas, jgg
In-Reply-To: <20260303000207.1836586-3-dan.j.williams@intel.com>
On Mon, 2 Mar 2026 16:01:50 -0800
Dan Williams <dan.j.williams@intel.com> wrote:
> In preparation for adding new fields to 'struct device_private' fix up
> existing kernel-doc warnings in this header file of the form:
>
> Warning: drivers/base/base.h:59 struct member 'subsys' not described in
> 'subsys_private'
> Warning: drivers/base/base.h:59 struct member 'devices_kset' not described
> in 'subsys_private'
> Warning: drivers/base/base.h:59 struct member 'interfaces' not described in
> 'subsys_private'
> Warning: drivers/base/base.h:59 struct member 'mutex' not described in
> 'subsys_private'
>
> ...which are simple replacements of " - " with ": ".
>
> Add new descriptions for these previously undescribed fields:
>
> Warning: drivers/base/base.h:58 struct member 'drivers_autoprobe' not
> described in 'subsys_private'
> Warning: drivers/base/base.h:117 struct member 'deferred_probe_reason' not
> described in 'device_private'
>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Maybe if the rest looks 'slow' can send this one ahead?
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Jonathan
^ permalink raw reply
* Re: [PATCH v2 01/19] PCI/TSM: Report active IDE streams per host bridge
From: Jonathan Cameron @ 2026-03-09 16:36 UTC (permalink / raw)
To: Dan Williams
Cc: linux-coco, linux-pci, gregkh, aik, aneesh.kumar, yilun.xu,
bhelgaas, alistair23, lukas, jgg
In-Reply-To: <20260303000207.1836586-2-dan.j.williams@intel.com>
On Mon, 2 Mar 2026 16:01:49 -0800
Dan Williams <dan.j.williams@intel.com> wrote:
> The first attempt at an ABI for this failed to account for naming
> collisions across host bridges:
>
> Commit a4438f06b1db ("PCI/TSM: Report active IDE streams")
>
> Revive this ABI with a per host bridge link that appears at first stream
> creation for a given host bridge and disappears after the last stream is
> removed.
>
> For systems with many host bridge objects it allows:
>
> ls /sys/class/tsm/tsmN/pci*/stream*
>
> ...to find all the host bridges with active streams without first iterating
> over all host bridges. Yilun notes that is handy to have this short cut [1]
> and from an administrator perspective it helps with inventory for
> constrained stream resources.
>
> Link: http://lore.kernel.org/aXLtILY85oMU5qlb@yilunxu-OptiPlex-7050 [1]
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> diff --git a/drivers/virt/coco/tsm-core.c b/drivers/virt/coco/tsm-core.c
> index 8712df8596a1..3c99c38cfaa5 100644
> --- a/drivers/virt/coco/tsm-core.c
> +++ b/drivers/virt/coco/tsm-core.c
> @@ -4,10 +4,12 @@
> +
> +static struct tsm_ide_stream *create_streams(struct tsm_dev *tsm_dev,
> + struct pci_host_bridge *bridge)
> +{
> + int rc;
> +
> + struct tsm_ide_stream *streams __free(kfree) =
> + kzalloc(sizeof(*streams), GFP_KERNEL);
Crossed with kzalloc_obj() etc being introduced which seems appropriate here.
> + if (!streams)
> + return NULL;
> +
> + streams->tsm_dev = tsm_dev;
> + streams->bridge = bridge;
> + kref_init(&streams->kref);
> + rc = xa_insert(&tsm_ide_streams, (unsigned long)bridge, streams,
> + GFP_KERNEL);
> + if (rc)
> + return NULL;
> +
> + rc = sysfs_create_link(&tsm_dev->dev.kobj, &bridge->dev.kobj,
> + dev_name(&bridge->dev));
> + if (rc) {
> + xa_erase(&tsm_ide_streams, (unsigned long)bridge);
> + return NULL;
> + }
> +
> + return no_free_ptr(streams);
> +}
^ permalink raw reply
* Re: [PATCH 4/4] KVM: x86: Disable the TDX module during kexec and kdump
From: Edgecombe, Rick P @ 2026-03-09 16:24 UTC (permalink / raw)
To: Gao, Chao
Cc: tglx@kernel.org, Hansen, Dave, seanjc@google.com, bp@alien8.de,
kas@kernel.org, ackerleytng@google.com, hpa@zytor.com,
linux-kernel@vger.kernel.org, mingo@redhat.com, x86@kernel.org,
kvm@vger.kernel.org, linux-coco@lists.linux.dev,
pbonzini@redhat.com, Verma, Vishal L, Huang, Kai
In-Reply-To: <aa6BmJzypU1o53rB@intel.com>
On Mon, 2026-03-09 at 16:15 +0800, Chao Gao wrote:
> > - /*
> > - * Some early TDX-capable platforms have an erratum. A
> > kernel
> > - * partial write (a write transaction of less than
> > cacheline
> > - * lands at memory controller) to TDX private memory
> > poisons that
> > - * memory, and a subsequent read triggers a machine check.
> > - *
> > - * On those platforms the old kernel must reset TDX
> > private
> > - * memory before jumping to the new kernel otherwise the
> > new
> > - * kernel may see unexpected machine check. For
> > simplicity
> > - * just fail kexec/kdump on those platforms.
> > - */
> > - if (boot_cpu_has_bug(X86_BUG_TDX_PW_MCE)) {
> > - pr_info_once("Not allowed on platform with
> > tdx_pw_mce bug\n");
> > - return -EOPNOTSUPP;
> > - }
>
> With this series, we need to update the "Kexec" section in tdx.rst.
Nice catch, and I agree on the others. Will update it. Thanks.
^ permalink raw reply
* Re: [PATCH 2/4] x86/virt/tdx: Pull kexec cache flush logic into arch/x86
From: Edgecombe, Rick P @ 2026-03-09 16:23 UTC (permalink / raw)
To: pbonzini@redhat.com, Hansen, Dave, seanjc@google.com,
bp@alien8.de, kas@kernel.org, ackerleytng@google.com,
hpa@zytor.com, linux-kernel@vger.kernel.org, mingo@redhat.com,
Huang, Kai, tglx@kernel.org, kvm@vger.kernel.org,
linux-coco@lists.linux.dev, x86@kernel.org, Gao, Chao
Cc: Verma, Vishal L
In-Reply-To: <d16e808b16d9c23f7db34e576c4dd82eb9772831.camel@intel.com>
On Mon, 2026-03-09 at 00:23 +0000, Huang, Kai wrote:
> Feel free to add:
>
> Acked-by: Kai Huang <kai.huang@intel.com>
>
> Btw, there's a functional change here, and perhaps we should call out
> in changelog:
Yea that makes sense.
>
> - Currently tdx_cpu_flush_cache_for_kexec() is done in
> kvm_disable_virtualization_cpu(), which is also called by KVM's CPUHP
> offline() callback. So tdx_cpu_flush_cache_for_kexec() is explicitly
> done in TDX code in CPU offline.
>
> - With this change, tdx_cpu_flush_cache_for_kexec() is not explicitly
> done in TDX code in CPU offline.
>
> But AFAICT this is fine, since IIUC the WBINVD is always done when
> kernel offlines one CPU (see [*]), i.e., the current
> tdx_cpu_flush_cache_for_kexec() done in KVM's CPUHP is actually
> superfluous.
>
> [*] See:
>
> native_play_dead() ->
> cpuidle_play_dead();
>
> hlt_play_dead();
>
> cpuidle_play_dead() can invoke different enter_dead() callbacks
> depending on what idle driver is being used, but AFAICT eventually it
> ends up calling either acpi_idle_play_dead() or mwait_play_dead(),
> both of which does WBINVD before going to idle.
>
> If cpuidle_play_dead() doesn't idle successfully, the hlt_play_dead()
> will then WBINVD and hlt.
>
> Actually, after looking at multiple commits around here, e.g.,
>
> ea53069231f93 ("x86, hotplug: Use mwait to offline a processor, fix
> the legacy case")
> dfbba2518aac4 ("Revert "ACPI: processor: idle: Only flush cache on
> entering C3")
>
> ... I believe it's a kernel policy to make sure cache is flushed when
> it offlines a CPU (which makes sense anyway of course), I just
> couldn't find the exact commit saying this (or I am not sure whether
> there's such commit).
>
>
Thanks for the analysis.
> Btw2, kinda related to this, could you help review:
>
> https://lore.kernel.org/lkml/20260302102226.7459-1-kai.huang@intel.com/
Well I think I wrote the log for it. But I yea I'll add a tag.
^ permalink raw reply
* Re: [PATCH 1/4] x86/tdx: Move all TDX error defines into <asm/shared/tdx_errno.h>
From: Edgecombe, Rick P @ 2026-03-09 16:20 UTC (permalink / raw)
To: pbonzini@redhat.com, Hansen, Dave, seanjc@google.com,
bp@alien8.de, kas@kernel.org, ackerleytng@google.com,
hpa@zytor.com, linux-kernel@vger.kernel.org, mingo@redhat.com,
Huang, Kai, tglx@kernel.org, kvm@vger.kernel.org,
linux-coco@lists.linux.dev, x86@kernel.org, Gao, Chao
Cc: kirill.shutemov@linux.intel.com, sagis@google.com,
Verma, Vishal L, Annapurve, Vishal
In-Reply-To: <19ae1ea7f3dc62ac95f5283f2f101066e52450f4.camel@intel.com>
On Sun, 2026-03-08 at 23:47 +0000, Huang, Kai wrote:
> Seems this patch was from your DPAMT v4.
>
> I made couple of small comments to that:
>
> https://lore.kernel.org/kvm/6968dcb446fb857b3f254030e487d889b464d7ce.camel@intel.com/
> https://lore.kernel.org/kvm/af7c8f3ec86688709cce550a2fc17110e3fd12b7.camel@intel.com/
>
> .. and seems you agreed to address them.
Oops. Yea, I incorporated those changes DPAMT branch. But between
Vishal and I, it didn't make it over here. I'll pull that one in for
V2.
>
> If you plan to address in the next version, free free to add:
>
> Reviewed-by: Kai Huang <kai.huang@intel.com>
Thanks.
^ permalink raw reply
* Re: [PATCH v3 2/3] swiotlb: dma: its: Enforce host page-size alignment for shared buffers
From: kernel test robot @ 2026-03-09 15:55 UTC (permalink / raw)
To: Aneesh Kumar K.V (Arm), linux-kernel, iommu, linux-coco,
linux-arm-kernel, kvmarm
Cc: llvm, oe-kbuild-all, Aneesh Kumar K.V (Arm), Marc Zyngier,
Thomas Gleixner, Catalin Marinas, Will Deacon, Jason Gunthorpe,
Marek Szyprowski, Robin Murphy, Steven Price, Suzuki K Poulose
In-Reply-To: <20260309102625.2315725-3-aneesh.kumar@kernel.org>
Hi Aneesh,
kernel test robot noticed the following build errors:
[auto build test ERROR on arm64/for-next/core]
[also build test ERROR on tip/irq/core arm/for-next arm/fixes kvmarm/next soc/for-next linus/master v7.0-rc3 next-20260306]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Aneesh-Kumar-K-V-Arm/dma-direct-swiotlb-handle-swiotlb-alloc-free-outside-__dma_direct_alloc_pages/20260309-182834
base: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
patch link: https://lore.kernel.org/r/20260309102625.2315725-3-aneesh.kumar%40kernel.org
patch subject: [PATCH v3 2/3] swiotlb: dma: its: Enforce host page-size alignment for shared buffers
config: i386-randconfig-012-20260309 (https://download.01.org/0day-ci/archive/20260309/202603092320.JgtItJg0-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260309/202603092320.JgtItJg0-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603092320.JgtItJg0-lkp@intel.com/
All errors (new ones prefixed by >>):
In file included from arch/x86/kernel/asm-offsets.c:9:
In file included from include/linux/crypto.h:15:
In file included from include/linux/completion.h:12:
In file included from include/linux/swait.h:7:
In file included from include/linux/spinlock.h:59:
In file included from include/linux/irqflags.h:18:
In file included from arch/x86/include/asm/irqflags.h:5:
In file included from arch/x86/include/asm/processor-flags.h:6:
>> include/linux/mem_encrypt.h:60:9: error: use of undeclared identifier 'PAGE_SIZE'
60 | return PAGE_SIZE;
| ^
>> include/linux/mem_encrypt.h:66:9: error: call to undeclared function 'ALIGN'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
66 | return ALIGN(size, mem_decrypt_granule_size());
| ^
In file included from arch/x86/kernel/asm-offsets.c:14:
In file included from include/linux/suspend.h:5:
In file included from include/linux/swap.h:9:
In file included from include/linux/memcontrol.h:13:
In file included from include/linux/cgroup.h:17:
In file included from include/linux/fs.h:5:
In file included from include/linux/fs/super.h:5:
In file included from include/linux/fs/super_types.h:13:
In file included from include/linux/percpu-rwsem.h:7:
In file included from include/linux/rcuwait.h:6:
In file included from include/linux/sched/signal.h:6:
include/linux/signal.h:98:11: warning: array index 3 is past the end of the array (that has type 'unsigned long[2]') [-Warray-bounds]
98 | return (set->sig[3] | set->sig[2] |
| ^ ~
arch/x86/include/asm/signal.h:24:2: note: array 'sig' declared here
24 | unsigned long sig[_NSIG_WORDS];
| ^
In file included from arch/x86/kernel/asm-offsets.c:14:
In file included from include/linux/suspend.h:5:
In file included from include/linux/swap.h:9:
In file included from include/linux/memcontrol.h:13:
In file included from include/linux/cgroup.h:17:
In file included from include/linux/fs.h:5:
In file included from include/linux/fs/super.h:5:
In file included from include/linux/fs/super_types.h:13:
In file included from include/linux/percpu-rwsem.h:7:
In file included from include/linux/rcuwait.h:6:
In file included from include/linux/sched/signal.h:6:
include/linux/signal.h:98:25: warning: array index 2 is past the end of the array (that has type 'unsigned long[2]') [-Warray-bounds]
98 | return (set->sig[3] | set->sig[2] |
| ^ ~
arch/x86/include/asm/signal.h:24:2: note: array 'sig' declared here
24 | unsigned long sig[_NSIG_WORDS];
| ^
In file included from arch/x86/kernel/asm-offsets.c:14:
In file included from include/linux/suspend.h:5:
In file included from include/linux/swap.h:9:
In file included from include/linux/memcontrol.h:13:
In file included from include/linux/cgroup.h:17:
In file included from include/linux/fs.h:5:
In file included from include/linux/fs/super.h:5:
In file included from include/linux/fs/super_types.h:13:
In file included from include/linux/percpu-rwsem.h:7:
In file included from include/linux/rcuwait.h:6:
In file included from include/linux/sched/signal.h:6:
include/linux/signal.h:114:11: warning: array index 3 is past the end of the array (that has type 'const unsigned long[2]') [-Warray-bounds]
114 | return (set1->sig[3] == set2->sig[3]) &&
| ^ ~
arch/x86/include/asm/signal.h:24:2: note: array 'sig' declared here
24 | unsigned long sig[_NSIG_WORDS];
| ^
In file included from arch/x86/kernel/asm-offsets.c:14:
In file included from include/linux/suspend.h:5:
In file included from include/linux/swap.h:9:
In file included from include/linux/memcontrol.h:13:
In file included from include/linux/cgroup.h:17:
In file included from include/linux/fs.h:5:
In file included from include/linux/fs/super.h:5:
In file included from include/linux/fs/super_types.h:13:
In file included from include/linux/percpu-rwsem.h:7:
In file included from include/linux/rcuwait.h:6:
In file included from include/linux/sched/signal.h:6:
include/linux/signal.h:114:27: warning: array index 3 is past the end of the array (that has type 'const unsigned long[2]') [-Warray-bounds]
114 | return (set1->sig[3] == set2->sig[3]) &&
| ^ ~
arch/x86/include/asm/signal.h:24:2: note: array 'sig' declared here
24 | unsigned long sig[_NSIG_WORDS];
| ^
In file included from arch/x86/kernel/asm-offsets.c:14:
In file included from include/linux/suspend.h:5:
In file included from include/linux/swap.h:9:
In file included from include/linux/memcontrol.h:13:
In file included from include/linux/cgroup.h:17:
In file included from include/linux/fs.h:5:
In file included from include/linux/fs/super.h:5:
In file included from include/linux/fs/super_types.h:13:
In file included from include/linux/percpu-rwsem.h:7:
In file included from include/linux/rcuwait.h:6:
In file included from include/linux/sched/signal.h:6:
include/linux/signal.h:115:5: warning: array index 2 is past the end of the array (that has type 'const unsigned long[2]') [-Warray-bounds]
115 | (set1->sig[2] == set2->sig[2]) &&
| ^ ~
arch/x86/include/asm/signal.h:24:2: note: array 'sig' declared here
24 | unsigned long sig[_NSIG_WORDS];
| ^
In file included from arch/x86/kernel/asm-offsets.c:14:
In file included from include/linux/suspend.h:5:
In file included from include/linux/swap.h:9:
In file included from include/linux/memcontrol.h:13:
In file included from include/linux/cgroup.h:17:
In file included from include/linux/fs.h:5:
In file included from include/linux/fs/super.h:5:
In file included from include/linux/fs/super_types.h:13:
In file included from include/linux/percpu-rwsem.h:7:
In file included from include/linux/rcuwait.h:6:
In file included from include/linux/sched/signal.h:6:
include/linux/signal.h:115:21: warning: array index 2 is past the end of the array (that has type 'const unsigned long[2]') [-Warray-bounds]
115 | (set1->sig[2] == set2->sig[2]) &&
vim +/PAGE_SIZE +60 include/linux/mem_encrypt.h
56
57 #ifndef mem_decrypt_granule_size
58 static inline size_t mem_decrypt_granule_size(void)
59 {
> 60 return PAGE_SIZE;
61 }
62 #endif
63
64 static inline size_t mem_decrypt_align(size_t size)
65 {
> 66 return ALIGN(size, mem_decrypt_granule_size());
67 }
68
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH net-next v3 2/2] dma-buf: heaps: system: add system_cc_decrypted heap for explicitly decrypted memory
From: Jason Gunthorpe @ 2026-03-09 15:50 UTC (permalink / raw)
To: Peter Gonda
Cc: Jiri Pirko, dri-devel, linaro-mm-sig, iommu, linux-media,
sumit.semwal, benjamin.gaignard, Brian.Starkey, jstultz,
tjmercier, christian.koenig, m.szyprowski, robin.murphy, leon,
sean.anderson, ptesarik, catalin.marinas, aneesh.kumar,
suzuki.poulose, steven.price, thomas.lendacky, john.allen,
ashish.kalra, suravee.suthikulpanit, linux-coco
In-Reply-To: <CAMkAt6o_yZ5T-3TRwymjYQZEq-Q_z=DAA3vc61h81X9sQr_CXA@mail.gmail.com>
On Mon, Mar 09, 2026 at 09:39:44AM -0600, Peter Gonda wrote:
> Great feature to have thanks Jiri! A couple naive questions.
>
> On Thu, Mar 5, 2026 at 5:38 AM Jiri Pirko <jiri@resnulli.us> wrote:
> >
> > From: Jiri Pirko <jiri@nvidia.com>
> >
> > Add a new "system_cc_decrypted" dma-buf heap to allow userspace to
> > allocate decrypted (shared) memory for confidential computing (CoCo)
> > VMs.
> >
> > On CoCo VMs, guest memory is encrypted by default. The hardware uses an
> > encryption bit in page table entries (C-bit on AMD SEV, "shared" bit on
> > Intel TDX) to control whether a given memory access is encrypted or
> > decrypted. The kernel's direct map is set up with encryption enabled,
> > so pages returned by alloc_pages() are encrypted in the direct map
> > by default. To make this memory usable for devices that do not support
> > DMA to encrypted memory (no TDISP support), it has to be explicitly
> > decrypted. A couple of things are needed to properly handle
> > decrypted memory for the dma-buf use case:
> >
> > - set_memory_decrypted() on the direct map after allocation:
> > Besides clearing the encryption bit in the direct map PTEs, this
> > also notifies the hypervisor about the page state change. On free,
> > the inverse set_memory_encrypted() must be called before returning
> > pages to the allocator. If re-encryption fails, pages
> > are intentionally leaked to prevent decrypted memory from being
> > reused as private.
> >
> > - pgprot_decrypted() for userspace and kernel virtual mappings:
> > Any new mapping of the decrypted pages, be it to userspace via
> > mmap or to kernel vmalloc space via vmap, creates PTEs independent
> > of the direct map. These must also have the encryption bit cleared,
> > otherwise accesses through them would see encrypted (garbage) data.
>
> So this only works on new mappings? What if there are existing
> mappings to the memory that will be converted to shared?
The set_memory_decrypted() is called during system_heap_allocate(), it
is not possible to change dynamically between encrypted/decrypted.
Once the heap is created every PTE is always created with the correct
pgprot.
Jason
^ permalink raw reply
* Re: [PATCH v3 2/3] swiotlb: dma: its: Enforce host page-size alignment for shared buffers
From: kernel test robot @ 2026-03-09 15:44 UTC (permalink / raw)
To: Aneesh Kumar K.V (Arm), linux-kernel, iommu, linux-coco,
linux-arm-kernel, kvmarm
Cc: oe-kbuild-all, Aneesh Kumar K.V (Arm), Marc Zyngier,
Thomas Gleixner, Catalin Marinas, Will Deacon, Jason Gunthorpe,
Marek Szyprowski, Robin Murphy, Steven Price, Suzuki K Poulose
In-Reply-To: <20260309102625.2315725-3-aneesh.kumar@kernel.org>
Hi Aneesh,
kernel test robot noticed the following build errors:
[auto build test ERROR on arm64/for-next/core]
[also build test ERROR on tip/irq/core arm/for-next arm/fixes kvmarm/next soc/for-next linus/master v7.0-rc3 next-20260306]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Aneesh-Kumar-K-V-Arm/dma-direct-swiotlb-handle-swiotlb-alloc-free-outside-__dma_direct_alloc_pages/20260309-182834
base: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
patch link: https://lore.kernel.org/r/20260309102625.2315725-3-aneesh.kumar%40kernel.org
patch subject: [PATCH v3 2/3] swiotlb: dma: its: Enforce host page-size alignment for shared buffers
config: i386-randconfig-013-20260309 (https://download.01.org/0day-ci/archive/20260309/202603092323.myqT3tXw-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260309/202603092323.myqT3tXw-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603092323.myqT3tXw-lkp@intel.com/
All errors (new ones prefixed by >>):
In file included from arch/x86/include/asm/processor-flags.h:6,
from arch/x86/include/asm/irqflags.h:5,
from include/linux/irqflags.h:18,
from include/linux/spinlock.h:59,
from include/linux/swait.h:7,
from include/linux/completion.h:12,
from include/linux/crypto.h:15,
from arch/x86/kernel/asm-offsets.c:9:
include/linux/mem_encrypt.h: In function 'mem_decrypt_granule_size':
>> include/linux/mem_encrypt.h:60:16: error: 'PAGE_SIZE' undeclared (first use in this function)
60 | return PAGE_SIZE;
| ^~~~~~~~~
include/linux/mem_encrypt.h:60:16: note: each undeclared identifier is reported only once for each function it appears in
include/linux/mem_encrypt.h: In function 'mem_decrypt_align':
>> include/linux/mem_encrypt.h:66:16: error: implicit declaration of function 'ALIGN' [-Wimplicit-function-declaration]
66 | return ALIGN(size, mem_decrypt_granule_size());
| ^~~~~
make[3]: *** [scripts/Makefile.build:184: arch/x86/kernel/asm-offsets.s] Error 1 shuffle=4157930943
make[3]: Target 'prepare' not remade because of errors.
make[2]: *** [Makefile:1333: prepare0] Error 2 shuffle=4157930943
make[2]: Target 'prepare' not remade because of errors.
make[1]: *** [Makefile:248: __sub-make] Error 2 shuffle=4157930943
make[1]: Target 'prepare' not remade because of errors.
make: *** [Makefile:248: __sub-make] Error 2 shuffle=4157930943
make: Target 'prepare' not remade because of errors.
vim +/PAGE_SIZE +60 include/linux/mem_encrypt.h
56
57 #ifndef mem_decrypt_granule_size
58 static inline size_t mem_decrypt_granule_size(void)
59 {
> 60 return PAGE_SIZE;
61 }
62 #endif
63
64 static inline size_t mem_decrypt_align(size_t size)
65 {
> 66 return ALIGN(size, mem_decrypt_granule_size());
67 }
68
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH net-next v3 2/2] dma-buf: heaps: system: add system_cc_decrypted heap for explicitly decrypted memory
From: Peter Gonda @ 2026-03-09 15:39 UTC (permalink / raw)
To: Jiri Pirko
Cc: dri-devel, linaro-mm-sig, iommu, linux-media, sumit.semwal,
benjamin.gaignard, Brian.Starkey, jstultz, tjmercier,
christian.koenig, m.szyprowski, robin.murphy, jgg, leon,
sean.anderson, ptesarik, catalin.marinas, aneesh.kumar,
suzuki.poulose, steven.price, thomas.lendacky, john.allen,
ashish.kalra, suravee.suthikulpanit, linux-coco
In-Reply-To: <20260305123641.164164-3-jiri@resnulli.us>
Great feature to have thanks Jiri! A couple naive questions.
On Thu, Mar 5, 2026 at 5:38 AM Jiri Pirko <jiri@resnulli.us> wrote:
>
> From: Jiri Pirko <jiri@nvidia.com>
>
> Add a new "system_cc_decrypted" dma-buf heap to allow userspace to
> allocate decrypted (shared) memory for confidential computing (CoCo)
> VMs.
>
> On CoCo VMs, guest memory is encrypted by default. The hardware uses an
> encryption bit in page table entries (C-bit on AMD SEV, "shared" bit on
> Intel TDX) to control whether a given memory access is encrypted or
> decrypted. The kernel's direct map is set up with encryption enabled,
> so pages returned by alloc_pages() are encrypted in the direct map
> by default. To make this memory usable for devices that do not support
> DMA to encrypted memory (no TDISP support), it has to be explicitly
> decrypted. A couple of things are needed to properly handle
> decrypted memory for the dma-buf use case:
>
> - set_memory_decrypted() on the direct map after allocation:
> Besides clearing the encryption bit in the direct map PTEs, this
> also notifies the hypervisor about the page state change. On free,
> the inverse set_memory_encrypted() must be called before returning
> pages to the allocator. If re-encryption fails, pages
> are intentionally leaked to prevent decrypted memory from being
> reused as private.
>
> - pgprot_decrypted() for userspace and kernel virtual mappings:
> Any new mapping of the decrypted pages, be it to userspace via
> mmap or to kernel vmalloc space via vmap, creates PTEs independent
> of the direct map. These must also have the encryption bit cleared,
> otherwise accesses through them would see encrypted (garbage) data.
So this only works on new mappings? What if there are existing
mappings to the memory that will be converted to shared?
It's also slightly worse than just reading ciphertext. If another
process writes to the memory with the incorrect mapping it could cause
corruption on AMD SEV, or an RMP violation on AMD SEV-SNP. Can we
update the existing mappings?
^ permalink raw reply
* Re: [PATCH net-next v3 1/2] dma-mapping: introduce DMA_ATTR_CC_DECRYPTED for pre-decrypted memory
From: Jason Gunthorpe @ 2026-03-09 15:18 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Jiri Pirko, dri-devel, linaro-mm-sig, iommu, linux-media,
sumit.semwal, benjamin.gaignard, Brian.Starkey, jstultz,
tjmercier, christian.koenig, m.szyprowski, robin.murphy,
sean.anderson, ptesarik, catalin.marinas, aneesh.kumar,
suzuki.poulose, steven.price, thomas.lendacky, john.allen,
ashish.kalra, suravee.suthikulpanit, linux-coco
In-Reply-To: <20260309140233.GW12611@unreal>
On Mon, Mar 09, 2026 at 04:02:33PM +0200, Leon Romanovsky wrote:
> On Mon, Mar 09, 2026 at 10:15:30AM -0300, Jason Gunthorpe wrote:
> > On Sun, Mar 08, 2026 at 12:19:48PM +0200, Leon Romanovsky wrote:
> >
> > > > +/*
> > > > + * DMA_ATTR_CC_DECRYPTED: Indicates memory that has been explicitly decrypted
> > > > + * (shared) for confidential computing guests. The caller must have
> > > > + * called set_memory_decrypted(). A struct page is required.
> > > > + */
> > > > +#define DMA_ATTR_CC_DECRYPTED (1UL << 12)
> > >
> > > While adding the new attribute is fine, I would expect additional checks in
> > > dma_map_phys() to ensure the attribute cannot be misused. For example,
> > > WARN_ON(attrs & (DMA_ATTR_CC_DECRYPTED | DMA_ATTR_MMIO)), along with a check
> > > that we are taking the direct path only.
> >
> > DECRYPYED and MMIO is something that needs to work, VFIO (inside a
> > TVM) should be using that combination.
>
> So this sentence "A struct page is required" from the comment above is
> not accurate.
It would be clearer to say "Unless DMA_ATTR_MMIO is provided a struct
page is required"
We need to audit if that works properly, IIRC it does, but I don't
remember.. Jiri?
Jason
^ permalink raw reply
* Re: [PATCH v3 2/3] swiotlb: dma: its: Enforce host page-size alignment for shared buffers
From: kernel test robot @ 2026-03-09 14:55 UTC (permalink / raw)
To: Aneesh Kumar K.V (Arm), linux-kernel, iommu, linux-coco,
linux-arm-kernel, kvmarm
Cc: oe-kbuild-all, Aneesh Kumar K.V (Arm), Marc Zyngier,
Thomas Gleixner, Catalin Marinas, Will Deacon, Jason Gunthorpe,
Marek Szyprowski, Robin Murphy, Steven Price, Suzuki K Poulose
In-Reply-To: <20260309102625.2315725-3-aneesh.kumar@kernel.org>
Hi Aneesh,
kernel test robot noticed the following build errors:
[auto build test ERROR on arm64/for-next/core]
[also build test ERROR on tip/irq/core arm/for-next arm/fixes kvmarm/next soc/for-next linus/master v7.0-rc3 next-20260306]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Aneesh-Kumar-K-V-Arm/dma-direct-swiotlb-handle-swiotlb-alloc-free-outside-__dma_direct_alloc_pages/20260309-182834
base: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
patch link: https://lore.kernel.org/r/20260309102625.2315725-3-aneesh.kumar%40kernel.org
patch subject: [PATCH v3 2/3] swiotlb: dma: its: Enforce host page-size alignment for shared buffers
config: x86_64-rhel-9.4 (https://download.01.org/0day-ci/archive/20260309/202603091555.ZRQIMCqJ-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260309/202603091555.ZRQIMCqJ-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603091555.ZRQIMCqJ-lkp@intel.com/
All errors (new ones prefixed by >>):
In file included from arch/x86/include/asm/processor-flags.h:6,
from arch/x86/include/asm/irqflags.h:5,
from include/linux/irqflags.h:18,
from include/linux/spinlock.h:59,
from include/linux/swait.h:7,
from include/linux/completion.h:12,
from include/linux/crypto.h:15,
from arch/x86/kernel/asm-offsets.c:9:
include/linux/mem_encrypt.h: In function 'mem_decrypt_granule_size':
>> include/linux/mem_encrypt.h:60:16: error: 'PAGE_SIZE' undeclared (first use in this function)
60 | return PAGE_SIZE;
| ^~~~~~~~~
include/linux/mem_encrypt.h:60:16: note: each undeclared identifier is reported only once for each function it appears in
include/linux/mem_encrypt.h: In function 'mem_decrypt_align':
>> include/linux/mem_encrypt.h:66:16: error: implicit declaration of function 'ALIGN' [-Wimplicit-function-declaration]
66 | return ALIGN(size, mem_decrypt_granule_size());
| ^~~~~
make[3]: *** [scripts/Makefile.build:184: arch/x86/kernel/asm-offsets.s] Error 1
make[3]: Target 'prepare' not remade because of errors.
make[2]: *** [Makefile:1333: prepare0] Error 2
make[2]: Target 'prepare' not remade because of errors.
make[1]: *** [Makefile:248: __sub-make] Error 2
make[1]: Target 'prepare' not remade because of errors.
make: *** [Makefile:248: __sub-make] Error 2
make: Target 'prepare' not remade because of errors.
vim +/PAGE_SIZE +60 include/linux/mem_encrypt.h
56
57 #ifndef mem_decrypt_granule_size
58 static inline size_t mem_decrypt_granule_size(void)
59 {
> 60 return PAGE_SIZE;
61 }
62 #endif
63
64 static inline size_t mem_decrypt_align(size_t size)
65 {
> 66 return ALIGN(size, mem_decrypt_granule_size());
67 }
68
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH net-next v3 1/2] dma-mapping: introduce DMA_ATTR_CC_DECRYPTED for pre-decrypted memory
From: Leon Romanovsky @ 2026-03-09 14:02 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Jiri Pirko, dri-devel, linaro-mm-sig, iommu, linux-media,
sumit.semwal, benjamin.gaignard, Brian.Starkey, jstultz,
tjmercier, christian.koenig, m.szyprowski, robin.murphy,
sean.anderson, ptesarik, catalin.marinas, aneesh.kumar,
suzuki.poulose, steven.price, thomas.lendacky, john.allen,
ashish.kalra, suravee.suthikulpanit, linux-coco
In-Reply-To: <20260309131530.GJ1687929@ziepe.ca>
On Mon, Mar 09, 2026 at 10:15:30AM -0300, Jason Gunthorpe wrote:
> On Sun, Mar 08, 2026 at 12:19:48PM +0200, Leon Romanovsky wrote:
>
> > > +/*
> > > + * DMA_ATTR_CC_DECRYPTED: Indicates memory that has been explicitly decrypted
> > > + * (shared) for confidential computing guests. The caller must have
> > > + * called set_memory_decrypted(). A struct page is required.
> > > + */
> > > +#define DMA_ATTR_CC_DECRYPTED (1UL << 12)
> >
> > While adding the new attribute is fine, I would expect additional checks in
> > dma_map_phys() to ensure the attribute cannot be misused. For example,
> > WARN_ON(attrs & (DMA_ATTR_CC_DECRYPTED | DMA_ATTR_MMIO)), along with a check
> > that we are taking the direct path only.
>
> DECRYPYED and MMIO is something that needs to work, VFIO (inside a
> TVM) should be using that combination.
So this sentence "A struct page is required" from the comment above is
not accurate.
Thanks
>
> Jason
^ permalink raw reply
* Re: [PATCH v3 2/3] swiotlb: dma: its: Enforce host page-size alignment for shared buffers
From: kernel test robot @ 2026-03-09 13:54 UTC (permalink / raw)
To: Aneesh Kumar K.V (Arm), linux-kernel, iommu, linux-coco,
linux-arm-kernel, kvmarm
Cc: oe-kbuild-all, Aneesh Kumar K.V (Arm), Marc Zyngier,
Thomas Gleixner, Catalin Marinas, Will Deacon, Jason Gunthorpe,
Marek Szyprowski, Robin Murphy, Steven Price, Suzuki K Poulose
In-Reply-To: <20260309102625.2315725-3-aneesh.kumar@kernel.org>
Hi Aneesh,
kernel test robot noticed the following build errors:
[auto build test ERROR on arm64/for-next/core]
[also build test ERROR on tip/irq/core arm/for-next arm/fixes kvmarm/next soc/for-next linus/master v7.0-rc3 next-20260306]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Aneesh-Kumar-K-V-Arm/dma-direct-swiotlb-handle-swiotlb-alloc-free-outside-__dma_direct_alloc_pages/20260309-182834
base: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
patch link: https://lore.kernel.org/r/20260309102625.2315725-3-aneesh.kumar%40kernel.org
patch subject: [PATCH v3 2/3] swiotlb: dma: its: Enforce host page-size alignment for shared buffers
config: x86_64-rhel-9.4-rust (https://download.01.org/0day-ci/archive/20260309/202603091444.4H1PFs01-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
rustc: rustc 1.88.0 (6b00bc388 2025-06-23)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260309/202603091444.4H1PFs01-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603091444.4H1PFs01-lkp@intel.com/
All errors (new ones prefixed by >>):
In file included from arch/x86/kernel/asm-offsets.c:9:
In file included from include/linux/crypto.h:15:
In file included from include/linux/completion.h:12:
In file included from include/linux/swait.h:7:
In file included from include/linux/spinlock.h:59:
In file included from include/linux/irqflags.h:18:
In file included from arch/x86/include/asm/irqflags.h:5:
In file included from arch/x86/include/asm/processor-flags.h:6:
>> include/linux/mem_encrypt.h:60:9: error: use of undeclared identifier 'PAGE_SIZE'
60 | return PAGE_SIZE;
| ^
>> include/linux/mem_encrypt.h:66:9: error: call to undeclared function 'ALIGN'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
66 | return ALIGN(size, mem_decrypt_granule_size());
| ^
In file included from arch/x86/kernel/asm-offsets.c:14:
In file included from include/linux/suspend.h:5:
In file included from include/linux/swap.h:9:
In file included from include/linux/memcontrol.h:13:
In file included from include/linux/cgroup.h:17:
In file included from include/linux/fs.h:5:
In file included from include/linux/fs/super.h:5:
In file included from include/linux/fs/super_types.h:13:
In file included from include/linux/percpu-rwsem.h:7:
In file included from include/linux/rcuwait.h:6:
In file included from include/linux/sched/signal.h:6:
include/linux/signal.h:98:11: warning: array index 3 is past the end of the array (that has type 'unsigned long[1]') [-Warray-bounds]
98 | return (set->sig[3] | set->sig[2] |
| ^ ~
arch/x86/include/asm/signal.h:24:2: note: array 'sig' declared here
24 | unsigned long sig[_NSIG_WORDS];
| ^
In file included from arch/x86/kernel/asm-offsets.c:14:
In file included from include/linux/suspend.h:5:
In file included from include/linux/swap.h:9:
In file included from include/linux/memcontrol.h:13:
In file included from include/linux/cgroup.h:17:
In file included from include/linux/fs.h:5:
In file included from include/linux/fs/super.h:5:
In file included from include/linux/fs/super_types.h:13:
In file included from include/linux/percpu-rwsem.h:7:
In file included from include/linux/rcuwait.h:6:
In file included from include/linux/sched/signal.h:6:
include/linux/signal.h:98:25: warning: array index 2 is past the end of the array (that has type 'unsigned long[1]') [-Warray-bounds]
98 | return (set->sig[3] | set->sig[2] |
| ^ ~
arch/x86/include/asm/signal.h:24:2: note: array 'sig' declared here
24 | unsigned long sig[_NSIG_WORDS];
| ^
In file included from arch/x86/kernel/asm-offsets.c:14:
In file included from include/linux/suspend.h:5:
In file included from include/linux/swap.h:9:
In file included from include/linux/memcontrol.h:13:
In file included from include/linux/cgroup.h:17:
In file included from include/linux/fs.h:5:
In file included from include/linux/fs/super.h:5:
In file included from include/linux/fs/super_types.h:13:
In file included from include/linux/percpu-rwsem.h:7:
In file included from include/linux/rcuwait.h:6:
In file included from include/linux/sched/signal.h:6:
include/linux/signal.h:99:4: warning: array index 1 is past the end of the array (that has type 'unsigned long[1]') [-Warray-bounds]
99 | set->sig[1] | set->sig[0]) == 0;
| ^ ~
arch/x86/include/asm/signal.h:24:2: note: array 'sig' declared here
24 | unsigned long sig[_NSIG_WORDS];
| ^
In file included from arch/x86/kernel/asm-offsets.c:14:
In file included from include/linux/suspend.h:5:
In file included from include/linux/swap.h:9:
In file included from include/linux/memcontrol.h:13:
In file included from include/linux/cgroup.h:17:
In file included from include/linux/fs.h:5:
In file included from include/linux/fs/super.h:5:
In file included from include/linux/fs/super_types.h:13:
In file included from include/linux/percpu-rwsem.h:7:
In file included from include/linux/rcuwait.h:6:
In file included from include/linux/sched/signal.h:6:
include/linux/signal.h:101:11: warning: array index 1 is past the end of the array (that has type 'unsigned long[1]') [-Warray-bounds]
101 | return (set->sig[1] | set->sig[0]) == 0;
| ^ ~
arch/x86/include/asm/signal.h:24:2: note: array 'sig' declared here
24 | unsigned long sig[_NSIG_WORDS];
| ^
In file included from arch/x86/kernel/asm-offsets.c:14:
In file included from include/linux/suspend.h:5:
In file included from include/linux/swap.h:9:
In file included from include/linux/memcontrol.h:13:
In file included from include/linux/cgroup.h:17:
In file included from include/linux/fs.h:5:
In file included from include/linux/fs/super.h:5:
In file included from include/linux/fs/super_types.h:13:
In file included from include/linux/percpu-rwsem.h:7:
In file included from include/linux/rcuwait.h:6:
In file included from include/linux/sched/signal.h:6:
include/linux/signal.h:114:11: warning: array index 3 is past the end of the array (that has type 'const unsigned long[1]') [-Warray-bounds]
114 | return (set1->sig[3] == set2->sig[3]) &&
| ^ ~
arch/x86/include/asm/signal.h:24:2: note: array 'sig' declared here
24 | unsigned long sig[_NSIG_WORDS];
| ^
In file included from arch/x86/kernel/asm-offsets.c:14:
In file included from include/linux/suspend.h:5:
In file included from include/linux/swap.h:9:
In file included from include/linux/memcontrol.h:13:
In file included from include/linux/cgroup.h:17:
In file included from include/linux/fs.h:5:
In file included from include/linux/fs/super.h:5:
In file included from include/linux/fs/super_types.h:13:
In file included from include/linux/percpu-rwsem.h:7:
In file included from include/linux/rcuwait.h:6:
In file included from include/linux/sched/signal.h:6:
include/linux/signal.h:114:27: warning: array index 3 is past the end of the array (that has type 'const unsigned long[1]') [-Warray-bounds]
114 | return (set1->sig[3] == set2->sig[3]) &&
vim +/PAGE_SIZE +60 include/linux/mem_encrypt.h
56
57 #ifndef mem_decrypt_granule_size
58 static inline size_t mem_decrypt_granule_size(void)
59 {
> 60 return PAGE_SIZE;
61 }
62 #endif
63
64 static inline size_t mem_decrypt_align(size_t size)
65 {
> 66 return ALIGN(size, mem_decrypt_granule_size());
67 }
68
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH net-next v3 1/2] dma-mapping: introduce DMA_ATTR_CC_DECRYPTED for pre-decrypted memory
From: Jason Gunthorpe @ 2026-03-09 13:17 UTC (permalink / raw)
To: Petr Tesarik
Cc: Jiri Pirko, dri-devel, linaro-mm-sig, iommu, linux-media,
sumit.semwal, benjamin.gaignard, Brian.Starkey, jstultz,
tjmercier, christian.koenig, m.szyprowski, robin.murphy, leon,
sean.anderson, catalin.marinas, aneesh.kumar, suzuki.poulose,
steven.price, thomas.lendacky, john.allen, ashish.kalra,
suravee.suthikulpanit, linux-coco
In-Reply-To: <20260309135610.1f81d2df@mordecai>
On Mon, Mar 09, 2026 at 01:56:10PM +0100, Petr Tesarik wrote:
> I don't want to start a bikeshedding discussion, so if everyone else
> likes this name, let's keep it. But maybe the "_CC" (meaning
> Confidential Comptuing) is not necessary. IIUC it's the same concept as
> set_page_encrypted(), set_page_decrypted(), which does not refer to
> CoCo either.
Frankly I hate that AMD got their "encrypted" "decrypted" naming baked
into the CC related APIs.
I'm not at all convinced that they "do not refer to CoCo" in the way
Linux uses them and other arches absolutely make them 100% tied to coco.
If we are going to bikeshed the name it should be DMA_ATTR_CC_SHARED
Jason
^ permalink raw reply
* Re: [PATCH net-next v3 1/2] dma-mapping: introduce DMA_ATTR_CC_DECRYPTED for pre-decrypted memory
From: Jason Gunthorpe @ 2026-03-09 13:15 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Jiri Pirko, dri-devel, linaro-mm-sig, iommu, linux-media,
sumit.semwal, benjamin.gaignard, Brian.Starkey, jstultz,
tjmercier, christian.koenig, m.szyprowski, robin.murphy,
sean.anderson, ptesarik, catalin.marinas, aneesh.kumar,
suzuki.poulose, steven.price, thomas.lendacky, john.allen,
ashish.kalra, suravee.suthikulpanit, linux-coco
In-Reply-To: <20260308101948.GO12611@unreal>
On Sun, Mar 08, 2026 at 12:19:48PM +0200, Leon Romanovsky wrote:
> > +/*
> > + * DMA_ATTR_CC_DECRYPTED: Indicates memory that has been explicitly decrypted
> > + * (shared) for confidential computing guests. The caller must have
> > + * called set_memory_decrypted(). A struct page is required.
> > + */
> > +#define DMA_ATTR_CC_DECRYPTED (1UL << 12)
>
> While adding the new attribute is fine, I would expect additional checks in
> dma_map_phys() to ensure the attribute cannot be misused. For example,
> WARN_ON(attrs & (DMA_ATTR_CC_DECRYPTED | DMA_ATTR_MMIO)), along with a check
> that we are taking the direct path only.
DECRYPYED and MMIO is something that needs to work, VFIO (inside a
TVM) should be using that combination.
Jason
^ permalink raw reply
* Re: [PATCH net-next v3 1/2] dma-mapping: introduce DMA_ATTR_CC_DECRYPTED for pre-decrypted memory
From: Jiri Pirko @ 2026-03-09 13:01 UTC (permalink / raw)
To: Petr Tesarik
Cc: dri-devel, linaro-mm-sig, iommu, linux-media, sumit.semwal,
benjamin.gaignard, Brian.Starkey, jstultz, tjmercier,
christian.koenig, m.szyprowski, robin.murphy, jgg, leon,
sean.anderson, catalin.marinas, aneesh.kumar, suzuki.poulose,
steven.price, thomas.lendacky, john.allen, ashish.kalra,
suravee.suthikulpanit, linux-coco
In-Reply-To: <20260309135610.1f81d2df@mordecai>
Mon, Mar 09, 2026 at 01:56:10PM +0100, ptesarik@suse.com wrote:
>On Thu, 5 Mar 2026 13:36:40 +0100
>Jiri Pirko <jiri@resnulli.us> wrote:
>
>> From: Jiri Pirko <jiri@nvidia.com>
>>
>> Current CC designs don't place a vIOMMU in front of untrusted devices.
>> Instead, the DMA API forces all untrusted device DMA through swiotlb
>> bounce buffers (is_swiotlb_force_bounce()) which copies data into
>> decrypted memory on behalf of the device.
>>
>> When a caller has already arranged for the memory to be decrypted
>> via set_memory_decrypted(), the DMA API needs to know so it can map
>> directly using the unencrypted physical address rather than bounce
>> buffering. Following the pattern of DMA_ATTR_MMIO, add
>> DMA_ATTR_CC_DECRYPTED for this purpose. Like the MMIO case, only the
>> caller knows what kind of memory it has and must inform the DMA API
>> for it to work correctly.
>>
>> Signed-off-by: Jiri Pirko <jiri@nvidia.com>
>> ---
>> v1->v2:
>> - rebased on top of recent dma-mapping-fixes
>> ---
>> include/linux/dma-mapping.h | 6 ++++++
>> include/trace/events/dma.h | 3 ++-
>> kernel/dma/direct.h | 14 +++++++++++---
>> 3 files changed, 19 insertions(+), 4 deletions(-)
>>
>> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
>> index 29973baa0581..ae3d85e494ec 100644
>> --- a/include/linux/dma-mapping.h
>> +++ b/include/linux/dma-mapping.h
>> @@ -85,6 +85,12 @@
>> * a cacheline must have this attribute for this to be considered safe.
>> */
>> #define DMA_ATTR_CPU_CACHE_CLEAN (1UL << 11)
>> +/*
>> + * DMA_ATTR_CC_DECRYPTED: Indicates memory that has been explicitly decrypted
>> + * (shared) for confidential computing guests. The caller must have
>> + * called set_memory_decrypted(). A struct page is required.
>> + */
>> +#define DMA_ATTR_CC_DECRYPTED (1UL << 12)
>
>I don't want to start a bikeshedding discussion, so if everyone else
>likes this name, let's keep it. But maybe the "_CC" (meaning
>Confidential Comptuing) is not necessary. IIUC it's the same concept as
>set_page_encrypted(), set_page_decrypted(), which does not refer to
>CoCo either.
Do I understand that correctly that you suggest DMA_ATTR_DECRYPTED ?
It's not uapi, so this is flexible for possible future renames.
^ permalink raw reply
* Re: [PATCH net-next v3 1/2] dma-mapping: introduce DMA_ATTR_CC_DECRYPTED for pre-decrypted memory
From: Petr Tesarik @ 2026-03-09 12:56 UTC (permalink / raw)
To: Jiri Pirko
Cc: dri-devel, linaro-mm-sig, iommu, linux-media, sumit.semwal,
benjamin.gaignard, Brian.Starkey, jstultz, tjmercier,
christian.koenig, m.szyprowski, robin.murphy, jgg, leon,
sean.anderson, catalin.marinas, aneesh.kumar, suzuki.poulose,
steven.price, thomas.lendacky, john.allen, ashish.kalra,
suravee.suthikulpanit, linux-coco
In-Reply-To: <20260305123641.164164-2-jiri@resnulli.us>
On Thu, 5 Mar 2026 13:36:40 +0100
Jiri Pirko <jiri@resnulli.us> wrote:
> From: Jiri Pirko <jiri@nvidia.com>
>
> Current CC designs don't place a vIOMMU in front of untrusted devices.
> Instead, the DMA API forces all untrusted device DMA through swiotlb
> bounce buffers (is_swiotlb_force_bounce()) which copies data into
> decrypted memory on behalf of the device.
>
> When a caller has already arranged for the memory to be decrypted
> via set_memory_decrypted(), the DMA API needs to know so it can map
> directly using the unencrypted physical address rather than bounce
> buffering. Following the pattern of DMA_ATTR_MMIO, add
> DMA_ATTR_CC_DECRYPTED for this purpose. Like the MMIO case, only the
> caller knows what kind of memory it has and must inform the DMA API
> for it to work correctly.
>
> Signed-off-by: Jiri Pirko <jiri@nvidia.com>
> ---
> v1->v2:
> - rebased on top of recent dma-mapping-fixes
> ---
> include/linux/dma-mapping.h | 6 ++++++
> include/trace/events/dma.h | 3 ++-
> kernel/dma/direct.h | 14 +++++++++++---
> 3 files changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> index 29973baa0581..ae3d85e494ec 100644
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -85,6 +85,12 @@
> * a cacheline must have this attribute for this to be considered safe.
> */
> #define DMA_ATTR_CPU_CACHE_CLEAN (1UL << 11)
> +/*
> + * DMA_ATTR_CC_DECRYPTED: Indicates memory that has been explicitly decrypted
> + * (shared) for confidential computing guests. The caller must have
> + * called set_memory_decrypted(). A struct page is required.
> + */
> +#define DMA_ATTR_CC_DECRYPTED (1UL << 12)
I don't want to start a bikeshedding discussion, so if everyone else
likes this name, let's keep it. But maybe the "_CC" (meaning
Confidential Comptuing) is not necessary. IIUC it's the same concept as
set_page_encrypted(), set_page_decrypted(), which does not refer to
CoCo either.
Just my two cents
Petr T
^ permalink raw reply
* Re: [PATCH v3 3/3] coco: guest: arm64: Add Realm Host Interface and hostconf RHI
From: Suzuki K Poulose @ 2026-03-09 10:50 UTC (permalink / raw)
To: Aneesh Kumar K.V (Arm), linux-kernel, iommu, linux-coco,
linux-arm-kernel, kvmarm
Cc: Marc Zyngier, Thomas Gleixner, Catalin Marinas, Will Deacon,
Jason Gunthorpe, Marek Szyprowski, Robin Murphy, Steven Price
In-Reply-To: <20260309102625.2315725-4-aneesh.kumar@kernel.org>
Hi Aneesh
On 09/03/2026 10:26, Aneesh Kumar K.V (Arm) wrote:
> - describe the Realm Host Interface SMC IDs and result codes in a new
> asm/rhi.h header
> - expose struct rsi_host_call plus an rsi_host_call() helper so we can
> invoke SMC_RSI_HOST_CALL from C code
> - add RHI hostconf SMC IDs and helper to query version, features, and IPA
> change alignment
> - derive the realm hypervisor page size during init and abort realm setup
> on invalid alignment
>
> This provides the host page-size discovery needed by previous patch that
> align shared buffer allocation/decryption to host requirements.
>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Thomas Gleixner <tglx@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Jason Gunthorpe <jgg@ziepe.ca>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Steven Price <steven.price@arm.com>
> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
> ---
> arch/arm64/include/asm/mem_encrypt.h | 3 ++
> arch/arm64/include/asm/rhi.h | 24 +++++++++++++
> arch/arm64/include/asm/rsi.h | 2 ++
> arch/arm64/include/asm/rsi_cmds.h | 10 ++++++
> arch/arm64/include/asm/rsi_smc.h | 7 ++++
> arch/arm64/kernel/Makefile | 2 +-
> arch/arm64/kernel/rhi.c | 53 ++++++++++++++++++++++++++++
> arch/arm64/kernel/rsi.c | 13 +++++++
> arch/arm64/mm/mem_encrypt.c | 8 +++++
> 9 files changed, 121 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm64/include/asm/rhi.h
> create mode 100644 arch/arm64/kernel/rhi.c
>
> diff --git a/arch/arm64/include/asm/mem_encrypt.h b/arch/arm64/include/asm/mem_encrypt.h
> index 314b2b52025f..5541911eb028 100644
> --- a/arch/arm64/include/asm/mem_encrypt.h
> +++ b/arch/arm64/include/asm/mem_encrypt.h
> @@ -16,6 +16,9 @@ int arm64_mem_crypt_ops_register(const struct arm64_mem_crypt_ops *ops);
> int set_memory_encrypted(unsigned long addr, int numpages);
> int set_memory_decrypted(unsigned long addr, int numpages);
>
> +#define mem_decrypt_granule_size mem_decrypt_granule_size
> +size_t mem_decrypt_granule_size(void);
> +
> int realm_register_memory_enc_ops(void);
>
> static inline bool force_dma_unencrypted(struct device *dev)
> diff --git a/arch/arm64/include/asm/rhi.h b/arch/arm64/include/asm/rhi.h
> new file mode 100644
> index 000000000000..0895dd92ea1d
> --- /dev/null
> +++ b/arch/arm64/include/asm/rhi.h
> @@ -0,0 +1,24 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (C) 2026 ARM Ltd.
> + */
> +
> +#ifndef __ASM_RHI_H_
> +#define __ASM_RHI_H_
> +
> +#include <linux/types.h>
> +
> +#define SMC_RHI_CALL(func) \
> + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
> + ARM_SMCCC_SMC_64, \
> + ARM_SMCCC_OWNER_STANDARD_HYP,\
> + (func))
> +
> +unsigned long rhi_get_ipa_change_alignment(void);
> +#define RHI_HOSTCONF_VER_1_0 0x10000
> +#define RHI_HOSTCONF_VERSION SMC_RHI_CALL(0x004E)
> +
> +#define __RHI_HOSTCONF_GET_IPA_CHANGE_ALIGNMENT BIT(0)
> +#define RHI_HOSTCONF_FEATURES SMC_RHI_CALL(0x004F)
> +#define RHI_HOSTCONF_GET_IPA_CHANGE_ALIGNMENT SMC_RHI_CALL(0x0050)
> +#endif
> diff --git a/arch/arm64/include/asm/rsi.h b/arch/arm64/include/asm/rsi.h
> index 88b50d660e85..ae54fb3b1429 100644
> --- a/arch/arm64/include/asm/rsi.h
> +++ b/arch/arm64/include/asm/rsi.h
> @@ -67,4 +67,6 @@ static inline int rsi_set_memory_range_shared(phys_addr_t start,
> return rsi_set_memory_range(start, end, RSI_RIPAS_EMPTY,
> RSI_CHANGE_DESTROYED);
> }
> +
> +unsigned long realm_get_hyp_pagesize(void);
> #endif /* __ASM_RSI_H_ */
> diff --git a/arch/arm64/include/asm/rsi_cmds.h b/arch/arm64/include/asm/rsi_cmds.h
> index 2c8763876dfb..a341ce0eeda1 100644
> --- a/arch/arm64/include/asm/rsi_cmds.h
> +++ b/arch/arm64/include/asm/rsi_cmds.h
> @@ -159,4 +159,14 @@ static inline unsigned long rsi_attestation_token_continue(phys_addr_t granule,
> return res.a0;
> }
>
> +static inline unsigned long rsi_host_call(struct rsi_host_call *rhi_call)
> +{
> + phys_addr_t addr = virt_to_phys(rhi_call);
> + struct arm_smccc_res res;
> +
> + arm_smccc_1_1_invoke(SMC_RSI_HOST_CALL, addr, &res);
> +
> + return res.a0;
> +}
> +
> #endif /* __ASM_RSI_CMDS_H */
> diff --git a/arch/arm64/include/asm/rsi_smc.h b/arch/arm64/include/asm/rsi_smc.h
> index e19253f96c94..9ee8b5c7612e 100644
> --- a/arch/arm64/include/asm/rsi_smc.h
> +++ b/arch/arm64/include/asm/rsi_smc.h
> @@ -182,6 +182,13 @@ struct realm_config {
> */
> #define SMC_RSI_IPA_STATE_GET SMC_RSI_FID(0x198)
>
> +struct rsi_host_call {
> + union {
> + u16 imm;
> + u64 padding0;
> + };
> + u64 gprs[31];
> +} __aligned(0x100);
> /*
> * Make a Host call.
> *
> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
> index 76f32e424065..fcb67f50ea89 100644
> --- a/arch/arm64/kernel/Makefile
> +++ b/arch/arm64/kernel/Makefile
> @@ -34,7 +34,7 @@ obj-y := debug-monitors.o entry.o irq.o fpsimd.o \
> cpufeature.o alternative.o cacheinfo.o \
> smp.o smp_spin_table.o topology.o smccc-call.o \
> syscall.o proton-pack.o idle.o patching.o pi/ \
> - rsi.o jump_label.o
> + rsi.o jump_label.o rhi.o
>
> obj-$(CONFIG_COMPAT) += sys32.o signal32.o \
> sys_compat.o
> diff --git a/arch/arm64/kernel/rhi.c b/arch/arm64/kernel/rhi.c
> new file mode 100644
> index 000000000000..d2141b5283e1
> --- /dev/null
> +++ b/arch/arm64/kernel/rhi.c
> @@ -0,0 +1,53 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2026 ARM Ltd.
> + */
> +
> +#include <asm/rsi.h>
> +#include <asm/rhi.h>
> +
> +/* we need an aligned rhicall for rsi_host_call. slab is not yet ready */
> +static struct rsi_host_call hyp_pagesize_rhicall;
> +unsigned long rhi_get_ipa_change_alignment(void)
> +{
> + long ret;
> + unsigned long ipa_change_align;
> +
> + hyp_pagesize_rhicall.imm = 0;
> + hyp_pagesize_rhicall.gprs[0] = RHI_HOSTCONF_VERSION;
> + ret = rsi_host_call(&hyp_pagesize_rhicall);
> + if (ret != RSI_SUCCESS)
> + goto err_out;
> +
> + if (hyp_pagesize_rhicall.gprs[0] != RHI_HOSTCONF_VER_1_0)
> + goto err_out;
> +
> + hyp_pagesize_rhicall.imm = 0;
> + hyp_pagesize_rhicall.gprs[0] = RHI_HOSTCONF_FEATURES;
> + ret = rsi_host_call(&hyp_pagesize_rhicall);
> + if (ret != RSI_SUCCESS)
> + goto err_out;
> +
> + if (!(hyp_pagesize_rhicall.gprs[0] & __RHI_HOSTCONF_GET_IPA_CHANGE_ALIGNMENT))
> + goto err_out;
> +
> + hyp_pagesize_rhicall.imm = 0;
> + hyp_pagesize_rhicall.gprs[0] = RHI_HOSTCONF_GET_IPA_CHANGE_ALIGNMENT;
> + ret = rsi_host_call(&hyp_pagesize_rhicall);
> + if (ret != RSI_SUCCESS)
> + goto err_out;
> +
> + ipa_change_align = hyp_pagesize_rhicall.gprs[0];
> + /* This error needs special handling in the caller */
> + if (ipa_change_align & (SZ_4K - 1))
> + return 0;
> +
> + return ipa_change_align;
> +
> +err_out:
> + /*
> + * For failure condition assume host is built with 4K page size
> + * and hence ipa change alignment can be guest PAGE_SIZE.
> + */
> + return PAGE_SIZE;
> +}
> diff --git a/arch/arm64/kernel/rsi.c b/arch/arm64/kernel/rsi.c
> index c64a06f58c0b..6e35cb947745 100644
> --- a/arch/arm64/kernel/rsi.c
> +++ b/arch/arm64/kernel/rsi.c
> @@ -13,8 +13,10 @@
> #include <asm/io.h>
> #include <asm/mem_encrypt.h>
> #include <asm/rsi.h>
> +#include <asm/rhi.h>
>
> static struct realm_config config;
> +static unsigned long ipa_change_alignment = PAGE_SIZE;
>
> unsigned long prot_ns_shared;
> EXPORT_SYMBOL(prot_ns_shared);
> @@ -138,6 +140,11 @@ static int realm_ioremap_hook(phys_addr_t phys, size_t size, pgprot_t *prot)
> return 0;
> }
>
> +unsigned long realm_get_hyp_pagesize(void)
> +{
> + return ipa_change_alignment;
> +}
> +
> void __init arm64_rsi_init(void)
> {
> if (arm_smccc_1_1_get_conduit() != SMCCC_CONDUIT_SMC)
> @@ -146,6 +153,12 @@ void __init arm64_rsi_init(void)
> return;
> if (WARN_ON(rsi_get_realm_config(&config)))
> return;
> +
> + ipa_change_alignment = rhi_get_ipa_change_alignment();
minor nit: We reset the alignment to 0 if this fails. see below.
> + /* If we don't get a correct alignment response, don't enable realm */
Do we need to enforce this ? If the Host doesn't implement this, we
could proceed and the guest might encounter failures in "sharing" in
the worst case. Otherwise, it could proceed. Eitherway, RMM guarantees
that the "state" of the PFNs are stable as reported by the RSI
calls and the Guest knows exactly what has happened.
Suzuki
> + if (!ipa_change_alignment)
> + return;
> +
> prot_ns_shared = BIT(config.ipa_bits - 1);
>
> if (arm64_ioremap_prot_hook_register(realm_ioremap_hook))
> diff --git a/arch/arm64/mm/mem_encrypt.c b/arch/arm64/mm/mem_encrypt.c
> index 38c62c9e4e74..f5d64bc29c20 100644
> --- a/arch/arm64/mm/mem_encrypt.c
> +++ b/arch/arm64/mm/mem_encrypt.c
> @@ -59,3 +59,11 @@ int set_memory_decrypted(unsigned long addr, int numpages)
> return crypt_ops->decrypt(addr, numpages);
> }
> EXPORT_SYMBOL_GPL(set_memory_decrypted);
> +
> +size_t mem_decrypt_granule_size(void)
> +{
> + if (is_realm_world())
> + return max(PAGE_SIZE, realm_get_hyp_pagesize());
> + return PAGE_SIZE;
> +}
> +EXPORT_SYMBOL_GPL(mem_decrypt_granule_size);
^ 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