From: Zachary Amsden <zach@vmware.com>
To: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Cc: Chris Wright <chrisw@sous-sol.org>,
Virtualization Mailing List <virtualization@lists.osdl.org>
Subject: Re: how set_pte_at()'s vaddr and ptep args relate
Date: Thu, 09 Nov 2006 01:15:49 -0800 [thread overview]
Message-ID: <4552F1C5.9060800@vmware.com> (raw)
In-Reply-To: <C178974F.4076%Keir.Fraser@cl.cam.ac.uk>
Keir Fraser wrote:
> On 8/11/06 11:25 pm, "Jeremy Fitzhardinge" <jeremy@goop.org> wrote:
>
>
>> Keir Fraser wrote:
>>
>>> Another
>>> factoid I discovered at the same meeting is that the CPU may cache partial
>>> page walks. So, for example, just because you 'detach' a page table from a
>>> page-directory entry, doesn't mean that page table won't be accessed on
>>> future hardware TLB fills.
>>>
Yes. The rule is, if you change a mapping at any level, your results of
using any descendants of that mapping for memory access are undefined
unless you have flushed the mappings you are trying to use.
>> Do you know if these intermediate TLB entries are level-sensitive? Ie,
>> if you have a linear pagetable mapping where the pagetable points back
>> to itself, will that result in multiple TLB entries for the pmd pages
>> (pmd as pmd, and pmd as pte)?
>>
>
> I think so. I can't think why the CPU would bother to disallow this. It does
> mean you have to be careful when changing page-directory entries that your
> linear mapping (if you have one) doesn't go stale.
>
No, as long as the pmd is only mapped in one linear address, there is
only one TLB entry for it. You can't mix large pages and circular
pagetables, so you can't have a pmd as pmd level TLB mapping in addition
to a pmd as pte level mapping. Thinking of it as pmd as pmd / pmd as
pte level mapping is confusing. It is better to think of it in terms of
physical page walks during TLB fills and virtual walks during circular
mapping access.
You do need to issue appropriate page invalidations after changing
page-directory level mappings for the page tables. If you update PDEs
and you use a circular mapping of page tables, then you may need to
issue invlpg's for the page tables that may have been disconnected or
changed. This is for your consistency, not the TLB consistency. The
TLB will fetch new mappings from physical space, and knows nothing about
your circular mapping. So a PDE update to an entire 4M/2M range could
require multiple flushes - one or more to invalidate mappings of
underlying PTEs that have changed, and one to invalidate the mapping of
the circularly mapped page table itself.
Of course, depending on the context and your consistency requirements,
some or all of these flushes may be redundant or subsumed by subsequent
flushes.
Zach
prev parent reply other threads:[~2006-11-09 9:15 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-07 19:57 how set_pte_at()'s vaddr and ptep args relate Jeremy Fitzhardinge
2006-11-07 22:19 ` Zachary Amsden
2006-11-07 22:38 ` Jeremy Fitzhardinge
2006-11-07 23:33 ` Zachary Amsden
2006-11-07 23:42 ` Jeremy Fitzhardinge
2006-11-07 23:59 ` Zachary Amsden
2006-11-08 0:15 ` Jeremy Fitzhardinge
2006-11-08 0:19 ` Zachary Amsden
2006-11-08 8:34 ` Keir Fraser
2006-11-08 19:59 ` Jeremy Fitzhardinge
2006-11-08 20:18 ` Jeremy Fitzhardinge
2006-11-08 23:17 ` Keir Fraser
2006-11-08 23:25 ` Jeremy Fitzhardinge
2006-11-09 8:29 ` Keir Fraser
2006-11-09 9:15 ` Zachary Amsden [this message]
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=4552F1C5.9060800@vmware.com \
--to=zach@vmware.com \
--cc=Keir.Fraser@cl.cam.ac.uk \
--cc=chrisw@sous-sol.org \
--cc=virtualization@lists.osdl.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;
as well as URLs for NNTP newsgroup(s).