On 15/09/2024 9:53 pm, Zhao, Yan Y wrote:
On Sat, Sep 14, 2024 at 05:27:32PM +0800, Yan Zhao wrote:
Similarly, can tdh_mem_page_aug() actually contend with tdg_mem_page_accept()?
The page isn't yet mapped, so why would the guest be allowed to take a lock on
the S-EPT entry?
Before tdg_mem_page_accept() accepts a gpa and set rwx bits in a SPTE, if second
tdh_mem_page_aug() is called on the same gpa, the second one may contend with
tdg_mem_page_accept().
But given KVM does not allow the second tdh_mem_page_aug(), looks the contention
between tdh_mem_page_aug() and tdg_mem_page_accept() will not happen.
I withdraw the reply above.
tdh_mem_page_aug() and tdg_mem_page_accept() both attempt to modify the same
SEPT entry, leading to contention.
- tdg_mem_page_accept() first walks the SEPT tree with no lock to get the SEPT
entry. It then acquire the guest side lock of the found SEPT entry before
checking entry state.
- tdh_mem_page_aug() first walks the SEPT tree with shared lock to locate the
SEPT entry to modify, it then aquires host side lock of the SEPT entry before
checking entry state.
This seems can only happen when there are multiple threads in guest
trying to do tdg_mem_page_accept() on the same page. This should be
extremely rare to happen, and if this happens, it will eventually result
in another fault in KVM.
So now we set SPTE to FROZEN_SPTE before doing AUG to prevent from other
threads from going on. I think when tdh_mem_page_aug() fails with
secure EPT "entry" busy, we can reset FROZEN_SPTE back to old_spte and
return PF_RETRY so that this thread and another fault thread can both
try to complete AUG again?
The thread fails with AUG can also go back to guest though, but since
host priority bit is already set, the further PAGE.ACCEPT will fail but
this is fine due to another AUG in KVM will eventually resolve this and
make progress to the guest.
