Re: [PATCH v2] target/ppc: Fix 64-bit decrementer

[Peter Maydell]

On Tue, 14 Sept 2021 at 10:47, Cédric Le Goater <clg@kaod.org> wrote:
>
> On 9/14/21 11:19 AM, Peter Maydell wrote:
> > On Tue, 14 Sept 2021 at 09:56, Cédric Le Goater <clg@kaod.org> wrote:
> >>
> >> The current way the mask is built can overflow with a 64-bit decrementer.
> >> Use sextract64() instead.
> >>
> >> Cc: Luis Fernando Fujita Pires <luis.pires@eldorado.org.br>
> >> Fixes: a8dafa525181 ("target/ppc: Implement large decrementer support for 
> >> TCG")
> >> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> >> ---
> >>
> >>  v2: replaced MAKE_64BIT_MASK by sextract64
> >>
> >>  hw/ppc/ppc.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/hw/ppc/ppc.c b/hw/ppc/ppc.c
> >> index 7375bf4fa910..4f14464c9220 100644
> >> --- a/hw/ppc/ppc.c
> >> +++ b/hw/ppc/ppc.c
> >> @@ -876,7 +876,7 @@ static void __cpu_ppc_store_decr(PowerPCCPU *cpu, 
> >> uint64_t *nextp,
> >>      bool negative;
> >>
> >>      /* Truncate value to decr_width and sign extend for simplicity */
> >> -    value &= ((1ULL << nr_bits) - 1);
> >> +    value = sextract64(value, 0, nr_bits);
> >>      negative = !!(value & (1ULL << (nr_bits - 1)));
> >>      if (negative) {
> >>          value |= (0xFFFFFFFFULL << nr_bits);
> >
> > I think these lines that say "if negative then force all the
> > high bits to one" are also no longer required. That is, this
> > entire section of code:
> >     value &= ((1ULL << nr_bits) - 1);
> >     negative = !!(value & (1ULL << (nr_bits - 1)));
> >     if (negative) {
> >         value |= (0xFFFFFFFFULL << nr_bits);
> >     }
> >
> > is an open-coded sign-extension, which can all be replaced with
> > the single line
> >     value = sextract64(value, 0, nr_bits);
>
> 'negative' is used for more tests afterwards but you are right. I will respin
> with more changes.

After the sign-extension you can set 'negative' with
  negative = ((target_long)value) < 0;

PS: passing a negative value into muldiv64() to set the next
timer event (as the existing code does in some cases) seems a bit
odd; this probably ends up with an arithmetic overflow and setting
the next timeout to something unintended. But that's a separate
issue from the bug you're dealing with here.

-- PMM