qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v4 16/19] target/riscv/cpu.c: create KVM mock properties


From: Andrew Jones
Subject: Re: [PATCH v4 16/19] target/riscv/cpu.c: create KVM mock properties
Date: Tue, 27 Jun 2023 10:11:16 +0200

On Mon, Jun 26, 2023 at 07:02:06PM -0300, Daniel Henrique Barboza wrote:
> KVM-specific properties are being created inside target/riscv/kvm.c. But
> at this moment we're gathering all the remaining properties from TCG and
> adding them as is when running KVM. This creates a situation where
> non-KVM properties are setting flags to 'true' due to its default
> settings (e.g.  Zawrs). Users can also freely enable them via command
> line.
> 
> This doesn't impact runtime per se because KVM doesn't care about these
> flags, but code such as riscv_isa_string_ext() take those flags into
> account. The result is that, for a KVM guest, setting non-KVM properties
> will make them appear in the riscv,isa DT.
> 
> We want to keep the same API for both TCG and KVM and at the same time,
> when running KVM, forbid non-KVM extensions to be enabled internally. We
> accomplish both by changing riscv_cpu_add_user_properties() to add a
> mock/no-op boolean property for every non-KVM extension in
> riscv_cpu_extensions[]. Then, when running KVM, users are still free to
> set extensions at will, we'll treat non-KVM extensions as a no-op, and
> riscv_isa_string_ext() will not report bogus extensions in the DT.

We're no longer treating these as no-ops. We're now intercepting attempts
to set unsupported extensions and erroring out.

> 
> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
> ---
>  target/riscv/cpu.c | 40 +++++++++++++++++++++++++++++++++++++---
>  1 file changed, 37 insertions(+), 3 deletions(-)
> 
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index b65db165cc..ad4b0e3490 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -1720,6 +1720,22 @@ static Property riscv_cpu_extensions[] = {
>      DEFINE_PROP_END_OF_LIST(),
>  };
>  
> +
> +static void cpu_set_cfg_noop(Object *obj, Visitor *v,

As stated above, I don't think 'noop' conveys the right message.

> +                             const char *name,
> +                             void *opaque, Error **errp)
> +{
> +    const char *propname = opaque;
> +    bool value;
> +
> +    if (!visit_type_bool(v, name, &value, errp)) {
> +        return;
> +    }
> +

We should only error out when value == true. Just like the other
KVM-unsupported extensions, we don't mind if the user explicitly
disables something we can't handle.

> +    error_setg(errp, "extension %s is not available with KVM",
> +               propname);
> +}
> +
>  /*
>   * Add CPU properties with user-facing flags.
>   *
> @@ -1738,9 +1754,27 @@ static void riscv_cpu_add_user_properties(Object *obj)
>      riscv_cpu_add_misa_properties(obj);
>  
>      for (prop = riscv_cpu_extensions; prop && prop->name; prop++) {
> -        /* Check if KVM didn't create the property already */
> -        if (object_property_find(obj, prop->name)) {
> -            continue;
> +        if (riscv_running_kvm()) {
> +            /* Check if KVM didn't create the property already */

The check is for the positive, so I think the comment would read better as

 "Check if KVM created the property already."

> +            if (object_property_find(obj, prop->name)) {
> +                continue;
> +            }
> +
> +            /*
> +             * Set every multi-letter extension that KVM doesn't
> +             * know as a no-op. This will allow users to set values

How about "Set the default to disabled for every extension unknown to
KVM and error out if the user attempts to enable any of them."


> +             * to them while keeping their internal state to 'false'.
> +             *
> +             * We're giving a pass for non-bool properties since they're
> +             * not related to the availability of extensions and can be
> +             * safely ignored as is.

I guess that's OK for now. Ideally, we wouldn't have any non-booleans as
that will complicate QMP cpu model expansion. Instead, we'd have booleans
for valid values. For example, for vlen, we'd have vlen128, vlen256,
vlen512, etc.. Figuring out how to do that best is for another series
though.

> +             */
> +            if (prop->info == &qdev_prop_bool) {
> +                object_property_add(obj, prop->name, "bool",
> +                                    NULL, cpu_set_cfg_noop,
> +                                    NULL, (void *)prop->name);
> +                continue;
> +            }
>          }
>  
>          qdev_property_add_static(dev, prop);
> -- 
> 2.41.0
>

Thanks,
drew



reply via email to

[Prev in Thread] Current Thread [Next in Thread]