FAILED: patch "[PATCH] KVM: x86: Re-split x2APIC ICR into ICR+ICR2 for AMD (x2AVIC)" failed to apply to 6.6-stable tree
Subsystems (3)
[email protected]
maintainerThe patch below does not apply to the 6.6-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.6.y
git checkout FETCH_HEAD
git cherry-pick -x 73b42dc69be8564d4951a14d00f827929fe5ef79
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<[email protected]>' --in-reply-to '2024100123-unreached-enrage-2cb1@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^..
Possible dependencies:
73b42dc69be8 ("KVM: x86: Re-split x2APIC ICR into ICR+ICR2 for AMD (x2AVIC)") d33234342f8b ("KVM: x86: Move x2APIC ICR helper above kvm_apic_write_nodecode()") 71bf395a276f ("KVM: x86: Enforce x2APIC's must-be-zero reserved ICR bits") 4b7c3f6d04bd ("KVM: x86: Make x2APIC ID 100% readonly")c7d4c5f01961 ("KVM: x86: Drop unused check_apicv_inhibit_reasons() callback definition") 5f18c642ff7e ("KVM: VMX: Move out vmx_x86_ops to 'main.c' to dispatch VMX and TDX") 0ec3d6d1f169 ("KVM: x86: Fully defer to vendor code to decide how to force immediate exit") bf1a49436ea3 ("KVM: x86: Move handling of is_guest_mode() into fastpath exit handlers") 11776aa0cfa7 ("KVM: VMX: Handle forced exit due to preemption timer in fastpath") e6b5d16bbd2d ("KVM: VMX: Re-enter guest in fastpath for "spurious" preemption timer exits") 9c9025ea003a ("KVM: x86: Plumb "force_immediate_exit" into kvm_entry() tracepoint") 8ecb10bcbfa3 ("Merge tag 'kvm-x86-lam-6.8' of https://github.com/kvm-x86/linux into HEAD")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 73b42dc69be8564d4951a14d00f827929fe5ef79 Mon Sep 17 00:00:00 2001
From: Sean Christopherson <[email protected]>
Date: Fri, 19 Jul 2024 16:51:00 -0700
Subject: [PATCH] KVM: x86: Re-split x2APIC ICR into ICR+ICR2 for AMD (x2AVIC)
Re-introduce the "split" x2APIC ICR storage that KVM used prior to Intel's IPI virtualization support, but only for AMD. While not stated anywhere in the APM, despite stating the ICR is a single 64-bit register, AMD CPUs store the 64-bit ICR as two separate 32-bit values in ICR and ICR2. When IPI virtualization (IPIv on Intel, all AVIC flavors on AMD) is enabled, KVM needs to match CPU behavior as some ICR ICR writes will be handled by the CPU, not by KVM.
Add a kvm_x86_ops knob to control the underlying format used by the CPU to store the x2APIC ICR, and tune it to AMD vs. Intel regardless of whether or not x2AVIC is enabled. If KVM is handling all ICR writes, the storage format for x2APIC mode doesn't matter, and having the behavior follow AMD versus Intel will provide better test coverage and ease debugging.
arch/x86/include/asm/kvm_host.h +2 -0
@@ -1727,6 +1727,8 @@ struct kvm_x86_ops {void (*enable_nmi_window)(struct kvm_vcpu *vcpu);void (*enable_irq_window)(struct kvm_vcpu *vcpu);void (*update_cr8_intercept)(struct kvm_vcpu *vcpu,int tpr,int irr); + +const bool x2apic_icr_is_split;const unsigned long required_apicv_inhibits;bool allow_apicv_in_x2apic_without_x2apic_virtualization;void (*refresh_apicv_exec_ctrl)(struct kvm_vcpu *vcpu);
arch/x86/kvm/lapic.c +30 -12
73 lines not on this page · raw message
arch/x86/kvm/svm/svm.c +2 -0
@@ -5053,6 +5053,8 @@ static struct kvm_x86_ops svm_x86_ops __initdata = { .enable_nmi_window = svm_enable_nmi_window, .enable_irq_window = svm_enable_irq_window, .update_cr8_intercept = svm_update_cr8_intercept, + + .x2apic_icr_is_split = true, .set_virtual_apic_mode = avic_refresh_virtual_apic_mode, .refresh_apicv_exec_ctrl = avic_refresh_apicv_exec_ctrl, .apicv_post_state_restore = avic_apicv_post_state_restore,
arch/x86/kvm/vmx/main.c +2 -0
@@ -89,6 +89,8 @@ struct kvm_x86_ops vt_x86_ops __initdata = { .enable_nmi_window = vmx_enable_nmi_window, .enable_irq_window = vmx_enable_irq_window, .update_cr8_intercept = vmx_update_cr8_intercept, + + .x2apic_icr_is_split = false, .set_virtual_apic_mode = vmx_set_virtual_apic_mode, .set_apic_access_page_addr = vmx_set_apic_access_page_addr, .refresh_apicv_exec_ctrl = vmx_refresh_apicv_exec_ctrl,
cover KVM: x86: Backport split ICR for x2AVIC
Also pull in commit 4b7c3f6d04bd ("KVM: x86: Make x2APIC ID 100% readonly") as a dependency, which itself fixes a WARN.
Tested with xapic_state_test avic=Y.
Sean Christopherson (2):
KVM: x86: Make x2APIC ID 100% readonly
KVM: x86: Re-split x2APIC ICR into ICR+ICR2 for AMD (x2AVIC)
arch/x86/include/asm/kvm_host.h | 2 + arch/x86/kvm/lapic.c | 66 +++++++++++++++++++++++---------- arch/x86/kvm/svm/svm.c | 2 + arch/x86/kvm/vmx/vmx.c | 2 + 4 files changed, 52 insertions(+), 20 deletions(-)
Signature · 1 line
2.48.1.362.g079036d154-goog
PATCH 1/2 KVM: x86: Make x2APIC ID 100% readonly
From: Sean Christopherson <[email protected]>
Ignore the userspace provided x2APIC ID when fixing up APIC state for KVM_SET_LAPIC, i.e. make the x2APIC fully readonly in KVM. Commit a92e2543d6a8 ("KVM: x86: use hardware-compatible format for APIC ID register"), which added the fixup, didn't intend to allow userspace to modify the x2APIC ID. In fact, that commit is when KVM first started treating the x2APIC ID as readonly, apparently to fix some race:
static inline u32 kvm_apic_id(struct kvm_lapic *apic) {
- return (kvm_lapic_get_reg(apic, APIC_ID) >> 24) & 0xff;
+ /* To avoid a race between apic_base and following APIC_ID update when
+ * switching to x2apic_mode, the x2apic mode returns initial x2apic id.
+ */
+ if (apic_x2apic_mode(apic))
+ return apic->vcpu->vcpu_id;
+
+ return kvm_lapic_get_reg(apic, APIC_ID) >> 24;
}
Furthermore, KVM doesn't support delivering interrupts to vCPUs with a modified x2APIC ID, but KVM *does* return the modified value on a guest RDMSR and for KVM_GET_LAPIC. I.e. no remotely sane setup can actually work with a modified x2APIC ID.
Making the x2APIC ID fully readonly fixes a WARN in KVM's optimized map calculation, which expects the LDR to align with the x2APIC ID.
WARNING: CPU: 2 PID: 958 at arch/x86/kvm/lapic.c:331 kvm_recalculate_apic_map+0x609/0xa00 [kvm] CPU: 2 PID: 958 Comm: recalc_apic_map Not tainted 6.4.0-rc3-vanilla+ #35 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.2-1-1 04/01/2014 RIP: 0010:kvm_recalculate_apic_map+0x609/0xa00 [kvm] Call Trace: <TASK> kvm_apic_set_state+0x1cf/0x5b0 [kvm] kvm_arch_vcpu_ioctl+0x1806/0x2100 [kvm] kvm_vcpu_ioctl+0x663/0x8a0 [kvm] __x64_sys_ioctl+0xb8/0xf0 do_syscall_64+0x56/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7fade8b9dd6f
Unfortunately, the WARN can still trigger for other CPUs than the current one by racing against KVM_SET_LAPIC, so remove it completely.
Message-ID: <[email protected]>
--- arch/x86/kvm/lapic.c | 22 +++++++++++++++------- 1 file changed, 15 insertions(+), 7 deletions(-)
arch/x86/kvm/lapic.c +15 -7
@@ -338,10 +338,8 @@ static void kvm_recalculate_logical_map(struct kvm_apic_map *new,* reversing the LDR calculation to get cluster of APICs, i.e. no * additional work is required. */ -if (apic_x2apic_mode (apic)) { -WARN_ON_ONCE (ldr !=kvm_apic_calc_x2apic_ldr (kvm_x2apic_id (apic))); +if (apic_x2apic_mode (apic))return ; - }if (WARN_ON_ONCE (!kvm_apic_map_get_logical_dest (new, ldr, &cluster, &mask))) {
@@ -2964,18 +2962,28 @@ static int kvm_apic_state_fixup(struct kvm_vcpu *vcpu, struct kvm_lapic_state *s, bool set) {if (apic_x2apic_mode (vcpu->arch.apic)) { +u32 x2apic_id =kvm_x2apic_id (vcpu->arch.apic);u32 *id = (u32 *)(s->regs +APIC_ID );u32 *ldr = (u32 *)(s->regs +APIC_LDR );u64 icr;if (vcpu->kvm->arch.x2apic_format) { -if (*id != vcpu->vcpu_id) +if (*id != x2apic_id)return -EINVAL ; }else { +/* +* Ignore the userspace value when setting APIC state. +* KVM's model is that the x2APIC ID is readonly, e.g. +* KVM only supports delivering interrupts to KVM's +* version of the x2APIC ID. However, for backwards +* compatibility, don't reject attempts to set a +* mismatched ID for userspace that hasn't opted into +* x2apic_format. +*/ if (set) - *id >>=24 ; + *id = x2apic_id;else - *id <<=24 ; + *id = x2apic_id <<24 ; }/*
@@ -2984,7 +2992,7 @@ static int kvm_apic_state_fixup(struct kvm_vcpu *vcpu,* split to ICR+ICR2 in userspace for backwards compatibility. */ if (set) { - *ldr =kvm_apic_calc_x2apic_ldr (*id); + *ldr =kvm_apic_calc_x2apic_ldr (x2apic_id); icr =__kvm_lapic_get_reg (s->regs,APIC_ICR ) | (u64 )__kvm_lapic_get_reg (s->regs,APIC_ICR2 ) <<32 ;
Signature · 1 line
2.48.1.362.g079036d154-goog
Sasha Levin
maintainerRe: [PATCH 6.6.y 1/2] KVM: x86: Make x2APIC ID 100% readonly
[ Sasha's backport helper bot ]
Hi,
Found matching upstream commit: 4b7c3f6d04bd53f2e5b228b6821fb8f5d1ba3071
WARNING: Author mismatch between patch and found commit:
Backport author: James Houghton<[email protected]> Commit author: Sean Christopherson<[email protected]>
Status in newer kernel trees:
6.13.y | Present (exact SHA1)
6.12.y | Present (exact SHA1)
6.6.y | Not found
Note: The patch differs from the upstream commit:
---
1: 4b7c3f6d04bd5 ! 1: 60f5174104fc8 KVM: x86: Make x2APIC ID 100% readonly
@@ Commit message
Message-ID: <[email protected]>
+ (cherry picked from commit 4b7c3f6d04bd53f2e5b228b6821fb8f5d1ba3071)
+ Signed-off-by: James Houghton <[email protected]>
## arch/x86/kvm/lapic.c ##
@@ arch/x86/kvm/lapic.c: static void kvm_recalculate_logical_map(struct kvm_apic_map *new,
---
Results of testing on various branches:
| Branch | Patch Apply | Build Test | |---------------------------|-------------|------------| | stable/linux-6.6.y | Success | Failed |
Build Errors:
Build error for stable/linux-6.6.y:
ssh: connect to host 192.168.1.58 port 22: No route to host
Re: [PATCH 6.6.y 1/2] KVM: x86: Make x2APIC ID 100% readonly
In reply to James HoughtonQuoted 53 lines · James Houghton
From: Sean Christopherson <[email protected]>
Ignore the userspace provided x2APIC ID when fixing up APIC state for
KVM_SET_LAPIC, i.e. make the x2APIC fully readonly in KVM. Commita92e2543d6a8("KVM: x86: use hardware-compatible format for APIC ID register"), which added the fixup, didn't intend to allow userspace to modify the x2APIC ID. In fact, that commit is when KVM first started treating the x2APIC ID as readonly, apparently to fix some race:static inline u32
kvm_apic_id(struct kvm_lapic *apic){(quoted diff) +7
-1- return (kvm_lapic_get_reg(apic, APIC_ID) >> 24) & 0xff; + /* To avoid a race between apic_base and following APIC_ID update when + * switching to x2apic_mode, the x2apic mode returns initial x2apic id. + */ + if (apic_x2apic_mode(apic)) + return apic->vcpu->vcpu_id; + + return kvm_lapic_get_reg(apic, APIC_ID) >> 24; }Furthermore, KVM doesn't support delivering interrupts to vCPUs with a modified x2APIC ID, but KVM *does* return the modified value on a guest RDMSR and for
KVM_GET_LAPIC. I.e. no remotely sane setup can actually work with a modified x2APIC ID.Making the x2APIC ID fully readonly fixes a WARN in KVM's optimized map calculation, which expects the LDR to align with the x2APIC ID.
WARNING: CPU: 2 PID: 958 at arch/x86/kvm/lapic.c:331 kvm_recalculate_apic_map+0x609/0xa00 [kvm] CPU: 2 PID: 958 Comm: recalc_apic_map Not tainted 6.4.0-rc3-vanilla+ #35 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.2-1-1 04/01/2014 RIP: 0010:kvm_recalculate_apic_map+0x609/0xa00 [kvm] Call Trace: <TASK> kvm_apic_set_state+0x1cf/0x5b0 [kvm] kvm_arch_vcpu_ioctl+0x1806/0x2100 [kvm] kvm_vcpu_ioctl+0x663/0x8a0 [kvm] __x64_sys_ioctl+0xb8/0xf0 do_syscall_64+0x56/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7fade8b9dd6fUnfortunately, the WARN can still trigger for other CPUs than the current one by racing against
KVM_SET_LAPIC, so remove it completely.Reported-by Michal Luczaj <[email protected]>Reported-by Haoyu Wu <[email protected]>Reported-by [email protected]Signed-off-by Sean Christopherson <[email protected]>
Quoted 3 lines
Message-ID: <[email protected]>
Signed-off-by Paolo Bonzini <[email protected]>(cherry picked from commit 4b7c3f6d04bd53f2e5b228b6821fb8f5d1ba3071)
FWIW, for upstream LTS backports, the upstream commit information is usually place at the top, before the original commit's changelog begins, and the blurb explicitly calls out that it's an upstream commit. I personally like this style:
[ Upstream commit 4b7c3f6d04bd53f2e5b228b6821fb8f5d1ba3071 ]
as I find it easy to visually parse/separate from the original changelog.
Quoted 2 lines
Signed-off-by James Houghton <[email protected]>---
Re: [PATCH 6.6.y 1/2] KVM: x86: Make x2APIC ID 100% readonly
Quoted 58 lines · Sean Christopherson
Quoted 53 lines · James Houghton
From: Sean Christopherson <[email protected]>
Ignore the userspace provided x2APIC ID when fixing up APIC state for
KVM_SET_LAPIC, i.e. make the x2APIC fully readonly in KVM. Commita92e2543d6a8("KVM: x86: use hardware-compatible format for APIC ID register"), which added the fixup, didn't intend to allow userspace to modify the x2APIC ID. In fact, that commit is when KVM first started treating the x2APIC ID as readonly, apparently to fix some race:static inline u32
kvm_apic_id(struct kvm_lapic *apic){(quoted diff) +7
-1- return (kvm_lapic_get_reg(apic, APIC_ID) >> 24) & 0xff; + /* To avoid a race between apic_base and following APIC_ID update when + * switching to x2apic_mode, the x2apic mode returns initial x2apic id. + */ + if (apic_x2apic_mode(apic)) + return apic->vcpu->vcpu_id; + + return kvm_lapic_get_reg(apic, APIC_ID) >> 24; }Furthermore, KVM doesn't support delivering interrupts to vCPUs with a modified x2APIC ID, but KVM *does* return the modified value on a guest RDMSR and for
KVM_GET_LAPIC. I.e. no remotely sane setup can actually work with a modified x2APIC ID.Making the x2APIC ID fully readonly fixes a WARN in KVM's optimized map calculation, which expects the LDR to align with the x2APIC ID.
WARNING: CPU: 2 PID: 958 at arch/x86/kvm/lapic.c:331 kvm_recalculate_apic_map+0x609/0xa00 [kvm] CPU: 2 PID: 958 Comm: recalc_apic_map Not tainted 6.4.0-rc3-vanilla+ #35 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.2-1-1 04/01/2014 RIP: 0010:kvm_recalculate_apic_map+0x609/0xa00 [kvm] Call Trace: <TASK> kvm_apic_set_state+0x1cf/0x5b0 [kvm] kvm_arch_vcpu_ioctl+0x1806/0x2100 [kvm] kvm_vcpu_ioctl+0x663/0x8a0 [kvm] __x64_sys_ioctl+0xb8/0xf0 do_syscall_64+0x56/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7fade8b9dd6fUnfortunately, the WARN can still trigger for other CPUs than the current one by racing against
KVM_SET_LAPIC, so remove it completely.Reported-by Michal Luczaj <[email protected]>Reported-by Haoyu Wu <[email protected]>Reported-by [email protected]Signed-off-by Sean Christopherson <[email protected]>Quoted 3 lines
Message-ID: <[email protected]>
Signed-off-by Paolo Bonzini <[email protected]>(cherry picked from commit 4b7c3f6d04bd53f2e5b228b6821fb8f5d1ba3071)
Quoted 7 lines
FWIW, for upstream LTS backports, the upstream commit information is usually place at the top, before the original commit's changelog begins, and the blurb explicitly calls out that it's an upstream commit. I personally like this style:
[ Upstream commit
4b7c3f6d04bd53f2e5b228b6821fb8f5d1ba3071]as I find it easy to visually parse/separate from the original changelog.
Yes, we prefer it at the top as our tools take it that way, BUT we can handle it in the footer down here and our tools will rewrite it to the proper place, so it's not a big deal.
The only problem is when it's not included at all.
thanks,
greg k-h
PATCH 2/2 KVM: x86: Re-split x2APIC ICR into ICR+ICR2 for AMD (x2AVIC)
In reply to James HoughtonFrom: Sean Christopherson <[email protected]>
Re-introduce the "split" x2APIC ICR storage that KVM used prior to Intel's IPI virtualization support, but only for AMD. While not stated anywhere in the APM, despite stating the ICR is a single 64-bit register, AMD CPUs store the 64-bit ICR as two separate 32-bit values in ICR and ICR2. When IPI virtualization (IPIv on Intel, all AVIC flavors on AMD) is enabled, KVM needs to match CPU behavior as some ICR ICR writes will be handled by the CPU, not by KVM.
Add a kvm_x86_ops knob to control the underlying format used by the CPU to store the x2APIC ICR, and tune it to AMD vs. Intel regardless of whether or not x2AVIC is enabled. If KVM is handling all ICR writes, the storage format for x2APIC mode doesn't matter, and having the behavior follow AMD versus Intel will provide better test coverage and ease debugging.
[JH: fixed conflict with vmx_x86_ops reshuffle due to missing commit 5f18c642ff7e2]
--- arch/x86/include/asm/kvm_host.h | 2 ++ arch/x86/kvm/lapic.c | 42 +++++++++++++++++++++++---------- arch/x86/kvm/svm/svm.c | 2 ++ arch/x86/kvm/vmx/vmx.c | 2 ++ 4 files changed, 36 insertions(+), 12 deletions(-)
arch/x86/include/asm/kvm_host.h +2 -0
@@ -1650,6 +1650,8 @@ struct kvm_x86_ops {void (*enable_irq_window)(struct kvm_vcpu *vcpu);void (*update_cr8_intercept)(struct kvm_vcpu *vcpu,int tpr,int irr);bool (*check_apicv_inhibit_reasons)(enum kvm_apicv_inhibit reason); + +const bool x2apic_icr_is_split;const unsigned long required_apicv_inhibits;bool allow_apicv_in_x2apic_without_x2apic_virtualization;void (*refresh_apicv_exec_ctrl)(struct kvm_vcpu *vcpu);
arch/x86/kvm/lapic.c +30 -12
73 lines not on this page · raw message
arch/x86/kvm/svm/svm.c +2 -0
@@ -5014,6 +5014,8 @@ static struct kvm_x86_ops svm_x86_ops __initdata = { .enable_nmi_window = svm_enable_nmi_window, .enable_irq_window = svm_enable_irq_window, .update_cr8_intercept = svm_update_cr8_intercept, + + .x2apic_icr_is_split = true, .set_virtual_apic_mode = avic_refresh_virtual_apic_mode, .refresh_apicv_exec_ctrl = avic_refresh_apicv_exec_ctrl, .apicv_post_state_restore = avic_apicv_post_state_restore,
arch/x86/kvm/vmx/vmx.c +2 -0
@@ -8323,6 +8323,8 @@ static struct kvm_x86_ops vmx_x86_ops __initdata = { .enable_nmi_window = vmx_enable_nmi_window, .enable_irq_window = vmx_enable_irq_window, .update_cr8_intercept = vmx_update_cr8_intercept, + + .x2apic_icr_is_split = false, .set_virtual_apic_mode = vmx_set_virtual_apic_mode, .set_apic_access_page_addr = vmx_set_apic_access_page_addr, .refresh_apicv_exec_ctrl = vmx_refresh_apicv_exec_ctrl,
Signature · 1 line
2.48.1.362.g079036d154-goog
Re: [PATCH 6.6.y 2/2] KVM: x86: Re-split x2APIC ICR into ICR+ICR2 for AMD (x2AVIC)
Quoted 16 lines · James Houghton
From: Sean Christopherson <[email protected]>
Re-introduce the "split" x2APIC ICR storage that KVM used prior to Intel's IPI virtualization support, but only for AMD. While not stated anywhere in the APM, despite stating the ICR is a single 64-bit register, AMD CPUs store the 64-bit ICR as two separate 32-bit values in ICR and ICR2. When IPI virtualization (IPIv on Intel, all AVIC flavors on AMD) is enabled, KVM needs to match CPU behavior as some ICR ICR writes will be handled by the CPU, not by KVM.
Add a
kvm_x86_opsknob to control the underlying format used by the CPU to store the x2APIC ICR, and tune it to AMD vs. Intel regardless of whether or not x2AVIC is enabled. If KVM is handling all ICR writes, the storage format for x2APIC mode doesn't matter, and having the behavior follow AMD versus Intel will provide better test coverage and ease debugging.
Quoted 7 lines
Fixes 4d1d7942e36a ("KVM: SVM: Introduce logic to (de)activate x2AVIC mode")Cc Maxim Levitsky <[email protected]>Cc Suravee Suthikulpanit <[email protected]>Signed-off-by Sean Christopherson <[email protected]>(cherry picked from commit 73b42dc69be8564d4951a14d00f827929fe5ef79)
Same nit on the upstream info here. Don't think it warrants a v2? (that's a question for Sasha and/or Greg).