Vivek Goyal <vgoyal@xxxxxxxxxx> writes: > On Wed, May 13, 2020 at 04:23:55PM +0200, Vitaly Kuznetsov wrote: > > [..] >> >> Also, >> >> kdump kernel may not even support APF so it will get very confused when >> >> APF events get delivered. >> > >> > New kernel can just ignore these events if it does not support async >> > pf? >> > >> > This is somewhat similar to devices still doing interrupts in new >> > kernel. And solution for that seemed to be doing a "reset" of devices >> > in new kernel. We probably need similar logic where in new kernel >> > we simply disable "async pf" so that we don't get new notifications. >> >> Right and that's what we're doing - just disabling new notifications. > > Nice. > > So why there is a need to deliver "page ready" notifications > to guest after guest has disabled async pf. Atleast kdump does not > seem to need it. It will boot into second kernel anyway, irrespective > of the fact whether it receives page ready or not. We don't deliver anything to the guest after it disables APF (neither 'page ready' for what was previously missing, nor 'page not ready' for new faults), kvm_arch_can_inject_async_page_present() is just another misnomer, it should be named something like 'kvm_arch_can_unqueue_async_page_present()' meaning that 'page ready' notification can be 'unqueued' from internal KVM queue. We will either deliver it (when guest has APF enabled) or just drop it (when guest has APF disabled). The only case when it has to stay in the queue is when guest has APF enabled and the slot is still busy (so it didn't get to process a previously delivered notification). We will try to deliver it again after guest writes to MSR_KVM_ASYNC_PF_ACK. -- Vitaly
