On 8/19/21 3:32 AM, Marc Orr wrote:> On Wed, Aug 18, 2021 at 1:38 AM Varad Gautam <varad.gautam at
suse.com> wrote:
>>
>> 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/
>
> 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 at suse.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