[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Implementing split memory in Xen is annoyingly hard?

Hi all,

This might end up being one of my last posts on this topic, as I think I've
determined that what I'd like to do with Xen is quite annoyingly hard for
now. If anyone could please either verify or poke some holes in what I'm
about to say, I'd very much appreciate that.

Let's assume shadow page tables are in use.

#1: Xen can mirror the guest's page table in its shadow page table because
it marks all the guest pages as read only; thus, when a page fault is
generated as a result of a write, it can allow the write to happen, while
quickly updating its own copy at the same time.

#2: Xen absolutely does not, (can not?), cause a fault or other VM exit to
be generated upon an execute or a read of a page.

#3: Since I wish to implement split memory, (Harvard Architecture), I have
to have the ability to intercept all of one of two different classes of
operations. Either I have to intercept all reads and writes, or I have to
intercept all executes.

#4: Since the best I can do is only intercept all writes, not all reads to
go along with that particular class of operation, I can't implement split
memory, (Harvard Architecture), in Xen.

One potential work around:

I could mark every single page of the guest's kernel as NX, and then when
that fault happens, I could then be privy to all executes from within Xen.

Is this an accurate understanding of the situation?

The following links are a subset of what I've been reading to arrive at this

1. https://wiki.cs.dartmouth.edu/nihal/doku.php/xen:memory
2. http://www.anandtech.com/weblog/showpost.aspx?i=467
4. http://forums.amd.com/devblog/blogpost.cfm?catid=317&threadid=104671
5. www.cc.gatech.edu/research/reports/GT-CS-08-09.pdf
6. www.usenix.org/publications/login/2007-02/pdfs/hand.pdf 

Take care,

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.