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

[Avi Kivity]

On 05/20/2011 05:51 PM, Anthony Liguori wrote:
> > Of course there is overlap. PCI BARs overlap each other, the VGA windows
> > and ROM overlap RAM.
>
>
> Here's what I'm still struggling with:
>
> If children normally overlap their parents, but child priorities are 
> always less than their parents, then what's the benefit of having 
> anything more than two priorities settings.
>
> As far as I can understand it, a priority of 0 means "let children 
> windows overlap" whereas a priority of 1 means "don't let children 
> windows overlap".
>
> Is there a use-case for a priority above 1 and if so, what does it mean?

Children always overlap their parents.  Priorities are among children of 
the same parent.

I expect there won't be a use case for priority 2, but that's not 
because of some inherent property of the design; the hardware designers 
simply haven't got around to designing such whacky hardware.

Note that a container is transparent, so layering several containers on 
top of each other simply generates a flattening of the tree.   You can 
have an opaque container by having a lowest-priority child that covers 
the entire address space.

> > That's what *exactl* what priority means. Which device is in front, and
> > which is in the back.
>
> Why not use registration order to resolve this type of conflict?  What 
> are the use cases to use priorities where registration order wouldn't 
> be adequate?

Registration order is not something you want in a declarative API.  
There is a non-priority equivalent, and that is to unregister 
(_del_subregion) all subregions in the contended region, except the one 
you want.

That doesn't work for PCI, since the "contended region" isn't known.  
You want RAM to hide PCI BARs (or perhaps vice versa), you need to tell 
the system which one takes precedence.


> > > There is no need to have centralized logic to decide this.
> >
> > I think you're completely missing the point of my proposal.
>
> I'm struggling to find the mental model for priorities.  I may just be 
> dense here but the analogy of transparent window ordering isn't 
> helping me.

If you like, you can think of "priority" as "explicit registration 
order".  The advantage is that is works dynamically, if a region is 
unregistered and re-registered, that doesn't mess up your registration 
order.


--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.