[lkml]   [2008]   [Aug]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] x86: split e820 reserved entries record to late

    On Thu, 28 Aug 2008, Yinghai Lu wrote:
    > so could let BAR res register at first, or even pnp?

    Well, I'm not sure whether PnP or e820 should be first, as long as any
    "real hardware" probing takes precedence over either. I _suspect_ that
    e820 is more trustworthy, which implies that PnP should probably be added
    last. It would be good to have some idea what Windows does, since usually
    all the firmware bugs are essentially hidden by whatever that other OS
    happens to do.

    The basic rule really should be: "What do we trust most?" and probe things
    in that order.

    So e820 is fairly trustworthy, but we know that it will have various
    random things marked as reserved because they are special in some way (but
    we don't know _how_ they are special - they may well be real BAR's that
    just have a fixed meaning to ACPI or whatever).

    But we obviously trust _part_ of it (the RAM stuff) more than we trust
    other parts. So it does make sense to consider that separately.

    PnP I personally wouldn't trust at all, except as a way to keep dynamic
    resources away from those things, which is why I'd put it last. But that's
    just my personal gut feeling.

    Hardware we generally trust more than any firmware, but even hardware can
    have bugs. And some classes of hardware tends to be less buggy than others
    (ie I'd trust some on-die APIC base pointer before I would trust a Cardbus
    controller BAR, for example).

    But yes, I think your patch looks like it is definitely moving in the
    right direction. If this means that we can now do PCI probing without
    having the BAR's move around because they also happened to be covered by
    an e820 map, then that sounds like a good thing.

    Of course, I bet there will be cases where this causes problems. It feels
    like we have _never_ worked around some PCI BAR allocation problem without
    hitting another unexpected one..


     \ /
      Last update: 2008-08-28 22:09    [W:0.022 / U:3.432 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site