[PATCH v9 07/13] KVM: guest_memfd: Add flag to remove from direct map

Nikita Kalyazin kalyazin at amazon.com
Fri Jan 16 07:02:29 PST 2026



On 15/01/2026 23:04, Edgecombe, Rick P wrote:
> On Wed, 2026-01-14 at 13:46 +0000, Kalyazin, Nikita wrote:
>> Add GUEST_MEMFD_FLAG_NO_DIRECT_MAP flag for KVM_CREATE_GUEST_MEMFD()
>> ioctl. When set, guest_memfd folios will be removed from the direct map
>> after preparation, with direct map entries only restored when the folios
>> are freed.
>>
>> To ensure these folios do not end up in places where the kernel cannot
>> deal with them, set AS_NO_DIRECT_MAP on the guest_memfd's struct
>> address_space if GUEST_MEMFD_FLAG_NO_DIRECT_MAP is requested.
>>
>> Note that this flag causes removal of direct map entries for all
>> guest_memfd folios independent of whether they are "shared" or "private"
>> (although current guest_memfd only supports either all folios in the
>> "shared" state, or all folios in the "private" state if
>> GUEST_MEMFD_FLAG_MMAP is not set). The usecase for removing direct map
>> entries of also the shared parts of guest_memfd are a special type of
>> non-CoCo VM where, host userspace is trusted to have access to all of
>> guest memory, but where Spectre-style transient execution attacks
>> through the host kernel's direct map should still be mitigated.  In this
>> setup, KVM retains access to guest memory via userspace mappings of
>> guest_memfd, which are reflected back into KVM's memslots via
>> userspace_addr. This is needed for things like MMIO emulation on x86_64
>> to work.
> 
> TDX does some clearing at the direct map mapping for pages that comes from gmem,
> using a special instruction. It also does some clflushing at the direct map
> address for these pages. So I think we need to make sure TDs don't pull from
> gmem fds with this flag.

Would you be able to give a pointer on how we can do that?  I'm not very 
familiar with the TDX code.

> 
> Not that there would be any expected use of the flag for TDs, but it could cause
> a crash.




More information about the linux-riscv mailing list