summaryrefslogtreecommitdiffstats
path: root/kernel
diff options
context:
space:
mode:
authorKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>2011-06-16 13:07:19 -0400
committerKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>2011-06-16 13:51:32 -0400
commitacd049c6e99d2ad1195666195230f6881d1c1588 (patch)
tree5ab67647e7726236d9e936259bb4c68ffb0431a5 /kernel
parentb2abe50688dcb470e2e46109da7e7e02245ed59b (diff)
downloadop-kernel-dev-acd049c6e99d2ad1195666195230f6881d1c1588.zip
op-kernel-dev-acd049c6e99d2ad1195666195230f6881d1c1588.tar.gz
xen/setup: Fix for incorrect xen_extra_mem_start.
The earlier attempts (24bdb0b62cc82120924762ae6bc85afc8c3f2b26) at fixing this problem caused other problems to surface (PV guests with no PCI passthrough would have SWIOTLB turned on - which meant 64MB of precious contingous DMA32 memory being eaten up per guest). The problem was: "on xen we add an extra memory region at the end of the e820, and on this particular machine this extra memory region would start below 4g and cross over the 4g boundary: [0xfee01000-0x192655000) Unfortunately e820_end_of_low_ram_pfn does not expect an e820 layout like that so it returns 4g, therefore initial_memory_mapping will map [0 - 0x100000000), that is a memory range that includes some reserved memory regions." The memory range was the IOAPIC regions, and with the 1-1 mapping turned on, it would map them as RAM, not as MMIO regions. This caused the hypervisor to complain. Fortunately this is experienced only under the initial domain so we guard for it. Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Diffstat (limited to 'kernel')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud