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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox