On Fri, Dec 20, 2019 at 10:34:20AM +0100, Paolo Bonzini wrote: > On 19/12/19 20:00, Sean Christopherson wrote: > >> And one last silly question, what about that line in > >> kvm_arch_can_inject_async_page_present: > >> > >> if (!(vcpu->arch.apf.msr_val & KVM_ASYNC_PF_ENABLED)) > >> return true; > >> > >> That looks weird, also it shortcuts the irqs_allowed() check. > > > > I wondered about that code as well :-). Definitely odd, but it would > > require the guest to disable async #PF after an async #PF is queued. Best > > guess is the idea is that it's the guest's problem if it disables async #PF > > on the fly. > > > > When the guest disables async #PF all outstanding page faults are > cancelled by kvm_clear_async_pf_completion_queue. However, in case they > complete while in cancel_work_sync. you need to inject them even if > interrupts are disabled. Hmm, shouldn't the guest wait for the whole pending waitqueue in kvm_async_pf_task_wait() to be serviced and woken up before actually allowing to disable async #PF ? Because you can't really afford to inject those #PF while IRQs are disabled, that's a big rq deadlock risk.
