From: Joerg Roedel <jroedel@suse.de>
To: Marc Orr <marcorr@google.com>
Cc: Varad Gautam <varad.gautam@suse.com>,
kvm list <kvm@vger.kernel.org>,
virtualization@lists.linux-foundation.org,
Paolo Bonzini <pbonzini@redhat.com>,
drjones@redhat.com, bp@suse.de, "Lendacky,
Thomas" <thomas.lendacky@amd.com>,
"Singh, Brijesh" <brijesh.singh@amd.com>,
Zixuan Wang <zixuanwang@google.com>,
"Hyunwook (Wooky) Baek" <baekhw@google.com>,
Erdem Aktas <erdemaktas@google.com>,
Tom Roeder <tmroeder@google.com>
Subject: Re: [kvm-unit-tests PATCH 0/6] Initial x86_64 UEFI support
Date: Tue, 17 Aug 2021 12:49:40 +0200 [thread overview]
Message-ID: <YRuURERGp8CQ1jAX@suse.de> (raw)
In-Reply-To: <CAA03e5HCdx2sLRqs2jkLDz3z8SB9JhCdxGv7Y6_ER-kMaqHXUg@mail.gmail.com>
Hi Marc,
On Fri, Aug 13, 2021 at 11:44:39AM -0700, Marc Orr wrote:
> To date, we have _most_ x86 test cases (39/44) working under UEFI and
> we've also got some of the test cases to boot under SEV-ES, using the
> UEFI #VC handler.
While the EFI APP approach simplifies the implementation a lot, I don't
think it is the best path to SEV and TDX testing for a couple of
reasons:
1) It leaves the details of #VC/#VE handling and the SEV-ES
specific communication channels (GHCB) under control of the
firmware. So we can't reliably test those interfaces from an
EFI APP.
2) Same for the memory validation/acceptance interface needed
for SEV-SNP and TDX. Using an EFI APP leaves those under
firmware control and we are not able to reliably test them.
3) The IDT also stays under control of the firmware in an EFI
APP, otherwise the firmware couldn't provide a #VC handler.
This makes it unreliable to test anything IDT or IRQ related.
4) Relying on the firmware #VC hanlder limits the tests to its
abilities. Implementing a separate #VC handler routine for
kvm-unit-tests is more work, but it makes test development
much more flexible.
So it comes down to the fact that and EFI APP leaves control over
SEV/TDX specific hypervisor interfaces in the firmware, making it hard
and unreliable to test these interfaces from kvm-unit-tests. The stub
approach on the other side gives the tests full control over the VM,
allowing to test all aspects of the guest-host interface.
Regards,
Joerg
WARNING: multiple messages have this Message-ID (diff)
From: Joerg Roedel <jroedel@suse.de>
To: Marc Orr <marcorr@google.com>
Cc: "Lendacky, Thomas" <thomas.lendacky@amd.com>,
drjones@redhat.com, "Singh, Brijesh" <brijesh.singh@amd.com>,
kvm list <kvm@vger.kernel.org>, Tom Roeder <tmroeder@google.com>,
"Hyunwook \(Wooky\) Baek" <baekhw@google.com>,
virtualization@lists.linux-foundation.org,
Zixuan Wang <zixuanwang@google.com>,
Erdem Aktas <erdemaktas@google.com>,
Paolo Bonzini <pbonzini@redhat.com>,
bp@suse.de
Subject: Re: [kvm-unit-tests PATCH 0/6] Initial x86_64 UEFI support
Date: Tue, 17 Aug 2021 12:49:40 +0200 [thread overview]
Message-ID: <YRuURERGp8CQ1jAX@suse.de> (raw)
In-Reply-To: <CAA03e5HCdx2sLRqs2jkLDz3z8SB9JhCdxGv7Y6_ER-kMaqHXUg@mail.gmail.com>
Hi Marc,
On Fri, Aug 13, 2021 at 11:44:39AM -0700, Marc Orr wrote:
> To date, we have _most_ x86 test cases (39/44) working under UEFI and
> we've also got some of the test cases to boot under SEV-ES, using the
> UEFI #VC handler.
While the EFI APP approach simplifies the implementation a lot, I don't
think it is the best path to SEV and TDX testing for a couple of
reasons:
1) It leaves the details of #VC/#VE handling and the SEV-ES
specific communication channels (GHCB) under control of the
firmware. So we can't reliably test those interfaces from an
EFI APP.
2) Same for the memory validation/acceptance interface needed
for SEV-SNP and TDX. Using an EFI APP leaves those under
firmware control and we are not able to reliably test them.
3) The IDT also stays under control of the firmware in an EFI
APP, otherwise the firmware couldn't provide a #VC handler.
This makes it unreliable to test anything IDT or IRQ related.
4) Relying on the firmware #VC hanlder limits the tests to its
abilities. Implementing a separate #VC handler routine for
kvm-unit-tests is more work, but it makes test development
much more flexible.
So it comes down to the fact that and EFI APP leaves control over
SEV/TDX specific hypervisor interfaces in the firmware, making it hard
and unreliable to test these interfaces from kvm-unit-tests. The stub
approach on the other side gives the tests full control over the VM,
allowing to test all aspects of the guest-host interface.
Regards,
Joerg
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
next prev parent reply other threads:[~2021-08-17 10:49 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-02 11:48 [kvm-unit-tests PATCH 0/6] Initial x86_64 UEFI support Varad Gautam
2021-07-02 11:48 ` Varad Gautam via Virtualization
2021-07-02 11:48 ` [kvm-unit-tests PATCH 1/6] x86: Build tests as PE objects for the EFI loader Varad Gautam
2021-07-02 11:48 ` Varad Gautam via Virtualization
2021-07-02 11:48 ` [kvm-unit-tests PATCH 2/6] x86: Call efi_main from _efi_pe_entry Varad Gautam
2021-07-02 11:48 ` Varad Gautam via Virtualization
2021-07-02 11:48 ` [kvm-unit-tests PATCH 3/6] x86: efi_main: Get EFI memory map and exit boot services Varad Gautam
2021-07-02 11:48 ` Varad Gautam via Virtualization
2021-07-02 11:48 ` [kvm-unit-tests PATCH 4/6] x86: efi_main: Self-relocate ELF .dynamic addresses Varad Gautam
2021-07-02 11:48 ` Varad Gautam via Virtualization
2021-07-02 11:48 ` [kvm-unit-tests PATCH 5/6] cstart64.S: x86_64 bootstrapping after exiting EFI Varad Gautam
2021-07-02 11:48 ` Varad Gautam via Virtualization
2021-07-02 11:48 ` [kvm-unit-tests PATCH 6/6] x86: Disable some breaking tests for EFI and modify vmexit test Varad Gautam
2021-07-02 11:48 ` Varad Gautam via Virtualization
2021-07-12 16:29 ` [kvm-unit-tests PATCH 0/6] Initial x86_64 UEFI support Andrew Jones
2021-07-12 16:29 ` Andrew Jones
2021-08-13 18:44 ` Marc Orr
2021-08-16 7:26 ` Andrew Jones
2021-08-16 7:26 ` Andrew Jones
2021-08-17 3:41 ` Marc Orr
2021-08-17 10:49 ` Joerg Roedel [this message]
2021-08-17 10:49 ` Joerg Roedel
2021-08-18 1:52 ` Marc Orr
2021-08-18 8:38 ` Varad Gautam
2021-08-18 8:38 ` Varad Gautam via Virtualization
2021-08-19 1:32 ` Marc Orr
2021-08-19 1:42 ` Nadav Amit
2021-08-19 1:42 ` Nadav Amit
2021-08-19 1:54 ` Zixuan Wang
2021-08-19 11:36 ` Varad Gautam
2021-08-19 11:36 ` Varad Gautam via Virtualization
2021-08-20 17:29 ` Marc Orr
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=YRuURERGp8CQ1jAX@suse.de \
--to=jroedel@suse.de \
--cc=baekhw@google.com \
--cc=bp@suse.de \
--cc=brijesh.singh@amd.com \
--cc=drjones@redhat.com \
--cc=erdemaktas@google.com \
--cc=kvm@vger.kernel.org \
--cc=marcorr@google.com \
--cc=pbonzini@redhat.com \
--cc=thomas.lendacky@amd.com \
--cc=tmroeder@google.com \
--cc=varad.gautam@suse.com \
--cc=virtualization@lists.linux-foundation.org \
--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.