| Message ID | 20230713054502.410911-4-gshan@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | hw/arm/virt: Use generic CPU invalidation | expand |
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.
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
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 };
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(+)