| Message ID | 900ea185630c17f315c4984b2a595b2d3fba7c9a.1486436186.git.sam.bobroff@au1.ibm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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.bobroff@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 <thuth@redhat.com>
Quoting Sam Bobroff (2017-02-06 20:56:44) > 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.bobroff@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); > } > > void spapr_ovec_ruler(int width, sPAPROptionVector *ov) > -- > 2.11.0 > I noticed this working on another series and ended up with the same fix. The patch doesn't apply cleanly for me though due to the "spapr_ovec_ruler" reference. But, assuming that is unrelated to this series: Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com>
On Tue, Feb 07, 2017 at 04:12:47PM -0600, Michael Roth wrote: > Quoting Sam Bobroff (2017-02-06 20:56:44) > > 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.bobroff@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); > > } > > > > void spapr_ovec_ruler(int width, sPAPROptionVector *ov) > > -- > > 2.11.0 > > > > I noticed this working on another series and ended up with the same fix. > > The patch doesn't apply cleanly for me though due to the "spapr_ovec_ruler" > reference. But, assuming that is unrelated to this series: > > Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com> You're corret, that line is unrelated. Thanks! Sam.
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.bobroff@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 <thuth@redhat.com> This is a correct fix regardless of the rest of the series, so I've applied it to ppc-for-2.9.
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); } void spapr_ovec_ruler(int width, sPAPROptionVector *ov)
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.bobroff@au1.ibm.com> --- hw/ppc/spapr_ovec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)