Re: Problems with oskit-mach
On Wed, Sep 06, 2000 at 02:49:55PM -0400, Roland McGrath wrote:
> I'm pretty sure I already make exactly that check (using the oskit header
> files and functions). That is the official Intel way of checking for the
> feature. The problem people are reporting is with AMD K6 family
> processors, which appear to report that feature bit in cpuid but not
> actually support the feature as I am using it.
Although this is the official way to check for the PGE feature, we are using
it a way explicitly defined by Intel as incorrect. This excerpt is from page
2-17 of the ``Intel Architecture Software Developer's Manual Volume 3: System
PGE Page Global Enable (bit 7 of CR4)
[T]he bit must not be enabled before paging
is enabled via CR0.PG. Program correctness may be affected by reversing this
sequence, and processor performance will be impacted.
This bit is definitely set before the paging bit, PG, is set and, I think
it is safe to say, it is indeed affecting processor performance. However,
as we also set kernel_pte_global when we set the PGE bit (see pmap.c), I am
not sure how the code should be rearranged.
Would moving the entire check into the paging enable function be reasonable?
This would imply that we would have to set a local var indicating that we
grok the PGE bit. Then we could build the kernel page tables and enable the
paging followed by enabling the PGE bit in paging_enable. My reading tells
me that this should work as the G bit on the pde's would just be ignored if
the PGE is unset. However, one cannot tell with out testing.
The other, cleaner, option that I see is to combine the pmap_bootstrap and
the paging_enable function. This seems acceptable and a bit more elegant
to me. This would also allow us to move the setting of the WP into a
function. On the other hand, paging_enable is an oskit function.
Thoughts on how I should do this are appreciated.
Neal H Walfield
University of Massachusetts at Lowell
email@example.com or firstname.lastname@example.org