Re: [PULL v2 00/35] ppc queue

[Michael Tokarev]

08.09.2023 07:24, Nicholas Piggin wrote:

> > > > Nicholas Piggin (26):
> > > >         target/ppc: Remove single-step suppression inside 0x100-0xf00
> > > >         target/ppc: Improve book3s branch trace interrupt for v2.07S
> > > >         target/ppc: Suppress single step interrupts on rfi-type instructions
> > > >         target/ppc: Implement breakpoint debug facility for v2.07S
> > > >         target/ppc: Implement watchpoint debug facility for v2.07S
> > > >         spapr: implement H_SET_MODE debug facilities
> > > >         ppc/vhyp: reset exception state when handling vhyp hcall
> > > >         ppc/vof: Fix missed fields in VOF cleanup
> > > >         hw/ppc/ppc.c: Tidy over-long lines
> > > >         hw/ppc: Introduce functions for conversion between timebase and 
> > > > nanoseconds
> > > >         host-utils: Add muldiv64_round_up
> > > >         hw/ppc: Round up the decrementer interval when converting to ns
> > > >         hw/ppc: Avoid decrementer rounding errors
> > > >         target/ppc: Sign-extend large decrementer to 64-bits
> > > >         hw/ppc: Always store the decrementer value
> > > >         target/ppc: Migrate DECR SPR
> > > >         hw/ppc: Reset timebase facilities on machine reset
> > > >         hw/ppc: Read time only once to perform decrementer write
> > > >         target/ppc: Fix CPU reservation migration for record-replay
> > > >         target/ppc: Fix timebase reset with record-replay
> > > >         spapr: Fix machine reset deadlock from replay-record
> > > >         spapr: Fix record-replay machine reset consuming too many events
> > > >         tests/avocado: boot ppc64 pseries replay-record test to Linux VFS mount
> > > >         tests/avocado: reverse-debugging cope with re-executing breakpoints
> > > >         tests/avocado: ppc64 reverse debugging tests for pseries and powernv
> > > >         target/ppc: Fix LQ, STQ register-pair order for big-endian
...
> > The decrementer fixes are good candidates but there are quite a few
> > patches and you might encounter conflicts.

So, there are 6 patches in there:

 7798f5c576 hw/ppc: Introduce functions for conversion between timebase and 
nanoseconds
 47de6c4c28 host-utils: Add muldiv64_round_up
 eab0888418 hw/ppc: Round up the decrementer interval when converting to ns
 8e0a5ac878 hw/ppc: Avoid decrementer rounding errors
 c8fbc6b9f2 target/ppc: Sign-extend large decrementer to 64-bits
 febb71d543 hw/ppc: Always store the decrementer value

It all applies cleanly to 8.1 (running ci now), which is fine.
For 8.0 and 7.2 things are a bit fun though.  6th patch (febb71d543)
has minor context conflict with this commit:

commit 17dd1354c1d1aba9caf4af01e11aa7dbe128474f
Author: Nicholas Piggin <npiggin@gmail.com>
Date:   Tue May 30 23:12:13 2023 +1000

    target/ppc: Decrementer fix BookE semantics

Technically, while the two touches nearby areas in
hw/ppc/ppc.c:__cpu_ppc_store_decr(), they don't actually
conflict, it is just the comment context.  But git is unable
to figure this out by its own.  With commit 17dd1354c1d applied,
everything goes flawlessly.  It looks like 17dd1354c1d can be
picked up too for stable just fine, without resorting to context
fixing.

Also, 2 more patches applies cleanly (to 8.1 anyway):

 30d0647bcf hw/ppc: Reset timebase facilities on machine reset
 ea62f8a517 hw/ppc: Read time only once to perform decrementer write

but it does not look like you mean these, esp. ea62f8a517.


> Decrementer I was nervous about since there were quite a lot of
> interacting issues. Decrementer has worked okay for a while, so
> even though there are some bugs, they're mostly in edge cases
> that most OSes don't hit or care so much about.

Ok.

> Possibly the decrementer migration patch could be a candidate.

I'm guessing this is this change:

 578912ad73 target/ppc: Migrate DECR SPR

This one is a bit more difficult.   First it requires the following:

 d5ee641cfc target/ppc: Implement watchpoint debug facility for v2.07S
 14192307ef target/ppc: Implement breakpoint debug facility for v2.07S

which aren't present in 8.1.  And second, I'm not sure for the
migration compatibility here, - will whole thing become unmigratable
between 8.1.0 and some 8.1.x this way?  (and how about 8.1 and 8.2?).

> In any case I would like them to get more testing upstream for
> a while first.

Ok, let's give it a try.

Thanks,

/mjt