From: Sean Christopherson <seanjc@google.com>
To: Zixuan Wang <zixuanwang@google.com>
Cc: kvm@vger.kernel.org, pbonzini@redhat.com, drjones@redhat.com,
marcorr@google.com, baekhw@google.com, tmroeder@google.com,
erdemaktas@google.com, rientjes@google.com,
brijesh.singh@amd.com, Thomas.Lendacky@amd.com,
varad.gautam@suse.com, jroedel@suse.de, bp@suse.de
Subject: Re: [kvm-unit-tests RFC 14/16] x86 AMD SEV-ES: Copy UEFI #VC IDT entry
Date: Fri, 20 Aug 2021 23:50:09 +0000 [thread overview]
Message-ID: <YSA/sYhGgMU72tn+@google.com> (raw)
In-Reply-To: <20210818000905.1111226-15-zixuanwang@google.com>
On Wed, Aug 18, 2021, Zixuan Wang wrote:
> AMD SEV-ES introduces a new #VC exception that handles the communication
> between guest and host. UEFI already implements a #VC handler so there
> is no need to re-implement it in KVM-Unit-Tests. To reuse this #VC
> handler, this commit reads UEFI's IDT, copy the #VC IDT entry into
> KVM-Unit-Tests' IDT.
>
> In this commit, load_idt() can work and now guest crashes in
> setup_page_table(), which will be fixed by follow-up commits.
As a stop gap to get SEV testing of any kind enabled, I think piggybacking the
vBIOS #VC handler is a great idea. But long term, kvm-unit-tests absolutely
needs to have its own #VC handler.
In addition to the downsides Joerg pointed out[*], relying on an external #VC
introduces the possibility of test failures that are tied to the vBIOS being
used. Such dependencies already exist to some extent, e.g. using a buggy QEMU or
SeaBIOS could certainly introduce failures, but those components are far more
mature and less likely to break in weird ways unique to a specific test.
Another potential issue is that it's possible vBIOS will be enlightened to the
point where it _never_ expects a #VC, e.g. does #VMGEXIT directly, and thus panics
on any #VC instead of requesting the necessary emulation.
Fixing the vBIOS image in the repo would mostly solve those problems, but it
wouldn't solve the lack of flexibility for the #VC handler, and debugging a third
party #VC handler would likely be far more difficult to debug when failures
inevitably occur.
So, if these shenanigans give us test coverage now instead of a few months from
now, than I say go for it. But, we need clear line of sight to a "native" #VC
handler, confidence that it will actually get written in a timely manner, and an
easily reverted set of commits to unwind all of the UEFI stuff.
[*] https://lkml.kernel.org/r/YRuURERGp8CQ1jAX@suse.de
> Signed-off-by: Zixuan Wang <zixuanwang@google.com>
> ---
> lib/x86/amd_sev.c | 10 ++++++++++
> lib/x86/amd_sev.h | 5 +++++
> 2 files changed, 15 insertions(+)
>
> diff --git a/lib/x86/amd_sev.c b/lib/x86/amd_sev.c
> index c2aebdf..04b6912 100644
> --- a/lib/x86/amd_sev.c
> +++ b/lib/x86/amd_sev.c
> @@ -46,11 +46,21 @@ EFI_STATUS setup_amd_sev(void)
>
> #ifdef CONFIG_AMD_SEV_ES
> EFI_STATUS setup_amd_sev_es(void){
> + struct descriptor_table_ptr idtr;
> + idt_entry_t *idt;
> +
> /* Test if SEV-ES is enabled */
> if (!(rdmsr(MSR_SEV_STATUS) & SEV_ES_ENABLED_MASK)) {
> return EFI_UNSUPPORTED;
> }
>
> + /* Copy UEFI's #VC IDT entry, so KVM-Unit-Tests can reuse it and does
Nit, multiline comments should have a leading bare /*, i.e.
/*
* Copy ....
* not have to ...
> + * not have to re-implement a #VC handler
> + */
> + sidt(&idtr);
> + idt = (idt_entry_t *)idtr.base;
> + boot_idt[SEV_ES_VC_HANDLER_VECTOR] = idt[SEV_ES_VC_HANDLER_VECTOR];
> +
> return EFI_SUCCESS;
> }
>
> diff --git a/lib/x86/amd_sev.h b/lib/x86/amd_sev.h
> index 4d81cae..5ebd4a6 100644
> --- a/lib/x86/amd_sev.h
> +++ b/lib/x86/amd_sev.h
> @@ -36,6 +36,11 @@
> #define SEV_ENABLED_MASK 0b1
> #define SEV_ES_ENABLED_MASK 0b10
>
> +/* AMD Programmer's Manual Volume 2
> + * - Section "#VC Exception"
> + */
> +#define SEV_ES_VC_HANDLER_VECTOR 29
> +
> EFI_STATUS setup_amd_sev(void);
> #ifdef CONFIG_AMD_SEV_ES
> EFI_STATUS setup_amd_sev_es(void);
> --
> 2.33.0.rc1.237.g0d66db33f3-goog
>
next prev parent reply other threads:[~2021-08-20 23:50 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-18 0:08 [kvm-unit-tests RFC 00/16] x86_64 UEFI and AMD SEV/SEV-ES support Zixuan Wang
2021-08-18 0:08 ` [kvm-unit-tests RFC 01/16] x86 UEFI: Copy code from GNU-EFI Zixuan Wang
2021-08-18 0:08 ` [kvm-unit-tests RFC 02/16] x86 UEFI: Boot from UEFI Zixuan Wang
2021-08-18 0:08 ` [kvm-unit-tests RFC 03/16] x86 UEFI: Move setjmp.h out of desc.h Zixuan Wang
2021-08-18 0:08 ` [kvm-unit-tests RFC 04/16] x86 UEFI: Load KVM-Unit-Tests IDT after UEFI boot up Zixuan Wang
2021-08-18 0:08 ` [kvm-unit-tests RFC 05/16] x86 UEFI: Load GDT and TSS " Zixuan Wang
2021-08-18 0:08 ` [kvm-unit-tests RFC 06/16] x86 UEFI: Set up memory allocator Zixuan Wang
2021-08-18 0:08 ` [kvm-unit-tests RFC 07/16] x86 UEFI: Set up RSDP after UEFI boot up Zixuan Wang
2021-08-18 0:08 ` [kvm-unit-tests RFC 08/16] x86 UEFI: Set up page tables Zixuan Wang
2021-08-18 0:08 ` [kvm-unit-tests RFC 09/16] x86 UEFI: Convert x86 test cases to PIC Zixuan Wang
2021-08-18 0:08 ` [kvm-unit-tests RFC 10/16] x86 AMD SEV: Initial support Zixuan Wang
2021-08-18 0:09 ` [kvm-unit-tests RFC 11/16] x86 AMD SEV: Page table with c-bit Zixuan Wang
2021-08-18 0:09 ` [kvm-unit-tests RFC 12/16] x86 AMD SEV-ES: Check SEV-ES status Zixuan Wang
2021-08-18 0:09 ` [kvm-unit-tests RFC 13/16] x86 AMD SEV-ES: Load GDT with UEFI segments Zixuan Wang
2021-08-18 0:09 ` [kvm-unit-tests RFC 14/16] x86 AMD SEV-ES: Copy UEFI #VC IDT entry Zixuan Wang
2021-08-20 23:50 ` Sean Christopherson [this message]
2021-08-21 0:37 ` Marc Orr
2021-08-21 0:47 ` Zixuan Wang
2021-08-18 0:09 ` [kvm-unit-tests RFC 15/16] x86 AMD SEV-ES: Set up GHCB page Zixuan Wang
2021-08-18 0:09 ` [kvm-unit-tests RFC 16/16] x86 AMD SEV-ES: Add test cases Zixuan Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YSA/sYhGgMU72tn+@google.com \
--to=seanjc@google.com \
--cc=Thomas.Lendacky@amd.com \
--cc=baekhw@google.com \
--cc=bp@suse.de \
--cc=brijesh.singh@amd.com \
--cc=drjones@redhat.com \
--cc=erdemaktas@google.com \
--cc=jroedel@suse.de \
--cc=kvm@vger.kernel.org \
--cc=marcorr@google.com \
--cc=pbonzini@redhat.com \
--cc=rientjes@google.com \
--cc=tmroeder@google.com \
--cc=varad.gautam@suse.com \
--cc=zixuanwang@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.