Re: [PATCH 1/1] KVM: x86: lapic: update apic_base and APIC ID together

[Dongli Zhang <dongli.zhang@oracle.com>]

On Tue, Aug 18, 2026 10:48:18PM -0700, Chao Gao wrote:
> On Tue, Aug 18, 2026 at 04:42:38PM -0700, Dongli Zhang wrote:
>>The commit b2849bec936b ("KVM: VMX: Update SVI during runtime APICv
>>activation") resolved the loss of EOI issue when apicv is activated after
>>being inhibited at runtime. However, it does not resolve the cause of the
>>runtime apicv inhibition.
> 
> Why lead with commit b2849bec936b? APICv is inhibited and re-activated for
> other reasons regardless of the race below, so that fix is needed anyway. The
> race is at best an orthogonal issue.

I was trying to explain the history behind the change.

> 
>>
>>The inhibition occurs because apic_base and the APIC ID are not updated
>>together.
>>
>>Although commit 052c3b99cbc8 ("KVM: x86: Reinitialize xAPIC ID when
>>userspace forces x2APIC => xAPIC") reinitializes the xAPIC ID to the
>>vCPU ID when userspace forces the APIC to transition directly from x2APIC
>>to xAPIC mode, the updates are not performed in a single transaction.
>>
>>If another thread calls kvm_recalculate_apic_map() during the window
>>between updating apic_base and the APIC ID, kvm_recalculate_phys_map() may
>>set xapic_id_mismatch and temporarily inhibit APICv.
> 
> So the goal is to avoid a _transient_ APICv inhibit in a corner case?

Yes.

> 
> If so, please spell out in the changelog why it's worth fixing.

Regarding "why it's worth fixing," the primary motivation is to avoid
unnecessary APICv inhibition and reactivation, ideally throughout the entire
lifecycle of a VM.

Another motivation came from reading the AMD SDM. As mentioned in commit
052c3b99cbc8 ("KVM: x86: Reinitialize xAPIC ID when
userspace forces x2APIC => xAPIC"), when x2APIC is enabled or disabled, the APIC
ID is expected to change according to the APIC mode. On real hardware, I assume
this operation is performed atomically in a single transaction when the APIC
mode is changed. This change makes the behavior more consistent with the SDM,
with APIC map recalculation being the major user-visible impact.

I would leave it to the maintainers and reviewers to decide whether this change
is needed. From a production perspective, zero APICv inhibition is appreciated.

Thank you very much!

Dongli Zhang