virtualization.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
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

      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).