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

[Gleb Natapov]

On Fri, May 20, 2011 at 12:10:22PM +0300, Avi Kivity wrote:
> On 05/19/2011 09:22 PM, Gleb Natapov wrote:
> >>
> >>  BARs may overlap with other BARs or with RAM. That's well-known, so PCI
> >>  bridged need to register their regions with the _overlap variant
> >>  unconditionally. In contrast to the current PhysPageDesc mechanism, the
> >With what priority?
> 
> It doesn't matter, since the spec doesn't define priorities among PCI BARs.
> 
And among PCI BAR and memory (the case the question above referred too).

> >If it needs to call _overlap unconditionally why not
> >always call _overlap and drop not _overlap variant?
> 
> Other uses need non-overlapping registration.
And who prohibit them from creating one?

> 
> >>
> >>  And they do not need to. The APIC regions will be managed by the per-CPU
> >>  region management, reusing the tool box we need for all bridges. It will
> >>  register the APIC page with a priority higher than the default one, thus
> >>  overriding everything that comes from the host bridge. I think that
> >>  reflects pretty well real machine behaviour.
> >>
> >What is "higher"? How does it know that priority is high enough?
> 
> It is well known that 1 > 0, for example.
> 
That is if you have global scale. In the case I am asking about you do
not. Even if PCI will register memory region that overlaps APIC address
with priority 1000 APIC memory region should still be able to override
it even with priority 0. Voila 1000 < 0? Where is your sarcasm now? :)

But Jan already answered this one. Actually what really matters is the
place of the node in a topology, not priority. But then for all of this
to make sense registration has to be hierarchical.

> >I
> >thought, from reading other replies, that priorities are meaningful
> >only on the same hierarchy level (which kinda make sense), but now you
> >are saying that you will override PCI address from another part of
> >the topology?
> 
> -- per-cpu memory
>     |
>     +--- apic page (prio 1)
>     |
>     +--- global memory (prio 0)
> 
> -- 
> I have a truly marvellous patch that fixes the bug which this
> signature is too narrow to contain.

--
                        Gleb.