On 23/12/19 03:17, Frederic Weisbecker wrote: > 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. That's just how Linux works, and Linux doesn't ever disable async page faults with disabled IRQ (reboot_notifier_list is a blocking notifier). Paolo
