> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
> Mads Bergdal
> Sent: 21 September 2006 12:46
> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-devel] Re: How to intercept interrupts from
> guest domains
> Keir Fraser wrote:
> > On 19/9/06 10:52, "Mads Bergdal" <mbergdal@xxxxxxxxx> wrote:
> >>>> I am writing my master thesis on virtualization with
> Xen. I am trying to
> >>>> intercept the hypercalls coming from the guest domains. More
> >>>> specific I am trying to determine where in memory a
> guest domain is
> >>>> writing. Does anyone have a hint on where in the code I
> should try to do
> >>>> this?
> >>> If you want to know where a guest is writing you need to
> do more than
> >>> intercept hypercalls. You want to intercept memory
> accesses to, which would
> >>> liekly mean you need to run on shadow pagetables and
> manipulate access
> >>> permissions to trap on first access to a page.
> >>> -- Keir
> >> Yes, that sounds reasonable. Do you know where in the code
> this could be
> >> achieved?
> > What's the intended purpose? You could perhaps look at the
> log-dirty shadow
> > mode. This is used to track which pages have been modified
> by the guest -- a
> > page which the guest maps writeable is not made writable in
> the shadow page
> > tables until the time of the first write access (when that
> page is added to
> > a 'dirty log' for further processing).
> > Be warned that modifying the shadow code is rather more
> difficult than a
> > project that would simply involve adding a hook point to
> every hypercall!
> > -- Keir
> Thanks for the hints. I really appreciate it.
> My main purpose of this is to try to monitor when a
> guestdomain tries to
> write to a specific address in it's memory. (An address that
> it should
> not write to) And then get the Hypervisor to notify my userspace
> "surveillance" program about this.
> I have spent quite some time now reading the code. I must
> admit I am a
> bit lost. I am not sure where in the code I should be looking to get
> From what you write above I take it that you think the
> easiest approach
> is to hook into the hypercalls? I that case which
> hypercalls and where?
> If not, where should I look to learn he internals of the shadow mode?
To catch a kernel writing to a specific address, you can't rely on
hypercalls - there is no hypercall to indicate that a particular address
(or any address) has been written to.
When the kernel writes to memory, the processor will read the page-table
entry according to CR3 and the relevant page-table entries after that
(depending on whether it's 32-bit, 32-bit+PAE or 64-bit and whether the
pages are "large" 2MB/4MB or "small" 4KB). If the page indicated by the
page-table is writable, then the processor will do nothing other than
write the requested data to the memory. If the page indicated by the
page-table is not writable, then the a page-fault is issued. In the case
of Xen, this is trapped by Xen directly, and handled in the
page-fault-handling routine. Depending on what the reason for page-fault
is, Xen either changes the page to writable, or issues the page-fault
back to the kernel (if Xen didn't think this page should be writable).
Xen uses non-writable pages to keep track of various things, so it's
perfectly "normal" for Xen to take a page-fault for write to a
non-writable page, and Xen "knows" whether a page SHOULD be written to
or not. A typical case is the shadow page-table handling itself.
Page-tables in the guest are write-protected, Xen takes the page-fault
and figures out what the new value for the page-table-entry should be
(remember that the Kernel doesn't actually know that memory mnay not be
organized like the kernel expects) and the ACTUAL page-table (shadow
version) used by the processor is updated accordingly, as well as
writing the new value to the kernel's "visible" page-table [but this
page-table is never used by the processor to address memory].
To make a memory address "trap" in the hypervisor, you would therefor
have to make sure the page that contains that address is always
write-protected, and when the page gets a hit, compare with your
"magical" value, and if so, indicate it back to your "supervisor"
application. Depending on the granularity, you could potentially just
write-protect the page and never have to worry about
[This gets even more tricky on SMP systems, I hope you're only planning
on doing this for a single processor!]
Is the target address you're after a physical or a virtual address?
This is just an overview of how paging (and shadow paging) works...
There's more to it than the above couple of paragraphs, as you can
> Hope I am not wasting your time...
> Xen-devel mailing list
Xen-devel mailing list