From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K2OA8-0001Wp-Ht for qemu-devel@nongnu.org; Sat, 31 May 2008 06:18:12 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K2OA7-0001WV-UC for qemu-devel@nongnu.org; Sat, 31 May 2008 06:18:12 -0400 Received: from [199.232.76.173] (port=34063 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K2OA7-0001WP-Os for qemu-devel@nongnu.org; Sat, 31 May 2008 06:18:11 -0400 Received: from bzq-179-150-194.static.bezeqint.net ([212.179.150.194]:35673 helo=il.qumranet.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1K2OA7-0000GU-G6 for qemu-devel@nongnu.org; Sat, 31 May 2008 06:18:11 -0400 Message-ID: <484125E3.1090003@qumranet.com> Date: Sat, 31 May 2008 13:18:11 +0300 From: Avi Kivity 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: >> 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. > kvm started out with qemu emulating 16-bit code (and before that, even 32-bit code; kvm only did 64-bit). The reason I don't like this approach is that it makes the interface complex and hard to understand, and makes kvm heavily tied into qemu. Some problems that arise from having qemu emulate code: - difficult to do smp properly - qemu needs to be able to inject mmio for in-kernel emulated devices - in-kernel devices (lapic, etc.) need to interact with guest code executing in userspace -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.