Re: [PATCH 03/16] target/riscv/cpu.c: restrict 'mvendorid' value

[Daniel Henrique Barboza]

On 6/6/23 10:19, Andrew Jones wrote:
> On Tue, May 30, 2023 at 04:46:10PM -0300, Daniel Henrique Barboza wrote:
> > We're going to change the handling of mvendorid/marchid/mimpid by the
> > KVM driver. Since these are always present in all CPUs let's put the
> > same validation for everyone.
> >
> > It doesn't make sense to allow 'mvendorid' to be different than it
> > is already set in named (vendor) CPUs. Generic (dynamic) CPUs can have
> > any 'mvendorid' they want.
> >
> > Change 'mvendorid' to be a class property created via
> > 'object_class_property_add', instead of using the DEFINE_PROP_UINT32()
> > macro. This allow us to define a custom setter for it that will verify,
> > for named CPUs, if mvendorid is different than it is already set by the
> > CPU. This is the error thrown for the 'veyron-v1' CPU if 'mvendorid' is
> > set to an invalid value:
> >
> > $ qemu-system-riscv64 -M virt -nographic -cpu veyron-v1,mvendorid=2
> > qemu-system-riscv64: can't apply global veyron-v1-riscv-cpu.mvendorid=2:
> >      Unable to change veyron-v1-riscv-cpu mvendorid (0x61f)
> >
> > Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
> > ---
> >   target/riscv/cpu.c | 31 ++++++++++++++++++++++++++++++-
> >   1 file changed, 30 insertions(+), 1 deletion(-)
> >
> > diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> > index 72f5433776..bcd69bb032 100644
> > --- a/target/riscv/cpu.c
> > +++ b/target/riscv/cpu.c
> > @@ -1723,7 +1723,6 @@ static void riscv_cpu_add_user_properties(Object *obj)
> >   static Property riscv_cpu_properties[] = {
> >       DEFINE_PROP_BOOL("debug", RISCVCPU, cfg.debug, true),
> >   
> > -    DEFINE_PROP_UINT32("mvendorid", RISCVCPU, cfg.mvendorid, 0),
> >       DEFINE_PROP_UINT64("marchid", RISCVCPU, cfg.marchid, RISCV_CPU_MARCHID),
> >       DEFINE_PROP_UINT64("mimpid", RISCVCPU, cfg.mimpid, RISCV_CPU_MIMPID),
> >   
> > @@ -1810,6 +1809,32 @@ static const struct TCGCPUOps riscv_tcg_ops = {
> >   #endif /* !CONFIG_USER_ONLY */
> >   };
> >   
> > +static bool riscv_cpu_is_dynamic(Object *cpu_obj)
> > +{
> > +    return object_dynamic_cast(cpu_obj, TYPE_RISCV_DYNAMIC_CPU) != NULL;
> > +}
> > +
> > +static void cpu_set_mvendorid(Object *obj, Visitor *v, const char *name,
> > +                              void *opaque, Error **errp)
> > +{
> > +    bool dynamic_cpu = riscv_cpu_is_dynamic(obj);
> > +    RISCVCPU *cpu = RISCV_CPU(obj);
> > +    uint32_t prev_val = cpu->cfg.mvendorid;
> > +    uint32_t value;
> > +
> > +    if (!visit_type_uint32(v, name, &value, errp)) {
> > +        return;
> > +    }
> > +
> > +    if (!dynamic_cpu && prev_val != value) {
> > +        error_setg(errp, "Unable to change %s mvendorid (0x%x)",
> > +                   object_get_typename(obj), prev_val);
> > +        return;
> > +    }
> > +
> > +    cpu->cfg.mvendorid = value;
> > +}
> > +
> >   static void riscv_cpu_class_init(ObjectClass *c, void *data)
> >   {
> >       RISCVCPUClass *mcc = RISCV_CPU_CLASS(c);
> > @@ -1841,6 +1866,10 @@ static void riscv_cpu_class_init(ObjectClass *c, void 
> > *data)
> >       cc->gdb_get_dynamic_xml = riscv_gdb_get_dynamic_xml;
> >       cc->tcg_ops = &riscv_tcg_ops;
> >   
> > +    object_class_property_add(c, "mvendorid", "uint32", NULL,
> > +                              cpu_set_mvendorid,
> > +                              NULL, NULL);
> > +
>
> Shouldn't we provide a get function as well?

We can. I refrain from adding a get() interface because I didn't add new code 
that
access mvendorid via object_property_get_uint(OBJECT(cpu), "mvendorid", errp). 
The
code that access this value uses cpu->cfg.mvendorid directly.

It would be interesting to add a get() interface if cpu->cfg.mvendorid was a 
value
that was read in a different manner that it's stored. It's not the case ATM, so
I only added the set() interface.


Thanks,


Daniel



> >       device_class_set_props(dc, riscv_cpu_properties);
> >   }
> >   
> > --
> > 2.40.1
>
> Otherwise,
>
> Reviewed-by: Andrew Jones <ajones@ventanamicro.com>