From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1EG1I9-00016L-8t
	for qemu-devel@nongnu.org; Thu, 15 Sep 2005 17:29:13 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1EG1I5-00013R-CM
	for qemu-devel@nongnu.org; Thu, 15 Sep 2005 17:29:09 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1EG1I5-00011y-58
	for qemu-devel@nongnu.org; Thu, 15 Sep 2005 17:29:09 -0400
Received: from [64.233.162.200] (helo=zproxy.gmail.com)
	by monty-python.gnu.org with esmtp (Exim 4.34) id 1EG1FU-0004jg-Ez
	for qemu-devel@nongnu.org; Thu, 15 Sep 2005 17:26:28 -0400
Received: by zproxy.gmail.com with SMTP id 14so434333nzn
	for <qemu-devel@nongnu.org>; Thu, 15 Sep 2005 14:26:27 -0700 (PDT)
Message-ID: <cd8ecdef050915142644768e9@mail.gmail.com>
Date: Thu, 15 Sep 2005 17:26:26 -0400
From: Karl Magdsick <kmagnum@gmail.com>
Subject: Re: [Qemu-devel] About qemu emulation speed (a question) and
	supported OS
In-Reply-To: <20050914133733.GA6052@jbrown.mylinuxbox.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <1dc7f0e3050913053635cd61af@mail.gmail.com>
	<20050913133813.GA28356@jbrown.mylinuxbox.org>
	<4326E903.7070900@us.ibm.com>
	<20050913214856.GA31111@jbrown.mylinuxbox.org>
	<43278F61.8060103@us.ibm.com>
	<20050914133733.GA6052@jbrown.mylinuxbox.org>
Reply-To: kmagnum@gmail.com, qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

> VMware handles kernel code. You are right that x86 code can't be 100% vir=
tualized
> (even at the userland level) but VMware uses a lot of nasty disgusting tr=
icks
> in order to work around them. (For example, playing with shadow pagetable=
s
> so that a page of modified code is run but if the code tries to inspect i=
tself
> it sees another (unexecuted) page that contains the original code.)

I take it self-modifying kernel code would have serious issues.

I seem to recall my attempts to run v2OS (which uses a self-modifying
assembly code boot sequence) inside VMWare crashing badly circa 2001.


-Karl