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

On 8/19/21 3:32 AM, Marc Orr wrote:

On Wed, Aug 18, 2021 at 1:38 AM Varad Gautam [off-list ref] wrote:

quoted

Hi Marc, Zixuan,

On 8/18/21 3:52 AM, Marc Orr wrote:

quoted

On Tue, Aug 17, 2021 at 3:49 AM Joerg Roedel [off-list ref] wrote:

quoted

Hi Marc,

On Fri, Aug 13, 2021 at 11:44:39AM -0700, Marc Orr wrote:

quoted

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.

Nomenclature aside, I believe Zixuan's patchset [1] takes the same approach
as I posted here. In the end, we need to:
- build the testcases as ELF shared objs and link them to look like a PE
- switch away from UEFI GDT/IDT/pagetable states on early boot to what
  kvm-unit-tests needs
- modify the testcases that contain non-PIC asm stubs to allow building
  them as shared objs

I went with avoiding to bring in gnu-efi objects into kvm-unit-tests
for EFI helpers, and disabling the non-PIC testcases for the RFC's sake.

I'll try out "x86 UEFI: Convert x86 test cases to PIC" [2] from Zixuan's
patchset with my series and see what breaks. I think we can combine
the two patchsets.

[1] https://lore.kernel.org/r/20210818000905.1111226-1-zixuanwang@google.com/ (local)
[2] https://lore.kernel.org/r/20210818000905.1111226-10-zixuanwang@google.com/ (local)

This sounds great to us. We will also experiment with combining the
two patchsets and report back when we have some experience with this.
Though, please do also report back if you have an update on this
before we do.

I sent out a v2 [1] with Zixuan's "x86 UEFI: Convert x86 test cases to PIC" [2]
pulled in, PTAL.

[1] https://lore.kernel.org/r/20210819113400.26516-1-varad.gautam@suse.com/ (local)
[2] https://lore.kernel.org/r/20210818000905.1111226-10-zixuanwang@google.com/ (local)

Thanks,
Varad

Thanks,
Marc

-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5
90409 Nürnberg
Germany

HRB 36809, AG Nürnberg
Geschäftsführer: Felix Imendörffer

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization