Re: [kvm-unit-tests PATCH 0/4] configure changes and rename --target-efi

From: Alexandru Elisei <alexandru.elisei@arm.com>
To: Sean Christopherson <seanjc@google.com>
Cc: thuth@redhat.com, kvm@vger.kernel.org, zixuanwang@google.com,
	kvmarm@lists.cs.columbia.edu, pbonzini@redhat.com,
	varad.gautam@suse.com
Subject: Re: [kvm-unit-tests PATCH 0/4] configure changes and rename --target-efi
Date: Thu, 10 Feb 2022 17:45:47 +0000	[thread overview]
Message-ID: <YgVPPCTJG7UFRkhQ@monolith.localdoman> (raw)
In-Reply-To: <YgVKmjBnAjITQcm+@google.com>

Hi,

On Thu, Feb 10, 2022 at 05:25:46PM +0000, Sean Christopherson wrote:
> On Thu, Feb 10, 2022, Alexandru Elisei wrote:
> > I renamed --target-efi to --efi-payload in the last patch because I felt it
> > looked rather confusing to do ./configure --target=qemu --target-efi when
> > configuring the tests. If the rename is not acceptable, I can think of a
> > few other options:
> 
> I find --target-efi to be odd irrespective of this new conflict.  A simple --efi
> seems like it would be sufficient.
> 
> > 1. Rename --target to --vmm. That was actually the original name for the
> > option, but I changed it because I thought --target was more generic and
> > that --target=efi would be the way going forward to compile kvm-unit-tests
> > to run as an EFI payload. I realize now that separating the VMM from
> > compiling kvm-unit-tests to run as an EFI payload is better, as there can
> > be multiple VMMs that can run UEFI in a VM. Not many people use kvmtool as
> > a test runner, so I think the impact on users should be minimal.
> 
> Again irrespective of --target-efi, I think --target for the VMM is a potentially
> confusing name.  Target Triplet[*] and --target have specific meaning for the
> compiler, usurping that for something similar but slightly different is odd.

Wouldn't that mean that --target-efi is equally confusing? Do you have
suggestions for other names?

> 
> But why is the VMM specified at ./configure time?  Why can't it be an option to
> run_tests.sh?  E.g. --target-efi in configure makes sense because it currently
> requires different compilation options, but even that I hope we can someday change
> so that x86-64 always builds EFI-friendly tests.  I really don't want to get to a
> point where tests themselves have to be recompiled to run under different VMMs.

Setting the VMM at configure time was initially added to remove a warning
from lib/arm/io.c, where if the UART address if different than what
kvm-unit-tests expects the test would print:

WARNING: early print support may not work. Found uart at 0x1000000, but early base is 0x9000000.

kvmtool emulates a different UART, at a different address than what qemu
emulates, and kvm-unit-tests compares the address found in the DTB with the
qemu UART's address (the address is used to be a #define lib/arm/io.c, now
it's generated at configure time in lib/config.h).

On top of that, configuring kvm-unit-tests to run under kvmtool will also
set CONFIG_ERRATA_FORCE to 1. At the time when kvmtool support was added,
kvmtool didn't have support for running a test with an initrd from which to
extract erratas. This has been recently fixed in kvmtool, now it can run a
test with an initrd.

Thanks,
Alex

> 
> [*] https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Specifying-Target-Triplets.html
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm