On 8/19/21 3:32 AM, Marc Orr wrote: > On Wed, Aug 18, 2021 at 1:38 AM Varad Gautam <varad.gautam@xxxxxxxx> 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@xxxxxxx> 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@xxxxxxxxxx/ >> [2] https://lore.kernel.org/r/20210818000905.1111226-10-zixuanwang@xxxxxxxxxx/ > > 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@xxxxxxxx/ [2] https://lore.kernel.org/r/20210818000905.1111226-10-zixuanwang@xxxxxxxxxx/ 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
