On 6/2/2026 9:50 PM, David Hildenbrand (Arm) wrote:
On 5/27/26 11:48, Xiaoyao Li wrote:
On 5/14/2026 4:47 AM, Peter Xu wrote:
On Mon, May 04, 2026 at 04:30:19PM +0400, Marc-André Lureau wrote:
In TDX guests, virtio-mem plug/unplug/re-plug fails because
kvm_set_phys_mem() unconditionally sets KVM memory attributes to
PRIVATE for all guest_memfd regions. On re-plug, the PRIVATE->PRIVATE
transition is a no-op, so KVM doesn't re-AUG pages and the guest's
TDG.MEM.PAGE.ACCEPT fails.
Know little on TDX, please bare with me..
I saw KVM does a seamcall to ADD or AUG whenever a new EPT pte is set, via
this path:
__tdp_mmu_set_spte_atomic
set_external_spte_present
tdx_sept_set_private_spte <------
On unplug, I'm expecting with your prior patches, gmem pages will be
truncated properly, so they'll be all gone.
Then, qemu does replug -> guest gets that event, start access page -> EPT
violation, KVM resolving page fault with __tdp_mmu_set_spte_atomic() (per
above) and a new page -> triggering AUG (not ADD, since it's post-boot).
Could you elaborate here why AUG is missing in the first place?
Peter, you analysis is correct.
The reason why plug -> unplug -> re-plug fails, is QEMU fails to discard the
private memory so that KVM doesn't zap the private mapping. When re-plug and
guest re-accepts, KVM doesn't get involved. Not discard the private memory on
unplug leads to another issue that the private memory is still accessible to the
guest.
But patch 11 fixes this. Patch 11 should be enough and we don't need this patch.
For guest kernel side, we need to ensure the guest kernel accepts the new
plugged memory, and no "start-shared" trick is required.
BTW, "start-shared" memory for coco is not something good. It violates the
contract that all the memory for Coco VM is initial private (accepted or
unaccepted) from EFI spec. We probably should avoid introducing exception unless
we have to.
Sorry, I have to double check: you are saying we do not need this patch, and
instead the guest has to do the right thing after plugging memory?
right, that's what I meant.
Whether the initial state of the (re-)hotplugged virtio-mem is shared or
private doesn't matter. Guest has to try to accept it before using it as
private memory. If guest hits the re-accept error, which means the
memory has not been taken off at the previous unplug and means the
memory is actually always available to the guest.
What matters is the host VMM needs to ensure the memory is actually
unplug'ed on the unplug operation, which is achieved by the patch 11 in
this series.
