On Tue, Jul 12, 2022, Maxim Levitsky wrote:
> On Tue, 2022-07-12 at 20:32 +0800, Wang Guangju wrote:
> > When EOI virtualization is performed on VMX, kvm_apic_set_eoi_accelerated()
> > is called upon EXIT_REASON_EOI_INDUCED but unlike its non-accelerated
> > apic_set_eoi() sibling, Hyper-V SINT vectors are left unhandled.
> >
> > Send EOI to Hyper-V SINT vectors when handling acclerated EOI-induced
> > VM-Exits. KVM Hyper-V needs to handle the SINT EOI irrespective of whether
> > the EOI is acclerated or not.
>
> How does this relate to the AutoEOI feature, and the fact that on AVIC,
> it can't intercept EOI at all (*)?
>
> Best regards,
> Maxim Levitsky
>
>
> (*) AVIC does intercept EOI write but only for level triggered interrupts.
If there are one or more AutoEOI vectors, KVM disables AVIC. Which begs the question
of why SVM doesn't disable the AVIC if there's an edge-triggered I/O APIC interrupt
that has a notifier, which is where kvm_hv_notify_acked_sint() eventually ends up.
vmx_load_eoi_exitmap() sets the EOI intercept for all such vectors, and for _all_
SynIC vectors (see vcpu_load_eoi_exitmap()), but AFAICT SVM relies purely on the
level-triggered behavior.
KVM manually disables AVIC for PIT reinjection, which uses an ack notifier;
AFAICT that's a one-off hack to workaround AVIC not playing nice with notifiers.
So yeah, it seems like the proper fix would be to add svm_load_eoi_exitmap() and
replace the PIT inhibit with a generic ACK inhibit that is set if there is at least
one edge-triggered vector present in the eoi_exit_bitmap.
Tangentially related to all of this, it's bizarre/confusing the KVM_CREATE_PIT{2}
is allowed regardless of whether or not the I/O APIC is in-kernel. I don't see
how it can possibly work since create_pit_timer() silently does nothing if the I/O
APIC isn't in-kernel.
