On Mon, Mar 25, 2019 at 12:25:15PM +0100, Greg Kurz wrote:
> On Mon, 25 Mar 2019 17:38:49 +1100
> David Gibson <da...@gibson.dropbear.id.au> wrote:
>
> > On Fri, Mar 22, 2019 at 07:03:46PM +0100, Greg Kurz wrote:
> > > Even if all ISAs up to v3 indeed mention:
> > >
> > > If the "decrement and test CTR" option is specified (BO2=0), the
> > > instruction form is invalid.
> > >
> > > The UMs of all existing 64-bit server class processors say:
> >
> > I've applied this series because it fixes an immediate problem, but I
> > have some significant reservations about it, read on..
> >
> > > If BO[2] = 0, the contents of CTR (before any update) are used as the
> > > target address and for the test of the contents of CTR to resolve the
> > > branch. The contents of the CTR are then decremented and written back
> > > to the CTR.
> >
> > So, if that's what the hardware does, I guess that's what we need to
> > do. That behaviour seems totally bizarre though - how can it make
> > sense for the same register value to act as both the branch target and
> > a flag/counter? Or am I misreading something?
> >
>
> I must confess this puzzles me as well :-\ ... and the linux commit that
> introduces the use of this opcode, ie. ee13cb249fab ("powerpc/64s: Add
> support for software count cache flush") doesn't provide any details,
> at least for someone ignorant like me :)
Oh... I suspect what's going on here is not actually that the branch
has that effect, but that they've re-used this nonsensical option
combination to mark the special cache count flush they need. In which
case we'd need to not trap, but do something else in the TCG code.
> Maybe Michael can enlight us ?
Michael or Suraj..?
--
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
