From: "H. Peter Anvin" <hpa@kernel.org>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Jan Beulich <jbeulich@novell.com>, Ingo Molnar <mingo@elte.hu>,
Stable Kernel <stable@kernel.org>,
x86@kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86: set PAE PHYSICAL_MASK_SHIFT to match 64-bit
Date: Sat, 07 Jun 2008 11:35:58 -0700 [thread overview]
Message-ID: <484AD50E.1080601@kernel.org> (raw)
In-Reply-To: <48485732.4090203@goop.org>
Jeremy Fitzhardinge wrote:
>>
>> It should either be 52 bits or dynamic based on CPUID information.
>> The latter is very expensive.
>
> I'm more concerned that it might not be possible. I'm trying to think
> how many places have compile-time constants derived from this mask.
> Maybe not too many.
>
>> If there end up being additional control bits assigned in this space
>> we won't use them since we know the size of the address space (which
>> won't include the control bits) and thus will leave them at zero.
>
> You mean, if new bits appear we can just adjust the mask accordingly to
> avoid them? And if we don't use them, then they'll be zero?
Correct. Remember, the page table entries come from the kernel - not
from some random areas.
>> It's largely theoretical, since I believe Linux on x86-64 relies on
>> virtual >= physical+N, where I believe N is about 3 bits, and the page
>> table format or page size need to change to support more than 48 bits
>> of virtual address space.
>
> I don't see any relationship between the physical and virtual size.
> Certainly virtual is fixed at 48 bits (4*9+12), but I don't think
> there's any deep reason why physical needs to be within 3 bits.
>
Identity-mapping. 1 bit goes to kernel/user split, then the kernel area
is split into multiple regions, one of which is identity-mapping. It
may be just 2.
-hpa
next prev parent reply other threads:[~2008-06-07 18:39 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-05 15:21 [PATCH] x86: set PAE PHYSICAL_MASK_SHIFT to match 64-bit Jeremy Fitzhardinge
2008-06-05 15:34 ` Jan Beulich
2008-06-05 15:42 ` Jeremy Fitzhardinge
2008-06-05 16:45 ` H. Peter Anvin
2008-06-05 21:14 ` Jeremy Fitzhardinge
2008-06-07 18:35 ` H. Peter Anvin [this message]
2008-06-06 9:21 ` [PATCH UPDATED] x86: set PAE PHYSICAL_MASK_SHIFT to 44 bits Jeremy Fitzhardinge
2008-06-06 9:58 ` Jan Beulich
2008-06-06 13:15 ` Andi Kleen
2008-06-06 13:50 ` Jeremy Fitzhardinge
2008-06-10 10:31 ` Ingo Molnar
2008-06-10 13:06 ` Jeremy Fitzhardinge
2008-06-13 7:24 ` Ingo Molnar
2008-06-06 1:40 ` [PATCH] x86: set PAE PHYSICAL_MASK_SHIFT to match 64-bit Andi Kleen
2008-06-06 7:14 ` Jan Beulich
2008-06-06 7:59 ` Jeremy Fitzhardinge
2008-06-06 8:14 ` Jan Beulich
2008-06-06 8:15 ` Jeremy Fitzhardinge
2008-06-07 18:39 ` H. Peter Anvin
2008-06-06 4:45 ` Arjan van de Ven
2008-06-06 8:08 ` Jeremy Fitzhardinge
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=484AD50E.1080601@kernel.org \
--to=hpa@kernel.org \
--cc=jbeulich@novell.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=stable@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox