From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH 7/7] Allow KVM from a normal QEMU binary Date: Sun, 05 Nov 2006 12:18:04 -0600 Message-ID: <454E2ADC.1060607@cs.utexas.edu> References: <454AE007.5070905@cs.utexas.edu> <454AE323.8090309@cs.utexas.edu> <454DAE74.4030306@qumranet.com> <454E1F40.2070200@cs.utexas.edu> <454E23EE.7040505@qumranet.com> 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: Avi Kivity In-Reply-To: <454E23EE.7040505-atKUWr5tajBWk0Htik3J/w@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 Avi Kivity wrote: > Anthony Liguori wrote: >> 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. Yeah, I'm on the fence myself. In the very least, we need a smarter configure check in QEMU to detect the presence of libkvm and enable the define appropriately. I'll go as far as to say that once there's proper configure checks (and kvm fails gracefully), it would be appropriate to send it to qemu-devel. What are your thoughts? >>> 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). The Xen tree already has the conversion code. It's annoying but it's not nearly as bad as say, shadow paging :-) While not necessarily in your scope, in the long term, having the state transfer would be really useful. I can imagine KVM eventually supporting VT, SVM, user mode virtualization, and paravirtualization. State transfer use is useful for VT at least but is absolutely required for user mode virtualization. All of these things exist in some form right now (user mode via qvm86 and para via lhype) and all are duplicating a lot of tough code (such as shadow paging). Of course, state transfer won't be impossible to add down the road at some point so if you think big real mode will be easier with emulation, it wouldn't be that bad to give it a shot. > 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? It's not so bad provided you don't use QEMU for emulation. That's what I was referring to. There are some tricky cases where QEMU is accessing a piece of memory with an atomic instruction while another VCPU is running on bare metal and trying to touch the same memory. I suspect that as-is, QEMU would violate the atomic guarantees when it translates the instruction. Regards, Anthony Liguori >> >> 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 :) > ------------------------------------------------------------------------- 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