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

xen-devel

[Top] [All Lists]

[Xen-devel] questions about the fast trap handler in Xen

To: xen-devel@xxxxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] questions about the fast trap handler in Xen
From: Xin Zhao <zhaoxin@xxxxxxxxxxxxxx>
Date: 2004年7月18日 20:49:49 -0400 (EDT)
Delivery-date: 2004年7月19日 01:54:03 +0100
Envelope-to: steven.hand@xxxxxxxxxxxx
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
I learned from the Xen SOSP paper that Xen installs a fast trap handler to
allow the system calls issued by guest app direct trap into the guest os
system trap handler. I guess the procedure should be as follows:
Guest app issues a system call, because it runs at ring 3, the instruction
will be trapped. Xem hypervisor, as a VMM, defines an exception handler
for int 80. In the exception handler, there are an interrupt vector
defined according to current running guest OS. That is, guest os reports
its interrupt vector to vmm, and vmm save the vector for fast handling.
Since VMM knows the interrupt vector of the specific guest os, it can
directly jump to the right place, which is the entry of the guest os
system call function, and start to process the system call.
Is my understanding right? If so, I have two questions:
first, when will the guest os register the system call handler with the
VMM?
second, if a guest os is compromised, can intruders change the handler by
registering another entry point at runtime?
I noticed that many people are trying to do more development on Xen. Can
Xen group publish more design document? Although reading source code is
usually a good way to understand Xen, it is not the fastest way, not to
mention that people may misunderstand some codes. Maybe a simple flow
chart of Xen will help us a lot!
Thanks.
Xin
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
<Prev in Thread] Current Thread [Next in Thread>
Previous by Date: RE: [Xen-devel] file corruption!!! , James Harper
Next by Date: RE: [Xen-devel] file corruption!!! , James Harper
Previous by Thread: [Xen-devel] vif naming? also halting a VM , Derek Glidden
Next by Thread: Re: [Xen-devel] questions about the fast trap handler in Xen , Keir Fraser
Indexes: [Date] [Thread] [Top] [All Lists]

Copyright ©, Citrix Systems Inc. All rights reserved. Legal and Privacy
Citrix This site is hosted by Citrix

AltStyle によって変換されたページ (->オリジナル) /