Re: [Qemu-devel] [PATCH v1 22/22] petalogix-ml605: Make the LMB visible only to the CPU

[Peter Maydell]

On 16 December 2013 14:03, Andreas Färber <address@hidden> wrote:
> Am 16.12.2013 14:29, schrieb Peter Maydell:


> If you leave aside the per-CPU aspect, you could start preparing such
> code today, just no one so far did. ;)
> Seriously, SysBus maps to system memory region, but you can access the
> to-be-mapped region via SysBus API and map it to some private, e.g.
> per-SoC, manually and map that to system MR for the time being.

Yes, definitely. There's just been not much point to it
so far while CPUs all use a single address space.

>> I don't have a strong opinion about the exact details of who
>> is allocating what at what level, but I do think we need to
>> move towards an idea of handing the consumer of an address
>> space be passed an appropriate AS/MR which is constructed
>> by the same thing that creates that consumer.
>
> While I concur with the possibility of a "cascaded" setup of container
> MemoryRegions, let's not forget that apart from SoC/MPCore parent
> realization one important thing that creates devices is device_add
> (user), so we are in need of a mechanism that is generic enough to not
> require per-board and per-bus implementations in order to keep today's
> generic functionality working. Therefore my request for some more
> self-containment while remaining accessible for advanced tweaking. For a
> PCIDevice we can have the PHB take care of handling mapping the bars,
> whereas the CPUState seems to grow a root memory space, so if not the
> CPU, who becomes the owner of that root memory then wrt dynamic creation
> or destruction? The ICC bus seems little suited to me and maintaining
> 15(?) implementations doesn't sound so thrilling to me. HTE.

I would suggest that where we have hot pluggable CPUs this needs
to happen via some kind of bus that encapsulates all the
address regions and interrupt lines that the CPU has that
need connecting to the system. I'm not sure how it works
at the moment but presumably something has to wire the interrupts
up already...

Similarly I think device_add should generally be reserved for
genuinely pluggable interfaces, in which case the interface
should include whatever the MemoryRegion*/AddressSpace* wiring
is, in the same way that it has to include interrupt line wiring
for that sort of bus.

Wiring up a MemoryRegion* should ideally be no harder than
wiring up a qemu_irq; but in general I wouldn't expect command
line access to doing either at a raw low level.

thanks
-- PMM