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: Sun, 22 May 2011 10:56:33 +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/20/2011 03:08 PM, Gleb Natapov wrote:
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).

One of them gets priority 0, the other gets priority 1. Depending on who should win according to the spec.


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

Nothing.

>
>  >>
>  >>   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? :)

This can be done in two ways:

1. Assign APIC the highest priority. Priority is not determined by the guest, but by qemu. Problem solved.
2. Use a hierarchy:


root
  |
  +-- RAM (prio 0)
  |
  +-- PCI (prio 1, lots of children)
  |
  +-- APIC (prio 2)


Nothing under the PCI subregion can obscure the APIC.


But Jan already answered this one. Actually what really matters is the
place of the node in a topology, not priority.

You need priority for the children of the same parent.

  But then for all of this
to make sense registration has to be hierarchical.

Well, that's the whole point.

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