From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 7/7] Allow KVM from a normal QEMU binary Date: Sun, 05 Nov 2006 19:48:30 +0200 Message-ID: <454E23EE.7040505@qumranet.com> References: <454AE007.5070905@cs.utexas.edu> <454AE323.8090309@cs.utexas.edu> <454DAE74.4030306@qumranet.com> <454E1F40.2070200@cs.utexas.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Return-path: To: Anthony Liguori In-Reply-To: <454E1F40.2070200-NZpS4cJIG2HvQtjrzfazuQ@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org Anthony Liguori wrote: > >> >> Most of the places where USE_KVM is used are now never called - they >> are relics from the days when we had mixed qemu/kvm execution. > > One of the things I was thinking of doing was getting rid of USE_KVM > completely. What I was thinking of doing is moving kvmctl.[ch] into > the QEMU tree I'd like to keep kvmctl out, so that non-qemu based userspace can be built. True, I wouldn't like to be the one to do it, but I'd like to keep the possibility open. > and refactoring things a bit so that it fails gracefully in the > absence of a working KVM device. Sure, if it can't create a kvm vm it should fall back to kqemu or normal emulation. > > The idea is to get rid of external dependencies. What are your > thoughts on this? Do you think there will be significant users of > libkvm.a outside of QEMU? Right now there's just the (mostly broken) test suite. > >> Now, the "big real" fiasco means that we need some sort of emulation, >> but I'm not sure the qemu cpu loop is the best choice. Qemu is very >> complex because it is geared to multi-host, multi-target, >> high-performance emulation. The cpu state is baroque, and SMP isn't >> going to be fun. > > Right. > >> I think we're better off with taking the x86 emulator from the kernel >> and extending it to support the non-memory instructions. It can run >> in the kernel or userspace since there's no performance requirement. > > This is the opposite strategy that Xen is taking FWIW. You not only > need a full 16 bit emulator but a 32 bit emulator too (to deal with > the transitions to/from userspace). We need a real-mode emulator. That includes 16 and 32 bits (via prefixes). We already have some significant fraction of it in x86_emulator.c. Whether to extend it (in the kernel or in userspace) or to use some other emulator is a good question. Of course, we can use qemu, but that's fairly complex. > > The tree we're working in is: > > http://xenbits.xensource.com/ext/xen-unstable-hvm.hg > > Linux kernel boots quite nicely and I'm in the process of debugging > why Windows guests aren't booting (there appears to be a problem in > the state transfer right now). State transfer is what turned us of qemu. Reconstructing the state (esp. eflags and the segments) is quite difficult and there are some annoying qemu bugs (like the busy task flag checks). BTW, dumping qemu cpu emulation will allow us to use gcc 4.x instead of gcc 3.x. > > SMP guest support is still a hard problem that needs thinking through > but if Xen solves it, KVM can use the solution (or vice versa). I don't see a huge problem. We'll have to get the APIC right, and the mmu locking right in the kernel, but what else? > > Don't discount the importance of 16 bit emulation performance. I use > QEMU a lot to play old DOS games :-) We'll add an option to udelay() in strategic places :) -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642