From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GdDPJ-0000Jz-Cc for qemu-devel@nongnu.org; Thu, 26 Oct 2006 18:09:01 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GdDPG-0000ES-LA for qemu-devel@nongnu.org; Thu, 26 Oct 2006 18:08:59 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GdDPG-0000EN-Fq for qemu-devel@nongnu.org; Thu, 26 Oct 2006 18:08:58 -0400 Received: from [81.29.64.88] (helo=mail.shareable.org) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1GdDPG-000632-1w for qemu-devel@nongnu.org; Thu, 26 Oct 2006 18:08:58 -0400 Received: from mail.shareable.org (localhost [127.0.0.1]) by mail.shareable.org (8.12.11.20060308/8.12.11) with ESMTP id k9QM8tdO011234 for ; Thu, 26 Oct 2006 23:08:55 +0100 Received: (from jamie@localhost) by mail.shareable.org (8.12.11.20060308/8.12.8/Submit) id k9QM8tAA011232 for qemu-devel@nongnu.org; Thu, 26 Oct 2006 23:08:55 +0100 Date: Thu, 26 Oct 2006 23:08:55 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] How to get guestOS's information Message-ID: <20061026220855.GA7264@mail.shareable.org> References: <001501c6f8cf$b2659bc0$37cb1585@s5pc49> <1161900005.29751.60.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1161900005.29751.60.camel@localhost.localdomain> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org maestro wrote: > You might want to consider useing the Page Directory Base Register (PDBR > aka cr3 or in qemu-x86 env->cr[3]) to idenify differnet processes. afaik > it is then OS-dependant how to get the corresponding PID. I did this for > windows and i assume it's a lot easier to do the same for linux/*BSD (as > the source is available). Since you probably will need to check for the > current process quite often, the shorter access times for this > information might come in handy. Good idea. However, on Linux cr3 is not updated for every process. Specifically, it is not updated for kernel threads which don't have any user-space mappings of their own. This is to avoid unnecessary TLB flushes. -- Jamie