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

[Jan Kiszka]

On 2011-05-19 15:23, Anthony Liguori wrote:
> On 05/19/2011 01:31 AM, Jan Kiszka wrote:
>> On 2011-05-18 21:10, Anthony Liguori wrote:
>>> On 05/18/2011 10:30 AM, Jan Kiszka wrote:
>>> 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....
>>
>> Actually, things are a bit more complicated: This layer has to properly
>> adopt the coalescing properties of underlying regions or we cause
>> performance regressions to VGA emulation. That means it has to register
>> dispatching slots of the corresponding size and set the coalescing flag
>> accordingly. And it likely need to adjust them as the regions below
>> change.
> 
> As I mentioned in another thread, I don't think we want to "design"
> coalescing into the API.  Coalescing is something that breaks through
> abstractions layers and is really just a hack.

We depend on it for speed, and even if it's nothing to be found in real
HW, we need to design it in as this example demonstrates. The pain of
not doing it, specifically when we go for hierarchical management, will
be much higher.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux