Version 3:

 * Splits out MicroBlazeCPUConfig, and moves some values
   out of CPUMBState (env) that are constant configuration
   parameters, or derived from configuration parameters.

 * Do not save configuration parameters with vmstate.
 * Pass around MicroBlazeCPUConfig in the translator.
 * Do not set TARGET_ABI32 in configure.

Version 2:

 * Includes fixes for iflags that could cause lockups.

   It seems it was easier to do so with icount=7, which is what we
   do during the replay acceptance tests.  This causes TBs to contain
   no more than 7 insns, and often less to make up for an incomplete
   count elsewhere.  Which stressed the iflags bits around delay slots
   and imm in ways that pure single-step doesn't.

  * cpu vmstate is filled in
  * interrupt logging is tidied.


r~


Richard Henderson (19):
  target/microblaze: Collected fixes for env->iflags
  target/microblaze: Renumber D_FLAG
  target/microblaze: Cleanup mb_cpu_do_interrupt
  target/microblaze: Rename mmu structs
  target/microblaze: Rename DISAS_UPDATE to DISAS_EXIT
  target/microblaze: Introduce DISAS_EXIT_NEXT, DISAS_EXIT_JUMP
  target/microblaze: Replace cpustate_changed with DISAS_EXIT_NEXT
  target/microblaze: Handle DISAS_EXIT_NEXT in delay slot
  target/microblaze: Force rtid, rted, rtbd to exit
  target/microblaze: Use tcg_gen_lookup_and_goto_ptr
  target/microblaze: Diagnose invalid insns in delay slots
  target/microblaze: Split out MicroBlazeCPUConfig
  target/microblaze: Reorg MicroBlazeCPUConfig to minimize holes
  target/microblaze: Move pvr regs to MicroBlazeCPUConfig
  target/microblaze: Treat pvr_regs as constant
  target/microblaze: Move mmu parameters to MicroBlazeCPUConfig
  target/microblaze: Fill in VMStateDescription for cpu
  target/microblaze: Put MicroBlazeCPUConfig into DisasContext
  configure: Do not set TARGET_ABI32 for microblaze

 configure                           |   1 -
 target/microblaze/cpu.h             |  81 +++++-----
 target/microblaze/mmu.h             |  20 +--
 hw/microblaze/petalogix_ml605_mmu.c |   6 +-
 target/microblaze/cpu.c             | 120 +++++++--------
 target/microblaze/gdbstub.c         |   6 +-
 target/microblaze/helper.c          | 220 +++++++++++++---------------
 target/microblaze/machine.c         | 106 ++++++++++++++
 target/microblaze/mmu.c             |  39 ++---
 target/microblaze/op_helper.c       |   2 +-
 target/microblaze/translate.c       | 198 ++++++++++++++++---------
 target/microblaze/meson.build       |   5 +-
 12 files changed, 482 insertions(+), 322 deletions(-)
 create mode 100644 target/microblaze/machine.c

-- 
2.25.1

On Fri, Sep 04, 2020 at 12:08:23PM -0700, Richard Henderson wrote:
> Version 3:
> 
>  * Splits out MicroBlazeCPUConfig, and moves some values
>    out of CPUMBState (env) that are constant configuration
>    parameters, or derived from configuration parameters.
> 
>  * Do not save configuration parameters with vmstate.
>  * Pass around MicroBlazeCPUConfig in the translator.
>  * Do not set TARGET_ABI32 in configure.
> 
> Version 2:
> 
>  * Includes fixes for iflags that could cause lockups.
> 
>    It seems it was easier to do so with icount=7, which is what we
>    do during the replay acceptance tests.  This causes TBs to contain
>    no more than 7 insns, and often less to make up for an incomplete
>    count elsewhere.  Which stressed the iflags bits around delay slots
>    and imm in ways that pure single-step doesn't.
> 
>   * cpu vmstate is filled in
>   * interrupt logging is tidied.
> 
> 
> r~

Looks good, none of the test issues were relatd. Thanks Richard!

On all the patches I had not previously reviewed:
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Tested-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>

Can you take the pull-req via your trees?

Cheers,
Edgar

On 9/7/20 2:20 AM, Edgar E. Iglesias wrote:
> Looks good, none of the test issues were relatd. Thanks Richard!
> 
> On all the patches I had not previously reviewed:
> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
> Tested-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>

Thanks,

> Can you take the pull-req via your trees?

Yes.


r~