Ackerley Tng <ackerleytng@xxxxxxxxxx> writes: > Yan Zhao <yan.y.zhao@xxxxxxxxx> writes: > >> On Tue, Dec 12, 2023 at 12:46:22PM -0800, Sagi Shahar wrote: >>> From: Ackerley Tng <ackerleytng@xxxxxxxxxx> >>> >>> 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 >>> >>>
