Re: [Qemu-devel] [RFC] Memory API

[Avi Kivity <avi@redhat.com>]

On 05/18/2011 10:10 PM, Anthony Liguori wrote:
> On 05/18/2011 10:30 AM, Jan Kiszka wrote:
>> On 2011-05-18 17:17, Peter Maydell wrote:
>>> On 18 May 2011 16:11, Jan Kiszka<jan.kiszka@siemens.com>  wrote:
>>>> On 2011-05-18 16:36, Avi Kivity wrote:
>>>>> There is nothing we can do with a return code.  You can't fail an 
>>>>> mmio
>>>>> that causes overlapping physical memory map.
>>>>
>>>> We must fail such requests to make progress with the API. That may
>>>> happen either on caller side or in cpu_register_memory_region itself
>>>> (hwerror). Otherwise the new API will just be a shiny new facade 
>>>> for on
>>>> old and still fragile building.
>>>
>>> If we don't allow overlapping regions, then how do you implement
>>> things like "on startup board maps ROM into lower addresses
>>> over top of devices, but later it is unmapped and you can see
>>> the underlying devices" ? (You can't currently do this AFAIK,
>>> and it would be nice if the new API supported it.)
>>
>> Right, we can't do this properly, and that's why the attempt if the
>> i440fx chipset model is so horribly broken ATM.
>>
>> Just allowing overlapping does not solve this problem either. It does
>> not specify what region is on top and what is below (even worse if
>> multiple regions overlap at the place).
>>
>> We need some managing instance here, and that is e.g. the chipset that
>> provide control over the overlap in reality. It could hook up a
>> PhysMemClient to receive and redirect updates to subregions, or only
>> allow to register them in disabled state.
>
> I think that gets ugly pretty fast.  The way this works IRL is that 
> all I/O dispatches pass through the chipset.  You literally need 
> something as simple as:
>
> static void i440fx_io_intercept(void *opaque, uint64_t addr, uint32_t 
> value, int size, MemRegion *next)
> {
>     I440FX *s = opaque;
>
>     if (range_overlaps(addr, size, PAM_REGION)) {
>         ...
>     } else {
>         dispatch_io(next, addr, value, size);
>     }
> }
>
> There's no need for an explicit intercept mechanism if you make 
> multiple levels have their own dispatch tables and register 
> progressively larger regions.  In fact....
>
> You really don't need to register 90% of the time.  In the case of a 
> PC with i440fx, it's really quite simple:
>
> if an I/O is to the APIC page,
>    it's handled by the APIC
> elif the I/O is in ROM regions:
>    if PAM RE or WE
>       redirect to RAM appropriately
>    else:
>       send to ROMs
> elif the I/O is in the PCI windows:
>    send to the PCI bus
> else:
>    send to the PIIX3
>

Memory regions do the exact same thing, except at registration time.  
The nested if/elif/else tree is captured in the nested region tree.

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