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

[Gleb Natapov <gleb@redhat.com>]

On Thu, May 19, 2011 at 03:02:09PM +0300, Avi Kivity wrote:
> On 05/19/2011 02:58 PM, Gleb Natapov wrote:
> >>
> >>  Devices shall register their regions with the bus. Every device is on
> >>  some bus, so that's not a problem. And we can then provide registration
> >>  handlers at bus level that either implement specific logic or just
> >>  forward the request to the next hierarchy level (default handler).
> >>
> >Yes, I agree with that. I just don't see the need for "priority" parameter
> >in this model.
> 
> Priority allows you to register RAM from 0-EOM and overlay it with
> the ROM and VGA windows as necessary.  It also allows PCI to
> override RAM (or vice versa, however we decide).
> 
> Sure, you can let the caller chop the various regions manually in
> the first case, but it's just extra work that can be done in common
> code.  And it cannot be done at all for the second case, if RAM
> overrides PCI (the PCI bus doesn't know how to chop BARs).
> 

In the model described by Jan no device or bus (except system bus)
will call memory API directly. Instead each device will call memory
registration function of its bus and the bus will call memory registration
function of a device that provides the bus and so on up to the system bus
(maps nicely to qdev!). Each level knows by itself (and only it really
knows!) how to solve the overlapping, but it can't provide meaningful
priority to the layer above since only layer above knows what are relative
priority between siblings (e.g only chipset knows that it will forward
access to particular address to RAM and not PCI, no matter that PCI bus
asked for priority 100 and RAM asked for 0).

So it boils down to this: since chopping will have to happen at each
level of the hierarchy I do not see why the lowest level of the hierarchy
should be made special.

--
			Gleb.