On Tue, Feb 07, 2017 at 04:47:53PM +0100, Thomas Huth wrote: > 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>
This is a correct fix regardless of the rest of the series, so I've
applied it to ppc-for-2.9.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
