I've been reading through the code regarding paging --> spending a lot of
time in mm/*.*, as well as some of the other parts up a level or two, but
I'm still unclear as to some key things.
Here's what I think I know:
I think I know how a domain's shadow page table is first allocated E.G. the
hash_table is xmalloc'ed and when it is destroyed E.G. xfree'ed.
I believe I have identified the functions where a shadow page is inserted
and deleted with all the tlb modifications that go along with that.
I'm semi-comfortable with the format of the shadow page table itself. In
32-bit PAE, it follows the 2, 9, 9, 12 format.
Why do shadow page tables exist in xen for pv guests? What is their purpose,
and how do pv guests interact with them?
How does one activate this?
Does one have to have pae enabled for 32-bit pv guests? I thought I read
that I do, but when I look at the source, the classic 10, 10, 12 format for
page tables is supported. Is that not supported for shadow page tables, and
if so ... How can I learn more about this?
* general goal *
Here is what I'm trying to do, in a finite way.
I'd like to add a structure, for now a reference in the paging struct would
be fine, let's call it hash_table2 for lack of a better name.
I'd like to mirror all operations to the page table, to hash_table, in my
Now to the purpose of why I'm doing this.
I'd like to make it so that if a page is accessed, with the supervisory bit
set, I direct all reads and writes to the original hash_table, but I want to
direct all executes to hash_table2, or vice versa, that hardly matters which
one gets which.
Eventually I'd like to not even mirror pages that are just data (read and
write only) or just code (execute only).
Again, I only want to do this for page swith supervisory bit set so as to
only affect the kernel's pages. That's the kernel of the pv guest.
In this way, I hope to implement split memory as a way of preventing certain
attacks to the guest.
Is there anyone I can speak to about this, perhaps over detailed emails, IM,
or even phone?
Thanks so much
Xen-devel mailing list