Re: [PATCH v3 06/14] xen/riscv: dt_processor_hartid() implementation

[Jan Beulich <jbeulich@xxxxxxxx>]

On 21.05.2025 18:03, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/smpboot.c
> +++ b/xen/arch/riscv/smpboot.c
> @@ -1,5 +1,8 @@
>  #include <xen/cpumask.h>
> +#include <xen/device_tree.h>
> +#include <xen/errno.h>
>  #include <xen/init.h>
> +#include <xen/types.h>
>  #include <xen/sections.h>

Nit: The latter insertion wants to move one line down. Yet then - isn't
xen/stdint.h sufficient here?

> @@ -14,3 +17,69 @@ void __init smp_prepare_boot_cpu(void)
>      cpumask_set_cpu(0, &cpu_possible_map);
>      cpumask_set_cpu(0, &cpu_online_map);
>  }
> +
> +/**
> + * dt_get_hartid - Get the hartid from a CPU device node
> + *
> + * @cpun: CPU number(logical index) for which device node is required
> + *
> + * Return: The hartid for the CPU node or ~0UL if not found.
> + */
> +static unsigned long dt_get_hartid(const struct dt_device_node *cpun)
> +{
> +    const __be32 *cell;
> +    unsigned int ac;
> +    uint32_t len;
> +
> +    ac = dt_n_addr_cells(cpun);
> +    cell = dt_get_property(cpun, "reg", &len);
> +    if ( !cell || !ac || ((sizeof(*cell) * ac) > len) )

Does DT make any guarantees for this multiplication to not overflow?

> +        return ~0UL;
> +
> +    return dt_read_number(cell, ac);
> +}
> +
> +/*
> + * Returns the hartid of the given device tree node, or -ENODEV if the node
> + * isn't an enabled and valid RISC-V hart node.
> + */
> +int dt_processor_hartid(const struct dt_device_node *node,
> +                        unsigned long *hartid)
> +{
> +    const char *isa;
> +    int ret;
> +
> +    if ( !dt_device_is_compatible(node, "riscv") )
> +    {
> +        printk("Found incompatible CPU\n");
> +        return -ENODEV;
> +    }
> +
> +    *hartid = dt_get_hartid(node);
> +    if ( *hartid == ~0UL )
> +    {
> +        printk("Found CPU without CPU ID\n");
> +        return -ENODATA;
> +    }
> +
> +    if ( !dt_device_is_available(node))
> +    {
> +        printk("CPU with hartid=%lu is not available\n", *hartid);

Considering that hart ID assignment is outside of our control, would we
perhaps better (uniformly) log such using %#lx?

> +        return -ENODEV;
> +    }
> +
> +    if ( (ret = dt_property_read_string(node, "riscv,isa", &isa)) )
> +    {
> +        printk("CPU with hartid=%lu has no \"riscv,isa\" property\n", 
> *hartid);
> +        return ret;
> +    }
> +
> +    if ( isa[0] != 'r' || isa[1] != 'v' )
> +    {
> +        printk("CPU with hartid=%lu has an invalid ISA of \"%s\"\n", *hartid,
> +               isa);
> +        return -EINVAL;

As before -EINVAL is appropriate when input arguments have wrong values.
Here, however, you found an unexpected value in something the platform
has presented to you. While not entirely appropriate either, maybe
-ENODEV again (if nothing better can be found)?

Jan