WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] Re: How to intercept interrupts from guest domains

To: "Mads Bergdal" <mbergdal@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Xen-devel] Re: How to intercept interrupts from guest domains
From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
Date: Thu, 21 Sep 2006 16:31:33 +0200
Delivery-date: Thu, 21 Sep 2006 07:32:15 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <eeu34q$pjm$1@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcbdgQtqZWoR8MhNScC6cJMLFNSNpQAAQcjQ
Thread-topic: [Xen-devel] Re: How to intercept interrupts from guest domains
> Thanks a lot!
> 
> Well clearly this is a bit more complicated than I first excepted....
> I'm only doing this for single 32-bit processors....
> 
> I guess I'm primarily interested in the virtual addresses. (I 
> think...). 
> If my 'supervisor' program first finds out which page the 
> guest kernels 
> syscall table (for instance...) maps to, the I would only need the 
> hypervisor to send an message if this page is being accessed 
> and let the 
> 'supervisor' program take care of the rest?

Ok, so you're trying to write something that detects writes to the
syscall page. Isn't that write-protected already [I haven't checked, but
I expect it to be]. In which case any kernel write to that page would be
trapped with a kernel-oops... 

But perhaps that's not really the page you're looking to see if it's
being written to?

> 
> The most promising thing to do then is to:
> - find out which page my 'untouchable' address is on and mark this 
> page  as non-writable. (how?) Or are all pages marked as 
> non-writable by 
> Xen as default?

Yes. How? I don't know... It may be that you'd have to invent your own
way to "fiddle" with the page-table. 

> - This way  the guest will always get a page fault, and trap to Xen. 
> (Where in Xen is this trap handled?)

You'd end up in "do_page_fault" in xen/arch/x86/traps.c - note that
there is also x86_64 and x86_32/traps.c - these are additional
architecture specific trap handlers. The function do_page_fault is 32/64
independent [obviously only to the x86 architecture, this code DOES NOT
work on ia64 or ppc for example], so it lives at the upper level... 

do_page_fault calls "fixup_page_fault" which calls "shadow_fault", which
in the current shadow page-table code ends up in "sh_page_fault". 

Any of these functions should be able to detect your fault. It depends
on how you want to treat the handling, and what information you need to
have available, which function is best for you. 

> -I maintain (in Xen) an array of pages that is not supposed to be 
> written to, and compare this to the page the guest kernel 
> wants to write 
> to.

Seems reasonable. 

> -If the page is in the array I send a message (how?) to my program 
> saying that the guest is trying to access a marked page.

The usual method is by "event channel". See
xen/include/public/event_channel.h

> -My program then decides if the guest kernel is allowed to 
> proceed, and 
> responds to the Hypervisor (how?)

Event channel?

> 
> Does this sound doable?

Certainly possible. Non-trivial, but doable. 


> If so, where in the xen code is the xen page-fault-handling 
> routine? And 
> how can I send messages to and from the Hypervisor?
> 
> Mads
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel