On 15/10/2024 6:36 am, Edgecombe, Rick P wrote:
On Mon, 2024-10-14 at 10:54 +0000, Huang, Kai wrote:
On Thu, 2024-10-10 at 21:53 +0000, Edgecombe, Rick P wrote:
On Thu, 2024-10-10 at 10:33 -0700, Sean Christopherson wrote:
1st: "fault->is_private != kvm_mem_is_private(kvm, fault->gfn)" is found.
2nd-6th: try_cmpxchg64() fails on each level SPTEs (5 levels in total)
Isn't there a more general scenario:
vcpu0 vcpu1
1. Freezes PTE
2. External op to do the SEAMCALL
3. Faults same PTE, hits frozen PTE
4. Retries N times, triggers zero-step
5. Finally finishes external op
Am I missing something?
I must be missing something. I thought KVM is going to
"Is going to", as in "will be changed to"? Or "does today"?
Will be changed to (today's behaviour is to go back to guest to let the
fault happen again to retry).
AFAICT this is what Sean suggested:
https://lore.kernel.org/all/ZuR09EqzU1WbQYGd@xxxxxxxxxx/
The whole point is to let KVM loop internally but not go back to guest
when the fault handler sees a frozen PTE. And in this proposal this
applies to both leaf and non-leaf PTEs IIUC, so it should handle the
case where try_cmpxchg64() fails as mentioned by Yan.
retry internally for
step 4 (retries N times) because it sees the frozen PTE, but will never go back
to guest after the fault is resolved? How can step 4 triggers zero-step?
Step 3-4 is saying it will go back to the guest and fault again.
As said above, the whole point is to make KVM loop internally when it
sees a frozen PTE, but not go back to guest.
