qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC v5 86/86] 440fx: fix PAM, PCI holes


From: Avi Kivity
Subject: Re: [Qemu-devel] [RFC v5 86/86] 440fx: fix PAM, PCI holes
Date: Mon, 25 Jul 2011 16:14:45 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc15 Thunderbird/3.1.11

On 07/25/2011 04:07 PM, Anthony Liguori wrote:
On 07/20/2011 11:50 AM, Avi Kivity wrote:
The current implementation of PAM and the PCI holes is broken in several
ways:

   - PCI BARs are not restricted to the PCI hole (a BAR may hide memory)

Technically, a BAR can be mapped to any non-RAM memory location.

I understood TOM (Top Of Memory) to be fixed - can't find a register for it - but maybe I misread the spec.


   - PCI devices do not respect PAM (if a PCI device maps a region while
     PAM maps the region to RAM, the request will be honored)

I assume you mean SMM shadowing, right? PAM doesn't cover an area that's ever forwarded to the PCI bus.

No, PAM. And all of the PAM address space is forwarded to the PCI bus (the ROMs are satisfied by PIIX which is a PCI device).

Here at least the spec is clear, see 3.2.18.


This patch fixes things by introducing a pci address space, and using
memory region aliases to represent PAM regions, SMRAM, and PCI holes.

The memory hierarchy looks something like

system_memory
  |
  +--- low memory alias (0-0xe0000000)

According to the spec, PCI memory doesn't start at e00... but rather at the top of RAM. In fact, this is what the spec says:

"The address range from the top of main DRAM to 4 Gbytes (top of physical memory space supported by the 440FX PCIset) is normally mapped to PCI. The PMC forwards all accesses within this address range to PCI. There are two sub-ranges within this address range defined as APIC Configuration Space and High BIOS Address Range."

So the right thing to do is to forward all accesses from low_memory_memsize ... 4GB to the PCI bus.


We could do that.  However what happens if we implement memory hotplug?

Maybe we should implement memory hotplug on a newer chipset anyway.

--
error compiling committee.c: too many arguments to function




reply via email to

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