Re: [PATCH] hw/arm: Add 'virtm' hardware

[Peter Maydell]

On Fri, 26 Jun 2020 at 17:40, Keith Packard <keithp@keithp.com> wrote:
>
> Peter Maydell <peter.maydell@linaro.org> writes:
>
> > So, I'm really dubious about adding more "virtual"
> > not-real-hardware boards. We have "virt" because we
> > absolutely have to have it for KVM purposes; but otherwise
> > "emulate real hardware" gives us a concrete specification
> > of what we're trying to do and tends to lead us into fewer
> > messy swamps than making up virtual platforms does.
>
> It depends on what you're using qemu for. I'm using it for C library
> tests, where I need memory and a processor, plus the ability to make
> semihosting calls and that's it.

You might find the user-mode qemu-arm sufficient for that
kind of thing. I know some gcc tests run that way. You
get a processor, semihosting, and whatever memory your
ELF file's data segment says you have (plus anything
you care to mmap()).

> > For instance, this board model claims to handle the M33
> > but makes no attempt to set up any of the TrustZone
> > related components like the IDAU, so it isn't really
> > a useful platform for that CPU.
>
> It's sufficient for my purposes, if adding those things would make it
> suitable for more people, that'd be awesome.

Sure, but "machine-that-works-for-keith-packard" isn't really
a very clearly-defined concept :-)

> > This is the kind of area where having a real hardware system to check
> > against means we make the right choices about what does or doesn't
> > need to be present.
>
> I have tried every single 32-bit ARM emulation provided by qemu and none
> of them offer enough memory along with the ability to select an
> arbitrary processor. The stellaris code is the closest as it allows
> overriding the CPU type, and I've been able to run most of the C library
> tests using that. However, both boards supported by that code have a
> small fixed memory size, which isn't large enough to run the full test
> suite (the math tests require over 1M of ROM and RAM).

> Instead of creating another virtual platform, should I be working on the
> existing virt code to add cortex-m support?

I think that trying to weld M-profile into the A-profile virt
board is likely to be more confusing than having a separate board.
But I remain unhappy about defining a virtual board at all
if I can avoid it.

thanks
-- PMM