* Re: [PATCH 8/8] MAINTAINERS: Add self as maintainer for PowerNV
From: Cédric Le Goater @ 2026-06-24 11:52 UTC (permalink / raw)
To: Aditya Gupta, qemu-devel, qemu-ppc, Harsh Prateek Bora,
Philippe Mathieu-Daudé, Shivang Upadhyay
Cc: Sourabh Jain, Hari Bathini, Nicholas Piggin, Miles Glenn,
Fabiano Rosas, Laurent Vivier, Paolo Bonzini, devel,
Misbah Anjum N, Anushree Mathur, Pierrick Bouvier, kvm,
Gautam Menghani, Chinmay Rath
In-Reply-To: <20260623141933.577981-9-adityag@linux.ibm.com>
Hello Nick,
Are you still active on the qemu-ppc subsystem ?
Thanks,
C.
On 6/23/26 16:19, Aditya Gupta wrote:
> Add myself as maintainer for PowerNV machine, and remove the
> reviewer entry
>
> Signed-off-by: Aditya Gupta <adityag@linux.ibm.com>
> ---
> MAINTAINERS | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 93df53d87f63..67f65bff3913 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1646,7 +1646,8 @@ F: tests/functional/ppc64/test_tuxrun.py
>
> PowerNV (Non-Virtualized)
> M: Nicholas Piggin <npiggin@gmail.com>
> -R: Aditya Gupta <adityag@linux.ibm.com>
> +M: Aditya Gupta <adityag@linux.ibm.com>
> +G: @adi-g15-ibm
> R: Glenn Miles <milesg@linux.ibm.com>
> R: Harsh Prateek Bora <harshpb@linux.ibm.com>
> L: qemu-ppc@nongnu.org
^ permalink raw reply
* Re: [PATCH v2 02/17] x86/virt/tdx: Configure add-on features on TDX module init and update
From: Xu Yilun @ 2026-06-24 12:00 UTC (permalink / raw)
To: Dave Hansen
Cc: x86, kvm, linux-coco, linux-kernel, djbw, kas, rick.p.edgecombe,
yilun.xu, xiaoyao.li, sohil.mehta, adrian.hunter, kishen.maloor,
tony.lindgren, peter.fang, baolu.lu, zhenzhong.duan, dave.hansen,
seanjc
In-Reply-To: <4f4b0f29-424b-45ed-8cfd-c77da2ea390f@intel.com>
> There's also zero stopping us from putting version in args:
>
> struct tdx_module_args args = {};
> int ret;
>
> if (tdx_addon_feature0) {
> args.r9 = tdx_addon_feature0;
> args.version = 1;
> }
>
> ret = seamcall_prerr(TDH_SYS_UPDATE, &args);
>
> Eh?
>
> That gives args.version==0 in all the normal cases which just happens to
> be the exact behavior we want. It also avoids having to plumb version
> through all the seamcall*() wrappers.
Ah, on 2nd reading, I'm pretty sure now I understand your logical argument in
patch 1 and 2. It's good to me. I append my diff at the end.
>
> But this is *exactly* the kind of thing that shouldn't be a part of an
> attestation patch series. This could very much have been a separate
> discussion and happened a month or a year ago. But now it is blocking
> this DICE thing from getting done <grumble>.
Sorry, I should have been more active in searching for the solution
rather than sticking to "kernel never keeps versions", when I've found
the problem that public modules are not available.
----8<----
diff --git a/arch/x86/include/asm/shared/tdx.h b/arch/x86/include/asm/shared/tdx.h
index f20e91d7ac35..972880910a5e 100644
--- a/arch/x86/include/asm/shared/tdx.h
+++ b/arch/x86/include/asm/shared/tdx.h
@@ -143,6 +143,8 @@ struct tdx_module_args {
u64 rbx;
u64 rdi;
u64 rsi;
+ /* for RAX encoding */
+ u8 version;
};
/* Used to communicate with the TDX module */
diff --git a/arch/x86/kernel/asm-offsets.c b/arch/x86/kernel/asm-offsets.c
index 081816888f7a..b3c00ff4d819 100644
--- a/arch/x86/kernel/asm-offsets.c
+++ b/arch/x86/kernel/asm-offsets.c
@@ -95,6 +95,7 @@ static void __used common(void)
OFFSET(TDX_MODULE_rbx, tdx_module_args, rbx);
OFFSET(TDX_MODULE_rdi, tdx_module_args, rdi);
OFFSET(TDX_MODULE_rsi, tdx_module_args, rsi);
+ OFFSET(TDX_MODULE_version, tdx_module_args, version);
BLANK();
OFFSET(BP_scratch, boot_params, scratch);
diff --git a/arch/x86/virt/vmx/tdx/tdxcall.S b/arch/x86/virt/vmx/tdx/tdxcall.S
index 016a2a1ec1d6..d1d3d40c5614 100644
--- a/arch/x86/virt/vmx/tdx/tdxcall.S
+++ b/arch/x86/virt/vmx/tdx/tdxcall.S
@@ -48,6 +48,14 @@
/* Move Leaf ID to RAX */
mov %rdi, %rax
+ /*
+ * Extract the version from 'struct tdx_module_args', append it to
+ * RAX[23:16]
+ */
+ movzbl TDX_MODULE_version(%rsi), %ecx
+ shll $16, %ecx
+ orq %rcx, %rax
+
/* Move other input regs from 'struct tdx_module_args' */
movq TDX_MODULE_rcx(%rsi), %rcx
movq TDX_MODULE_rdx(%rsi), %rdx
diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c
index a6f8fd0a3df0..bc3aa1f78fc8 100644
--- a/arch/x86/virt/vmx/tdx/tdx.c
+++ b/arch/x86/virt/vmx/tdx/tdx.c
@@ -1036,7 +1036,6 @@ static __init void set_tdx_addon_features(void)
static __init int config_tdx_module(struct tdmr_info_list *tdmr_list,
u64 global_keyid)
{
- u64 seamcall_fn = TDH_SYS_CONFIG_V0;
struct tdx_module_args args = {};
u64 *tdmr_pa_array;
size_t array_sz;
@@ -1059,18 +1058,18 @@ static __init int config_tdx_module(struct tdmr_info_list *tdmr_list,
for (i = 0; i < tdmr_list->nr_consumed_tdmrs; i++)
tdmr_pa_array[i] = __pa(tdmr_entry(tdmr_list, i));
+ set_tdx_addon_features();
+
args.rcx = __pa(tdmr_pa_array);
args.rdx = tdmr_list->nr_consumed_tdmrs;
args.r8 = global_keyid;
- set_tdx_addon_features();
-
if (tdx_addon_feature0) {
args.r9 = tdx_addon_feature0;
- seamcall_fn = TDH_SYS_CONFIG;
+ args.version = 1;
}
- ret = seamcall_prerr(seamcall_fn, &args);
+ ret = seamcall_prerr(TDH_SYS_CONFIG, &args);
/* Free the array as it is not required anymore. */
kfree(tdmr_pa_array);
@@ -1761,16 +1760,15 @@ int tdx_module_shutdown(void)
int tdx_module_run_update(void)
{
- u64 seamcall_fn = TDH_SYS_UPDATE_V0;
struct tdx_module_args args = {};
int ret;
if (tdx_addon_feature0) {
args.r9 = tdx_addon_feature0;
- seamcall_fn = TDH_SYS_UPDATE;
+ args.version = 1;
}
- ret = seamcall_prerr(seamcall_fn, &args);
+ ret = seamcall_prerr(TDH_SYS_UPDATE, &args);
if (ret)
return ret;
@@ -2353,6 +2351,7 @@ u64 tdh_vp_init(struct tdx_vp *vp, u64 initial_rcx, u32 x2apicid)
.rcx = vp->tdvpr_pa,
.rdx = initial_rcx,
.r8 = x2apicid,
+ .version = 1,
};
return seamcall(TDH_VP_INIT, &args);
diff --git a/arch/x86/virt/vmx/tdx/tdx.h b/arch/x86/virt/vmx/tdx/tdx.h
index 32b13b0c85f9..018988c25caa 100644
--- a/arch/x86/virt/vmx/tdx/tdx.h
+++ b/arch/x86/virt/vmx/tdx/tdx.h
@@ -44,7 +44,7 @@
#define TDH_VP_CREATE 10
#define TDH_MNG_KEY_FREEID 20
#define TDH_MNG_INIT 21
-#define TDH_VP_INIT SEAMCALL_LEAF_VER(22, 1)
+#define TDH_VP_INIT 22
#define TDH_PHYMEM_PAGE_RDMD 24
#define TDH_VP_RD 26
#define TDH_PHYMEM_PAGE_RECLAIM 28
@@ -58,11 +58,9 @@
#define TDH_PHYMEM_CACHE_WB 40
#define TDH_PHYMEM_PAGE_WBINVD 41
#define TDH_VP_WR 43
-#define TDH_SYS_CONFIG_V0 45
-#define TDH_SYS_CONFIG SEAMCALL_LEAF_VER(TDH_SYS_CONFIG_V0, 1)
+#define TDH_SYS_CONFIG 45
#define TDH_SYS_SHUTDOWN 52
-#define TDH_SYS_UPDATE_V0 53
-#define TDH_SYS_UPDATE SEAMCALL_LEAF_VER(TDH_SYS_UPDATE_V0, 1)
+#define TDH_SYS_UPDATE 53
#define TDH_EXT_INIT 60
#define TDH_EXT_MEM_ADD 61
#define TDH_SYS_DISABLE 69
^ permalink raw reply related
* Re: [PATCH v12 02/12] x86/bhi: Make clear_bhb_loop() effective on newer CPUs
From: Nikolay Borisov @ 2026-06-24 12:12 UTC (permalink / raw)
To: Pawan Gupta, x86, Jon Kohler, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Sean Christopherson, Borislav Petkov, Dave Hansen,
Peter Zijlstra, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, KP Singh, Jiri Olsa, David S. Miller,
David Laight, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
David Ahern, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, Stanislav Fomichev, Hao Luo,
Paolo Bonzini, Jonathan Corbet, Jason Baron, Alice Ryhl,
Steven Rostedt, Ard Biesheuvel, Shuah Khan
Cc: linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf, netdev,
linux-doc
In-Reply-To: <20260622-vmscape-bhb-v12-2-76cbda0ae3e5@linux.intel.com>
On 23.06.26 г. 20:33 ч., Pawan Gupta wrote:
> As a mitigation for BHI, clear_bhb_loop() executes branches that overwrite
> the Branch History Buffer (BHB). On Alder Lake and newer parts this
> sequence is not sufficient because it doesn't clear enough entries. This
> was not an issue because these CPUs use the BHI_DIS_S hardware mitigation
> in the kernel.
>
> Now with VMSCAPE (BHI variant) it is also required to isolate branch
> history between guests and userspace. Since BHI_DIS_S only protects the
> kernel, the newer CPUs also use IBPB.
>
> A cheaper alternative to the current IBPB mitigation is clear_bhb_loop().
> But it currently does not clear enough BHB entries to be effective on newer
> CPUs with larger BHB. At boot, dynamically set the loop count of
> clear_bhb_loop() such that it is effective on newer CPUs too.
>
> Introduce global loop counts, initializing them with appropriate value
> based on the hardware feature X86_FEATURE_BHI_CTRL.
>
> Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
> Acked-by: Borislav Petkov (AMD) <bp@alien8.de>
> Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Reviewed-by: Nikolay Borisov <nik.borisov@suse.com>
Although AI brings up a valid argument about whether guests should be
pessimized and fallback to the longer sequence ?
^ permalink raw reply
* Re: [PATCH v4 00/30] KVM: x86: x86.{c,h} spring cleaning
From: Paolo Bonzini @ 2026-06-24 12:30 UTC (permalink / raw)
To: Sean Christopherson, Vitaly Kuznetsov
Cc: kvm, linux-kernel, Yosry Ahmed, Kai Huang
In-Reply-To: <20260613000329.732085-1-seanjc@google.com>
On 6/13/26 02:02, Sean Christopherson wrote:
> It's still technically spring!
>
> Perform spring cleaning on x86.{c,h} and asm/kvm_host.h, by adding regs.c
> (the kvm_cache_regs.h => regs.h is already applied) and msrs.{c,h}, and moving
> relevant code out of x86.c.
Rebased and applied to kvm/queue, with the following changes:
- Collect more tags
- Move enum kvm_apicv_inhibit to x86.h
- Move TSS constants to tss.h, include it in vmx.c
- Rename kvm_x86_vcpu_ioctl_get_sregs2 to kvm_vcpu_ioctl_x86_get_sregs2
- Rename kvm_x86_vcpu_ioctl_set_sregs2 to kvm_vcpu_ioctl_x86_set_sregs2
- Fix conflicts
- Changed srcu_dereference_check() to __force cast (see 18/30)
- Adjust commit message on patches 11 and 26
Paolo
^ permalink raw reply
* Re: [PATCH v4 00/30] KVM: x86: x86.{c,h} spring cleaning
From: Sean Christopherson @ 2026-06-24 12:55 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: Vitaly Kuznetsov, kvm, linux-kernel, Yosry Ahmed, Kai Huang
In-Reply-To: <5c254d26-1dfc-4037-8ab6-5f8af6d0501f@redhat.com>
On Wed, Jun 24, 2026, Paolo Bonzini wrote:
> On 6/13/26 02:02, Sean Christopherson wrote:
> > It's still technically spring!
> >
> > Perform spring cleaning on x86.{c,h} and asm/kvm_host.h, by adding regs.c
> > (the kvm_cache_regs.h => regs.h is already applied) and msrs.{c,h}, and moving
> > relevant code out of x86.c.
>
> Rebased and applied to kvm/queue, with the following changes:
>
> - Collect more tags
> - Move enum kvm_apicv_inhibit to x86.h
> - Move TSS constants to tss.h, include it in vmx.c
> - Rename kvm_x86_vcpu_ioctl_get_sregs2 to kvm_vcpu_ioctl_x86_get_sregs2
> - Rename kvm_x86_vcpu_ioctl_set_sregs2 to kvm_vcpu_ioctl_x86_set_sregs2
> - Fix conflicts
> - Changed srcu_dereference_check() to __force cast (see 18/30)
> - Adjust commit message on patches 11 and 26
Shoot, I have a fully refreshed version that I was going to send today (well, I
was going to send it on Monday, but life happened). Any chance you want to wait
and grab that? It has all of the above (except for maybe rebasing?), along with
a few more cleanups.
^ permalink raw reply
* Re: [PATCH v12 07/12] static_call: Define EXPORT_STATIC_CALL_FOR_MODULES()
From: Sean Christopherson @ 2026-06-24 12:59 UTC (permalink / raw)
To: Pawan Gupta
Cc: x86, Jon Kohler, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Borislav Petkov, Dave Hansen, Peter Zijlstra,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, KP Singh,
Jiri Olsa, David S. Miller, David Laight, Andy Lutomirski,
Thomas Gleixner, Ingo Molnar, David Ahern, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, John Fastabend,
Stanislav Fomichev, Hao Luo, Paolo Bonzini, Jonathan Corbet,
Jason Baron, Alice Ryhl, Steven Rostedt, Ard Biesheuvel,
Shuah Khan, linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf,
netdev, linux-doc
In-Reply-To: <20260622-vmscape-bhb-v12-7-76cbda0ae3e5@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 3538 bytes --]
On Tue, Jun 23, 2026, Pawan Gupta wrote:
> There is EXPORT_STATIC_CALL_TRAMP() that hides the static key from all
> modules. But there is no equivalent of EXPORT_SYMBOL_FOR_MODULES() to
> restrict symbol visibility to only certain modules.
>
> Add EXPORT_STATIC_CALL_FOR_MODULES(name, mods) that wraps both the key and
> the trampoline with EXPORT_SYMBOL_FOR_MODULES(), allowing only a limited
> set of modules to see and update the static key.
>
> The immediate user is KVM, in the following commit.
>
> checkpatch reported below warnings with this change that I believe don't
> apply in this case:
>
> include/linux/static_call.h:219: WARNING: Non-declarative macros with multiple statements should be enclosed in a do - while loop
> include/linux/static_call.h:220: WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable
>
> Suggested-by: Peter Zijlstra <peterz@infradead.org>
> Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> ---
> include/linux/static_call.h | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/include/linux/static_call.h b/include/linux/static_call.h
> index 78a77a4ae0ea..b610afd1ed55 100644
> --- a/include/linux/static_call.h
> +++ b/include/linux/static_call.h
> @@ -216,6 +216,9 @@ extern long __static_call_return0(void);
> #define EXPORT_STATIC_CALL_GPL(name) \
> EXPORT_SYMBOL_GPL(STATIC_CALL_KEY(name)); \
> EXPORT_SYMBOL_GPL(STATIC_CALL_TRAMP(name))
> +#define EXPORT_STATIC_CALL_FOR_MODULES(name, mods) \
> + EXPORT_SYMBOL_FOR_MODULES(STATIC_CALL_KEY(name), mods); \
> + EXPORT_SYMBOL_FOR_MODULES(STATIC_CALL_TRAMP(name), mods)
>
> /* Leave the key unexported, so modules can't change static call targets: */
> #define EXPORT_STATIC_CALL_TRAMP(name) \
> @@ -276,6 +279,9 @@ extern long __static_call_return0(void);
> #define EXPORT_STATIC_CALL_GPL(name) \
> EXPORT_SYMBOL_GPL(STATIC_CALL_KEY(name)); \
> EXPORT_SYMBOL_GPL(STATIC_CALL_TRAMP(name))
> +#define EXPORT_STATIC_CALL_FOR_MODULES(name, mods) \
> + EXPORT_SYMBOL_FOR_MODULES(STATIC_CALL_KEY(name), mods); \
> + EXPORT_SYMBOL_FOR_MODULES(STATIC_CALL_TRAMP(name), mods)
>
> /* Leave the key unexported, so modules can't change static call targets: */
> #define EXPORT_STATIC_CALL_TRAMP(name) \
> @@ -346,6 +352,8 @@ static inline int static_call_text_reserved(void *start, void *end)
>
> #define EXPORT_STATIC_CALL(name) EXPORT_SYMBOL(STATIC_CALL_KEY(name))
> #define EXPORT_STATIC_CALL_GPL(name) EXPORT_SYMBOL_GPL(STATIC_CALL_KEY(name))
> +#define EXPORT_STATIC_CALL_FOR_MODULES(name, mods) \
> + EXPORT_SYMBOL_FOR_MODULES(STATIC_CALL_KEY(name), mods)
>
> #endif /* CONFIG_HAVE_STATIC_CALL */
Drat, I forgot about this. Exporting static call trampolines for KVM came up in
another conversation[*]. I had already put together patches to effectively default
to exporting only the trampoline, and also to deduplicate this code so that the
CONFIG_HAVE_STATIC_CALL_INLINE=y / CONFIG_HAVE_STATIC_CALL=y / CONFIG_HAVE_STATIC_CALL=n
implementations don't need to copy+paste the same lines of code.
The attached patches touch a lot more code, and will conflict mightily with KVM
changes I want to land in 7.3 (more use of a static_call in KVM). But if we get
them applied (to tip tree) shortly after 7.2-rc1 and provide a topic branch/tag,
then there shouldn't be too much juggling needed?
If we want to go with the more aggressive cleanup, I'll formally post the patches.
[*] https://lore.kernel.org/all/ahhoDGUz39KSGZ6o@google.com
[-- Attachment #2: 0001-static_call-Add-stub-for-ARCH_ADD_TRAMP_KEY-if-not-p.patch --]
[-- Type: text/x-diff, Size: 1244 bytes --]
From 415eb214ed200ef82244468a0682ac884b14c051 Mon Sep 17 00:00:00 2001
From: Sean Christopherson <seanjc@google.com>
Date: Thu, 28 May 2026 08:09:56 -0700
Subject: [PATCH 1/4] static_call: Add stub for ARCH_ADD_TRAMP_KEY if not
provided by arch
Add a dummy #define for ARCH_ADD_TRAMP_KEY if one is not provided by arch
code so that EXPORT_STATIC_CALL_TRAMP{,_GPL} can be used in arch-neutral
code.
No functional change intended.
Fixes: 73f44fe19d35 ("static_call: Allow module use without exposing static_call_key")
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
include/linux/static_call.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/include/linux/static_call.h b/include/linux/static_call.h
index 78a77a4ae0ea..7539c82dd35f 100644
--- a/include/linux/static_call.h
+++ b/include/linux/static_call.h
@@ -210,6 +210,10 @@ extern long __static_call_return0(void);
#define static_call_cond(name) (void)__static_call(name)
+#ifndef ARCH_ADD_TRAMP_KEY
+#define ARCH_ADD_TRAMP_KEY(name)
+#endif
+
#define EXPORT_STATIC_CALL(name) \
EXPORT_SYMBOL(STATIC_CALL_KEY(name)); \
EXPORT_SYMBOL(STATIC_CALL_TRAMP(name))
base-commit: 9d4853b044beefa21c4ee3e18c40653601a64ced
--
2.55.0.rc0.799.gd6f94ed593-goog
[-- Attachment #3: 0002-KVM-x86-Don-t-export-static-call-keys-to-vendor-modu.patch --]
[-- Type: text/x-diff, Size: 2823 bytes --]
From 0166d0df57a43f20a24f5b75a6c34929221c1f30 Mon Sep 17 00:00:00 2001
From: Sean Christopherson <seanjc@google.com>
Date: Thu, 28 May 2026 07:01:36 -0700
Subject: [PATCH 2/4] KVM: x86: Don't export static call keys to vendor modules
Export only the trampoline, not the full trampoline+key, of KVM's static
calls that are also used by vendor modules, to harden KVM against unwanted
modifications of the static calls, i.e. to allow vendor code to invoke the
static call, but not redirect it.
Use static_call_mod() instead of the vanilla static_call(), which is
required by the objtool magic to glue things together when exporting only
the trampoline.
No functional change intended.
Reported-by: Peter Zijlstra <peterz@infradead.org>
Closes: https://lore.kernel.org/all/20260528091357.GB343181@noisy.programming.kicks-ass.net
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
arch/x86/include/asm/kvm_host.h | 2 +-
arch/x86/kvm/pmu.h | 2 +-
arch/x86/kvm/x86.c | 6 +++---
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index eee473717c0e..55d674c647e6 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -2061,7 +2061,7 @@ extern bool __read_mostly enable_ipiv;
extern bool __read_mostly enable_device_posted_irqs;
extern struct kvm_x86_ops kvm_x86_ops;
-#define kvm_x86_call(func) static_call(kvm_x86_##func)
+#define kvm_x86_call(func) static_call_mod(kvm_x86_##func)
#define KVM_X86_OP(func) \
DECLARE_STATIC_CALL(kvm_x86_##func, *(((struct kvm_x86_ops *)0)->func));
diff --git a/arch/x86/kvm/pmu.h b/arch/x86/kvm/pmu.h
index a5821d7c87f9..77cdee3e4aa6 100644
--- a/arch/x86/kvm/pmu.h
+++ b/arch/x86/kvm/pmu.h
@@ -54,7 +54,7 @@ struct kvm_pmu_ops {
const u32 MSR_STRIDE;
};
-#define kvm_pmu_call(func) static_call(kvm_x86_pmu_##func)
+#define kvm_pmu_call(func) static_call_mod(kvm_x86_pmu_##func)
#define KVM_X86_PMU_OP(func) \
DECLARE_STATIC_CALL(kvm_x86_pmu_##func, *(((struct kvm_pmu_ops *)0)->func));
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index d9d51803b7b2..792f402f493f 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -148,9 +148,9 @@ struct kvm_x86_ops kvm_x86_ops __read_mostly;
#define KVM_X86_OP_OPTIONAL KVM_X86_OP
#define KVM_X86_OP_OPTIONAL_RET0 KVM_X86_OP
#include <asm/kvm-x86-ops.h>
-EXPORT_STATIC_CALL_GPL(kvm_x86_get_cs_db_l_bits);
-EXPORT_STATIC_CALL_GPL(kvm_x86_cache_reg);
-EXPORT_STATIC_CALL_GPL(kvm_x86_get_cpl);
+EXPORT_STATIC_CALL_TRAMP_GPL(kvm_x86_get_cs_db_l_bits);
+EXPORT_STATIC_CALL_TRAMP_GPL(kvm_x86_cache_reg);
+EXPORT_STATIC_CALL_TRAMP_GPL(kvm_x86_get_cpl);
static bool __read_mostly ignore_msrs = 0;
module_param(ignore_msrs, bool, 0644);
--
2.55.0.rc0.799.gd6f94ed593-goog
[-- Attachment #4: 0003-static_call-Restrict-exporting-of-static-call-key-to.patch --]
[-- Type: text/x-diff, Size: 10765 bytes --]
From 87068920d63a87235ae9a1e62529a4d897bd6c6c Mon Sep 17 00:00:00 2001
From: Sean Christopherson <seanjc@google.com>
Date: Thu, 28 May 2026 07:03:24 -0700
Subject: [PATCH 3/4] static_call: Restrict exporting of static call *key* to
tracepoints
Rename the export macros for static call trampolines and keys so that the
"default" EXPORT_STATIC_CALL{,_GPL}() exports only the trampoline, and full
exports of trampoline+key pairs is restricted to tracepoints (by naming
convention). Most developers are blissfully unaware of the gory details of
static calls, and so don't understand the implications of using the
innocuous-looking "vanilla" macros.
Effectively defaulting to exporting the key is undesirable as there is no
known use case for allowing a module to change an export static call's
target, outside of tracepoints.
Opportunistically massage the macro magic to deduplicate the
CONFIG_HAVE_STATIC_CALL_INLINE=y vs. CONFIG_HAVE_STATIC_CALL=y vs.
CONFIG_HAVE_STATIC_CALL=n implementations.
No functional change intended.
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
arch/x86/events/amd/brs.c | 2 +-
arch/x86/kernel/apic/init.c | 4 +--
arch/x86/kernel/cpu/mshyperv.c | 2 +-
arch/x86/kernel/traps.c | 2 +-
arch/x86/kvm/x86.c | 6 ++--
arch/x86/xen/enlighten.c | 2 +-
include/linux/static_call.h | 59 +++++++++++++---------------------
include/linux/tracepoint.h | 4 +--
kernel/sched/core.c | 8 ++---
9 files changed, 38 insertions(+), 51 deletions(-)
diff --git a/arch/x86/events/amd/brs.c b/arch/x86/events/amd/brs.c
index 06f35a6b58a5..b9a246989bd4 100644
--- a/arch/x86/events/amd/brs.c
+++ b/arch/x86/events/amd/brs.c
@@ -424,7 +424,7 @@ void noinstr perf_amd_brs_lopwr_cb(bool lopwr_in)
}
DEFINE_STATIC_CALL_NULL(perf_lopwr_cb, perf_amd_brs_lopwr_cb);
-EXPORT_STATIC_CALL_TRAMP_GPL(perf_lopwr_cb);
+EXPORT_STATIC_CALL_GPL(perf_lopwr_cb);
void __init amd_brs_lopwr_init(void)
{
diff --git a/arch/x86/kernel/apic/init.c b/arch/x86/kernel/apic/init.c
index 821e2e536f19..933b8d2d3af5 100644
--- a/arch/x86/kernel/apic/init.c
+++ b/arch/x86/kernel/apic/init.c
@@ -30,8 +30,8 @@ DEFINE_APIC_CALL(wakeup_secondary_cpu);
DEFINE_APIC_CALL(wakeup_secondary_cpu_64);
DEFINE_APIC_CALL(write);
-EXPORT_STATIC_CALL_TRAMP_GPL(apic_call_send_IPI_mask);
-EXPORT_STATIC_CALL_TRAMP_GPL(apic_call_send_IPI_self);
+EXPORT_STATIC_CALL_GPL(apic_call_send_IPI_mask);
+EXPORT_STATIC_CALL_GPL(apic_call_send_IPI_self);
/* The container for function call overrides */
struct apic_override __x86_apic_override __initdata;
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index b5b6a58b67b0..9adfc12be1db 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -333,7 +333,7 @@ static void __init x86_setup_ops_for_tsc_pg_clock(void)
#ifdef CONFIG_X86_64
DEFINE_STATIC_CALL(hv_hypercall, hv_std_hypercall);
-EXPORT_STATIC_CALL_TRAMP_GPL(hv_hypercall);
+EXPORT_STATIC_CALL_GPL(hv_hypercall);
#define hypercall_update(hc) static_call_update(hv_hypercall, hc)
#endif
#endif /* CONFIG_HYPERV */
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 0ca3912ecb7f..df05ad454414 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -218,7 +218,7 @@ static inline unsigned long pt_regs_val(struct pt_regs *regs, int nr)
#ifdef HAVE_ARCH_BUG_FORMAT_ARGS
DEFINE_STATIC_CALL(WARN_trap, __WARN_trap);
-EXPORT_STATIC_CALL_TRAMP(WARN_trap);
+EXPORT_STATIC_CALL(WARN_trap);
/*
* Create a va_list from an exception context.
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 792f402f493f..d9d51803b7b2 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -148,9 +148,9 @@ struct kvm_x86_ops kvm_x86_ops __read_mostly;
#define KVM_X86_OP_OPTIONAL KVM_X86_OP
#define KVM_X86_OP_OPTIONAL_RET0 KVM_X86_OP
#include <asm/kvm-x86-ops.h>
-EXPORT_STATIC_CALL_TRAMP_GPL(kvm_x86_get_cs_db_l_bits);
-EXPORT_STATIC_CALL_TRAMP_GPL(kvm_x86_cache_reg);
-EXPORT_STATIC_CALL_TRAMP_GPL(kvm_x86_get_cpl);
+EXPORT_STATIC_CALL_GPL(kvm_x86_get_cs_db_l_bits);
+EXPORT_STATIC_CALL_GPL(kvm_x86_cache_reg);
+EXPORT_STATIC_CALL_GPL(kvm_x86_get_cpl);
static bool __read_mostly ignore_msrs = 0;
module_param(ignore_msrs, bool, 0644);
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 23b91bf9b663..ec14d2017909 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -23,7 +23,7 @@
#include "xen-ops.h"
DEFINE_STATIC_CALL(xen_hypercall, xen_hypercall_hvm);
-EXPORT_STATIC_CALL_TRAMP(xen_hypercall);
+EXPORT_STATIC_CALL(xen_hypercall);
/*
* Pointer to the xen_vcpu_info structure or
diff --git a/include/linux/static_call.h b/include/linux/static_call.h
index 7539c82dd35f..c2c667baf8fe 100644
--- a/include/linux/static_call.h
+++ b/include/linux/static_call.h
@@ -26,7 +26,7 @@
* static_call_update(name, func);
* static_call_query(name);
*
- * EXPORT_STATIC_CALL{,_TRAMP}{,_GPL}()
+ * EXPORT_STATIC_CALL{,_GPL}()
*
* Usage example:
*
@@ -121,14 +121,6 @@
* completely eliding any function call overhead.
*
* Notably argument setup is unconditional.
- *
- *
- * EXPORT_STATIC_CALL() vs EXPORT_STATIC_CALL_TRAMP():
- *
- * The difference is that the _TRAMP variant tries to only export the
- * trampoline with the result that a module can use static_call{,_cond}() but
- * not static_call_update().
- *
*/
#include <linux/types.h>
@@ -214,19 +206,8 @@ extern long __static_call_return0(void);
#define ARCH_ADD_TRAMP_KEY(name)
#endif
-#define EXPORT_STATIC_CALL(name) \
- EXPORT_SYMBOL(STATIC_CALL_KEY(name)); \
- EXPORT_SYMBOL(STATIC_CALL_TRAMP(name))
-#define EXPORT_STATIC_CALL_GPL(name) \
- EXPORT_SYMBOL_GPL(STATIC_CALL_KEY(name)); \
- EXPORT_SYMBOL_GPL(STATIC_CALL_TRAMP(name))
-
-/* Leave the key unexported, so modules can't change static call targets: */
-#define EXPORT_STATIC_CALL_TRAMP(name) \
- EXPORT_SYMBOL(STATIC_CALL_TRAMP(name)); \
- ARCH_ADD_TRAMP_KEY(name)
-#define EXPORT_STATIC_CALL_TRAMP_GPL(name) \
- EXPORT_SYMBOL_GPL(STATIC_CALL_TRAMP(name)); \
+#define __EXPORT_STATIC_CALL(name, scope) \
+ EXPORT_SYMBOL##scope(STATIC_CALL_TRAMP(name)); \
ARCH_ADD_TRAMP_KEY(name)
#elif defined(CONFIG_HAVE_STATIC_CALL)
@@ -274,18 +255,8 @@ static inline int static_call_text_reserved(void *start, void *end)
extern long __static_call_return0(void);
-#define EXPORT_STATIC_CALL(name) \
- EXPORT_SYMBOL(STATIC_CALL_KEY(name)); \
- EXPORT_SYMBOL(STATIC_CALL_TRAMP(name))
-#define EXPORT_STATIC_CALL_GPL(name) \
- EXPORT_SYMBOL_GPL(STATIC_CALL_KEY(name)); \
- EXPORT_SYMBOL_GPL(STATIC_CALL_TRAMP(name))
-
-/* Leave the key unexported, so modules can't change static call targets: */
-#define EXPORT_STATIC_CALL_TRAMP(name) \
- EXPORT_SYMBOL(STATIC_CALL_TRAMP(name))
-#define EXPORT_STATIC_CALL_TRAMP_GPL(name) \
- EXPORT_SYMBOL_GPL(STATIC_CALL_TRAMP(name))
+#define __EXPORT_STATIC_CALL(name, scope) \
+ EXPORT_SYMBOL##scope(STATIC_CALL_TRAMP(name))
#else /* Generic implementation */
@@ -348,9 +319,25 @@ static inline int static_call_text_reserved(void *start, void *end)
return 0;
}
-#define EXPORT_STATIC_CALL(name) EXPORT_SYMBOL(STATIC_CALL_KEY(name))
-#define EXPORT_STATIC_CALL_GPL(name) EXPORT_SYMBOL_GPL(STATIC_CALL_KEY(name))
+#define __EXPORT_STATIC_CALL(name, scope)
#endif /* CONFIG_HAVE_STATIC_CALL */
+#define __EXPORT_TRACEPOINT_STATIC_CALL(name, scope) \
+ EXPORT_SYMBOL##scope(STATIC_CALL_KEY(name)); \
+ __EXPORT_STATIC_CALL(name, scope)
+#define EXPORT_TRACEPOINT_STATIC_CALL(name) \
+ __EXPORT_TRACEPOINT_STATIC_CALL(name, )
+#define EXPORT_TRACEPOINT_STATIC_CALL_GPL(name) \
+ __EXPORT_TRACEPOINT_STATIC_CALL(name, _GPL)
+
+/*
+ * For non-tracepoint usage, leave the key unexported, so modules can't change
+ * static call targets, i.e. can only invoke the static call.
+ */
+#define EXPORT_STATIC_CALL(name) \
+ __EXPORT_STATIC_CALL(name, )
+#define EXPORT_STATIC_CALL_GPL(name) \
+ __EXPORT_STATIC_CALL(name, _GPL)
+
#endif /* _LINUX_STATIC_CALL_H */
diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
index 2d2b9f8cdda4..1b64dcaf683e 100644
--- a/include/linux/tracepoint.h
+++ b/include/linux/tracepoint.h
@@ -423,12 +423,12 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
TRACEPOINT_CHECK(name) \
EXPORT_SYMBOL_GPL(__tracepoint_##name); \
EXPORT_SYMBOL_GPL(__traceiter_##name); \
- EXPORT_STATIC_CALL_GPL(tp_func_##name)
+ EXPORT_TRACEPOINT_STATIC_CALL_GPL(tp_func_##name)
#define EXPORT_TRACEPOINT_SYMBOL(name) \
TRACEPOINT_CHECK(name) \
EXPORT_SYMBOL(__tracepoint_##name); \
EXPORT_SYMBOL(__traceiter_##name); \
- EXPORT_STATIC_CALL(tp_func_##name)
+ EXPORT_TRACEPOINT_STATIC_CALL(tp_func_##name)
#else /* !TRACEPOINTS_ENABLED */
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index b8871449d3c6..c4d0db00d036 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -7403,7 +7403,7 @@ EXPORT_SYMBOL(preempt_schedule);
# define preempt_schedule_dynamic_disabled NULL
# endif
DEFINE_STATIC_CALL(preempt_schedule, preempt_schedule_dynamic_enabled);
-EXPORT_STATIC_CALL_TRAMP(preempt_schedule);
+EXPORT_STATIC_CALL(preempt_schedule);
# elif defined(CONFIG_HAVE_PREEMPT_DYNAMIC_KEY)
static DEFINE_STATIC_KEY_TRUE(sk_dynamic_preempt_schedule);
void __sched notrace dynamic_preempt_schedule(void)
@@ -7476,7 +7476,7 @@ EXPORT_SYMBOL_GPL(preempt_schedule_notrace);
# define preempt_schedule_notrace_dynamic_disabled NULL
# endif
DEFINE_STATIC_CALL(preempt_schedule_notrace, preempt_schedule_notrace_dynamic_enabled);
-EXPORT_STATIC_CALL_TRAMP(preempt_schedule_notrace);
+EXPORT_STATIC_CALL(preempt_schedule_notrace);
# elif defined(CONFIG_HAVE_PREEMPT_DYNAMIC_KEY)
static DEFINE_STATIC_KEY_TRUE(sk_dynamic_preempt_schedule_notrace);
void __sched notrace dynamic_preempt_schedule_notrace(void)
@@ -7723,12 +7723,12 @@ EXPORT_SYMBOL(__cond_resched);
# define cond_resched_dynamic_enabled __cond_resched
# define cond_resched_dynamic_disabled ((void *)&__static_call_return0)
DEFINE_STATIC_CALL_RET0(cond_resched, __cond_resched);
-EXPORT_STATIC_CALL_TRAMP(cond_resched);
+EXPORT_STATIC_CALL(cond_resched);
# define might_resched_dynamic_enabled __cond_resched
# define might_resched_dynamic_disabled ((void *)&__static_call_return0)
DEFINE_STATIC_CALL_RET0(might_resched, __cond_resched);
-EXPORT_STATIC_CALL_TRAMP(might_resched);
+EXPORT_STATIC_CALL(might_resched);
# elif defined(CONFIG_HAVE_PREEMPT_DYNAMIC_KEY)
static DEFINE_STATIC_KEY_FALSE(sk_dynamic_cond_resched);
int __sched dynamic_cond_resched(void)
--
2.55.0.rc0.799.gd6f94ed593-goog
[-- Attachment #5: 0004-static_call-Add-FOR_MODULES-static-call-exports-use-.patch --]
[-- Type: text/x-diff, Size: 4948 bytes --]
From 05623900bddabdc47e6797b72a610b1d4f825e1d Mon Sep 17 00:00:00 2001
From: Sean Christopherson <seanjc@google.com>
Date: Thu, 28 May 2026 07:32:41 -0700
Subject: [PATCH 4/4] static_call: Add FOR_MODULES static call exports, use 'em
in KVM
Add EXPORT_STATIC_CALL_FOR_MODULES(), along with KVM-specific variants,
and use the KVM-internal variants to export KVM's internal static calls
only to KVM's vendor modules (if any exist).
For all intents and purposes, no functional change intended.
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
arch/x86/kvm/pmu.c | 2 +-
arch/x86/kvm/x86.c | 6 +++---
include/linux/kvm_types.h | 8 ++++++++
include/linux/static_call.h | 12 +++++++-----
4 files changed, 19 insertions(+), 9 deletions(-)
diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c
index b92dd2e58335..7e4f6e5ff436 100644
--- a/arch/x86/kvm/pmu.c
+++ b/arch/x86/kvm/pmu.c
@@ -100,7 +100,7 @@ static struct kvm_pmu_ops kvm_pmu_ops __read_mostly;
#define KVM_X86_PMU_OP_OPTIONAL KVM_X86_PMU_OP
#define KVM_X86_PMU_OP_OPTIONAL_RET0 KVM_X86_PMU_OP
#include <asm/kvm-x86-pmu-ops.h>
-EXPORT_STATIC_CALL_GPL(kvm_x86_pmu_pmc_is_disabled_in_current_mode);
+EXPORT_STATIC_CALL_FOR_KVM_INTERNAL(kvm_x86_pmu_pmc_is_disabled_in_current_mode);
void kvm_pmu_ops_update(const struct kvm_pmu_ops *pmu_ops)
{
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index d9d51803b7b2..6df084d827b8 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -148,9 +148,9 @@ struct kvm_x86_ops kvm_x86_ops __read_mostly;
#define KVM_X86_OP_OPTIONAL KVM_X86_OP
#define KVM_X86_OP_OPTIONAL_RET0 KVM_X86_OP
#include <asm/kvm-x86-ops.h>
-EXPORT_STATIC_CALL_GPL(kvm_x86_get_cs_db_l_bits);
-EXPORT_STATIC_CALL_GPL(kvm_x86_cache_reg);
-EXPORT_STATIC_CALL_GPL(kvm_x86_get_cpl);
+EXPORT_STATIC_CALL_FOR_KVM_INTERNAL(kvm_x86_get_cs_db_l_bits);
+EXPORT_STATIC_CALL_FOR_KVM_INTERNAL(kvm_x86_cache_reg);
+EXPORT_STATIC_CALL_FOR_KVM_INTERNAL(kvm_x86_get_cpl);
static bool __read_mostly ignore_msrs = 0;
module_param(ignore_msrs, bool, 0644);
diff --git a/include/linux/kvm_types.h b/include/linux/kvm_types.h
index a568d8e6f4e8..3bf9d113b001 100644
--- a/include/linux/kvm_types.h
+++ b/include/linux/kvm_types.h
@@ -13,8 +13,14 @@
EXPORT_SYMBOL_FOR_MODULES(symbol, __stringify(KVM_SUB_MODULES))
#define EXPORT_SYMBOL_FOR_KVM(symbol) \
EXPORT_SYMBOL_FOR_MODULES(symbol, "kvm," __stringify(KVM_SUB_MODULES))
+#define EXPORT_STATIC_CALL_FOR_KVM_INTERNAL(symbol) \
+ EXPORT_STATIC_CALL_FOR_MODULES(symbol, __stringify(KVM_SUB_MODULES))
+#define EXPORT_STATIC_CALL_FOR_KVM(symbol) \
+ EXPORT_STATIC_CALL_FOR_MODULES(symbol, "kvm," __stringify(KVM_SUB_MODULES))
#else
#define EXPORT_SYMBOL_FOR_KVM_INTERNAL(symbol)
+#define EXPORT_STATIC_CALL_FOR_KVM_INTERNAL(symbol)
+
/*
* Allow architectures to provide a custom EXPORT_SYMBOL_FOR_KVM, but only
* if there are no submodules, e.g. to allow suppressing exports if KVM=m, but
@@ -23,8 +29,10 @@
#ifndef EXPORT_SYMBOL_FOR_KVM
#if IS_MODULE(CONFIG_KVM)
#define EXPORT_SYMBOL_FOR_KVM(symbol) EXPORT_SYMBOL_FOR_MODULES(symbol, "kvm")
+#define EXPORT_STATIC_CALL_FOR_KVM(symbol) EXPORT_STATIC_CALL_FOR_MODULES(symbol, "kvm")
#else
#define EXPORT_SYMBOL_FOR_KVM(symbol)
+#define EXPORT_STATIC_CALL_FOR_KVM(symbol)
#endif /* IS_MODULE(CONFIG_KVM) */
#endif /* EXPORT_SYMBOL_FOR_KVM */
#endif
diff --git a/include/linux/static_call.h b/include/linux/static_call.h
index c2c667baf8fe..9b38f82b35c4 100644
--- a/include/linux/static_call.h
+++ b/include/linux/static_call.h
@@ -206,8 +206,8 @@ extern long __static_call_return0(void);
#define ARCH_ADD_TRAMP_KEY(name)
#endif
-#define __EXPORT_STATIC_CALL(name, scope) \
- EXPORT_SYMBOL##scope(STATIC_CALL_TRAMP(name)); \
+#define __EXPORT_STATIC_CALL(name, scope, ...) \
+ EXPORT_SYMBOL##scope(STATIC_CALL_TRAMP(name), ##__VA_ARGS__); \
ARCH_ADD_TRAMP_KEY(name)
#elif defined(CONFIG_HAVE_STATIC_CALL)
@@ -255,8 +255,8 @@ static inline int static_call_text_reserved(void *start, void *end)
extern long __static_call_return0(void);
-#define __EXPORT_STATIC_CALL(name, scope) \
- EXPORT_SYMBOL##scope(STATIC_CALL_TRAMP(name))
+#define __EXPORT_STATIC_CALL(name, scope, ...) \
+ EXPORT_SYMBOL##scope(STATIC_CALL_TRAMP(name), ##__VA_ARGS__)
#else /* Generic implementation */
@@ -319,7 +319,7 @@ static inline int static_call_text_reserved(void *start, void *end)
return 0;
}
-#define __EXPORT_STATIC_CALL(name, scope)
+#define __EXPORT_STATIC_CALL(name, scope, ...)
#endif /* CONFIG_HAVE_STATIC_CALL */
@@ -339,5 +339,7 @@ static inline int static_call_text_reserved(void *start, void *end)
__EXPORT_STATIC_CALL(name, )
#define EXPORT_STATIC_CALL_GPL(name) \
__EXPORT_STATIC_CALL(name, _GPL)
+#define EXPORT_STATIC_CALL_FOR_MODULES(name, mods) \
+ __EXPORT_STATIC_CALL(name, _FOR_MODULES, mods)
#endif /* _LINUX_STATIC_CALL_H */
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* Re: [PATCH v4 00/30] KVM: x86: x86.{c,h} spring cleaning
From: Paolo Bonzini @ 2026-06-24 13:00 UTC (permalink / raw)
To: Sean Christopherson
Cc: Vitaly Kuznetsov, kvm, linux-kernel, Yosry Ahmed, Kai Huang
In-Reply-To: <ajvTrLNWGgulNJaj@google.com>
On 6/24/26 14:55, Sean Christopherson wrote:
> On Wed, Jun 24, 2026, Paolo Bonzini wrote:
>> On 6/13/26 02:02, Sean Christopherson wrote:
>>> It's still technically spring!
>>>
>>> Perform spring cleaning on x86.{c,h} and asm/kvm_host.h, by adding regs.c
>>> (the kvm_cache_regs.h => regs.h is already applied) and msrs.{c,h}, and moving
>>> relevant code out of x86.c.
>>
>> Rebased and applied to kvm/queue, with the following changes:
>>
>> - Collect more tags
>> - Move enum kvm_apicv_inhibit to x86.h
>> - Move TSS constants to tss.h, include it in vmx.c
>> - Rename kvm_x86_vcpu_ioctl_get_sregs2 to kvm_vcpu_ioctl_x86_get_sregs2
>> - Rename kvm_x86_vcpu_ioctl_set_sregs2 to kvm_vcpu_ioctl_x86_set_sregs2
>> - Fix conflicts
>> - Changed srcu_dereference_check() to __force cast (see 18/30)
>> - Adjust commit message on patches 11 and 26
>
> Shoot, I have a fully refreshed version that I was going to send today (well, I
> was going to send it on Monday, but life happened). Any chance you want to wait
> and grab that? It has all of the above (except for maybe rebasing?), along with
> a few more cleanups.
I was expecting some kind of conflict which is why I put it only on
kvm/queue. If it's possible to have them on top, that would be helpful
because it means I can move what I have on kvm/next, before leaving for
vacation.
Paolo
^ permalink raw reply
* Re: [PATCH v4 00/30] KVM: x86: x86.{c,h} spring cleaning
From: Sean Christopherson @ 2026-06-24 13:02 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: Vitaly Kuznetsov, kvm, linux-kernel, Yosry Ahmed, Kai Huang
In-Reply-To: <7d03539d-2a97-44fc-a9c7-0b3687730157@redhat.com>
On Wed, Jun 24, 2026, Paolo Bonzini wrote:
> On 6/24/26 14:55, Sean Christopherson wrote:
> > On Wed, Jun 24, 2026, Paolo Bonzini wrote:
> > > On 6/13/26 02:02, Sean Christopherson wrote:
> > > > It's still technically spring!
> > > >
> > > > Perform spring cleaning on x86.{c,h} and asm/kvm_host.h, by adding regs.c
> > > > (the kvm_cache_regs.h => regs.h is already applied) and msrs.{c,h}, and moving
> > > > relevant code out of x86.c.
> > >
> > > Rebased and applied to kvm/queue, with the following changes:
> > >
> > > - Collect more tags
> > > - Move enum kvm_apicv_inhibit to x86.h
> > > - Move TSS constants to tss.h, include it in vmx.c
> > > - Rename kvm_x86_vcpu_ioctl_get_sregs2 to kvm_vcpu_ioctl_x86_get_sregs2
> > > - Rename kvm_x86_vcpu_ioctl_set_sregs2 to kvm_vcpu_ioctl_x86_set_sregs2
> > > - Fix conflicts
> > > - Changed srcu_dereference_check() to __force cast (see 18/30)
> > > - Adjust commit message on patches 11 and 26
> >
> > Shoot, I have a fully refreshed version that I was going to send today (well, I
> > was going to send it on Monday, but life happened). Any chance you want to wait
> > and grab that? It has all of the above (except for maybe rebasing?), along with
> > a few more cleanups.
>
> I was expecting some kind of conflict which is why I put it only on
> kvm/queue. If it's possible to have them on top, that would be helpful
> because it means I can move what I have on kvm/next, before leaving for
> vacation.
Roger that, I'll see how things look if I rebase on top asap, and report back.
^ permalink raw reply
* [PATCH] KVM: riscv: SBI FWFT: Apply LOCK flag only on successful set
From: SeungJu Cheon @ 2026-06-24 13:02 UTC (permalink / raw)
To: anup
Cc: atish.patra, cleger, ajones, skhan, kvm, kvm-riscv, linux-riscv,
linux-kernel-mentees, SeungJu Cheon
kvm_sbi_fwft_set() applies the caller's flags to conf->flags before
invoking the set() callback. If the callback returns an error, the LOCK
bit persists and the feature becomes permanently locked without its value
ever being changed.
Move the flags assignment after the callback so LOCK takes effect only
on success.
Fixes: 6b72fd170592 ("RISC-V: KVM: add support for FWFT SBI extension")
Signed-off-by: SeungJu Cheon <suunj1331@gmail.com>
---
arch/riscv/kvm/vcpu_sbi_fwft.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/riscv/kvm/vcpu_sbi_fwft.c b/arch/riscv/kvm/vcpu_sbi_fwft.c
index ab39ac464ffd..1342adb3180c 100644
--- a/arch/riscv/kvm/vcpu_sbi_fwft.c
+++ b/arch/riscv/kvm/vcpu_sbi_fwft.c
@@ -327,9 +327,11 @@ static int kvm_sbi_fwft_set(struct kvm_vcpu *vcpu, u32 feature,
if (conf->flags & SBI_FWFT_SET_FLAG_LOCK)
return SBI_ERR_DENIED_LOCKED;
- conf->flags = flags;
+ ret = conf->feature->set(vcpu, conf, false, value);
+ if (ret == SBI_SUCCESS)
+ conf->flags = flags;
- return conf->feature->set(vcpu, conf, false, value);
+ return ret;
}
static int kvm_sbi_fwft_get(struct kvm_vcpu *vcpu, unsigned long feature,
--
2.52.0
^ permalink raw reply related
* [PATCH] KVM: x86: Drop WARN_ON_ONCE() for concurrently disappearing interrupts
From: syzbot @ 2026-06-24 13:15 UTC (permalink / raw)
To: syzkaller-bugs, Borislav Petkov, Dave Hansen, kvm, Ingo Molnar,
Paolo Bonzini, Sean Christopherson, Thomas Gleixner, x86
Cc: hpa, linux-kernel, syzbot
From: Alexander Potapenko <glider@google.com>
A warning can be triggered in kvm_check_and_inject_events() when an
interrupt disappears between the time it is checked via
kvm_cpu_has_injectable_intr() and the time it is fetched via
kvm_cpu_get_interrupt(). This occurs because the warning incorrectly
assumes that if an interrupt is injectable, fetching it must always return
a valid interrupt vector (i.e., not -1).
However, this assumption is broken by level-triggered interrupts that are
deasserted concurrently by another thread. For example, if a misconfigured
PIT or a PCI device asserts and then immediately deasserts a
level-triggered interrupt, the VCPU thread might see the pending interrupt
during the check but find it gone during the fetch, resulting in
kvm_cpu_get_interrupt() returning -1.
The warning manifests as follows:
------------[ cut here ]------------
irq == -1
WARNING: arch/x86/kvm/x86.c:10860 at kvm_check_and_inject_events
arch/x86/kvm/x86.c:10860 [inline]
WARNING: arch/x86/kvm/x86.c:10860 at vcpu_enter_guest
arch/x86/kvm/x86.c:11356 [inline]
WARNING: arch/x86/kvm/x86.c:10860 at vcpu_run+0x57ec/0x7950
arch/x86/kvm/x86.c:11770
RIP: 0010:kvm_check_and_inject_events arch/x86/kvm/x86.c:10860 [inline]
RIP: 0010:vcpu_enter_guest arch/x86/kvm/x86.c:11356 [inline]
RIP: 0010:vcpu_run+0x57ec/0x7950 arch/x86/kvm/x86.c:11770
Call Trace:
<TASK>
kvm_arch_vcpu_ioctl_run+0x1193/0x2070 arch/x86/kvm/x86.c:12125
kvm_vcpu_ioctl+0xa61/0xfd0 virt/kvm/kvm_main.c:4470
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
</TASK>
Since this is a legitimate Time-Of-Check to Time-Of-Use (TOCTOU) race
condition that can occur during normal operation, WARN_ON_ONCE() must not
be used for conditions that can legitimately happen. The patch removes the
WARN_ON_ONCE() in kvm_check_and_inject_events() and replaces it with a
pr_err_ratelimited() to log the event instead.
Fixes: bf672720e83c ("KVM: x86: check the kvm_cpu_get_interrupt result before using it")
Assisted-by: Gemini:gemini-3.1-pro-preview Gemini:gemini-3-flash-preview syzbot
Reported-by: syzbot+dd769db18693736eee89@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=dd769db18693736eee89
Link: https://syzkaller.appspot.com/ai_job?id=35cad3cd-95fd-4c0d-8ca8-812f58d56e59
Signed-off-by: Alexander Potapenko <glider@google.com>
---
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 0550359ed..c5b4cddd9 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -10857,10 +10857,13 @@ static int kvm_check_and_inject_events(struct kvm_vcpu *vcpu,
if (r) {
int irq = kvm_cpu_get_interrupt(vcpu);
- if (!WARN_ON_ONCE(irq == -1)) {
+ if (irq != -1) {
kvm_queue_interrupt(vcpu, irq, false);
kvm_x86_call(inject_irq)(vcpu, false);
WARN_ON(kvm_x86_call(interrupt_allowed)(vcpu, true) < 0);
+ } else {
+ pr_err_ratelimited(
+ "KVM: interrupt disappeared between checking and fetching\n");
}
}
if (kvm_cpu_has_injectable_intr(vcpu))
base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
--
See https://goo.gle/syzbot-ai-patches for information about AI-generated patches.
You can comment on the patch as usual, syzbot will try to address
the comments and send a new version of the patch if necessary.
syzbot engineers can be reached at syzkaller@googlegroups.com.
^ permalink raw reply related
* Re: [PATCH] KVM: x86: Clamp the EOI vector if its OOB instead of bugging the kernel
From: Sean Christopherson @ 2026-06-24 13:18 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: kvm, linux-kernel
In-Reply-To: <3948934a-eb84-418f-b29e-c1176b47370d@redhat.com>
On Wed, Jun 24, 2026, Paolo Bonzini wrote:
> On 6/18/26 20:55, Sean Christopherson wrote:
> > If KVM handles an I/O APIC EOI exit request with a bad vector, clamp the
> > vector to 255 and hope for the best instead of bugging the host. In all
> > likelihood, a missed EOI is survivable for the guest, and it's most
> > definitely not remotely fatal to the host, i.e. potentially panicking the
> > host is completely unjustified. Arbitrarily use 255 for the dummy vector,
> > the goal is purely to ensure the vector is covered by the bitmap.
> >
> > Opportunistically ensure the EOI vector isn't negative, as it's a signed
> > integer, i.e. the "greater than 255" check won't guard against setting the
> > vector to a negative value (KVM uses -1 to say "no IRQ" in many flows).
> >
> > Signed-off-by: Sean Christopherson <seanjc@google.com>
> > ---
> > arch/x86/kvm/x86.c | 5 ++++-
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > index d9d51803b7b2..fda09e03b960 100644
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -11212,7 +11212,10 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
> > if (kvm_check_request(KVM_REQ_NMI, vcpu))
> > process_nmi(vcpu);
> > if (kvm_check_request(KVM_REQ_IOAPIC_EOI_EXIT, vcpu)) {
> > - BUG_ON(vcpu->arch.pending_ioapic_eoi > 255);
> > + if (WARN_ON_ONCE(vcpu->arch.pending_ioapic_eoi < 0 ||
> > + vcpu->arch.pending_ioapic_eoi > 255))
> > + vcpu->arch.pending_ioapic_eoi = 255;
> > +
>
> Yay, it's my turn to say "why?!?" I'm not going to go full Linus on
> it :) but I've been waiting for the moment for years!
LOL. Well, well, well, if it isn't the consequences of my own actions.
> If this happens we have a much bigger problem: the vector is set in
> kvm_ioapic_send_eoi() and ultimately comes from apic_find_highest_isr().
> It is simply not going to happen.
>
> Unlike pending_external_vector or highest_stale_pending_ioapic_eoi, this
> cannot even be -1...255 so make it u8 and call it a day?
Ya, that's waaay better, especially since pending_ioapic_eoi defaults to '0'
anyways.
^ permalink raw reply
* Re: [PATCH] KVM: riscv: SBI FWFT: Apply LOCK flag only on successful set
From: sashiko-bot @ 2026-06-24 13:20 UTC (permalink / raw)
To: SeungJu Cheon; +Cc: kvm
In-Reply-To: <20260624130238.524706-1-suunj1331@gmail.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
Pre-existing issues:
- [High] SBI FWFT sub-features are enabled by default if supported by the host, violating KVM API architectural rules and breaking live migration.
- [High] Modifying FWFT features via KVM_SET_ONE_REG fails to set vcpu->arch.csr_dirty, which can cause the hardware CSRs to remain out of sync with the vCPU configuration.
- [High] Hardware feature probe in try_to_set_pmm() can be preempted, leading to false negatives and host CSR corruption.
- [High] Direct hardware CSR modifications in FWFT set handlers break nested virtualization (nacl) and are vulnerable to preemption.
--
commit 599bb2245d648d414e424da52cb50ced8f5d755b
Author: SeungJu Cheon <suunj1331@gmail.com>
KVM: riscv: SBI FWFT: Apply LOCK flag only on successful set
kvm_sbi_fwft_set() applies the caller's flags to conf->flags before
invoking the set() callback. If the callback returns an error, the LOCK
bit persists and the feature becomes permanently locked without its value
ever being changed.
Move the flags assignment after the callback so LOCK takes effect only
on success.
> diff --git a/arch/riscv/kvm/vcpu_sbi_fwft.c b/arch/riscv/kvm/vcpu_sbi_fwft.c
> index 2eab15339694f..a9b5bffc0e572 100644
> --- a/arch/riscv/kvm/vcpu_sbi_fwft.c
> +++ b/arch/riscv/kvm/vcpu_sbi_fwft.c
> @@ -303,9 +303,11 @@ static int kvm_sbi_fwft_set(struct kvm_vcpu *vcpu, u32 feature,
> if (conf->flags & SBI_FWFT_SET_FLAG_LOCK)
> return SBI_ERR_DENIED_LOCKED;
>
> - conf->flags = flags;
> + ret = conf->feature->set(vcpu, conf, false, value);
> + if (ret == SBI_SUCCESS)
> + conf->flags = flags;
>
> - return conf->feature->set(vcpu, conf, false, value);
> + return ret;
> }
>
> static int kvm_sbi_fwft_get(struct kvm_vcpu *vcpu, unsigned long feature,
While reviewing this file, I noticed a few pre-existing issues in
arch/riscv/kvm/vcpu_sbi_fwft.c:
In kvm_sbi_ext_fwft_init():
if (feature->supported)
conf->supported = feature->supported(vcpu);
else
conf->supported = true;
conf->enabled = conf->supported;
[Severity: High]
This isn't a bug introduced by this patch, but it appears FWFT sub-features
are unconditionally enabled by default if the hardware supports them. Does
this violate the KVM architectural rule that new guest-visible features must
default to OFF?
Could this break live migration if a VM is moved to a host lacking support
for a feature that was silently exposed?
In kvm_sbi_ext_fwft_set_reg():
case 2:
ret = conf->feature->set(vcpu, conf, true, value);
break;
[Severity: High]
This is a pre-existing issue, but does modifying FWFT features via
KVM_SET_ONE_REG fail to set vcpu->arch.csr_dirty?
When vcpu_load() runs on the same physical CPU, it bypasses
kvm_riscv_vcpu_config_load(). Can this leave the hardware CSRs (like
CSR_HEDELEG or CSR_HENVCFG) out of sync with the vCPU configuration?
In try_to_set_pmm():
csr_set(CSR_HENVCFG, value);
return (csr_read_clear(CSR_HENVCFG, ENVCFG_PMM) & ENVCFG_PMM) == value;
[Severity: High]
This is a pre-existing issue, but is it safe to modify and read back the CSR
here without disabling preemption?
If the thread is migrated between csr_set() and csr_read_clear(), could this
result in false negatives and corrupt the original CPU's CSR_HENVCFG by
persistently leaving ENVCFG_PMM bits set?
In kvm_sbi_fwft_set_misaligned_delegation():
if (!one_reg_access)
csr_set(CSR_HEDELEG, MIS_DELEG);
And in kvm_sbi_fwft_set_pointer_masking_pmlen():
if (!one_reg_access)
csr_write(CSR_HENVCFG, vcpu->arch.cfg.henvcfg);
[Severity: High]
This is a pre-existing issue, but do these direct hardware CSR modifications
break nested virtualization? By bypassing nacl_shmem(), the L0 hypervisor
might not observe L1's FWFT changes.
Also, since SBI_EXT_FWFT_SET exits are handled with preemption enabled,
could preempting or migrating these calls corrupt CSR_HEDELEG or CSR_HENVCFG
on a random CPU?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260624130238.524706-1-suunj1331@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH] KVM: x86: Drop WARN_ON_ONCE() for concurrently disappearing interrupts
From: sashiko-bot @ 2026-06-24 13:23 UTC (permalink / raw)
To: syzbot; +Cc: kvm
In-Reply-To: <345e9d6c-d7d9-4bab-adb3-d6a7bd27599f@mail.kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Guest-triggerable host log spam via pr_err_ratelimited() for a normal TOCTOU condition.
--
commit 116bec97d294fdbb66935efe3243c46e486faba6
Author: Alexander Potapenko <glider@google.com>
KVM: x86: Drop WARN_ON_ONCE() for concurrently disappearing interrupts
This commit removes a warning in kvm_check_and_inject_events() that occurs
when an interrupt disappears between being checked and fetched. Since this
is a legitimate race condition, the warning is replaced with a rate-limited
error message.
Link: https://syzkaller.appspot.com/ai_job?id=35cad3cd-95fd-4c0d-8ca8-812f58d56e59
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 0550359ed798f..c5b4cddd9c0cb 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -10857,10 +10857,13 @@ static int kvm_check_and_inject_events(struct kvm_vcpu *vcpu,
> if (r) {
> int irq = kvm_cpu_get_interrupt(vcpu);
>
> - if (!WARN_ON_ONCE(irq == -1)) {
> + if (irq != -1) {
> kvm_queue_interrupt(vcpu, irq, false);
> kvm_x86_call(inject_irq)(vcpu, false);
> WARN_ON(kvm_x86_call(interrupt_allowed)(vcpu, true) < 0);
> + } else {
> + pr_err_ratelimited(
> + "KVM: interrupt disappeared between checking and fetching\n");
[Severity: Medium]
Since the commit message identifies this as a legitimate race condition that
can occur during normal operation, could this pr_err_ratelimited() allow an
unprivileged guest to continuously spam the host kernel log?
By configuring a PIT or PCI device to rapidly assert and deassert
level-triggered interrupts, a guest could intentionally trigger this path and
force the host to log messages at the maximum rate-limited frequency
indefinitely.
Should this event be logged with pr_warn_once() instead, or dropped entirely
to prevent adversary-reachable host log pollution?
> + }
> }
> if (kvm_cpu_has_injectable_intr(vcpu))
--
Sashiko AI review · https://sashiko.dev/#/patchset/345e9d6c-d7d9-4bab-adb3-d6a7bd27599f@mail.kernel.org?part=1
^ permalink raw reply
* Re: [PATCH 8/8] MAINTAINERS: Add self as maintainer for PowerNV
From: Aditya Gupta @ 2026-06-24 13:34 UTC (permalink / raw)
To: Daniel P. Berrangé
Cc: qemu-devel, qemu-ppc, Harsh Prateek Bora, Cédric Le Goater,
Philippe Mathieu-Daudé, Shivang Upadhyay, Sourabh Jain,
Hari Bathini, Nicholas Piggin, Miles Glenn, Fabiano Rosas,
Laurent Vivier, Paolo Bonzini, devel, Misbah Anjum N,
Anushree Mathur, Pierrick Bouvier, kvm, Gautam Menghani,
Chinmay Rath
In-Reply-To: <aju1vc-yqJoaK7CO@redhat.com>
On 26/06/24 11:47AM, Daniel P. Berrangé wrote:
> On Tue, Jun 23, 2026 at 07:49:33PM +0530, Aditya Gupta wrote:
> > Add myself as maintainer for PowerNV machine, and remove the
> > reviewer entry
> >
> > Signed-off-by: Aditya Gupta <adityag@linux.ibm.com>
> > ---
> > MAINTAINERS | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 93df53d87f63..67f65bff3913 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -1646,7 +1646,8 @@ F: tests/functional/ppc64/test_tuxrun.py
> >
> > PowerNV (Non-Virtualized)
> > M: Nicholas Piggin <npiggin@gmail.com>
> > -R: Aditya Gupta <adityag@linux.ibm.com>
> > +M: Aditya Gupta <adityag@linux.ibm.com>
> > +G: @adi-g15-ibm
>
> Please drop the G: line, as I'm changing the approach for recording
> this info to be more automatic.
Sure Daniel, will remove it in v2.
Thanks,
- Aditya G
^ permalink raw reply
* Re: [PATCH v8 07/46] KVM: Rename memory attribute APIs to prepare for in-place gmem conversion
From: Ackerley Tng @ 2026-06-24 13:37 UTC (permalink / raw)
To: Fuad Tabba, sashiko-reviews; +Cc: Ackerley Tng via B4 Relay, kvm
In-Reply-To: <CA+EHjTxdN+TsqSyp+f+8QO-BbOgHEebmpMhJbmD0D8quWg3s8A@mail.gmail.com>
Fuad Tabba <tabba@google.com> writes:
>
> [...snip...]
>
>> Pre-existing issues:
>> - [High] `kvm_range_has_vm_memory_attributes` iterates over potentially massive ranges under `rcu_read_lock()` without yielding, leading to RCU stalls.
>
> Not a concern. The xarray walk is pointer comparisons with no I/O or
> allocation per iteration. Realistic ranges (memslot-sized, low
> millions of GFNs) complete in microseconds. The "billions of elements"
> scenario mentioned below requires ~8 GB of xarray metadata to even set
> up and doesn't happen in practice. The `!attrs` fast path
> short-circuits via `xas_find` when no entries exist. This is the
> standard xarray-under-RCU pattern used throughout KVM and mm/. Pre-
> existing and unchanged by this rename patch.
>
> /fuad
>
Thanks for looking into this, I agree that each iteration is fast so
it's not too bad.
Setting up vm memory attributes with 1 entry per index in
kvm_vm_set_mem_attributes() actually does allocations, so it is kind of
slow and affects VM startup time. That's also okay since it isn't done
while holding rcu_read_lock().
For the private/shared attribute kvm_range_has_vm_memory_attributes() is
on the deprecation path so I'd say optimizing the setup is a task for
another day.
>>
>> [...snip...]
>>
^ permalink raw reply
* Re: [PATCH v8 07/46] KVM: Rename memory attribute APIs to prepare for in-place gmem conversion
From: Ackerley Tng @ 2026-06-24 13:44 UTC (permalink / raw)
To: Binbin Wu
Cc: aik, andrew.jones, brauner, chao.p.peng, david, jmattson,
jthoughton, michael.roth, oupton, pankaj.gupta, qperret,
rick.p.edgecombe, rientjes, shivankg, steven.price, tabba, willy,
wyihan, yan.y.zhao, forkloop, pratyush, suzuki.poulose,
aneesh.kumar, liam, Paolo Bonzini, Sean Christopherson,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, Jonathan Corbet, Shuah Khan, Shuah Khan,
Vishal Annapurve, Andrew Morton, Chris Li, Kairui Song,
Kemeng Shi, Nhat Pham, Barry Song, Axel Rasmussen, Yuanchu Xie,
Wei Xu, Youngjun Park, Qi Zheng, Shakeel Butt, Kiryl Shutsemau,
Baoquan He, Jason Gunthorpe, Vlastimil Babka, kvm, linux-kernel,
linux-trace-kernel, linux-doc, linux-kselftest, linux-mm,
linux-coco
In-Reply-To: <96fb369d-dbff-4ed6-b1f9-0ce63d7d4ed0@linux.intel.com>
Binbin Wu <binbin.wu@linux.intel.com> writes:
>
> [...snip...]
>
>> +static inline bool kvm_mem_range_is_private(struct kvm *kvm, gfn_t start,
>> + gfn_t end)
>> +{
>> + return kvm_range_has_vm_memory_attributes(kvm, start, end,
>> + KVM_MEMORY_ATTRIBUTE_PRIVATE,
>> + KVM_MEMORY_ATTRIBUTE_PRIVATE);
>> }
>
> This function is added, but never used in this patch series.
> Is it intended to be called only when CONFIG_KVM_VM_MEMORY_ATTRIBUTES is
> enabled?
>
Thank you for catching this! I think in some earlier revision this was
meant to be used from the guest_memfd populate flow.
I think the version of kvm_gmem_range_is_private in this revision is
good because it is symmetric. If conversion is enabled, call the gmem
range-has-attributes function, and if conversion is disabled, use the VM
range-has-attributes function.
Sean, if no new revision is needed would you be able to drop
kvm_mem_range_is_private() while you're pulling it in?
>>
>> [...snip...]
>>
^ permalink raw reply
* Re: [PATCH 3/8] tests/qtest: Add Power11 chip & machine to qtests
From: Aditya Gupta @ 2026-06-24 13:44 UTC (permalink / raw)
To: Shivang Upadhyay
Cc: qemu-devel, qemu-ppc, Harsh Prateek Bora, Cédric Le Goater,
Philippe Mathieu-Daudé, Sourabh Jain, Hari Bathini,
Nicholas Piggin, Miles Glenn, Fabiano Rosas, Laurent Vivier,
Paolo Bonzini, devel, Misbah Anjum N, Anushree Mathur,
Pierrick Bouvier, kvm, Gautam Menghani, Chinmay Rath
In-Reply-To: <54a9b8d16347f6cc94a625aca81897ba6b875385.camel@linux.ibm.com>
On 26/06/23 09:24PM, Shivang Upadhyay wrote:
> On Tue, 2026-06-23 at 19:49 +0530, Aditya Gupta wrote:
> > +static const char *pnv_get_machine_type(enum PnvChipType chip_type)
> > +{
> > + if (chip_type == PNV_CHIP_POWER8) {
> > + return "powernv8";
> > + } else if (chip_type == PNV_CHIP_POWER9) {
> > + return "powernv9";
> > + } else if (chip_type == PNV_CHIP_POWER10) {
> > + return "powernv10";
> > + } else if (chip_type == PNV_CHIP_POWER11) {
> > + return "powernv11";
> > + } else {
> > + g_assert_not_reached();
> > + }
> > +}
>
> How about refactoring to the following?
>
> static const char *const machine_types[] = {
> [PNV_CHIP_POWER8] = "powernv8",
> [PNV_CHIP_POWER9] = "powernv9",
> [PNV_CHIP_POWER10] = "powernv10",
> [PNV_CHIP_POWER11] = "powernv11",
> };
> return machine_types[x];
Has a subtle difference, that it may not assert/segfault on unknown
value for x, I want the test to crash/fail if this is called with an
unknown/new processor chip. I believe the if-else/switch is better as it
handles (by 'crashing') unknown values too.
- Aditya G
>
> ~Shivang.
^ permalink raw reply
* Re: [PATCH 1/8] tests/functional: Add remote interrupts test for PowerNV
From: Aditya Gupta @ 2026-06-24 13:47 UTC (permalink / raw)
To: Cédric Le Goater
Cc: qemu-devel, qemu-ppc, Harsh Prateek Bora,
Philippe Mathieu-Daudé, Shivang Upadhyay, Sourabh Jain,
Hari Bathini, Nicholas Piggin, Miles Glenn, Fabiano Rosas,
Laurent Vivier, Paolo Bonzini, devel, Misbah Anjum N,
Anushree Mathur, Pierrick Bouvier, kvm, Gautam Menghani,
Chinmay Rath
In-Reply-To: <2f6d69e5-e11e-4561-a38f-84760525a549@redhat.com>
On 26/06/24 01:44PM, Cédric Le Goater wrote:
> On 6/23/26 16:19, Aditya Gupta wrote:
> > <...snip...>
> > def do_test_linux_boot(self, command_line = KERNEL_COMMON_COMMAND_LINE):
> > self.require_accelerator("tcg")
> > kernel_path = self.ASSET_KERNEL.fetch()
> > @@ -71,6 +75,88 @@ def test_linux_smt_boot(self):
> > wait_for_console_pattern(self, console_pattern, self.panic_message)
> > wait_for_console_pattern(self, self.good_message, self.panic_message)
> > + def test_linux_remote_interrupts(self):
> > + self.require_accelerator("tcg")
> > + self.set_machine('powernv')
> > +
> > + # have more sockets with as few CPUs as possible, increasing the
> > + # probability to have remote interrupts from one chip to another
> > + # also have e1000e network device to generate interrupts
>
> Can you attach the PCI device to a PCI bus known to be on the
> second socket ? and then offline cpus on the second socket,
> so that all IRQ servers are on the first socket.
Makes sense, thanks cedric ! will keep the device attached to 4th
socket, and offline it's CPU, and let the other setting affinity part
same
Thanks,
- Aditya G
^ permalink raw reply
* Re: [PATCH] KVM: x86: Drop WARN_ON_ONCE() for concurrently disappearing interrupts
From: Sean Christopherson @ 2026-06-24 14:00 UTC (permalink / raw)
To: syzbot
Cc: syzkaller-bugs, Borislav Petkov, Dave Hansen, kvm, Ingo Molnar,
Paolo Bonzini, Thomas Gleixner, x86, hpa, linux-kernel, syzbot
In-Reply-To: <345e9d6c-d7d9-4bab-adb3-d6a7bd27599f@mail.kernel.org>
On Wed, Jun 24, 2026, syzbot wrote:
> From: Alexander Potapenko <glider@google.com>
>
> A warning can be triggered in kvm_check_and_inject_events() when an
> interrupt disappears between the time it is checked via
> kvm_cpu_has_injectable_intr() and the time it is fetched via
> kvm_cpu_get_interrupt(). This occurs because the warning incorrectly
> assumes that if an interrupt is injectable, fetching it must always return
> a valid interrupt vector (i.e., not -1).
>
> However, this assumption is broken by level-triggered interrupts that are
> deasserted concurrently by another thread. For example, if a misconfigured
> PIT or a PCI device asserts and then immediately deasserts a
> level-triggered interrupt, the VCPU thread might see the pending interrupt
> during the check but find it gone during the fetch, resulting in
> kvm_cpu_get_interrupt() returning -1.
I think this the race is limited to the PIC case, no? Because for all other
cases, mucking with pending IRQs requires holding vcpu->mutex.
So rather than removing the WARN entirely, can't we fix this by exempting the
in-kernel PIC case? Given that we're pushing hard to move to a split IRQCHIP
model, this would preserve the WARN for the use case we care most about.
diff --git arch/x86/kvm/x86.c arch/x86/kvm/x86.c
index 3a2e4493516f..64f6592f5b23 100644
--- arch/x86/kvm/x86.c
+++ arch/x86/kvm/x86.c
@@ -7694,7 +7694,7 @@ static int kvm_check_and_inject_events(struct kvm_vcpu *vcpu,
if (r) {
int irq = kvm_cpu_get_interrupt(vcpu);
- if (!WARN_ON_ONCE(irq == -1)) {
+ if (!WARN_ON_ONCE(irq == -1 && !pic_in_kernel(vcpu->kvm))) {
kvm_queue_interrupt(vcpu, irq, false);
kvm_x86_call(inject_irq)(vcpu, false);
WARN_ON(kvm_x86_call(interrupt_allowed)(vcpu, true) < 0);
> The warning manifests as follows:
>
> ------------[ cut here ]------------
> irq == -1
> WARNING: arch/x86/kvm/x86.c:10860 at kvm_check_and_inject_events
> arch/x86/kvm/x86.c:10860 [inline]
> WARNING: arch/x86/kvm/x86.c:10860 at vcpu_enter_guest
> arch/x86/kvm/x86.c:11356 [inline]
> WARNING: arch/x86/kvm/x86.c:10860 at vcpu_run+0x57ec/0x7950
> arch/x86/kvm/x86.c:11770
> RIP: 0010:kvm_check_and_inject_events arch/x86/kvm/x86.c:10860 [inline]
> RIP: 0010:vcpu_enter_guest arch/x86/kvm/x86.c:11356 [inline]
> RIP: 0010:vcpu_run+0x57ec/0x7950 arch/x86/kvm/x86.c:11770
> Call Trace:
> <TASK>
> kvm_arch_vcpu_ioctl_run+0x1193/0x2070 arch/x86/kvm/x86.c:12125
> kvm_vcpu_ioctl+0xa61/0xfd0 virt/kvm/kvm_main.c:4470
> vfs_ioctl fs/ioctl.c:51 [inline]
> __do_sys_ioctl fs/ioctl.c:597 [inline]
> __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583
> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
> </TASK>
>
> Since this is a legitimate Time-Of-Check to Time-Of-Use (TOCTOU) race
> condition that can occur during normal operation, WARN_ON_ONCE() must not
> be used for conditions that can legitimately happen. The patch removes the
> WARN_ON_ONCE() in kvm_check_and_inject_events() and replaces it with a
> pr_err_ratelimited() to log the event instead.
If we can't salvage the WARN, I don't want to log anything to dmesg. The purpose
of the WARN is to find KVM bugs. A ratelimited printk isn't going to help on that
front.
> Fixes: bf672720e83c ("KVM: x86: check the kvm_cpu_get_interrupt result before using it")
> Assisted-by: Gemini:gemini-3.1-pro-preview Gemini:gemini-3-flash-preview syzbot
> Reported-by: syzbot+dd769db18693736eee89@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=dd769db18693736eee89
> Link: https://syzkaller.appspot.com/ai_job?id=35cad3cd-95fd-4c0d-8ca8-812f58d56e59
> Signed-off-by: Alexander Potapenko <glider@google.com>
>
> ---
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 0550359ed..c5b4cddd9 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -10857,10 +10857,13 @@ static int kvm_check_and_inject_events(struct kvm_vcpu *vcpu,
> if (r) {
> int irq = kvm_cpu_get_interrupt(vcpu);
>
> - if (!WARN_ON_ONCE(irq == -1)) {
> + if (irq != -1) {
> kvm_queue_interrupt(vcpu, irq, false);
> kvm_x86_call(inject_irq)(vcpu, false);
> WARN_ON(kvm_x86_call(interrupt_allowed)(vcpu, true) < 0);
> + } else {
> + pr_err_ratelimited(
> + "KVM: interrupt disappeared between checking and fetching\n");
> }
> }
> if (kvm_cpu_has_injectable_intr(vcpu))
>
>
> base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
> --
> See https://goo.gle/syzbot-ai-patches for information about AI-generated patches.
> You can comment on the patch as usual, syzbot will try to address
> the comments and send a new version of the patch if necessary.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
^ permalink raw reply related
* Re: [PATCH v8 08/46] KVM: Provide generic interface for checking memory private/shared status
From: Ackerley Tng @ 2026-06-24 14:18 UTC (permalink / raw)
To: Suzuki K Poulose, Fuad Tabba
Cc: aik, andrew.jones, binbin.wu, brauner, chao.p.peng, david,
jmattson, jthoughton, michael.roth, oupton, pankaj.gupta, qperret,
rick.p.edgecombe, rientjes, shivankg, steven.price, willy, wyihan,
yan.y.zhao, forkloop, pratyush, aneesh.kumar, liam, Paolo Bonzini,
Sean Christopherson, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, Jonathan Corbet, Shuah Khan,
Shuah Khan, Vishal Annapurve, Andrew Morton, Chris Li,
Kairui Song, Kemeng Shi, Nhat Pham, Barry Song, Axel Rasmussen,
Yuanchu Xie, Wei Xu, Youngjun Park, Qi Zheng, Shakeel Butt,
Kiryl Shutsemau, Baoquan He, Jason Gunthorpe, Vlastimil Babka,
kvm, linux-kernel, linux-trace-kernel, linux-doc, linux-kselftest,
linux-mm, linux-coco
In-Reply-To: <3ec15992-2a29-434b-8c99-8b86bfcf007e@arm.com>
Suzuki K Poulose <suzuki.poulose@arm.com> writes:
>
> [...snip...]
>
>>>> @@ -2546,7 +2546,7 @@ bool kvm_arch_pre_set_memory_attributes(struct kvm *kvm,
>>>> bool kvm_arch_post_set_memory_attributes(struct kvm *kvm,
>>>> struct kvm_gfn_range *range);
>>>>
>>>> -static inline bool kvm_mem_is_private(struct kvm *kvm, gfn_t gfn)
>>>> +static inline bool kvm_vm_mem_is_private(struct kvm *kvm, gfn_t gfn)
>>
>> Should have read the Sashiko review first, but where is this used?
>> It's not used at all in this series...
>
> See below:
>
>>
>> /fuad
>>
>>>> {
>>>> return kvm_get_vm_memory_attributes(kvm, gfn) & KVM_MEMORY_ATTRIBUTE_PRIVATE;
>>>> }
>>>> @@ -2557,6 +2557,16 @@ static inline bool kvm_mem_range_is_private(struct kvm *kvm, gfn_t start,
>>>> KVM_MEMORY_ATTRIBUTE_PRIVATE,
>>>> KVM_MEMORY_ATTRIBUTE_PRIVATE);
>>>> }
>>>> +#endif /* CONFIG_KVM_VM_MEMORY_ATTRIBUTES */
>>>> +
>>>> +#ifdef kvm_arch_has_private_mem
>>>> +typedef bool (kvm_mem_is_private_t)(struct kvm *kvm, gfn_t gfn);
>>>> +DECLARE_STATIC_CALL(__kvm_mem_is_private, kvm_mem_is_private_t);
>>>> +
>>>> +static inline bool kvm_mem_is_private(struct kvm *kvm, gfn_t gfn)
>>>> +{
>>>> + return static_call(__kvm_mem_is_private)(kvm, gfn);
>>>> +}
>>>> #else
>>>> static inline bool kvm_mem_is_private(struct kvm *kvm, gfn_t gfn)
>>>> {
>>>> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
>>>> index 6669f1477013c..8b238e461b854 100644
>>>> --- a/virt/kvm/kvm_main.c
>>>> +++ b/virt/kvm/kvm_main.c
>>>> @@ -2627,6 +2627,20 @@ static int kvm_vm_ioctl_set_mem_attributes(struct kvm *kvm,
>>>> }
>>>> #endif /* CONFIG_KVM_VM_MEMORY_ATTRIBUTES */
>>>>
>>>> +#ifdef kvm_arch_has_private_mem
>>>> +DEFINE_STATIC_CALL_RET0(__kvm_mem_is_private, kvm_mem_is_private_t);
>>>> +EXPORT_STATIC_CALL_GPL(__kvm_mem_is_private);
>>>> +
>>>> +static void kvm_init_memory_attributes(void)
>>>> +{
>>>> +#ifdef CONFIG_KVM_VM_MEMORY_ATTRIBUTES
>>>> + static_call_update(__kvm_mem_is_private, kvm_vm_mem_is_private);
>>>> +#endif
>>>> +}
>
>
> Here ^^ as the static call update ?
>
>
> Suzuki
Thanks Suzuki, it is used here. kvm_mem_is_private() was and still is
the function used to check if some gfn is private or shared. Hence, in
this patch, the usages of kvm_mem_is_private() were not
updated. Instead, kvm_mem_is_private() is now set up as a static call,
and the static call is hard-wired to kvm_vm_mem_is_private() in this
patch.
In the later wiring patch, all the places where attributes are looked up
are updated all at once: if conversion enabled, take gmem route, else
take VM route.
kvm_mem_is_private() is special in that the if-else is done at KVM load
time rather than runtime, and I believe that's for performance reasons
since this is checked quite often from the KVM fault handling code.
Buut I think perhaps Fuad was referring to kvm_mem_range_is_private(),
which is indeed not used anywhere. Binbin also asked about this, I think
we should drop kvm_mem_range_is_private(). My reply to Binbin is at [1].
[1] https://lore.kernel.org/all/CAEvNRgGbBcrX5Fw3vNTsTOBNC=Ypi=9-S07674yPxLU9i4akjA@mail.gmail.com/
^ permalink raw reply
* Re: [PATCH 2/8] tests/qtest/pnv_spi: Test Power11 PNV_SPI
From: Aditya Gupta @ 2026-06-24 14:28 UTC (permalink / raw)
To: Cédric Le Goater
Cc: qemu-devel, qemu-ppc, Harsh Prateek Bora,
Philippe Mathieu-Daudé, Shivang Upadhyay, Sourabh Jain,
Hari Bathini, Nicholas Piggin, Miles Glenn, Fabiano Rosas,
Laurent Vivier, Paolo Bonzini, devel, Misbah Anjum N,
Anushree Mathur, Pierrick Bouvier, kvm, Gautam Menghani,
Chinmay Rath
In-Reply-To: <ccbadb13-888b-495d-b894-826a8e664d3e@redhat.com>
On 26/06/24 01:47PM, Cédric Le Goater wrote:
> On 6/23/26 16:19, Aditya Gupta wrote:
> > <...snip...>
> >
> > g_test_init(&argc, &argv, NULL);
> > - char *tname = g_strdup_printf("pnv-xscom/spi-seeprom/%s",
> > - pnv_chips[3].cpu_model);
> > - qtest_add_data_func(tname, &pnv_chips[3], test_spi_seeprom);
> > - g_free(tname);
> > +
> > + for (int i = 0; i < ARRAY_SIZE(pnv_chips); i++) {
> > + /* TYPE_PNV_SPI is not instantiated for older Power8/9 machines */
> > + if (pnv_chips[i].chip_type < PNV_CHIP_POWER10) {
>
> Can we remove this chip_type field from the tests too ? see 248e4e924e87.
I went through the usage, and don't see any fix currently, as the
PnvChip structure these qtests are using is basic, and we need some way
to identify the chip type, for things like which machine to use, xscom
addresses, and to skip/do specific things for particular chip type.
I went through the mentioned commit and its parent, seems it was
possible with the compat property being handled by respective
class_init. So currently I don't see a better way, what do you think ?
>
> > + continue;
> > + }
> > +
> > + char *tname = g_strdup_printf("pnv-xscom/spi-seeprom/%s",
> > + pnv_chips[i].cpu_model);
>
> please consider g_autofree variables.
Sure cedric, will use it in v2.
Thanks,
- Aditya G
>
> > + qtest_add_data_func(tname, &pnv_chips[i], test_spi_seeprom);
> > + g_free(tname);
> > + }
> > return g_test_run();
> > }
>
^ permalink raw reply
* Re: [PATCH v4 00/30] KVM: x86: x86.{c,h} spring cleaning
From: Sean Christopherson @ 2026-06-24 14:37 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: Vitaly Kuznetsov, kvm, linux-kernel, Yosry Ahmed, Kai Huang
In-Reply-To: <ajvVaYBFjweVcqlY@google.com>
On Wed, Jun 24, 2026, Sean Christopherson wrote:
> On Wed, Jun 24, 2026, Paolo Bonzini wrote:
> > On 6/24/26 14:55, Sean Christopherson wrote:
> > > On Wed, Jun 24, 2026, Paolo Bonzini wrote:
> > > > On 6/13/26 02:02, Sean Christopherson wrote:
> > > > > It's still technically spring!
> > > > >
> > > > > Perform spring cleaning on x86.{c,h} and asm/kvm_host.h, by adding regs.c
> > > > > (the kvm_cache_regs.h => regs.h is already applied) and msrs.{c,h}, and moving
> > > > > relevant code out of x86.c.
> > > >
> > > > Rebased and applied to kvm/queue, with the following changes:
> > > >
> > > > - Collect more tags
> > > > - Move enum kvm_apicv_inhibit to x86.h
> > > > - Move TSS constants to tss.h, include it in vmx.c
> > > > - Rename kvm_x86_vcpu_ioctl_get_sregs2 to kvm_vcpu_ioctl_x86_get_sregs2
> > > > - Rename kvm_x86_vcpu_ioctl_set_sregs2 to kvm_vcpu_ioctl_x86_set_sregs2
> > > > - Fix conflicts
> > > > - Changed srcu_dereference_check() to __force cast (see 18/30)
> > > > - Adjust commit message on patches 11 and 26
> > >
> > > Shoot, I have a fully refreshed version that I was going to send today (well, I
> > > was going to send it on Monday, but life happened). Any chance you want to wait
> > > and grab that? It has all of the above (except for maybe rebasing?), along with
> > > a few more cleanups.
> >
> > I was expecting some kind of conflict which is why I put it only on
> > kvm/queue. If it's possible to have them on top, that would be helpful
> > because it means I can move what I have on kvm/next, before leaving for
> > vacation.
>
> Roger that, I'll see how things look if I rebase on top asap, and report back.
Everything can go on top, and shouldn't generate massive conflicts, i.e. doesn't
need to be rushed into kvm/next and can go through kvm-x86.
Thanks much!
^ permalink raw reply
* Re: [PATCH v8 09/46] KVM: guest_memfd: Introduce function to check GFN private/shared status
From: Ackerley Tng @ 2026-06-24 14:38 UTC (permalink / raw)
To: Binbin Wu
Cc: aik, andrew.jones, brauner, chao.p.peng, david, jmattson,
jthoughton, michael.roth, oupton, pankaj.gupta, qperret,
rick.p.edgecombe, rientjes, shivankg, steven.price, tabba, willy,
wyihan, yan.y.zhao, forkloop, pratyush, suzuki.poulose,
aneesh.kumar, liam, Paolo Bonzini, Sean Christopherson,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, Jonathan Corbet, Shuah Khan, Shuah Khan,
Vishal Annapurve, Andrew Morton, Chris Li, Kairui Song,
Kemeng Shi, Nhat Pham, Barry Song, Axel Rasmussen, Yuanchu Xie,
Wei Xu, Youngjun Park, Qi Zheng, Shakeel Butt, Kiryl Shutsemau,
Baoquan He, Jason Gunthorpe, Vlastimil Babka, kvm, linux-kernel,
linux-trace-kernel, linux-doc, linux-kselftest, linux-mm,
linux-coco
In-Reply-To: <1b59fec2-a464-4429-8532-880394912af5@linux.intel.com>
Binbin Wu <binbin.wu@linux.intel.com> writes:
>
> [...snip...]
>
>> +bool kvm_gmem_is_private(struct kvm *kvm, gfn_t gfn)
>> +{
>> + struct kvm_memory_slot *slot = gfn_to_memslot(kvm, gfn);
>> + struct inode *inode;
>> +
>> + /*
>> + * If this gfn has no associated memslot, there's no chance of the gfn
>> + * being backed by private memory, since guest_memfd must be used for
>> + * private memory,
>
> "guest_memfd must be used for private memory" is a bit confusing to me.
>
Hmm good point. Is the source of confusion that guest_memfd can be used
for both shared and private memory?
Perhaps this can be rephrased as:
guest_memfd is the only provider of private memory and guest_memfd must
be used with a memslot, hence if there's no associated memslot, there's
no chance of this gfn being private.
>> and guest_memfd must be associated with some memslot.
>> + */
>> + if (!slot)
>> + return 0;
>> +
>>
>> [...snip...]
>>
^ permalink raw reply
* Re: [PATCH v8 04/46] KVM: Decouple kvm_has_arch_private_mem from CONFIG_KVM_VM_MEMORY_ATTRIBUTES
From: Sean Christopherson @ 2026-06-24 15:12 UTC (permalink / raw)
To: Ackerley Tng
Cc: Binbin Wu, aik, andrew.jones, brauner, chao.p.peng, david,
jmattson, jthoughton, michael.roth, oupton, pankaj.gupta, qperret,
rick.p.edgecombe, rientjes, shivankg, steven.price, tabba, willy,
wyihan, yan.y.zhao, forkloop, pratyush, suzuki.poulose,
aneesh.kumar, liam, Paolo Bonzini, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, Jonathan Corbet, Shuah Khan,
Shuah Khan, Vishal Annapurve, Andrew Morton, Chris Li,
Kairui Song, Kemeng Shi, Nhat Pham, Barry Song, Axel Rasmussen,
Yuanchu Xie, Wei Xu, Youngjun Park, Qi Zheng, Shakeel Butt,
Kiryl Shutsemau, Baoquan He, Jason Gunthorpe, Vlastimil Babka,
kvm, linux-kernel, linux-trace-kernel, linux-doc, linux-kselftest,
linux-mm, linux-coco
In-Reply-To: <CAEvNRgGF+O7r-YHqcLp-ZgoXTCbqjuUhpOdD5eE5w2wu3YYYpw@mail.gmail.com>
On Tue, Jun 23, 2026, Ackerley Tng wrote:
> Binbin Wu <binbin.wu@linux.intel.com> writes:
>
> > On 6/19/2026 8:31 AM, Ackerley Tng via B4 Relay wrote:
> >> From: Sean Christopherson <seanjc@google.com>
> >>
> >> When memory attributes become trackable in guest_memfd, the concept of
> >> having private memory is no longer dependent on
> >> CONFIG_KVM_VM_MEMORY_ATTRIBUTES.
> >>
> >> With this, on x86, kvm_arch_has_private_mem() is defined if some CoCo
> >> platform support (or the testing CONFIG_KVM_SW_PROTECTED_VM) is compiled
> >> in.
> >>
> >> Signed-off-by: Sean Christopherson <seanjc@google.com>
> >> Co-developed-by: Ackerley Tng <ackerleytng@google.com>
> >> Signed-off-by: Ackerley Tng <ackerleytng@google.com>
> >
> > Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com>
> >
> > One nit below.
> >
> >> ---
> >> arch/x86/include/asm/kvm_host.h | 4 +++-
> >> include/linux/kvm_host.h | 2 +-
> >> 2 files changed, 4 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> >> index 8e8eb8a5e8a6b..1bde67cf6eb0e 100644
> >> --- a/arch/x86/include/asm/kvm_host.h
> >> +++ b/arch/x86/include/asm/kvm_host.h
> >> @@ -2394,7 +2394,9 @@ void kvm_configure_mmu(bool enable_tdp, int tdp_forced_root_level,
> >> int tdp_max_root_level, int tdp_huge_page_level);
> >>
> >>
> >> -#ifdef CONFIG_KVM_VM_MEMORY_ATTRIBUTES
> >> +#if defined(CONFIG_KVM_SW_PROTECTED_VM) || \
> >> + defined(CONFIG_KVM_INTEL_TDX) || \
> >> + defined(CONFIG_KVM_AMD_SEV)
> >
> > Nit:
> > Vertically align the defined(XXX) statements for better readability?
> >
>
> Sean had this aligned with spaces, and checkpatch complained about
checkpatch is a tool, it is neither omniscient nor authoritative. And for things
like this, the *entire* purpose for rules/guildlines like "no tabs after spaces"
is to help ensure the code is easier to read, e.g. doesn't end up with wonky
formatting when viewed in certain editors or whatever. So, ignore checkpatch if
it complains about formatting that is visually superior to what makes checkpatch
happy.
> having no spaces before tabs, so I switched it to tabs instead since I
> don't think alignment like that is officially documented either way.
This exact case may not be "officially" documented, but the general gist is in
Documentation/process/maintainer-tip.rst:
When splitting function declarations or function calls, then please align
the first argument in the second line with the first argument in the first
line::
And there is lots and lots of prior art on-list (from me and others) that is more
or less as good as official documentation.
> Either way is fine :)
Please restore the alignment.
^ permalink raw reply
* Re: [PATCH 1/8] tests/functional: Add remote interrupts test for PowerNV
From: Aditya Gupta @ 2026-06-24 15:21 UTC (permalink / raw)
To: Shivang Upadhyay
Cc: qemu-devel, qemu-ppc, Harsh Prateek Bora, Cédric Le Goater,
Philippe Mathieu-Daudé, Sourabh Jain, Hari Bathini,
Nicholas Piggin, Miles Glenn, Fabiano Rosas, Laurent Vivier,
Paolo Bonzini, devel, Misbah Anjum N, Anushree Mathur,
Pierrick Bouvier, kvm, Gautam Menghani, Chinmay Rath
In-Reply-To: <4de3eafc3c47799d0b503076b0d71be7cf261b61.camel@linux.ibm.com>
On 26/06/23 09:17PM, Shivang Upadhyay wrote:
> On Tue, 2026-06-23 at 19:49 +0530, Aditya Gupta wrote:
> > + # Check that interrupt counts increased
> > + success_msg = "Interrupts increased"
> > + self.helper_exec_shell_command(f"export
> > PASS='{success_msg}'")
> This is a great idea. Maybe in future we can pull this to a saperate
> function? something like the following.
>
> self.is_booted = True
> shell_check_pass_fail_command("asdf")
Makes sense. Will have a helper in v2.
Thanks,
- Aditya G
>
> ~Shivang.
^ 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