Received-SPF: pass (google.com: domain of linux-kernel+bounces-149168-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
From: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
To: kvm@vger.kernel.org
Cc: seanjc@google.com, pbonzini@redhat.com, linux-kernel@vger.kernel.org,
        joao.m.martins@oracle.com, boris.ostrovsky@oracle.com,
        suravee.suthikulpanit@amd.com, mlevitsk@redhat.com,
        alejandro.j.jimenez@oracle.com
Subject: [PATCH 0/2] APICv-related fixes for inhibits and tracepoint
Date: Wed, 17 Apr 2024 20:08:47 +0000
Message-Id: <20240417200849.971433-1-alejandro.j.jimenez@oracle.com>
Precedence: bulk
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Patch 1 fixes an issue when avic=0 (current default) where
APICV_INHIBIT_REASON_ABSENT remains set even after an in-kernel local APIC has
been created. e.g. tracing the inhibition tracepoint shows:

<...>-196432  [247] ..... 70380.628931: kvm_apicv_inhibit_changed: set reason=2, inhibits=0x4
<...>-196432  [247] ..... 70380.628941: kvm_apicv_inhibit_changed: set reason=0, inhibits=0x5

and the reason=2 inhibit is not removed after the local APIC is created.

Patch 2 modifies the wording in the pi_irte_update tracepoint to make it clear
that it is used by the posted interrupt implementation of both vendors. I have
reservations about modifying the tracepoint output and breaking user scripts,
but according to recent discussions tracepoints are not strictly a stable ABI,
so I'd consider this minor change to avoid confusion around this area.

Thank you,
Alejandro

Alejandro Jimenez (2):
  KVM: x86: Only set APICV_INHIBIT_REASON_ABSENT if APICv is enabled
  KVM: x86: Remove VT-d mention in posted interrupt tracepoint

 arch/x86/kvm/trace.h |  4 ++--
 arch/x86/kvm/x86.c   | 15 ++++++++++++++-
 2 files changed, 16 insertions(+), 3 deletions(-)


base-commit: 2d181d84af38146748042a6974c577fc46c3f1c3
-- 
2.39.3