On Thu, Dec 19, 2019 at 05:15:25PM +0100, Frederic Weisbecker wrote: > On Thu, Dec 19, 2019 at 07:57:46AM -0800, Sean Christopherson wrote: > > On Thu, Dec 19, 2019 at 04:28:15PM +0100, Frederic Weisbecker wrote: > > > Hi, > > > > > > While checking the x86 async page fault code, I can't > > > find anything that prevents KVM_PV_REASON_PAGE_READY to be injected > > > while the guest has interrupts disabled. If that page fault happens > > > to trap in an interrupt disabled section, there may be a deadlock due to the > > > call to wake_up_process() which locks the rq->lock (among others). > > > > > > Given how long that code is there, I guess such an issue would > > > have been reported for a while already. But I just would like to > > > be sure we are checking that. > > > > > > Can someone enlighten me? > > > > The check is triggered from the caller of kvm_async_page_present(). > > > > kvm_check_async_pf_completion() > > | > > |-> kvm_arch_can_inject_async_page_present() > > | > > |-> kvm_can_do_async_pf() > > | > > |-> kvm_x86_ops->interrupt_allowed() > > Ah thanks, I missed that one. And what about > kvm_async_page_present_sync()? I don't see a similar check > there. CONFIG_KVM_ASYNC_PF_SYNC is selected only by s390, it can't be turned on for x86. > 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.
