Hi Marc, Zixuan,
On 8/18/21 3:52 AM, Marc Orr wrote:> On Tue, Aug 17, 2021 at 3:49 AM Joerg Roedel <jroedel at 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.
>
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 at google.com/
[2] https://lore.kernel.org/r/20210818000905.1111226-10-zixuanwang at
google.com/
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