Re: [Qemu-ppc] [RFC PATCH 1/9] spapr: fix off-by-one error in spapr_ovec_populate_dt()

[Thomas Huth]

On 07.02.2017 03:56, Sam Bobroff wrote:
> The last byte of the option vector was missing due to an off-by-one
> error. Without this fix, client architecture support negotiation will
> fail because the last byte of option vector 5, which contains the MMU
> support, will be missed.
> 
> Signed-off-by: Sam Bobroff <address@hidden>
> ---
>  hw/ppc/spapr_ovec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/ppc/spapr_ovec.c b/hw/ppc/spapr_ovec.c
> index 4f4c090a29..18dbc4a9ac 100644
> --- a/hw/ppc/spapr_ovec.c
> +++ b/hw/ppc/spapr_ovec.c
> @@ -251,7 +251,7 @@ int spapr_ovec_populate_dt(void *fdt, int fdt_offset,
>          }
>      }
>  
> -    return fdt_setprop(fdt, fdt_offset, name, vec, vec_len);
> +    return fdt_setprop(fdt, fdt_offset, name, vec, vec_len + 1);
>  }

It took a while 'til I understood the encoding / length calculation of
the property here, but I think you're right. According to LoPAPR the
total length of the property is n+2 where n is the value of the first
byte. Since n is vec_len-1 in the QEMU code, vec_len+1 is the right
value for the property length.

Reviewed-by: Thomas Huth <address@hidden>