KVM: x86: Retry APIC optimized map recalc if vCPU is added/enabled
authorSean Christopherson <seanjc@google.com>
Fri, 2 Jun 2023 23:32:49 +0000 (16:32 -0700)
committerSean Christopherson <seanjc@google.com>
Wed, 2 Aug 2023 23:48:44 +0000 (16:48 -0700)
commit41e90a69a49be2e3467e811ae8fdc17456af1b02
tree04ac76b2a17d204c81c1a780e46296ecc85e63b1
parent550ba57faa04042956079b8d09ec0f83bef8817f
KVM: x86: Retry APIC optimized map recalc if vCPU is added/enabled

Retry the optimized APIC map recalculation if an APIC-enabled vCPU shows
up between allocating the map and filling in the map data.  Conditionally
reschedule before retrying even though the number of vCPUs that can be
created is bounded by KVM.  Retrying a few thousand times isn't so slow
as to be hugely problematic, but it's not blazing fast either.

Reset xapic_id_mistach on each retry as a vCPU could change its xAPIC ID
between loops, but do NOT reset max_id.  The map size also factors in
whether or not a vCPU's local APIC is hardware-enabled, i.e. userspace
and/or the guest can theoretically keep KVM retrying indefinitely.  The
only downside is that KVM will allocate more memory than is strictly
necessary if the vCPU with the highest x2APIC ID disabled its APIC while
the recalculation was in-progress.

Refresh kvm->arch.apic_map_dirty to opportunistically change it from
DIRTY => UPDATE_IN_PROGRESS to avoid an unnecessary recalc from a
different task, i.e. if another task is waiting to attempt an update
(which is likely since a retry happens if and only if an update is
required).

Link: https://lore.kernel.org/r/20230602233250.1014316-3-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
arch/x86/kvm/lapic.c