|
From: | Gavin Shan |
Subject: | Re: [PATCH 3/3] hw/arm/virt: Support host CPU type only when KVM or HVF is configured |
Date: | Thu, 13 Jul 2023 23:16:29 +1000 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 |
Hi Connie, On 7/13/23 22:46, Cornelia Huck wrote:
On Thu, Jul 13 2023, Gavin Shan <gshan@redhat.com> wrote:The CPU type 'host-arm-cpu' class won't be registered until KVM or HVF is configured in target/arm/cpu64.c. Support the corresponding CPU type only when KVM or HVF is configured. Signed-off-by: Gavin Shan <gshan@redhat.com> --- hw/arm/virt.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/hw/arm/virt.c b/hw/arm/virt.c index 43d7772ffd..ad28634445 100644 --- a/hw/arm/virt.c +++ b/hw/arm/virt.c @@ -217,7 +217,9 @@ static const char *valid_cpu_types[] = { #endif ARM_CPU_TYPE_NAME("cortex-a53"), ARM_CPU_TYPE_NAME("cortex-a57"), +#if defined(CONFIG_KVM) || defined(CONFIG_HVF) ARM_CPU_TYPE_NAME("host"), +#endif ARM_CPU_TYPE_NAME("max"), NULL };Doesn't the check in parse_cpu_option() already catch the case where the "host" cpu model isn't registered? I might be getting lost in the code flow, though.
Right, it's guranteed that the needed CPU type (class) is registered by parse_cpu_option(). However, we have different story here. The CPU type invalidation intends to limit the CPU type (class) into a range for the specific machine (board). Taking "cortex-a8-arm-cpu" as an example, it's not expected by hw/arm/virt machines even it has been registered when we have CONFIG_TCG=y. the list of supported CPU type (class) will be dumped by hw/core/machine.c::validate_cpu_type() in PATCH[1], "host" is obviously invalid when we have CONFIG_KVM=n and CONFIG_HVF=n. We can't tell user that "host" is supported, to confuse user. Thanks, Gavin
[Prev in Thread] | Current Thread | [Next in Thread] |