On Wed, Oct 09, 2019 at 11:21:41AM +0200, Paolo Bonzini wrote: > On 13/09/19 21:01, Suthikulpanit, Suravee wrote: > > /* > > + * In case APICv accelerate EOI write and do not trap, > > + * in-kernel IOAPIC will not be able to receive the EOI. > > + * In this case, we do lazy update of the pending EOI when > > + * trying to set IOAPIC irq. > > + */ > > + if (kvm_apicv_eoi_accelerate(ioapic->kvm, edge)) > > + ioapic_lazy_update_eoi(ioapic, irq); > > + > > This is okay for the RTC, and in fact I suggest that you make it work > like this even for Intel. This will get rid of kvm_apicv_eoi_accelerate > and be nicer overall. > > However, it cannot work for the in-kernel PIT, because it is currently > checking ps->irq_ack before kvm_set_irq. Unfortunately, the in-kernel > PIT is relying on the ack notifier to timely queue the pt->worker work > item and reinject the missed tick. > > Thus, you cannot enable APICv if ps->reinject is true. > > Perhaps you can make kvm->arch.apicv_state a disabled counter? Then > Hyper-V can increment it when enabled, PIT can increment it when > ps->reinject becomes true and decrement it when it becomes false; > finally, svm.c can increment it when an SVM guest is launched and > increment/decrement it around ExtINT handling? This can benefit Hyper-V emulation too. The point is that it's only AutoEOI feature in SynIC that is incompatible with APICv. So the VM can use APICv until the guest configures its first AutoEOI SINT. If the hypervisor sets HV_DEPRECATING_AEOI_RECOMMENDED (bit 9) in HYPERV_CPUID_ENLIGHTMENT_INFO (0x40000004) cpuid this may never happen so we will not be pessimizing guests on modern hardware by merely enabling SynIC. I started looking into this recently and would be happy to piggy-back on this series. Roman. > (This conflicts with some of the suggestions I made earlier, which > implied the existence of apicv_state, but everything should if anything > become easier). > > Paolo
