diff options
author | Sean Christopherson <seanjc@google.com> | 2025-06-11 15:46:04 -0700 |
---|---|---|
committer | Sean Christopherson <seanjc@google.com> | 2025-06-23 09:50:52 -0700 |
commit | b03500f03ea09f5fa31a408135c95c665542ff15 (patch) | |
tree | 87fd245699cdfcd9bd9625fc5b8f122a6b7e726c /scripts/lib/kdoc/kdoc_re.py | |
parent | b9e53f9ff4a88f01b22524878c9a381a6c5f65ff (diff) |
KVM: SVM: Generate GA log IRQs only if the associated vCPUs is blocking
Configure IRTEs to GA log interrupts for device posted IRQs that hit
non-running vCPUs if and only if the target vCPU is blocking, i.e.
actually needs a wake event. If the vCPU has exited to userspace or was
preempted, generating GA log entries and interrupts is wasteful and
unnecessary, as the vCPU will be re-loaded and/or scheduled back in
irrespective of the GA log notification (avic_ga_log_notifier() is just a
fancy wrapper for kvm_vcpu_wake_up()).
Use a should-be-zero bit in the vCPU's Physical APIC ID Table Entry to
track whether or not the vCPU's associated IRTEs are configured to
generate GA logs, but only set the synthetic bit in KVM's "cache", i.e.
never set the should-be-zero bit in tables that are used by hardware.
Use a synthetic bit instead of a dedicated boolean to minimize the odds
of messing up the locking, i.e. so that all the existing rules that apply
to avic_physical_id_entry for IS_RUNNING are reused verbatim for
GA_LOG_INTR.
Note, because KVM (by design) "puts" AVIC state in a "pre-blocking"
phase, using kvm_vcpu_is_blocking() to track the need for notifications
isn't a viable option.
Link: https://lore.kernel.org/r/20250611224604.313496-63-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Diffstat (limited to 'scripts/lib/kdoc/kdoc_re.py')
0 files changed, 0 insertions, 0 deletions