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.
