From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 824831DF261 for ; Sun, 11 Oct 2026 00:13:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791677594; cv=none; b=RiRS0Xs8L0V/OCL3fFRNgqFip+B9/v0W7AsO7IN6RUNL1r3igRbw2rYmsC64s34G0cjAIIgkj/vgarTErJY86IjBfsG1wPKUHt93f/LBH44HlQZVtgyxaJJz8Uh91tMPYuJlwd8V5ymGOqDLBIgIajTC8jd00k2OmWu2WTzq9Qw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791677594; c=relaxed/simple; bh=wuy49R4ZylKDMuxAAgyj1Iw846aJVkbP4fABqxiluSE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=BnjUrX6fR8gC8LrPnjXjA8EaBUIxLcXz11g6I5IWnyiRU/suy1HPVt4ZUw+IbTgCovpvxJXuSKxb3v3lnEXP7Q/PZAtOK6cn2jnWOBocMvjlg6A+EVH/kUmFU8PSgUC6t2KaRUtwyDeJzcSPL475/vYQEsWqUYT4So85MqBlE9Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=dhW+rXz8; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="dhW+rXz8" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1791677592; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=cve7xkl3kcebsEhdTM2PWYNdngkA+VZ+2cPZO3+8JFw=; b=dhW+rXz87Fb9EAiEW2dpvBaDL3HtFb2Yilb/P9ZmE8b5iekHOzdnbFTFleo2/+0GANETTc bXKwmcsvNIUnSfnDpsxxEtFS0IE0C4TknhCPLR6+qIiblE7DtGWmzCJBjhUCA/gyl/xYbk Wz4ZJkPpUKcjXL15APYTt5H0wqTBNfg= Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-19-zlGe1gDlOFaQ0fSP_sNEpA-1; Sun, 11 Oct 2026 00:13:08 +0000 X-MC-Unique: zlGe1gDlOFaQ0fSP_sNEpA-1 X-Mimecast-MFC-AGG-ID: zlGe1gDlOFaQ0fSP_sNEpA_1791677587 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id F0BA919541A1; Sun, 11 Oct 2026 00:13:06 +0000 (UTC) Received: from mlevitsk-thinkpadt14gen3.ibmmarkh.csb (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id E7FA11800351; Sun, 11 Oct 2026 00:13:05 +0000 (UTC) From: Maxim Levitsky To: kvm@vger.kernel.org Cc: Sean Christopherson , x86@kernel.org, linux-kernel@vger.kernel.org, Paolo Bonzini , Maxim Levitsky Subject: [PATCH v2 1/2] KVM: nVMX: don't check PIR.ON when processing nested posted interrupts Date: Sat, 10 Oct 2026 20:13:02 -0400 Message-ID: <20261011001303.723721-2-mlevitsk@redhat.com> In-Reply-To: <20261011001303.723721-1-mlevitsk@redhat.com> References: <20261011001303.723721-1-mlevitsk@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 Despite the suggestion to test and set the PIR.ON and avoid sending a posted interrupt if it is already set, there is no requirement for this bit to be set for posted interrupt processing to happen when the target CPU receives the posted notification vector. See section 30.6 POSTED-INTERRUPT PROCESSING: "The processor clears the outstanding-notification bit in the posted-interrupt descriptor. This is done atomically so as to leave the remainder of the descriptor unmodified (e.g., with a locked AND operation)." Apparently Windows' implementation of APICv does exactly this: it sets bits in PIR, without bothering to also set the PIR.ON. Signed-off-by: Maxim Levitsky --- arch/x86/kvm/vmx/nested.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c index 151873407abd..8504a2c12d9d 100644 --- a/arch/x86/kvm/vmx/nested.c +++ b/arch/x86/kvm/vmx/nested.c @@ -4041,8 +4041,16 @@ static int vmx_complete_nested_posted_interrupt(struct kvm_vcpu *vcpu) vmx->nested.pi_pending = false; - if (!pi_test_and_clear_on(vmx->nested.pi_desc)) - return 0; + /* + * Don't test the value of PID.ON. + * It is valid to trigger a posted interrupt without setting this bit + */ + pi_clear_on(vmx->nested.pi_desc); + + /* Ensure that guests sees the change to PIR.ON before KVM harvest + * the PIR + */ + __smp_mb__after_atomic(); max_irr = pi_find_highest_vector(vmx->nested.pi_desc); if (max_irr > 0) { @@ -4209,8 +4217,7 @@ static bool vmx_has_nested_events(struct kvm_vcpu *vcpu, bool for_injection) if ((max_irr & 0xf0) > (vppr & 0xf0)) return true; - if (vmx->nested.pi_pending && vmx->nested.pi_desc && - pi_test_on(vmx->nested.pi_desc)) { + if (vmx->nested.pi_pending && vmx->nested.pi_desc) { max_irr = pi_find_highest_vector(vmx->nested.pi_desc); if (max_irr > 0 && (max_irr & 0xf0) > (vppr & 0xf0)) return true; -- 2.54.0