qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Avi Kivity
Subject: Re: [Qemu-devel] [RFC] Memory API
Date: Fri, 20 May 2011 12:10:22 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Thunderbird/3.1.10

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]