[haiku-commits] Re: r35515 - in haiku/trunk: headers/private/kernel/arch/x86 src/add-ons/kernel/cpu/x86 src/system/kernel/arch/x86 src/system/kernel/vm
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Thu, 18 Feb 2010 16:53:47 +0100
On 2010-02-18 at 15:02:14 [+0100], Rene Gollent <anevilyak@xxxxxxxxx> wrote:
> On Thu, Feb 18, 2010 at 8:52 AM, <ingo_weinhold@xxxxxx> wrote:
> > Author: bonefish
> > Date: 2010-02-18 14:52:43 +0100 (Thu, 18 Feb 2010)
> > New Revision: 35515
> > Changeset: http://dev.haiku-os.org/changeset/35515/haiku
> > Ticket: http://dev.haiku-os.org/ticket/5383
>
> Nice changes! Does this by any chance resolve #5353 as well?
It might fix the reporter's problems. I took the liberty to interpret the
meaning of the ticket a bit wider, though, and the short answer is, that we
simply don't support everything we should support ATM.
The long version:
MTRRs are pretty annoying due to the fact that their number is rather
limited (usually 8 or 7) and that pretty strict restrictions apply. A
register can specify a single typed memory range with the size of the range
being a power of 2 and the base address being aligned to the size. That
makes it necessary to describe a range with a size that is not a power of
two or with an unaligned base with more than one register. So it is
entirely possible to run out of registers specifying just a single range.
The current algorithm uses all the available knowledge about unused ranges
to round-extend the used ranges to more MTRR-friendly values. Still it is
totally possible to run out of MTRRs.
IMHO ideally one should completely avoid the MTRRs and use a different
(higher-level) mechanism. MTRRs define the caching/memory ordering
attributes of physical memory ranges. It is also possible to define those
attributes in the paging structures that define the mapping of virtual to
physical addresses. Unlike the MTRRs the mechanism cannot run out of any
resource, allows to define the attributes on a per-page base, and exists
since 486. Unfortunately before the Pentium III (which introduces page
attribute tables (PAT)) it allows only to specify three of the five
possible modes. Most relevantly the write-combining mode (interesting for
the frame buffer) was not supported, which would force us to resort to
uncached (i.e. very slow) access.
So, to sum up the situation, we have three set of x86 processors:
1. Pentium: No MTRRs at all. The memory types are predefined by hardware
and can be further restricted via the (limited) PTE method.
2. Pentium II and Pentium Pro: Have MTRRs. Do not support PAT, i.e. cannot
specify the write-combining mode via the PTE method.
3. Pentium III and later: Have MTRRs and support PAT. The PTE method would
work perfectly.
The current implementation (using MTRRs only) should work fine on
everything but the Pentium as long as not running out of registers. For the
(hopefully) unlikely case of running out of registers, things will go wrong
-- from serious graphics glitches to malfunctioning hardware drivers. On
the Pentium things should work OK as long as the required ranges are not
stricter than the ones predefined by the hardware (e.g. the nVidia driver
shouldn't work correctly).
A perfect implementation would use the PTE method on Pentium III and later,
use MTRRs on Pentium II/Pro falling back to the PTE method when running out
of registers, and use the PTE method on the Pentium in cases where the
predefined attributes are not strict enough. Unless something like that is
implemented, I would leave #5353 open.
CU, Ingo
Other related posts:
