From: Varad Gautam <varad.gautam@suse.com> To: Marc Orr <marcorr@google.com> Cc: Joerg Roedel <jroedel@suse.de>, 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: Thu, 19 Aug 2021 13:36:26 +0200 [thread overview] Message-ID: <ffae117c-4961-c0de-1f17-7092b7bc3d65@suse.com> (raw) In-Reply-To: <CAA03e5H6mM0z5r4knbjHDLS4svLP6WQuhC_5BnSgCyXpRZgqAQ@mail.gmail.com> On 8/19/21 3:32 AM, Marc Orr wrote: > On Wed, Aug 18, 2021 at 1:38 AM Varad Gautam <varad.gautam@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@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@google.com/ >> [2] https://lore.kernel.org/r/20210818000905.1111226-10-zixuanwang@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@suse.com/ [2] https://lore.kernel.org/r/20210818000905.1111226-10-zixuanwang@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
WARNING: multiple messages have this Message-ID (diff)
From: Varad Gautam via Virtualization <virtualization@lists.linux-foundation.org> To: Marc Orr <marcorr@google.com> Cc: "Lendacky, Thomas" <thomas.lendacky@amd.com>, Andrew Jones <drjones@redhat.com>, Joerg Roedel <jroedel@suse.de>, "Singh, Brijesh" <brijesh.singh@amd.com>, kvm list <kvm@vger.kernel.org>, Tom Roeder <tmroeder@google.com>, "Hyunwook \(Wooky\) Baek" <baekhw@google.com>, virtualization@lists.linux-foundation.org, Zixuan Wang <zixuanwang@google.com>, Erdem Aktas <erdemaktas@google.com>, Paolo Bonzini <pbonzini@redhat.com>, bp@suse.de Subject: Re: [kvm-unit-tests PATCH 0/6] Initial x86_64 UEFI support Date: Thu, 19 Aug 2021 13:36:26 +0200 [thread overview] Message-ID: <ffae117c-4961-c0de-1f17-7092b7bc3d65@suse.com> (raw) In-Reply-To: <CAA03e5H6mM0z5r4knbjHDLS4svLP6WQuhC_5BnSgCyXpRZgqAQ@mail.gmail.com> On 8/19/21 3:32 AM, Marc Orr wrote: > On Wed, Aug 18, 2021 at 1:38 AM Varad Gautam <varad.gautam@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@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@google.com/ >> [2] https://lore.kernel.org/r/20210818000905.1111226-10-zixuanwang@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@suse.com/ [2] https://lore.kernel.org/r/20210818000905.1111226-10-zixuanwang@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 _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
next prev parent reply other threads:[~2021-08-19 11:36 UTC|newest] Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-02 11:48 [kvm-unit-tests PATCH 0/6] Initial x86_64 UEFI support Varad Gautam 2021-07-02 11:48 ` Varad Gautam via Virtualization 2021-07-02 11:48 ` [kvm-unit-tests PATCH 1/6] x86: Build tests as PE objects for the EFI loader Varad Gautam 2021-07-02 11:48 ` Varad Gautam via Virtualization 2021-07-02 11:48 ` [kvm-unit-tests PATCH 2/6] x86: Call efi_main from _efi_pe_entry Varad Gautam 2021-07-02 11:48 ` Varad Gautam via Virtualization 2021-07-02 11:48 ` [kvm-unit-tests PATCH 3/6] x86: efi_main: Get EFI memory map and exit boot services Varad Gautam 2021-07-02 11:48 ` Varad Gautam via Virtualization 2021-07-02 11:48 ` [kvm-unit-tests PATCH 4/6] x86: efi_main: Self-relocate ELF .dynamic addresses Varad Gautam 2021-07-02 11:48 ` Varad Gautam via Virtualization 2021-07-02 11:48 ` [kvm-unit-tests PATCH 5/6] cstart64.S: x86_64 bootstrapping after exiting EFI Varad Gautam 2021-07-02 11:48 ` Varad Gautam via Virtualization 2021-07-02 11:48 ` [kvm-unit-tests PATCH 6/6] x86: Disable some breaking tests for EFI and modify vmexit test Varad Gautam 2021-07-02 11:48 ` Varad Gautam via Virtualization 2021-07-12 16:29 ` [kvm-unit-tests PATCH 0/6] Initial x86_64 UEFI support Andrew Jones 2021-07-12 16:29 ` Andrew Jones 2021-08-13 18:44 ` Marc Orr 2021-08-16 7:26 ` Andrew Jones 2021-08-16 7:26 ` Andrew Jones 2021-08-17 3:41 ` Marc Orr 2021-08-17 10:49 ` Joerg Roedel 2021-08-17 10:49 ` Joerg Roedel 2021-08-18 1:52 ` Marc Orr 2021-08-18 8:38 ` Varad Gautam 2021-08-18 8:38 ` Varad Gautam via Virtualization 2021-08-19 1:32 ` Marc Orr 2021-08-19 1:42 ` Nadav Amit 2021-08-19 1:42 ` Nadav Amit 2021-08-19 1:54 ` Zixuan Wang 2021-08-19 11:36 ` Varad Gautam [this message] 2021-08-19 11:36 ` Varad Gautam via Virtualization 2021-08-20 17:29 ` Marc Orr
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=ffae117c-4961-c0de-1f17-7092b7bc3d65@suse.com \ --to=varad.gautam@suse.com \ --cc=baekhw@google.com \ --cc=bp@suse.de \ --cc=brijesh.singh@amd.com \ --cc=drjones@redhat.com \ --cc=erdemaktas@google.com \ --cc=jroedel@suse.de \ --cc=kvm@vger.kernel.org \ --cc=marcorr@google.com \ --cc=pbonzini@redhat.com \ --cc=thomas.lendacky@amd.com \ --cc=tmroeder@google.com \ --cc=virtualization@lists.linux-foundation.org \ --cc=zixuanwang@google.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.