This patchseries resolves issue
https://gitlab.com/qemu-project/qemu/-/issues/1772
which is a report that we don't implement the correct number of MPU
regions on our MPS2/MPS3 boards.  Ideally guest software ought not to
care since (a) it can find out the number of regions by looking at
the MPU_TYPE register and (b) if it wanted 8 MPU regions it can just
ignore the 8 extra ones.  However, Zephyr at least seems both to
hardcode this and to care.

Patch 1 cleans up a bug in target/arm code that meant that we
were accidentally not exposing the pmsav7-dregion on v8M CPUs.

Patches 2 and 3 then define properties on the armv7m object
and the ARMSSE SoC object, and have the mps2-tz.c board code
set the properties appropriately to match the config as
described for those FPGA images.

I have not looked at whether we also get this wrong for the
older (M3, M4, M7) boards in hw/arm/mps2.c.

I suspect we will want to allow users to reenable the old wrong
behaviour if they had guest images built to run on QEMU and not
tested on the real hardware.  There are some notes in patch 3's
commit message about that: with this series you can do that
using the -global option, but this might not be the best way.

thanks
-- PMM

Peter Maydell (3):
  target/arm: Do all "ARM_FEATURE_X implies Y" checks in post_init
  hw/arm/armv7m: Add mpu-ns-regions and mpu-s-regions properties
  hw/arm: Set number of MPU regions correctly for an505, an521, an524

 include/hw/arm/armsse.h |   5 ++
 include/hw/arm/armv7m.h |   8 ++
 hw/arm/armsse.c         |  16 ++++
 hw/arm/armv7m.c         |  21 +++++
 hw/arm/mps2-tz.c        |  29 +++++++
 target/arm/cpu.c        | 176 +++++++++++++++++++++-------------------
 6 files changed, 173 insertions(+), 82 deletions(-)

-- 
2.34.1

On Mon, 24 Jul 2023 at 18:43, Peter Maydell <peter.maydell@linaro.org> wrote:
>
> This patchseries resolves issue
> https://gitlab.com/qemu-project/qemu/-/issues/1772
> which is a report that we don't implement the correct number of MPU
> regions on our MPS2/MPS3 boards.  Ideally guest software ought not to
> care since (a) it can find out the number of regions by looking at
> the MPU_TYPE register and (b) if it wanted 8 MPU regions it can just
> ignore the 8 extra ones.  However, Zephyr at least seems both to
> hardcode this and to care.
>
> Patch 1 cleans up a bug in target/arm code that meant that we
> were accidentally not exposing the pmsav7-dregion on v8M CPUs.
>
> Patches 2 and 3 then define properties on the armv7m object
> and the ARMSSE SoC object, and have the mps2-tz.c board code
> set the properties appropriately to match the config as
> described for those FPGA images.

Ping for review on patch 3, please ?

thanks
-- PMM

On Mon, 24 Jul 2023 at 18:43, Peter Maydell <peter.maydell@linaro.org> wrote:
>
> This patchseries resolves issue
> https://gitlab.com/qemu-project/qemu/-/issues/1772
> which is a report that we don't implement the correct number of MPU
> regions on our MPS2/MPS3 boards.  Ideally guest software ought not to
> care since (a) it can find out the number of regions by looking at
> the MPU_TYPE register and (b) if it wanted 8 MPU regions it can just
> ignore the 8 extra ones.  However, Zephyr at least seems both to
> hardcode this and to care.
>
> Patch 1 cleans up a bug in target/arm code that meant that we
> were accidentally not exposing the pmsav7-dregion on v8M CPUs.
>
> Patches 2 and 3 then define properties on the armv7m object
> and the ARMSSE SoC object, and have the mps2-tz.c board code
> set the properties appropriately to match the config as
> described for those FPGA images.
>
> I have not looked at whether we also get this wrong for the
> older (M3, M4, M7) boards in hw/arm/mps2.c.

I checked up on this, and for these cores the hardware
is not configurable -- they always have 8 MPU regions,
which is the way our models of them are set up. So these
boards (mps2-an385, -an386, -an500, -an511) are fine.

thanks
-- PMM