On Tue, Aug 6, 2024 at 6:03 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > As is noted in [1], this issue is considered to be a microcode issue > > specific to SPR/EMR. > > I don't think we can claim that without a more explicit statement from Intel. > And I would really like Intel to clarify exactly what is going on, so that (a) > it can be properly documented and (b) we can implement a precise, targeted > workaround in KVM. It is not even clear to me why this patch has any effect at all, because PV EOI and APICv don't work together anyway: PV EOI requires apic->highest_isr_cache == -1 (see apic_sync_pv_eoi_to_guest()) but the cache is only set without APICv (see apic_set_isr()). Therefore, PV EOI should be basically a no-op with APICv in use. Second, there should be no need to disable APICv: as long as kvm_lapic_set_pv_eoi() is not called, the VP assist page can be enabled but PV EOI never triggered. That should be tested and, if it doesn't work, that's even more proof that we don't know what's going on. Also note that the PV EOI mechanism exists in the same way with KVM paravirtualization, even without Hyper-V enabled, and should trigger the same microcode issue. The only difference is that Windows does not know about it and, it seems, the issue does not trigger with Linux. Paolo > Chao? > > > Disable APICv when guest tries to enable VP Assist page only when it's > > running on those problematic CPU models. > > > > Link: https://bugzilla.kernel.org/show_bug.cgi?id=218267 [1] > > Signed-off-by: Eiichi Tsukata <eiichi.tsukata@xxxxxxxxxxx> > > --- >
