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

[Avi Kivity]

On 07/19/2011 07:05 PM, Avi Kivity wrote:
> On 07/19/2011 05:50 PM, Anthony Liguori wrote:
> > > > 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.
>
> Well, it's impossible to do it in a side band.  When a range that has 
> coalesced mmio is exposed is completely orthogonal to programming the 
> BAR register - it can happen, for example, due to another BAR being 
> removed or the bridge window being programmed.  You can also have a 
> coalesced mmio region being partially clipped.

Of course, it's not really impossible, just clumsy.

You could have

   struct MemoryRegionOps {
        void (*on_mapping_added)(t_p_a_t offset, unsigned nr, const 
AddrRange ranges[]);
        void (*on_mapping_removed)(t_p_a_t offset, unsigned nr, const 
AddrRange ranges[]);
    };

the device callbacks would then compare the added or removed ranges with 
the coalesced mmio ranges needed by the device, and call the kvm 
callbacks as needed.  But that's not something a device model writer 
should do, IMO (same goes for ioeventfd - they are now part of the API 
as well).

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