Re: [PATCH] x86: mtrr: don't modify RdDram/WrDram bits of fixed MTRRs

[Yinghai Lu]

On Wed, Mar 11, 2009 at 8:00 AM, Andreas Herrmann
<andreas.herrmann3@xxxxxxx> wrote:
> BIOS is expected to clear the SYSCFG[MtrrFixDramModEn] on AMD CPUs after
> fixed MTRRs are configured.
>
> Some BIOSes do not clear SYSCFG[MtrrFixDramModEn] on BP (and on APs).
>
> This can lead to obfuscation in Linux when this bit is not cleared on
> BP but cleared on APs. A consequence of this is that the saved
> fixed-MTRR state (from BP) differs from the fixed-MTRRs of APs --
> because RdDram/WrDram bits are read as zero when
> SYSCFG[MtrrFixDramModEn] is cleared -- and Linux tries to sync
> fixed-MTRR state from BP to AP. This implies that Linux sets
> SYSCFG[MtrrFixDramEn] and activates those bits.
>
> More important is that (some) systems change these bits in SMM when
> ACPI is enabled. Hence it is racy if Linux modifies RdMem/WrMem bits,
> too.
>
> I suggest not to touch RdDram/WrDram bits of fixed-MTRRs and
> SYSCFG[MtrrFixDramEn] and to clear SYSCFG[MtrrFixDramModEn] as
> suggested by AMD K8, and AMD family 10h/11h BKDGs.
> BIOS is expected to do this anyway. This should avoid that
> Linux and SMM tread on each other's toes ...
>

wonder if you could add one dmi check to tell the user that bios is
buggy, ask vendor fixed BIOS
and skip fixed mtrr sync.

instead of covering bios problem quietly.

YH
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/