On 11/11/22 00:21, Michael Kelley wrote:
Hyper-V guests on AMD SEV-SNP hardware have the option of using the
"virtual Top Of Memory" (vTOM) feature specified by the SEV-SNP
architecture. With vTOM, shared vs. private memory accesses are
controlled by splitting the guest physical address space into two
halves. vTOM is the dividing line where the uppermost bit of the
physical address space is set; e.g., with 47 bits of guest physical
address space, vTOM is 0x40000000000 (bit 46 is set). Guest phyiscal
memory is accessible at two parallel physical addresses -- one below
vTOM and one above vTOM. Accesses below vTOM are private (encrypted)
while accesses above vTOM are shared (decrypted). In this sense, vTOM
is like the GPA.SHARED bit in Intel TDX.
Support for Hyper-V guests using vTOM was added to the Linux kernel in
two patch sets[1][2]. This support treats the vTOM bit as part of
the physical address. For accessing shared (decrypted) memory, these
patch sets create a second kernel virtual mapping that maps to physical
addresses above vTOM.
A better approach is to treat the vTOM bit as a protection flag, not
as part of the physical address. This new approach is like the approach
for the GPA.SHARED bit in Intel TDX. Rather than creating a second kernel
virtual mapping, the existing mapping is updated using recently added
coco mechanisms. When memory is changed between private and shared using
set_memory_decrypted() and set_memory_encrypted(), the PTEs for the
existing kernel mapping are changed to add or remove the vTOM bit
in the guest physical address, just as with TDX. The hypercalls to
change the memory status on the host side are made using the existing
callback mechanism. Everything just works, with a minor tweak to map
the I/O APIC to use private accesses.
To accomplish the switch in approach, the following must be done in
in this single patch:
* Update Hyper-V initialization to set the cc _mask based on vTOM
and do other coco initialization.
* Update physical_mask so the vTOM bit is no longer treated as part
of the physical address
* Update cc_mkenc() and cc_mkdec() to be active for Hyper-V guests.
This makes the vTOM bit part of the protection flags.
* Code already exists to make hypercalls to inform Hyper-V about pages
changing between shared and private. Update this code to run as a
callback from __set_memory_enc_pgtable().
* Remove the Hyper-V special case from __set_memory_enc_dec(), and
make the normal case active for Hyper-V VMs, which have
CC_ATTR_GUEST_MEM_ENCRYPT, but not CC_ATTR_MEM_ENCRYPT.
[1] https://lore.kernel.org/all/20211025122116.264793-1-ltykernel@xxxxxxxxx/
[2] https://lore.kernel.org/all/20211213071407.314309-1-ltykernel@xxxxxxxxx/
Signed-off-by: Michael Kelley <mikelley@xxxxxxxxxxxxx>
Reviewed-by: Tianyu Lan <Tianyu.Lan@xxxxxxxxxxxxx>
---
arch/x86/coco/core.c | 10 ++++++++-
arch/x86/hyperv/ivm.c | 45 +++++++++++++++++++++++++++++++----------
arch/x86/include/asm/mshyperv.h | 8 ++------
arch/x86/kernel/cpu/mshyperv.c | 15 +++++++-------
arch/x86/mm/pat/set_memory.c | 6 ++----
5 files changed, 54 insertions(+), 30 deletions(-)
diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c
index 06eb8910..024fbf4 100644
--- a/arch/x86/mm/pat/set_memory.c
+++ b/arch/x86/mm/pat/set_memory.c
@@ -2126,10 +2126,8 @@ static int __set_memory_enc_pgtable(unsigned long addr, int numpages, bool enc)
static int __set_memory_enc_dec(unsigned long addr, int numpages, bool enc)
{
- if (hv_is_isolation_supported())
- return hv_set_mem_host_visibility(addr, numpages, !enc);
-
- if (cc_platform_has(CC_ATTR_MEM_ENCRYPT))
+ if (cc_platform_has(CC_ATTR_MEM_ENCRYPT) ||
+ cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT))
This seems kind of strange since CC_ATTR_MEM_ENCRYPT is supposed to mean
either HOST or GUEST memory encryption, but then you check for GUEST
memory encryption directly. Can your cc_platform_has() support be setup to
handle the CC_ATTR_MEM_ENCRYPT attribute in some way?
Thanks,
Tom
return __set_memory_enc_pgtable(addr, numpages, enc);
return 0;
