On 15/05/20 20:46, Sean Christopherson wrote: >> The new one using #VE is not coming very soon (we need to emulate it for >> <Broadwell and AMD processors, so it's not entirely trivial) so we are >> going to keep "page not ready" delivery using #PF for some time or even >> forever. However, page ready notification as #PF is going away for good. > > And isn't hardware based EPT Violation #VE going to require a completely > different protocol than what is implemented today? For hardware based #VE, > KVM won't intercept the fault, i.e. the guest will need to make an explicit > hypercall to request the page. Yes, but it's a fairly simple hypercall to implement. >> That said, type1/type2 is quite bad. :) Let's change that to page not >> present / page ready. > > 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. And the #PF mechanism also has the problem with NMIs that happen before the error code is read and page faults happening in the handler (you may connect some dots now). For #VE, the virtualization exception data area is enough to hold all the data that is needed. Paolo
