On Sat, May 16, 2020 at 12:23:31AM +0200, Paolo Bonzini wrote: > On 15/05/20 22:43, Sean Christopherson wrote: > > On Fri, May 15, 2020 at 09:18:07PM +0200, Paolo Bonzini wrote: > >> On 15/05/20 20:46, Sean Christopherson wrote: > >>> Why even bother using 'struct kvm_vcpu_pv_apf_data' for the #PF case? VMX > >>> only requires error_code[31:16]==0 and SVM doesn't vet it at all, i.e. we > >>> can (ab)use the error code to indicate an async #PF by setting it to an > >>> impossible value, e.g. 0xaaaa (a is for async!). That partciular error code > >>> is even enforced by the SDM, which states: > >> > >> Possibly, but it's water under the bridge now. > > > > Why is that? I thought we were redoing the entire thing because the current > > ABI is unfixably broken? In other words, since the guest needs to change, > > why are we keeping any of the current async #PF pieces? E.g. why keep using > > #PF instead of usurping something like #NP? > > Because that would be 3 ABIs to support instead of 2. The #PF solution > is only broken as long as you allow async PF from ring 0 (which wasn't > even true except for preemptable kernels) _and_ have NMIs that can > generate page faults. We also have the #PF vmexit part for nested > virtualization. This adds up and makes a quick fix for 'page not ready' > notifications not that quick. > > However, interrupts for 'page ready' do have a bunch of advantages (more > control on what can be preempted by the notification, a saner check for > new page faults which is effectively a bug fix) so it makes sense to get > them in more quickly (probably 5.9 at this point due to the massive > cleanups that are being done around interrupt vectors). Ah, so the plan is to fix 'page ready' for the current ABI, but keep the existing 'page not ready' part because it's not thaaaat broken. Correct? In that case, is Andy's patch to kill KVM_ASYNC_PF_SEND_ALWAYS in the guest being picked up? I'll read through your #VE stuff on Monday :-).
