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

[Avi Kivity]

On 12/14/2011 04:11 PM, Anthony Liguori wrote:
>> In fact I want the ability to create new address spaces.  For example
>> index/data style interfaces, as found in RTC, IOAPIC, and PCI 0xcf8
>> style config space, can be hooked to drive an RTC MemoryRegion, an
>> IOAPIC MemoryRegion, and the PCI config space address space.
>
>
> I think that might be overgeneralizing a bit.  There tends to be a lot
> of weirdness in how register demultiplexing works.
>
> A UART uses a bit to determine whether address 0/1 reads the divisor
> or the thr/ier register.  It also dispatches reads/writes to different
> registers.
>
> Even PCI config space is a bit weird.  The address register always
> needs to have the high bit set, otherwise ~0U is returned.  You could
> do something weird like either offset the address space, or have some
> special logic to handle it, but I think this tends to vary so much
> that you'll end up with a lot of special cases instead of having the
> logic live in the device where it more correctly belongs.

I don't want to hook it directly, instead issue an address_space_read()
or address_space_write() that will go into a separate MemoryRegion
hierarchy.  So the PCI 0xcfc callback,for example, can look at the high
bit, and if set, call address_space_read() on the PCI config address space.

This lets devices expose their config spaces via MemoryRegions, that can
then be directly mapped into the mmio space via mmconfig on newer host
bridges.  If we get a Register class, they can use that too.

>
>>
>>>    We discussed it before and I believe he was planning on adding
>>> itl_shift as a MemoryRegion mutator.
>>
>> I don't think it makes sense as a mutator, can it_shift change
>> dynamically?  But as part of setup, yes.
>>
>>> Avi, did I understand that all correctly?
>>
>> If you mean that the interface between serial.c and isa-serial.c (or
>> however they're renamed) should be MemoryRegions exposed by one and
>> mapped by the other, then yes, I think that's the right interface.
>
> So I guess it's just a question of how to make it work.  I actually
> think the most natural way is to have a MemoryRegion not attached to
> an AddressSpace and have the MemoryRegion bounce requests to another
> MemoryRegion.
>
> I think that violates the basic design of the memory API though.

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).

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