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

[Avi Kivity <avi@redhat.com>]

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.

> If it needs to call _overlap unconditionally why not
> always call _overlap and drop not _overlap variant?

Other uses need non-overlapping registration.

> >
> >  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.

> 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.