Re: [Qemu-devel] [RFC] Plan for moving forward with QOM

[Avi Kivity <avi@redhat.com>]

On 12/14/2011 04:46 PM, Anthony Liguori wrote:
>> Well, that's exactly what I had in mind (except that you'd bounce the
>> I/O to an AddressSpace, which takes care of preparing the dispatch
>> tables etc. instead of searching dynamically through the hierarchy).
>
>
> But the I/O table for the AddressSpace would be independent of the
> system/io address space tables, correct?

Correct.  We'd have N address spaces; mmio would dispatch into the
first, pio into the second, and we'd have manual dispatch for the others.

>
> For these sort of virtual AddressSpaces, do we care about flattening
> things?
>
> For the serial device, you would:
>
> 1) Create a memory region using some form of addressing that makes
> sense for your device.  For serial, it would be a 0-8 single byte
> addressing.
>
> 2) Create a virtual AddressSpace, add the MemoryRegion from (1) to the
> AddressSpace
>
> 3) Export the AddressSpace from your device.  Serial would then expose
> an AddressSpace, not a MemoryRegion
>
> 4) MMSerial would create a MemoryRegion that implemented itl_shift by
> calling into the Serial device's AddressSpace
>
> Is this right?
>
> Honestly, it seems a bit complex to me without an obvious benefit. 
> The use of AddressSpace seems to be overkill since we really don't
> care about creating a linear table for the Serial device.

For serial, yes.  Just use it_shift during initialization.

>
> I actually think relaxing the requirement for MemoryRegions to be
> associated with an AddressSpace and having the ability to bounce from
> one MR to another is a bit more straight forward (with perhaps a loss
> in elegance).

It means duplicating the dispatch path; having an optimized path through
a radix tree and a dynamic path which walks the MemoryRegion tree and
considers ranges and priorities; this reduces maintainability.

Creating an address space and associating it with a MemoryRegion should
be one call, I don't think it will be that much of a burden.

-- 
error compiling committee.c: too many arguments to function