[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 19:09:43 +0100
On 2010-02-18 at 18:30:09 [+0100], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
wrote:
> Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> > 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.
>
> What about the physical page mapper? How would it be able not to violate
> the PAT flags?
AFAIK all explicitly mapped physical pages are RAM pages, temporarily
mapped by the VM or I/O subsystems to copy/clear data. One could simply
declare it an official restriction to be heeded by the user of the memory
typing API not to use an API that could potentially do that (probably
indeed only I/O and certain area operations), if they choose to use memory
types other than write-back for RAM.
Alternatively the physical page mapping API functions could get another
parameter specifying the memory type. This would probably mean some passing
around of these types.
Or the the simplest option: Since the memory type ranges are centrally
tracked anyway, the physical page mapper could look up which type was
specified for the to-be-mapped physical page and use the same one.
CU, Ingo
Other related posts: