Re: [PATCH 2/8] KVM: x86: extend struct kvm_vcpu_pv_apf_data with token info

Paolo Bonzini
2020-05-15T19:18:19Z

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