On Fri, 26 Apr 2019 00:51:56 +0800
x00249684 <xuw...@huawei.com> wrote:
> Hi Igor,
>
> +static void test_acpi_virt_tcg(void)
> +{
> + test_data data = {
> + .machine = "virt",
> + .uefi_fl1 = "pc-bios/edk2-aarch64-code.fd",
> + .uefi_fl2 = "pc-bios/edk2-arm-vars.fd",
> + .cd =
> "tests/data/uefi-boot-images/bios-tables-test.aarch64.iso.qcow2",
> + .ram_start = 0x40000000ULL,
> + .scan_len = 128ULL * 1024 * 1024,
> + };
> +
> + test_acpi_one("-cpu cortex-a57 ", &data);
>
> Replaced the cortex-a57 with host and succesfully tested on the hisilicon
> arm64
> D05 board. Otherwise it failed with "kvm_init_vcpu failed: Invalid argument".
> Is it possilbe to set the cpu type like numa-test.c?
I think it works with numa-test because it uses TCG only but in case of
bios-tables-test
it uses accel="kvm:tcg" to leverage KVM capabilities whenever possible to speed
up test.
Now back to our ARM test case, uefi requirement is to use 64bit CPU (hence it
was cortex-a57)
however unlike x86 it obviously breaks since KVM accelerator on ARM host is used
and it doesn't work with anything other than 'host' cpu model.
I think we still want to use KVM whenever possible, but problem lies in that
user (testcase) doesn't have an idea if KVM accelerator is available and host
is 64 CPU.
to sum up we need to support 2 modes:
1. host is 64 ARM, use kvm with -cpu host
2. all other cases use tcg with -cpu cortex-a57
I can hack to probe if /dev/kvm is accessible and host is 64 bit and use #1
otherwise fallback to #2
or as quick fix do only #2 initially and think about a better solution to #1
Is there any other suggestions/opinions how to approach issue/proceed.
PS:
we probably would like to reuse this not only for acpi tests but also for other
arm/virt test cases that involve running guest code.
> Thanks!
>
> Best Regards,
> Wei
