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

[Avi Kivity <avi@redhat.com>]

On 05/19/2011 04:35 PM, Anthony Liguori wrote:
> On 05/19/2011 08:26 AM, Avi Kivity wrote:
>> On 05/19/2011 04:23 PM, Anthony Liguori wrote:
>>>> 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.
>>
>> It's impossible not to design it into the API. The layer which wants to
>> do coalescing (the device) has no idea if and where its memory is 
>> mapped.
>
> There's two places coalescing currently matters: VGA and PCI devices. 
> Since VGA is just a special PCI device, let's just focus on PCI devices.
>
> The PCI bus knows exactly where the memory is mapped. 

The PCI bus doesn't know about coalescing.  Only the device does.  Look 
at e1000 for an example.  Cirrus also enables/disables coalescing 
dynamically.

> Yes, if you have complex IOMMU hierarchies it doesn't, but this is my 
> point.  We don't need to design coalesced IO to support these sort of 
> complex hierarchies.
>

Are we aiming at our own feet again?

Look at the API, it adds three functions that non-users need not care about.

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