Re: [PATCH v5 7/8] KVM: VMX: Update PID-pointer table entry when APIC ID is changed
From: Chao Gao
Date: Wed Feb 23 2022 - 00:59:54 EST
On Thu, Feb 03, 2022 at 08:22:13PM +0000, Sean Christopherson wrote:
>i.e. ACPI_NUMA gets priority and thus amd_numa_init() will never be reached if
>the NUMA topology is enumerated in the ACPI tables. Furthermore, the VMM would
>have to actually emulate an old AMD northbridge, which is also extremely unlikely.
>
>The odds of breaking a guest are further diminised given that KVM doesn't emulate
>the xAPIC ID => x2APIC ID hilarity on AMD CPUs and no one has complained.
>
>So, rather than tie this to IPI virtualization, I think we should either make
>the xAPIC ID read-only across the board,
We will go this way and defer the introduction of "xapic_id_writable" to the
emergence of the "crazy" use case.
Levitsky, we plan to revise your patch 13 "[PATCH RESEND 13/30] KVM: x86: lapic:
don't allow to change APIC ID when apic acceleration is enabled" to make xAPIC
ID read-only regardless of APICv/AVIC and include it into IPI virtualization
series (to eliminate the dependency on your AVIC series). Is it fine with you?
And does this patch 13 depend on other patches in your fixes?
>or if we want to hedge in case someone
>has a crazy use case, make the xAPIC ID read-only by default, add a module param
>to let userspace opt-in to a writable xAPIC ID, and report x2APIC and APICv as
>unsupported if the xAPIC ID is writable. E.g. rougly this, plus your AVIC patches
>if we want to hedge.