From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GvKVM-0006wF-R2 for qemu-devel@nongnu.org; Fri, 15 Dec 2006 16:22:08 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GvKVK-0006vp-U7 for qemu-devel@nongnu.org; Fri, 15 Dec 2006 16:22:07 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GvKVK-0006vl-P4 for qemu-devel@nongnu.org; Fri, 15 Dec 2006 16:22:06 -0500 Received: from [32.97.182.141] (helo=e1.ny.us.ibm.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1GvKVK-0000yz-FW for qemu-devel@nongnu.org; Fri, 15 Dec 2006 16:22:06 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.13.8/8.12.11) with ESMTP id kBFLM1Q7017470 for ; Fri, 15 Dec 2006 16:22:01 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kBFLM13C208278 for ; Fri, 15 Dec 2006 16:22:01 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kBFLM0T1019098 for ; Fri, 15 Dec 2006 16:22:00 -0500 Message-ID: <458311F6.9010602@linux.vnet.ibm.com> From: Anthony Liguori MIME-Version: 1.0 References: <10541fa50612130009s798a1587n4a3d2b8b51baa334@mail.gmail.com> <4581836C.7080709@tidetamerboatlifts.com> <200612141645.40403.paul@codesourcery.com> <200612151632.07145.mark.williamson@cl.cam.ac.uk> In-Reply-To: <200612151632.07145.mark.williamson@cl.cam.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: using mmap? Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Fri, 15 Dec 2006 21:22:09 -0000 To: qemu-devel@nongnu.org Cc: Paul Brook Mark Williamson wrote: >> I'm also doubtful how much benefit it gave in practice. I'm sure it would >> be good for synthetic CPU benchmarks. However using mmap significantly >> increases the overhead of context switches/tlb misses. >> >> To get good overall performance I suspect you're going to need closer >> cooperation with the kernel than mmap gives you. If you really want to make >> cross-emulation go fast I suggest working with the xen and/or kvm people to >> integrate qemu dynamic translation into those products. In theory I'd guess >> you should be able to plug it in as an alternative to the HVM code. I've no >> idea how close that is to being practical. > > http://wiki.xensource.com/xenwiki/HVM/V2E > > The v2e stuff allows execution state to be extracted from the real CPU, > plugged into QEmu for a bit for emulation, then transferred back to the real > CPU again. This is initially to be used for supporting Big Real Mode > emulation on HVM platforms. Later on it's planned to be used to accelerate > IO emulation further. > > Eventually this may provide a means to use QEmu's translator to execute kernel > code whilst running user mode code under Xen. It may be that this isn't as > fast as other approaches, but it'd be a useful feature for Xen to have IMO. I'd absolute like to get there. The current Xen HVM code is a bit of a mess at the moment. There are far too many assumptions about having VT/SVM hardware present. However, I'd really like to get to a point where Xen could run unmodified guests on non VT/SVM hardware using qemu with user virtualization. KVM is having similar trouble ATM with big real mode. It would be very nice to also add a V2E like interface to KVM. I'd also like to see the translator even used for paravirtual guests. This way we could still have a proper boot loader run without having to deal with paravirtualizing it. It would be nice to use emulation to avoid paravirtualizing the non-performance critical bits. Regards, Anthony Liguori > Cheers, > Mark > >>> Wouldn't this be a *significant* >>> performance enhancement for this setup which I'm sure is a common one? >>> Maybe this can be implemented for regular processes on the guest and >>> only use the softmmu for the kernel? Would someone point me in the >>> right direction for technical information? I have had to switch to >>> vmware free player until Qemu+KQEMU reaches a point of similar >>> performance, but I would really rather see Qemu advance further. >> If you're using an accelerator (eg. kqemu or kvm) this is all irelevant as >> most code isn't run by qemu, it's virtualized by the accelerator. qemu just >> does the IO emulation. >> >> Paul >> >> >> _______________________________________________ >> Qemu-devel mailing list >> Qemu-devel@nongnu.org >> http://lists.nongnu.org/mailman/listinfo/qemu-devel >