lkml.org 
[lkml]   [2008]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] x86-64: disable the GART early v2

    * Yinghai Lu <Yinghai.Lu@Sun.COM> wrote:

    > --- a/arch/x86/kernel/aperture_64.c
    > +++ b/arch/x86/kernel/aperture_64.c
    > @@ -218,6 +218,73 @@ static __u32 __init search_agp_bridge(u32 *order, int *valid_agp)
    > return 0;
    > }
    >
    > +void __init early_gart_iommu_disable(void)
    > +{
    > + /*
    > + * disable it in case it is enabled before, esp for kexec/kdump,
    > + * previous kernel already enable that. otherwise memset called
    > + * by allocate_aperture/__alloc_bootmem_nopanic cause restart.
    > + * or second kernel have different position for GART hole. and new
    > + * kernel could use hole as RAM that is still used by GART set by
    > + * first kernel
    > + */

    hm, i'm wondering, instead of modifying the GART, why dont we simply
    _detect_ whatever GART settings we have inherited, and propagate that
    into our e820 maps? I.e. if there's inconsistency, then punch that out
    from the memory maps and just dont use that memory.

    that way it would not matter whether the GART settings came from a [old
    or crashing] Linux kernel that has not called gart_iommu_shutdown(), or
    whether it's a BIOS that has set up an aperture hole inconsistent with
    the memory map it passed. (or the memory map we _think_ i tried to pass
    us)

    it would also be more robust to only read and do a memory map quirk
    based on that, than actively trying to change the GART so early in the
    bootup. Later on we have to re-enable the GART _anyway_ and have to
    punch a hole for it.

    and as a bonus, we would have shored up our defenses against crappy
    BIOSes as well.

    Ingo


    \
     
     \ /
      Last update: 2008-01-11 09:17    [W:0.027 / U:33.616 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site