Ackerley Tng ackerleytng@google.com writes:
Yan Zhao yan.y.zhao@intel.com writes:
On Tue, Dec 12, 2023 at 12:46:22PM -0800, Sagi Shahar wrote:
From: Ackerley Tng ackerleytng@google.com
If guest memory is backed by restricted memfd
- UPM is being used, hence encrypted memory region has to be registered
- Can avoid making a copy of guest memory before getting TDX to initialize the memory region
<snip>
For memslot 0, 1, 2, when guest_memfd != -1, is it possible to also munmap(mmap_start, mmap_size) after finish loading?
Thank you for your review!
Did you mean "possible" as in whether it is "correct" to do munmap() for the rest of the earlier memslots containing non-test-code?
It is correct because the munmap() just deallocates memory that was recently allocated in mmap() in this same change. The memory set up for the VM is not affected.
<snip>
If we are not using guest_memfd (region->region.guest_memfd == -1), then we need to make the source and destination address different by copying the contents at the source address somewhere else for the call to tdx_init_mem_region(). That is what the mmap() is doing. This temporary buffer then needs to be freed, hence the munmap(). Without this copying, the destination address for the ioctl's copy would be the same as the source address, since those very same pages are provided in the memslot for this memory region.
Update on this:
Since TDX requires the use of guest_memfd, this patch will be simplified in the next revision.
The checks for region->region.guest_memfd != -1 will be removed, and there will be no need to do any mmap() or munmap(), so those will be removed as well.
If we are using guest_memfd, then the destination address for the ioctl's copy will be taken from the guest_memfd, which is already different from the source address, hence we can skip the copying.
} -- 2.43.0.472.g3155946c3a-goog