On 29/04/20 14:40, Vitaly Kuznetsov wrote: > Paolo Bonzini <pbonzini@xxxxxxxxxx> writes: > >> On 29/04/20 11:36, Vitaly Kuznetsov wrote: >>> + >>> + Type 1 page (page missing) events are currently always delivered as >>> + synthetic #PF exception. Type 2 (page ready) are either delivered >>> + by #PF exception (when bit 3 of MSR_KVM_ASYNC_PF_EN is clear) or >>> + via an APIC interrupt (when bit 3 set). APIC interrupt delivery is >>> + controlled by MSR_KVM_ASYNC_PF2. >> >> I think we should (in the non-RFC version) block async page faults >> completely and only keep APF_HALT unless the guest is using page ready >> interrupt delivery. > > Sure, we can do that. This is, however, a significant behavioral change: > APF_HALT frees the host, not the guest, so even if the combined > performance of all guests on the same pCPU remain the same guests with > e.g. a lot of simultaneously running processes may suffer more. Yes, it is a significant change. However the resulting clean up in the spec is significant, because we don't have type 2 notifications at all anymore. (APF_HALT does free the guest a little bit by allowing interrupt delivery during a host page fault; in particular it lets the scheduler tick run, which does improve responsiveness somewhat significantly). Likewise, I think we should clean up the guest side without prejudice. Patch 6 should disable async page fault unless page-ready interrupts are available, and drop the page ready case from the #PF handler. Thanks, Paolo > In theory, we can keep two mechanisms side by side for as long as we > want but if the end goal is to have '#PF abuse eliminated' than we'll > have to get rid of the legacy one some day. The day when the new > mechanism lands is also a good choice :-)
