From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K1mEc-0001zk-O6 for qemu-devel@nongnu.org; Thu, 29 May 2008 13:48:18 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K1mEc-0001yx-2d for qemu-devel@nongnu.org; Thu, 29 May 2008 13:48:18 -0400 Received: from [199.232.76.173] (port=38260 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K1mEb-0001ye-RD for qemu-devel@nongnu.org; Thu, 29 May 2008 13:48:17 -0400 Received: from yx-out-1718.google.com ([74.125.44.153]:56923) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1K1mEb-0007uf-HA for qemu-devel@nongnu.org; Thu, 29 May 2008 13:48:17 -0400 Received: by yx-out-1718.google.com with SMTP id 3so364075yxi.82 for ; Thu, 29 May 2008 10:48:17 -0700 (PDT) Message-ID: <483EEC56.4030203@codemonkey.ws> Date: Thu, 29 May 2008 12:48:06 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: KQEMU code organization References: <483C3D55.2000508@siemens.com> <483C8705.307@bellard.org> <483D81FA.5070202@siemens.com> <483D8A2E.5070907@bellard.org> <483D8E9A.40509@siemens.com> <483EA1AD.1010901@bellard.org> <20080529161322.GB21610@shareable.org> <483ED935.2060802@codemonkey.ws> <483EDF80.3060003@siemens.com> In-Reply-To: <483EDF80.3060003@siemens.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 Jan Kiszka wrote: > Anthony Liguori wrote: > >> >> It wouldn't be too bad if you focused on kqemu-user and limited yourself >> to UP guests. The first step would be getting the existing KVM support >> code to function with TCG. For instance, use TCG to run 16-bit code, >> and then KVM to run 32/64-bit code. Once that was all worked out, the >> rest would be pretty straight-forward porting and code cleanup. >> > > I guess you mean real-mode code with 16-bit here. /me always wondered > why it takes an in-kernel code interpreter for kvm to achieve this - at > least as long as it runs via qemu. > We don't use an in-kernel interpreter, we use vm86 mode for 16-bit code. There is an in-kernel interpreter (x86_emulate) but that is used mostly for handling shadow page table faults. Regards, Anthony Liguori > Jan > >