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

[Avi Kivity]

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