All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Orr <marcorr@google.com>
To: Andrew Jones <drjones@redhat.com>
Cc: Varad Gautam <varad.gautam@suse.com>,
	kvm list <kvm@vger.kernel.org>,
	virtualization@lists.linux-foundation.org,
	Paolo Bonzini <pbonzini@redhat.com>,
	Joerg Roedel <jroedel@suse.de>,
	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: Mon, 16 Aug 2021 20:41:53 -0700	[thread overview]
Message-ID: <CAA03e5GJO4wzp-bxG=zXJOfjgXCd6ZjEfUi-GPjrxhLmfyiNpQ@mail.gmail.com> (raw)
In-Reply-To: <20210816072629.zbxooxhr3mkxuwbx@gator.home>

On Mon, Aug 16, 2021 at 12:26 AM Andrew Jones <drjones@redhat.com> wrote:
>
> On Fri, Aug 13, 2021 at 11:44:39AM -0700, Marc Orr wrote:
> > On Fri, Jul 2, 2021 at 4:48 AM Varad Gautam <varad.gautam@suse.com> wrote:
> > >
> > > This series brings EFI support to a reduced subset of kvm-unit-tests
> > > on x86_64. I'm sending it out for early review since it covers enough
> > > ground to allow adding KVM testcases for EFI-only environments.
> > >
> > > EFI support works by changing the test entrypoint to a stub entry
> > > point for the EFI loader to jump to in long mode, where the test binary
> > > exits EFI boot services, performs the remaining CPU bootstrapping,
> > > and then calls the testcase main().
> > >
> > > Since the EFI loader only understands PE objects, the first commit
> > > introduces a `configure --efi` mode which builds each test as a shared
> > > lib. This shared lib is repackaged into a PE via objdump.
> > >
> > > Commit 2-4 take a trip from the asm entrypoint to C to exit EFI and
> > > relocate ELF .dynamic contents.
> > >
> > > Commit 5 adds post-EFI long mode x86_64 setup and calls the testcase.
> > >
> > > Commit 6 patches out some broken tests for EFI. Testcases that refuse
> > > to build as shared libs are also left disabled, these need some massaging.
> > >
> > > git tree: https://github.com/varadgautam/kvm-unit-tests/commits/efi-stub
> >
> > Thanks for this patchset. My colleague, Zixuan Wang
> > <zixuanwang@google.com>, has also been working to extend
> > kvm-unit-tests to run under UEFI. Our goal is to enable running
> > kvm-unit-tests under SEV-ES.
> >
> > Our approach is a bit different. Rather than pull in bits of the EFI
> > library and Linux EFI ABI, we've elected to build the entire
> > kvm-unit-tests binaries as an EFI app (similar to the ARM approach).
> >
> > 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.
> >
> > We will post our patchset as soon as possible (hopefully by Monday) so
> > that the community can see our approach. We are very eager to see
> > kvm-unit-tests running under SEV-ES (and SNP) and are happy to work
> > with you all on either approach, depending on what the community
> > thinks is the best approach.
> >
> > Thanks in advance,
> > Marc
> >
>
> Hi Marc,
>
> I'm definitely eager to see your approach. I was actually working on
> a second version of EFI support for ARM using the stub approach like
> this series before getting perpetually sidetracked. I've been wanted
> to experiment with Varad's code to continue that, but haven't been
> able to find the time. I'm curious if you considered the stub approach
> as well, but then opted for the app approach in the end. I was
> leaning towards the stub approach to avoid the gnu-efi dependency.

Ack. We never seriously contemplated the stub approach. In hindsight,
I think we were probably biased towards the EFI app approach because
we have some test cases running as UEFI EFI apps internally with great
success (not using the kvm-unit-tests framework though). That being
said, I agree that avoiding the gnu-efi dependency is a win. I also
asked Zixuan, who wrote our patches, if he had an opinion on this. He
said that GNU-EFI provides useful set up code and library functions,
so we do not have to re-implement and debug them in KVM-Unit-Tests.

In any case, we have the patchset ready to post. However, Zixuan ran
into some permission issues when he tried to post the patches because
they are outside of our corporate domain. We'll try to get these
permissions issues fixed up and post the patches tomorrow. If we
cannot get them fixed up, I can always post the patches on his behalf.

Also, we will spend some more time reading Varad's patches this week,
so we can better contrast the stub approach taken by Varad vs. the EFI
app approach that we've taken.

Thanks,
Marc

  reply	other threads:[~2021-08-17  3:42 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 [this message]
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
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='CAA03e5GJO4wzp-bxG=zXJOfjgXCd6ZjEfUi-GPjrxhLmfyiNpQ@mail.gmail.com' \
    --to=marcorr@google.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=pbonzini@redhat.com \
    --cc=thomas.lendacky@amd.com \
    --cc=tmroeder@google.com \
    --cc=varad.gautam@suse.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: link
Be 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.