Re: [Qemu-devel] how to handle QOM 'container' objects whose contents depend on QOM properties?

[Peter Maydell <peter.maydell@linaro.org>]

On 7 February 2018 at 16:38, Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 07/02/2018 17:22, Peter Maydell wrote:
>>> Just to understand the context better, when you buy a SoC (presumably as
>>> IP) can you also configure it to hardwire different CPU config signals?
>>
>> Usually if you buy an SoC you're buying the silicon, not
>> the IP. I think the usual case is that the SoC ties the
>> CPU config signals to 0 or 1 (part of the SoC designer's
>> job is configuring the semi-configurable bits of IP the
>> way they want when they put them all together). It would
>> certainly be in theory possible for the SoC to instead
>> route those signals out to pins on the SoC for the board
>> to tie off, but my impression is that's not a likely design
>> choice.
>
> Yeah, that's why I was wondering if buying an SoC as configurable IP was
> a thing at all.  In that case, I would just make things less
> configurable and, if needed, hack the configurability with -global.

So is that a vote for the aspeed style "create N different
QOM types" ?

It doesn't necessarily help with 'armv7m', which isn't an
SoC, but just part of the way we currently model M profile CPUs.
In real hardware, the CPU includes all of the interrupt
controller, timers, etc, which in QEMU are separate
objects to the QEMU CPU object and wrapped up inside
an armv7m container.

(It would I guess be possible to merge the 'armv7m' container
entirely into the QEMU CPU object, so creating the CPU object
gave you an nvic and the mmio register regions to map and so
on. We don't do anything like that for other cpus right now,
though...)

thanks
-- PMM