From: Emre Can Sezer <ecsezer@ncsu.edu>
To: Xen Devel <xen-devel@lists.xensource.com>
Subject: Two shadow page tables for HVM
Date: Wed, 17 Dec 2008 18:06:07 -0500 [thread overview]
Message-ID: <494985DF.9040701@ncsu.edu> (raw)
Hi,
As part of my research I am going to play around with page permissions.
However, I might have to do this pretty often, so I'm thinking about
having two page tables that are synchronized and only differ in their
permissions. The idea is to have a set of permissions when code block A
is being executed and another set when block B is being executed. I
plan to capture execution jumps by specifying the inactive block as
non-executable.
I am running a HVM guest on a x86_64 machine. I'm only interested in
kernel pages, in that I don't have to have a second page table for user
level pages as their permissions will be the same.
So far I can think of only two ways of doing this. First, I can have
two top level shadow page tables and use one of the unused slots in
struct arch_domain to store this page. Then I modify
propagate_l*e_from_guest functions to ensure that they create and
synchronize the second page table. Second, I can have pages that are
twice as large as original page tables. I'm not sure what the
implications are concerning shadow cache and the linear page table
mappings.
Which one of these methods would be easier to implement? Is there an
easier way of having two sets of page tables? If I had the means, would
it be worth switching to AMD for the NPT?
Thanks in advance,
John
next reply other threads:[~2008-12-17 23:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-17 23:06 Emre Can Sezer [this message]
2008-12-18 3:50 ` Two shadow page tables for HVM Sina Bahram
2008-12-18 11:32 ` Tim Deegan
2008-12-22 18:28 ` Emre Can Sezer
2008-12-23 12:03 ` Gianluca Guida
[not found] ` <494FC8C7.8030508@ncsu.edu>
[not found] ` <20081223161006.GB28336@york.uk.xensource.com>
2008-12-29 16:17 ` Emre Can Sezer
[not found] ` <4958F7E0.8050207@ncsu.edu>
[not found] ` <20081229165415.GB5734@york.uk.xensource.com>
2009-01-09 22:08 ` Emre Can Sezer
2009-01-12 9:46 ` Tim Deegan
2009-01-27 0:39 ` Emre Can Sezer
2009-01-27 10:34 ` Tim Deegan
2009-01-27 19:07 ` Emre Can Sezer
2009-01-28 9:25 ` Tim Deegan
2009-01-30 16:15 ` Emre Can Sezer
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=494985DF.9040701@ncsu.edu \
--to=ecsezer@ncsu.edu \
--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.