Messages in this thread | | | Subject | Re: [PATCH v5 01/16] x86/mm: Move force_dma_unencrypted() to common code | From | Sathyanarayanan Kuppuswamy <> | Date | Wed, 20 Oct 2021 09:43:43 -0700 |
| |
On 10/20/21 9:11 AM, Tom Lendacky wrote: >> Intel TDX doesn't allow VMM to access guest private memory. Any memory >> that is required for communication with VMM must be shared explicitly >> by setting the bit in page table entry. After setting the shared bit, >> the conversion must be completed with MapGPA hypercall. Details about >> MapGPA hypercall can be found in [1], sec 3.2. >> >> The call informs VMM about the conversion between private/shared >> mappings. The shared memory is similar to unencrypted memory in AMD >> SME/SEV terminology but the underlying process of sharing/un-sharing >> the memory is different for Intel TDX guest platform. >> >> SEV assumes that I/O devices can only do DMA to "decrypted" physical >> addresses without the C-bit set. In order for the CPU to interact with >> this memory, the CPU needs a decrypted mapping. To add this support, >> AMD SME code forces force_dma_unencrypted() to return true for >> platforms that support AMD SEV feature. It will be used for DMA memory >> allocation API to trigger set_memory_decrypted() for platforms that >> support AMD SEV feature. >> >> TDX is similar. So, to communicate with I/O devices, related pages need >> to be marked as shared. As mentioned above, shared memory in TDX >> architecture is similar to decrypted memory in AMD SME/SEV. So similar >> to AMD SEV, force_dma_unencrypted() has to forced to return true. This >> support is added in other patches in this series. >> >> So move force_dma_unencrypted() out of AMD specific code and call AMD >> specific (amd_force_dma_unencrypted()) initialization function from it. >> force_dma_unencrypted() will be modified by later patches to include >> Intel TDX guest platform specific initialization. >> >> Also, introduce new config option X86_MEM_ENCRYPT_COMMON that has to be >> selected by all x86 memory encryption features. This will be selected >> by both AMD SEV and Intel TDX guest config options. >> >> This is preparation for TDX changes in DMA code and it has no >> functional change. > > Can force_dma_unencrypted() be moved to arch/x86/kernel/cc_platform.c, > instead of creating a new file? It might fit better with patch #6.
Please check the final version of mem_encrypt_common.c
https://github.com/intel/tdx/blob/guest/arch/x86/mm/mem_encrypt_common.c
I am not sure whether it is alright to move mem_encrypt_init() and arch_has_restricted_virtio_memory_access() to cc_platform.c
If this is fine, I can get rid of mem_encrypt_common.c
-- Sathyanarayanan Kuppuswamy Linux Kernel Developer
| |