Re: [Qemu-devel] [RFC v4 00/58] Memory API

[Anthony Liguori <anthony@codemonkey.ws>]

On 07/19/2011 08:27 AM, Avi Kivity wrote:
> On 07/19/2011 04:09 PM, Anthony Liguori wrote:
>> On 07/17/2011 06:13 AM, Avi Kivity wrote:
>>> New in this version:
>>> MemoryRegionOps gained .old_mmio and .old_portio members, which allow
>>> reusing old-style callbacks with the new API. All uses were converted,
>>> except for eepro100.c, which uses the same MemoryRegionOps for both
>>> portio and mmio. Some intermediate patches do introduce dispatching
>>> callbacks, but they are removed later.
>>>
>>> Caveats:
>>> - some devices still grab a global memory region instead of inheriting
>>> it from their bus. Seen in the code as #include "exec-memory.h"
>>
>> Could you write up a quick document on how to use this new api for docs/?
>
> Sure. It's pretty simple.

Thanks.

>>
>> There's bits I don't like about the interface
>
> Which bits are these?

Nothing I haven't already commented on.  I think there's too much in the 
generic level.  I don't think coalesced I/O belongs here.  It's a 
concept that doesn't fit.  I think a side-band API would be nicer.

Endianness also seems out of place.  There are many layers that can 
affect final endianness.  It depends on how devices handle endianness 
and also whether the bus modifies endianness.

There are numerous devices that have a register that allows endianness 
to be toggled for the device.  That makes the actual endianness of the 
device dynamic which doesn't fit the memory region API very well IMHO.

>
>> but I think it's a huge improvement over what we have now so I'm
>> inclined to commit once it includes documentation.
>>
>
> My problem is that to start leveraging it, everything must flow through
> it. There are still several hundred call sites that are unconverted.

Really several hundred?  That surprises me.

Regards,

Anthony Liguori

>
> One option is to invert the relationship between ram_addr_t and
> MemoryRegion - implement the former in terms of the latter. That only
> works for uses which don't invoke IO_MEM_UNASSIGNED or address arithmetic.
>