On Fri, Jul 19, 2024, Sean Christopherson wrote: > I made the mistake of expanding my testing to run with and without AVIC > enabled, and to my surprise (wow, sarcasm), x2AVIC failed hard on the > xapic_state_test due to ICR issues. > > AFAICT, the issue is that AMD splits the 64-bit ICR into the legacy ICR > and ICR2 fields when storing the ICR in the vAPIC (apparently "it's a > single 64-bit register" is open to intepretation). Aside from causing > the selftest failure and potential live migration issues, botching the > format is quite bad, as KVM will mishandle incomplete virtualized IPIs, > e.g. generate IRQs to the wrong vCPU, drop IRQs, etc. > > Patch 1 fixes are rather annoying wart where the xapic_state *deliberately* > skips reserved bit tests to work around a KVM bug. *sigh* > > I couldn't find anything definitive in the APM, my findings are based on > testing on Genoa. > > Sean Christopherson (8): > KVM: x86: Enforce x2APIC's must-be-zero reserved ICR bits > KVM: x86: Move x2APIC ICR helper above kvm_apic_write_nodecode() > KVM: x86: Re-split x2APIC ICR into ICR+ICR2 for AMD (x2AVIC) > KVM: selftests: Open code vcpu_run() equivalent in guest_printf test > KVM: selftests: Report unhandled exceptions on x86 as regular guest > asserts > KVM: selftests: Add x86 helpers to play nice with x2APIC MSR #GPs > KVM: selftests: Skip ICR.BUSY test in xapic_state_test if x2APIC is > enabled > KVM: selftests: Test x2APIC ICR reserved bits Gah, ignore this version, I managed to hit send in the middle of a rebase and left off two patches. I'll post a v2 to minimize confusion.
