• Zhang, Fengzhe's avatar
    xen/setup: Inhibit resource API from using System RAM E820 gaps as PCI mem gaps. · 2f14ddc3
    Zhang, Fengzhe authored
    With the hypervisor argument of dom0_mem=X we iterate over the physical
    (only for the initial domain) E820 and subtract the the size from each
    E820_RAM region the delta so that the cumulative size of all E820_RAM regions
    is equal to 'X'. This sometimes ends up with E820_RAM regions with zero size
    (which are removed by e820_sanitize) and E820_RAM that are smaller
    than physically.
    
    Later on the PCI API looks at the E820 and attempts to set up an
    resource region for the "PCI mem". The E820 (assume dom0_mem=1GB is
    set) compared to the physical looks as so:
    
     [    0.000000] BIOS-provided physical RAM map:
     [    0.000000]  Xen: 0000000000000000 - 0000000000097c00 (usable)
     [    0.000000]  Xen: 0000000000097c00 - 0000000000100000 (reserved)
    -[    0.000000]  Xen: 0000000000100000 - 00000000defafe00 (usable)
    +[    0.000000]  Xen: 0000000000100000 - 0000000040000000 (usable)
     [    0.000000]  Xen: 00000000defafe00 - 00000000defb1ea0 (ACPI NVS)
     [    0.000000]  Xen: 00000000defb1ea0 - 00000000e0000000 (reserved)
     [    0.000000]  Xen: 00000000f4000000 - 00000000f8000000 (reserved)
    ..
    And we get
    [    0.000000] Allocating PCI resources starting at 40000000 (gap: 40000000:9efafe00)
    
    while it should have started at e0000000 (a nice big gap up to
    f4000000 exists). The "Allocating PCI" is part of the resource API.
    
    The users that end up using those PCI I/O regions usually supply their
    own BARs when calling the resource API (request_resource, or allocate_resource),
    but there are exceptions which provide an empty 'struct resource' and
    expect the API to provide the 'struct resource' to be populated with valid values.
    The one that triggered this bug was the intel AGP driver that requested
    a region for the flush page (intel_i9xx_setup_flush).
    
    Before this patch, when running under Xen hypervisor, the 'struct resource'
    returned could have (depending on the dom0_mem size) physical ranges of a 'System RAM'
    instead of 'I/O' regions. This ended up with the Hypervisor failing a request
    to populate PTE's with those PFNs as the domain did not have access to those
    'System RAM' regions (rightly so).
    
    After this patch, the left-over E820_RAM region from the truncation, will be
    labeled as E820_UNUSABLE. The E820 will look as so:
    
     [    0.000000] BIOS-provided physical RAM map:
     [    0.000000]  Xen: 0000000000000000 - 0000000000097c00 (usable)
     [    0.000000]  Xen: 0000000000097c00 - 0000000000100000 (reserved)
    -[    0.000000]  Xen: 0000000000100000 - 00000000defafe00 (usable)
    +[    0.000000]  Xen: 0000000000100000 - 0000000040000000 (usable)
    +[    0.000000]  Xen: 0000000040000000 - 00000000defafe00 (unusable)
     [    0.000000]  Xen: 00000000defafe00 - 00000000defb1ea0 (ACPI NVS)
     [    0.000000]  Xen: 00000000defb1ea0 - 00000000e0000000 (reserved)
     [    0.000000]  Xen: 00000000f4000000 - 00000000f8000000 (reserved)
    
    For more information:
    http://mid.gmane.org/1A42CE6F5F474C41B63392A5F80372B2335E978C@shsmsx501.ccr.corp.intel.com
    
    BugLink: http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1726Signed-off-by: default avatarFengzhe Zhang <fengzhe.zhang@intel.com>
    Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    2f14ddc3
setup.c 9.68 KB