lkml.org 
[lkml]   [2023]   [Feb]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [RFC PATCH V3 00/16] x86/hyperv/sev: Add AMD sev-snp enlightened guest support on hyperv
Date
From: Zhi Wang <zhi.wang.linux@gmail.com> Sent: Thursday, February 2, 2023 3:01 PM
>
> On Sat, 21 Jan 2023 21:45:50 -0500
> Tianyu Lan <ltykernel@gmail.com> wrote:
>
> 1) I am thinking if it is a good time to organize a common code path for
> enlightened VM on hyper-v.
>
> Wouldn't it be better to have a common flag for enlightened VM?
> Like bool hv_isolation_type_enlightened()
>
> Many of the decryption of the post msg page... are also required
> in the enlightened TDX guest, they are not AMD-specific.
>
> Then in the "TDX guest on hyper-V" patch set, Dexuan can save some LOCs instead
> of ending up with if (hv_isolation_type_en_snp() ||
> hv_isolation_type_en_tdx())...

I've had the same thought, and have briefly discussed the
idea with Dexuan and Tianyu. But there's some code coming
for a non-confidential VM scenario that hasn't yet been posted
upstream, and it adds yet more cases to consider. We were
thinking to wait a bit until all the cases were evident, and then
find the right simplification. If we try to do the simplification
now, we may need to do it again.

>
> 2) It seems the AMD SEV-SNP enlightened guest on hyper-V is implemented as
> CC_VENDOR_AMD, while TDX enlightened guest is still implemented as
> CC_VENDOR_HYPERV. I am curious about the reason.

Patch set [1] makes CC_VENDOR_HYPERV go away. Once that
happens, the TDX enlightened guest uses CC_VENDOR_INTEL.

Michael

[1] https://lore.kernel.org/linux-hyperv/1673559753-94403-1-git-send-email-mikelley@microsoft.com/T/#m4639d697e9a6619edfcdceffc1b0613a9016f601



>
> > From: Tianyu Lan <tiala@microsoft.com>
> >
> > This patchset is to add AMD sev-snp enlightened guest
> > support on hyperv. Hyperv uses Linux direct boot mode
> > to boot up Linux kernel and so it needs to pvalidate
> > system memory by itself.
> >
> > In hyperv case, there is no boot loader and so cc blob
> > is prepared by hypervisor. In this series, hypervisor
> > set the cc blob address directly into boot parameter
> > of Linux kernel. If the magic number on cc blob address
> > is valid, kernel will read cc blob.
> >
> > Shared memory between guests and hypervisor should be
> > decrypted and zero memory after decrypt memory. The data
> > in the target address. It maybe smearedto avoid smearing
> > data.
> >
> > Introduce #HV exception support in AMD sev snp code and
> > #HV handler.
> >
> > Change since v2:
> > - Remove validate kernel memory code at boot stage
> > - Split #HV page patch into two parts
> > - Remove HV-APIC change due to enable x2apic from
> > host side
> > - Rework vmbus code to handle error of decrypt page
> > - Spilt memory and cpu initialization patch.
> >
> > Change since v1:
> > - Remove boot param changes for cc blob address and
> > use setup head to pass cc blob info
> > - Remove unnessary WARN and BUG check
> > - Add system vector table map in the #HV exception
> > - Fix interrupt exit issue when use #HV exception
> >
> > Ashish Kalra (2):
> > x86/sev: optimize system vector processing invoked from #HV exception
> > x86/sev: Fix interrupt exit code paths from #HV exception
> >
> > Tianyu Lan (14):
> > x86/hyperv: Add sev-snp enlightened guest specific config
> > x86/hyperv: Decrypt hv vp assist page in sev-snp enlightened guest
> > x86/hyperv: Set Virtual Trust Level in vmbus init message
> > x86/hyperv: Use vmmcall to implement Hyper-V hypercall in sev-snp
> > enlightened guest
> > clocksource/drivers/hyper-v: decrypt hyperv tsc page in sev-snp
> > enlightened guest
> > x86/hyperv: decrypt vmbus pages for sev-snp enlightened guest
> > drivers: hv: Decrypt percpu hvcall input arg page in sev-snp
> > enlightened guest
> > x86/hyperv: Initialize cpu and memory for sev-snp enlightened guest
> > x86/hyperv: SEV-SNP enlightened guest don't support legacy rtc
> > x86/hyperv: Add smp support for sev-snp guest
> > x86/hyperv: Add hyperv-specific hadling for VMMCALL under SEV-ES
> > x86/sev: Add a #HV exception handler
> > x86/sev: Add Check of #HV event in path
> > x86/sev: Initialize #HV doorbell and handle interrupt requests
> >
> > arch/x86/entry/entry_64.S | 82 ++++++
> > arch/x86/hyperv/hv_init.c | 43 +++
> > arch/x86/hyperv/ivm.c | 10 +
> > arch/x86/include/asm/cpu_entry_area.h | 6 +
> > arch/x86/include/asm/hyperv-tlfs.h | 4 +
> > arch/x86/include/asm/idtentry.h | 105 ++++++-
> > arch/x86/include/asm/irqflags.h | 10 +
> > arch/x86/include/asm/mem_encrypt.h | 2 +
> > arch/x86/include/asm/mshyperv.h | 56 +++-
> > arch/x86/include/asm/msr-index.h | 6 +
> > arch/x86/include/asm/page_64_types.h | 1 +
> > arch/x86/include/asm/sev.h | 13 +
> > arch/x86/include/asm/svm.h | 59 +++-
> > arch/x86/include/asm/trapnr.h | 1 +
> > arch/x86/include/asm/traps.h | 1 +
> > arch/x86/include/asm/x86_init.h | 2 +
> > arch/x86/include/uapi/asm/svm.h | 4 +
> > arch/x86/kernel/cpu/common.c | 1 +
> > arch/x86/kernel/cpu/mshyperv.c | 228 ++++++++++++++-
> > arch/x86/kernel/dumpstack_64.c | 9 +-
> > arch/x86/kernel/idt.c | 1 +
> > arch/x86/kernel/sev.c | 395 ++++++++++++++++++++++----
> > arch/x86/kernel/traps.c | 42 +++
> > arch/x86/kernel/vmlinux.lds.S | 7 +
> > arch/x86/kernel/x86_init.c | 4 +-
> > arch/x86/mm/cpu_entry_area.c | 2 +
> > drivers/clocksource/hyperv_timer.c | 2 +-
> > drivers/hv/connection.c | 1 +
> > drivers/hv/hv.c | 33 ++-
> > drivers/hv/hv_common.c | 26 +-
> > include/asm-generic/hyperv-tlfs.h | 19 ++
> > include/asm-generic/mshyperv.h | 2 +
> > include/linux/hyperv.h | 4 +-
> > 33 files changed, 1102 insertions(+), 79 deletions(-)
> >

\
 
 \ /
  Last update: 2023-03-27 00:08    [W:0.784 / U:0.272 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site