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

[Anthony Liguori <anthony@codemonkey.ws>]

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

For x86, you could easily completely skip the explicit registration and 
just have a direct dispatch to the i440fx and implement something 
slightly more fancy than the above.

And I think this is true for most other types of boards too.

Regards,

Anthony Liguori

>
> Jan
>