Andreas Herrmann wrote:
quoted text
> On Thu, Sep 13, 2007 at 10:20:56AM -0700, H. Peter Anvin wrote:
>> Yinghai Lu wrote:
>>> BIOS guys also said that fam 10h need mmconfig via eax accessing, may
>>> need OS do sth, so it is safe to stay with MCFG entry for SB like
>>> mcp55...
>>>
>>> but latest kernel already have that workaround to make mmconfig via eax...
>>>
>> This is actually a good point.  Since the CPU vendor managed to
>> completely fuck up the operation of MMCONFIG itself on this CPU (it's a
>> *MEMORY REFERENCE*, guys!), it is actually to be expected and prudent
>> that BIOS vendors will drop the MCFG entry.  MMCONFIG doesn't actually
>> work on this CPU for any system software which doesn't already know to
>> work around this particular piece of severe braindamage;
> 
> But wait, isn't it true that Vista is using MCFG?
> So, poor BIOS guys what should they do now?
> If you have a special problem here why not upgrading your Linux kernel?
> 

I'm not talking about Linux here.  I'm talking about any random system
software (which may or may not be Vista, and may nor may not even be an
OS.)  If they advertise MCFG, then a random OS could try to use it, in
accordance with the spec, without the workaround, with serious
malfunction as a result.

If they don't include MCFG, then the worst thing that can happen is that
the OS doesn't see the extended space.  An OS that has chip-specific
workarounds can be aware that this chip is Special and enable MMCONFIG
and use it anyway.

In RFC-speak:

Since this chip doesn't implement standards-conformant mmconfig, a BIOS
MUST NOT enable MCFG in ACPI.  As a result, OSes that have chip-specific
workarounds, like Linux has, SHOULD detect it and use ad hoc code to
enable it anyway.

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