All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arne Mejlholm <mejlholm@cs.aau.dk>
To: xen-devel@lists.xensource.com
Subject: Shadow page table questions
Date: Wed, 19 Apr 2006 12:35:24 +0200	[thread overview]
Message-ID: <4446126C.9070403@cs.aau.dk> (raw)

Dear All,

I'm trying to understand some of the details of the shadow page table
implementation. In particular I'm interested in the inner workings of
translated mode.

Now as I understand it, the principle behind Shadow Page Tables (SPTs)
is to provide a level of indirection between virtual and machine
addresses. In Xen this is implemented by a P2M table for each domain (at
least in translated mode this address space is reused). Each entry in
this table is indexed by "physical" addresses and point to a given
machine frame number (mfn). As far as I can tell from the code, this
structure is walked much like a normal page table. In translated mode
the guest VM however cannot make use of the two level lookup (first
from virtual to physical and then from physical to machine addresses),
so a hardware specific version (the SPT) of the two mappings is
produced and given to the MMU instead of the ordinary page table.

My first question is have the status bits of each entry in the P2M
table changed semantics (compared to a normal l1 entry) or do they
signify the same flags? If the read/write flag is not set (read only),
will this be propagated to the SPT seen by the MMU?

Normally producing a SPT each time a the cr3 register is updated (as
required per context switch), is considered to be an overhead. One
solution to this is to make use of a cache, where references to old
SPTs are kept. This again involves the overhead in terms of memory
usage and tracking if the cached SPT is valid.

My second question is thus, does the implementation make use of a SPT
cache or are SPTs produced on demand? If a cache is used, can anyone
give me pointers to where I can find this structure?

The implementation makes use of snapshots, how do these fit into big
picture?

Finally some of the terminology used for the implementation seems a
bit un-intuitive to me. Throughout the source, there is the concept of
a hl2 table. As far as I can tell, a l2 table is the PGD in Linux
kernel terminology and a l1 table is the table pointed to by an entry
in the l2 table (PT in Linux). My first guess was that the hl2 table
was the table actually pointed to by the cr3 register, but I cannot
seem to confirm this. What does the h in hl2 stand for and what is it
used for?

Thank you,
Arne Mejlholm

             reply	other threads:[~2006-04-19 10:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-19 10:35 Arne Mejlholm [this message]
  -- strict thread matches above, loose matches on Subject: below --
2010-03-10  4:57 Shadow page table questions Marek Olszewski
2010-03-10  9:47 ` Avi Kivity
2010-03-11  0:06   ` Marek Olszewski
2010-03-11  6:39     ` Avi Kivity
2010-03-11 16:14       ` Marek Olszewski
2010-03-13  8:51         ` Avi Kivity

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=4446126C.9070403@cs.aau.dk \
    --to=mejlholm@cs.aau.dk \
    --cc=xen-devel@lists.xensource.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.