On 15/10/21 18:36, Sean Christopherson wrote:
Installing a SPTE based on global state is weird because this is a vCPU
action; installing it based on vCPU state is weird because it is knowingly
out of date.
If that's the argument, then kvm_faultin_page() should explicitly check for a
pending KVM_REQ_APICV_UPDATE, because I would then argue that contuining on when
KVM_knows_ its new SPTE will either get zapped (page fault wins the race) or
will get rejected (kvm_zap_gfn_range() wins the race) is just as wrong. The SPTE
_cannot_ be used even if the page fault wins the race, becuase all vCPUs need to
process KVM_REQ_APICV_UPDATE and thus will be blocked until the initiating vCPU
zaps the range and drops the APICv lock.
Right, that was my counter-argument - no need to check for the request
because the request "synchronizes" with the actual use of the PTE, via
kvm_make_all_cpus_request + kvm_zap_gfn_range.
And I personally do_not_ want to add a check for the request because it implies
the check is sufficient, which it is not, because the page fault doesn't yet hold
mmu_lock.
Of course, that would be even worse.
Since all answers are some form of wrong, IMO we should at least be coherent with
respect to the original page fault.
Okay, you win if you send a patch with a comment. :)
Paolo
