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 <sam.bobr...@au1.ibm.com> > --- > 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 <th...@redhat.com>