[lkml]   [2009]   [Apr]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] x86/pci: make pci_mem_start to be aligned only -v4

    * Linus Torvalds <> wrote:

    > On Sat, 18 Apr 2009, Ingo Molnar wrote:
    > >
    > > Am i missing something?
    > We also try to avoid random motherboard resources etc that aren't
    > reserved or documented by the BIOS. It's better to go into big
    > holes. It's also better to try to keep as close to the old
    > (tested) behavior.

    Yeah - i'm not suggesting any change in behavior, nor am i
    suggesting any risky behavior. The current code seems to work quite

    I'm just suggesting (maybe foolishly) that instead of having any
    gap-rounding logic at all, add artificial entries to the e820 map to
    'extend' and round up any odd ending entries.

    I.e. explicitly manage all the 'hole' space to be nicely rounded and
    to be far away from any T-Seg or other sekrit motherboard resource
    danger area.

    We'd do this after PCI static allocations (so we dont ever stomp on
    real, known resources) but before PCI dynamic allocations.

    The e820 printout would look literally like this:

    BIOS-provided physical RAM map:
    BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) 0.639 MB RAM
    BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) 0.001 MB
    [ hole ] 0.250 MB
    BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved) 0.125 MB
    BIOS-e820: 0000000000100000 - 000000003ed94000 (usable) 1004.5 MB RAM
    BIOS-e820: 000000003ed94000 - 000000003ee4e000 (ACPI NVS) 0.7 MB
    BIOS-e820: 000000003ee4e000 - 000000003fea2000 (usable) 16.3 MB RAM
    BIOS-e820: 000000003fea2000 - 000000003fee9000 (ACPI NVS) 0.3 MB
    BIOS-e820: 000000003fee9000 - 000000003feed000 (usable) 0.15 MB RAM
    BIOS-e820: 000000003feed000 - 000000003feff000 (ACPI data 0.07 MB
    BIOS-e820: 000000003feff000 - 000000003ff00000 (usable) 0.004 MB RAM
    BIOS-e820: 000000003ff00000 - 0000000040000000 (guard) 1.0 MB
    [ hole ] 3072.0 MB

    The '(guard)' entry at the end i added above.

    This way we intentionally create a 'free physical address space'
    hole space that is the same as the rounding logic. No rounding
    needed anywhere - as all the remaining address space is well-rounded
    already. Plus we'd also _see_ all our rounding logic by looking at
    the '(guard)' entries.

    Or maybe there's some aspect of gap-rounding that cannot be
    expressed in such a static way?


     \ /
      Last update: 2009-04-18 21:17    [W:0.022 / U:11.568 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site