Re: [kvm-unit-tests PATCH 0/6] Initial x86_64 UEFI support

From: Marc Orr <marcorr@google.com>
To: Joerg Roedel <jroedel@suse.de>
Cc: Varad Gautam <varad.gautam@suse.com>,
	kvm list <kvm@vger.kernel.org>,
	virtualization@lists.linux-foundation.org,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andrew Jones <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 18:52:05 -0700	[thread overview]
Message-ID: <CAA03e5FTrkLpZ3yr3nBphOW3D+8HF-Wmo4um4MTXum3BR6BMQw@mail.gmail.com> (raw)
In-Reply-To: <YRuURERGp8CQ1jAX@suse.de>

On Tue, Aug 17, 2021 at 3:49 AM Joerg Roedel <jroedel@suse.de> wrote:
>
> 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.

I think we might be using terminology differently. (Maybe I mis-used
the term “EFI app”?) With our approach, it is true that all
pre-existing x86_64 test cases work out of the box with the UEFI #VC
handler. However, because kvm-unit-tests calls `ExitBootServices` to
take full control of the system it executes as a “UEFI-stubbed
kernel”. Thus, it should be trivial for test cases to update the IDT
to set up a custom #VC handler for the duration of a test. (Some of
the x86_64 test cases already do something similar where they install
a temporary exception handler and then restore the “default”
kvm-unit-tests exception handler.)

In general, our approach is to set up the test cases to run with the
kvm-unit-tests configuration (e.g., IDT, GDT). The one exception is
the #VC handler. However, all of this state can be overridden within a
test as needed.

Zixuan just posted the patches. So hopefully they make things more clear.

Thanks,
Marc