diff options
author | Paolo Bonzini <pbonzini@redhat.com> | 2021-11-23 03:43:10 +0300 |
---|---|---|
committer | Paolo Bonzini <pbonzini@redhat.com> | 2021-11-30 11:52:39 +0300 |
commit | 37c4dbf337c5c2cdb24365ffae6ed70ac1e74d7a (patch) | |
tree | dec097ef78d23a930833dd41a25278f3865cc9d7 /tools/perf/scripts/python/export-to-sqlite.py | |
parent | 7e1901f6c86c896acff6609e0176f93f756d8b2a (diff) | |
download | linux-37c4dbf337c5c2cdb24365ffae6ed70ac1e74d7a.tar.xz |
KVM: x86: check PIR even for vCPUs with disabled APICv
The IRTE for an assigned device can trigger a POSTED_INTR_VECTOR even
if APICv is disabled on the vCPU that receives it. In that case, the
interrupt will just cause a vmexit and leave the ON bit set together
with the PIR bit corresponding to the interrupt.
Right now, the interrupt would not be delivered until APICv is re-enabled.
However, fixing this is just a matter of always doing the PIR->IRR
synchronization, even if the vCPU has temporarily disabled APICv.
This is not a problem for performance, or if anything it is an
improvement. First, in the common case where vcpu->arch.apicv_active is
true, one fewer check has to be performed. Second, static_call_cond will
elide the function call if APICv is not present or disabled. Finally,
in the case for AMD hardware we can remove the sync_pir_to_irr callback:
it is only needed for apic_has_interrupt_for_ppr, and that function
already has a fallback for !APICv.
Cc: stable@vger.kernel.org
Co-developed-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: David Matlack <dmatlack@google.com>
Message-Id: <20211123004311.2954158-4-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'tools/perf/scripts/python/export-to-sqlite.py')
0 files changed, 0 insertions, 0 deletions