On Wed, Jun 18, 2025, Naveen N Rao wrote: > On Tue, Jun 17, 2025 at 09:10:10AM -0700, Sean Christopherson wrote: > > Hmm, yes and no. I completely agree that clearing apicv_active in avic.c > > is all kinds of gross, but clearing apic->apicv_active in lapic.c to handle > > this particular scenario is just as problematic, because then > > avic_init_backing_page() would need to check kvm_vcpu_apicv_active() to > > determine whether or not to allocate the backing page. In a way, that's > > even worse, because setting apic->apicv_active by default is purely an > > optimization, i.e. leaving it %false _should_ work as well, it would just > > be suboptimal. But if AVIC were to key off apic->apicv_active, that could > > lead to KVM incorrectly skipping allocation of the AVIC backing page. > > I understand your concern about key'ing off apic->apicv_active - that > would definitely require a thorough audit and does add complexity to > this. > > However, as far as I can see, after your current series, we no longer > maintain a pointer to the AVIC backing page, but instead rely on the > lapic-allocated page. > > Were you referring to the APIC access page though? Gah, yes. I was hyper aware of the two things when typing up the response, and still managed to screw up. *sigh* :-) > That is behind kvm_apicv_activated() today, which looks to be problematic if > there are inhibits set during vcpu_create() and if those can be unset later? > Shouldn't we be allocating the apic access page unconditionally here? In theory, yes. In practice, this guards against an unnecessary allocation for SEV+ guests (see APICV_INHIBIT_REASON_SEV). That said, I completely agree that checking kvm_apicv_activated() is weird and sketchy. Hopefully that can be cleaned up, too (but after this series).
