Re: Why preallocate pmd in x86 32-bit PAE?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeremy Fitzhardinge wrote:

Hm, do you recall what processors that might affect?  As far as I know,
current processors will ignore non-present top-level entries.  Anyway,
we can point them not present to empty_zero_page, so testing the present
bit will still be sufficient to tell if we need to allocate a new pmd,
but if the hardware decides to follow the page reference there's no harm
done.  (Hm, unless the hardware decides it wants to set A or D bits in
empty_zero_page for some reason...)


PDPTR is documented to have P bits but none of the other control bits, unlike other levels of the hierarchy.

The hardware never sets A or D bits on non-present pages, since all the bits except P are reserved for the operating systems (and, besides, they can never be accessed or dirty.)

What earlier CPU's did was to basically load all four values into the CPU when you loaded %cr3. There was no "three-level page table walker" at all: it was still a two-level page table walker, there were just for magic internal page tables that were indexed off the two high bits.

That just means we need to reload cr3 after populating the pgd with a
new pmd, right?

Yes.  And as Linus said, it would be a new special case.

	-hpa

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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux