From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.openvz.org (unknown [69.168.225.77]) by lore.virtuozzo.com (Postfix) with ESMTPS id AF8C78015B for ; Thu, 24 Sep 2026 17:17:03 +0000 (UTC) Received: from mail.openvz.org (localhost [127.0.0.1]) by mail.openvz.org (8.14.4/8.14.4) with ESMTP id 68OHFkY8018229; Thu, 24 Sep 2026 20:15:47 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 68OHFkY8018229 Authentication-Results: mail.openvz.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=virtuozzo.com header.i=@virtuozzo.com header.b="VdVSzCf0" Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by mail.openvz.org (8.14.4/8.14.4) with ESMTP id 68OHFiox018217 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=FAIL) for ; Thu, 24 Sep 2026 20:15:44 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 68OHFiox018217 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-490a767c7dcso369005e9.2 for ; Thu, 24 Sep 2026 10:15:44 -0700 (PDT) X-Forwarded-Encrypted: i=2; AKwUvBx1Hx6qdcjYmGsekmgv34mKUlUdiiVLLUz8pT1jyHefJUAXg2kSKD1TwyM8ldm25U9WHDgGRg==@openvz.org X-Gm-Message-State: AFuF++lM4xZeHO6+i7wgb/WETHIYdE5ZbncK5XedrYEBdWMBlAlxg/hY yDDoGBflNX89jxrag8o1T6QXykfYKNfzzmE+KVZUwcqJnokCPrpAP/6lA5RmeAb52za80Fv05r3 6O1e0DD5Fki5YNzAQm+7m9Sh4vsdZtdhP+hIHP7oUv2UhmMZAQ6sw+Q== X-Gm-Gg: AYBFou25/s6WNuoXlansEkL1phkuW+mpFwOoOJZSw0Bw6Rk2ZJlEv43PZBgux1lHV1T YKBGBxi1LMSvTbcEbOS2or5obLnxslfXdLw2I54oISpw8X5+pO4uC3B8IS68HI48SK6XJW+orn0 a8VN0htt48dU1cxMaIh/cKhdXSNDoQujxOJFk7luQ3RgmZr1P0hm8pntPduQz167UBDgHIE5MGr G83Ok8iqr0BwWaRItLMP2sjUCQl21GB+ZV26rNG1OIz/qBkgU2RTSSD7gAj0lBVg2Sp3NPZ2DF+ p5xPY3kCMGwZ1+M9JfSMVzEnYeIXCYIV0iTQW0uYz32jh2Uz5sBdxqAPRj74b9mGxRxOOeiTWk8 szj5agVS0Ipsa8fxGmg== X-Received: by 2002:a05:600c:4e55:b0:49c:fc6c:be03 with SMTP id 5b1f17b1804b1-49fe66fc5ffmr52835905e9.26.1790270144523; Thu, 24 Sep 2026 10:15:44 -0700 (PDT) X-Received: by 2002:a05:600c:4e55:b0:49c:fc6c:be03 with SMTP id 5b1f17b1804b1-49fe66fc5ffmr52835285e9.26.1790270144012; Thu, 24 Sep 2026 10:15:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1790270144; cv=none; d=google.com; s=arc-20260327; b=E9Su1+LA1rsc7+7Mi7pj1o36iz9dNZNrrdwWVCiDXB0cARREz0L8muGByuGrhOkDrG DWp8xpBv8hu8OxECC65jvAUclg14zE2k1/M1skcCTdKTaZvxIgtSH7NXLZWsgH1It+yt e0w1HX5VOcxtUvqechEjVzBaG9rTw+tCnTLfUQ0tS6gLrNZZisOjclYPVXGqL0OACMEo BremihAHT1r0HccnX3mb0pyN8sHWQuikBJ/c0L9gA5SqgPvuFGur9be6RUqN3huX48/U Cj7pobVzSnz9VpWopICSS4KSzON1XFzBdMe5CYbXzRdtOcpg2+ehcp6Ji91cMh+YsjF1 Ww3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:dkim-signature; bh=JvZm9uQk7ANg5pkP76JFUEn+ISlqItSaw6DnwZTCJ34=; fh=CYcqLjLSfZMYXQrAlD49Y7qij+C3kWyN/pW02euNCoQ=; b=AQ3rS9vzDpb61kABS1hmOMsYH5aX/S6czO0OcSX2YRAz1rvdxCrXNyDcDVsT/1ymRX hqcGYXxMW6M0cQWFULM0Ewu6HG5kbmc+1nvGboEM7FfQlaXaucE9kjDqOm+6A0HS/Vqf eydHdXqGOpMLoD6427gYDhiIhyre/r6qZUyZZuTAOZNxhCnQ4u6hvBBmi6W0mklCeD4M rk4hmdXUK0redqTJkoYM8EEofC0HHPCFzeaTlow8a6PBijCDHhsp6kK8IYFMX++4vw2R 8dvVxsES4YSRsrby/MaQR45CHbiigItN3OIcq/3IaU/vFU7oB2so844wfXIEbw1dP4LB AqbA==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@virtuozzo.com header.s=relay header.b=VdVSzCf0; spf=pass (google.com: domain of khorenko@virtuozzo.com designates 130.117.225.111 as permitted sender) smtp.mailfrom=khorenko@virtuozzo.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=virtuozzo.com Received: from relay.virtuozzo.com (relay.virtuozzo.com. [130.117.225.111]) by mx.google.com with ESMTPS id ffacd0b85a97d-4887a8817ffsi323540f8f.453.2026.09.24.10.15.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Sep 2026 10:15:43 -0700 (PDT) Received-SPF: pass (google.com: domain of khorenko@virtuozzo.com designates 130.117.225.111 as permitted sender) client-ip=130.117.225.111; Authentication-Results: mx.google.com; dkim=pass header.i=@virtuozzo.com header.s=relay header.b=VdVSzCf0; spf=pass (google.com: domain of khorenko@virtuozzo.com designates 130.117.225.111 as permitted sender) smtp.mailfrom=khorenko@virtuozzo.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=virtuozzo.com DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=virtuozzo.com; s=relay; h=Message-Id:Content-Type:MIME-Version:Subject:Date :From; bh=JvZm9uQk7ANg5pkP76JFUEn+ISlqItSaw6DnwZTCJ34=; b=VdVSzCf0uHnIkrWlts0 SJw96BQhX2a4jeCpVDu8+DgV8EJyc2SMB1MTRAPKKFrpUo73FgZbwwVLLB0cSS6k8O43BGNho0VTF E0BjTCMdVls4xi59ID6CFd4dgxSmU9wWGkKhUzV1xwsjtbzUiNq1Qj4KXAIGElTBc1qk6o0yfJTDf g26QORiKbWm92AhLVoeDUy9a68gDeKHti8Vlbl+gxbHgPiySAN3ylzwVIukU8po4wMQbKBBjQCZE6 ZBAJMwot50KxiQP5fMBXjBuj7Pgus5a6hzOSnuECSNXuV1xFGxPhakOSDFyJoNVctTROSsVJm5BAs R/bKar8jWfnR1cg==; Received: from ch-demo-asa.virtuozzo.com ([130.117.225.8] helo=f0.sw.ru) by relay.virtuozzo.com with esmtp (Exim 4.96) (envelope-from ) id 1x9mzw-002HCZ-28; Thu, 24 Sep 2026 19:15:40 +0200 From: Konstantin Khorenko Date: Thu, 24 Sep 2026 19:15:37 +0200 MIME-Version: 1.0 Message-Id: <20260924-b4-prep-kvm-v2-1-ad742e43266c@virtuozzo.com> References: <20260924-b4-prep-kvm-v2-0-ad742e43266c@virtuozzo.com> In-Reply-To: <20260924-b4-prep-kvm-v2-0-ad742e43266c@virtuozzo.com> To: "Denis V. Lunev" , devel@openvz.org, Konstantin Khorenko X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=6818; i=khorenko@virtuozzo.com; h=from:subject:message-id; bh=cLEeMZJpmnQ3lQcCm99/BSRgwVt1dnncn3PBQy5iOwI=; b=owEBbQKS/ZANAwAKAVGWCkf5YVwqAcsmYgBqtVq+6BwFn7o/Wmh9zIsfFYP5Cnp/z2Iykvceb 3Pds6T+F3SJAjMEAAEKAB0WIQRWD23IPcXT0GO9CCxRlgpH+WFcKgUCarVavgAKCRBRlgpH+WFc Kh3SD/0WREctZeZ/QLctUQgdX7AVMy4OWElAh47uvfVutNELr2LTwTH7dagqnFGYP0sI6gUzgFy 0HeM0lQccU0TH08BhtFKkVN7qfDvsa3ViB1bNkrqOoUq/5WLziDnO3z894YfeibIvD7vsS7B+ss ZngYw9y++zI8jn6Yz1KYQAqsYcQs7MjUfCYLaK3yDAJcTgxrmvEanOxe8JUferbLC4+kejklzUF Pn9Jr8HHKN3Bgl5IM/+voMUCGHRjtvQFna9H9vxa4gk6Xfvuk/wzBRQJdosTC8Gm/yvTN10QjTw Z3H6zaszi550plO5Ipej9BeMocdAJdhzOiemgQ4XCPrhvlAv2dUuUwZqzDox4byAuEUJ/AEUW5j S7OElskssHk0Nh+Rba9Sm+rJFx5tpUN6/oTQmhThNUueUl/qYiQ3GTCeh5/QRgNrz6S94FCTH45 /5jlQNgU/h7EsIYMnTLxrX0jYIfO2Q1VqGjPUoamNJMsB7g28QTVT7tI7XJO0RoaBHNalpj7YOh 76CKMvBaqsESevF+MRNkOCoqETgiFA4Gmi0HdXCrPIH+hpvYAW0+NpXweBKLOpFxUC8yAfF8FR9 +VZHbWttxCsYRJ9kWRSn3M0KPpOIBaeBcVGOEmtK3frMy9SEI7J3HpaD54siOoSuFKQ4DHQg4Zn H99OKoK3PVOs1DA== X-Developer-Key: i=khorenko@virtuozzo.com; a=openpgp; fpr=560F6DC83DC5D3D063BD082C51960A47F9615C2A X-OZ-Fwd: true Subject: [Devel] [PATCH hci-8.1 v2 1/2] ms/KVM: VMX: Update SVI during runtime APICv activation X-BeenThere: devel@openvz.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OpenVZ development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: devel-bounces@openvz.org Errors-To: devel-bounces@openvz.org From: Dongli Zhang The APICv (apic->apicv_active) can be activated or deactivated at runtime, for instance, because of APICv inhibit reasons. Intel VMX employs different mechanisms to virtualize LAPIC based on whether APICv is active. When APICv is activated at runtime, GUEST_INTR_STATUS is used to configure and report the current pending IRR and ISR states. Unless a specific vector is explicitly included in EOI_EXIT_BITMAP, its EOI will not be trapped to KVM. Intel VMX automatically clears the corresponding ISR bit based on the GUEST_INTR_STATUS.SVI field. When APICv is deactivated at runtime, the VM_ENTRY_INTR_INFO_FIELD is used to specify the next interrupt vector to invoke upon VM-entry. The VMX IDT_VECTORING_INFO_FIELD is used to report un-invoked vectors on VM-exit. EOIs are always trapped to KVM, so the software can manually clear pending ISR bits. There are scenarios where, with APICv activated at runtime, a guest-issued EOI may not be able to clear the pending ISR bit. Taking vector 236 as an example, here is one scenario. 1. Suppose APICv is inactive. Vector 236 is pending in the IRR. 2. To handle KVM_REQ_EVENT, KVM moves vector 236 from the IRR to the ISR, and configures the VM_ENTRY_INTR_INFO_FIELD via vmx_inject_irq(). 3. After VM-entry, vector 236 is invoked through the guest IDT. At this point, the data in VM_ENTRY_INTR_INFO_FIELD is no longer valid. The guest interrupt handler for vector 236 is invoked. 4. Suppose a VM exit occurs very early in the guest interrupt handler, before the EOI is issued. 5. Nothing is reported through the IDT_VECTORING_INFO_FIELD because vector 236 has already been invoked in the guest. 6. Now, suppose APICv is activated. Before the next VM-entry, KVM calls kvm_vcpu_update_apicv() to activate APICv. 7. Unfortunately, GUEST_INTR_STATUS.SVI is not configured, although vector 236 is still pending in the ISR. 8. After VM-entry, the guest finally issues the EOI for vector 236. However, because SVI is not configured, vector 236 is not cleared. 9. ISR is stalled forever on vector 236. Here is another scenario. 1. Suppose APICv is inactive. Vector 236 is pending in the IRR. 2. To handle KVM_REQ_EVENT, KVM moves vector 236 from the IRR to the ISR, and configures the VM_ENTRY_INTR_INFO_FIELD via vmx_inject_irq(). 3. VM-exit occurs immediately after the next VM-entry. The vector 236 is not invoked through the guest IDT. Instead, it is saved to the IDT_VECTORING_INFO_FIELD during the VM-exit. 4. KVM calls kvm_queue_interrupt() to re-queue the un-invoked vector 236 into vcpu->arch.interrupt. A KVM_REQ_EVENT is requested. 5. Now, suppose APICv is activated. Before the next VM-entry, KVM calls kvm_vcpu_update_apicv() to activate APICv. 6. Although APICv is now active, KVM still uses the legacy VM_ENTRY_INTR_INFO_FIELD to re-inject vector 236. GUEST_INTR_STATUS.SVI is not configured. 7. After the next VM-entry, vector 236 is invoked through the guest IDT. Finally, an EOI occurs. However, due to the lack of GUEST_INTR_STATUS.SVI configuration, vector 236 is not cleared from the ISR. 8. ISR is stalled forever on vector 236. Using QEMU as an example, vector 236 is stuck in ISR forever. (qemu) info lapic 1 dumping local APIC state for CPU 1 LVT0 0x00010700 active-hi edge masked ExtINT (vec 0) LVT1 0x00010400 active-hi edge masked NMI LVTPC 0x00000400 active-hi edge NMI LVTERR 0x000000fe active-hi edge Fixed (vec 254) LVTTHMR 0x00010000 active-hi edge masked Fixed (vec 0) LVTT 0x000400ec active-hi edge tsc-deadline Fixed (vec 236) Timer DCR=0x0 (divide by 2) initial_count = 0 current_count = 0 SPIV 0x000001ff APIC enabled, focus=off, spurious vec 255 ICR 0x000000fd physical edge de-assert no-shorthand ICR2 0x00000000 cpu 0 (X2APIC ID) ESR 0x00000000 ISR 236 IRR 37(level) 236 The issue isn't applicable to AMD SVM as KVM simply writes vmcb01 directly irrespective of whether L1 (vmcs01) or L2 (vmcb02) is active (unlike VMX, there is no need/cost to switch between VMCBs). In addition, APICV_INHIBIT_REASON_IRQWIN ensures AMD SVM AVIC is not activated until the last interrupt is EOI'd. Fix the bug by configuring Intel VMX GUEST_INTR_STATUS.SVI if APICv is activated at runtime. Signed-off-by: Dongli Zhang Reviewed-by: Chao Gao Link: https://patch.msgid.link/20251110063212.34902-1-dongli.zhang@oracle.com [sean: call out that SVM writes vmcb01 directly, tweak comment] Link: https://patch.msgid.link/20251205231913.441872-2-seanjc@google.com Signed-off-by: Sean Christopherson (cherry picked from commit b2849bec936be642b5420801f902337f2507648e) https://virtuozzo.atlassian.net/browse/VSTOR-147087 Feature: fix ms/kvm Signed-off-by: Denis V. Lunev --- arch/x86/kvm/vmx/vmx.c | 9 --------- arch/x86/kvm/x86.c | 7 +++++++ 2 files changed, 7 insertions(+), 9 deletions(-) diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index ddf8ee3f905b3..00ec973140374 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -6768,15 +6768,6 @@ void vmx_hwapic_isr_update(struct kvm_vcpu *vcpu, int max_isr) * VM-Exit, otherwise L1 with run with a stale SVI. */ if (is_guest_mode(vcpu)) { - /* - * KVM is supposed to forward intercepted L2 EOIs to L1 if VID - * is enabled in vmcs12; as above, the EOIs affect L2's vAPIC. - * Note, userspace can stuff state while L2 is active; assert - * that VID is disabled if and only if the vCPU is in KVM_RUN - * to avoid false positives if userspace is setting APIC state. - */ - WARN_ON_ONCE(vcpu->wants_to_run && - nested_cpu_has_vid(get_vmcs12(vcpu))); to_vmx(vcpu)->nested.update_vmcs01_hwapic_isr = true; return; } diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index dd1769ba8da4e..f7e4350b33403 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -10566,9 +10566,16 @@ void __kvm_vcpu_update_apicv(struct kvm_vcpu *vcpu) * pending. At the same time, KVM_REQ_EVENT may not be set as APICv was * still active when the interrupt got accepted. Make sure * kvm_check_and_inject_events() is called to check for that. + * + * Update SVI when APICv gets enabled, otherwise SVI won't reflect the + * highest bit in vISR and the next accelerated EOI in the guest won't + * be virtualized correctly (the CPU uses SVI to determine which vISR + * vector to clear). */ if (!apic->apicv_active) kvm_make_request(KVM_REQ_EVENT, vcpu); + else + kvm_apic_update_hwapic_isr(vcpu); out: preempt_enable(); -- 2.43.0 _______________________________________________ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel