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 20:29:56 +0200 Message-ID: <454E2DA4.8070405@qumranet.com> References: <454AE007.5070905@cs.utexas.edu> <454AE323.8090309@cs.utexas.edu> <454DAE74.4030306@qumranet.com> <454E1F40.2070200@cs.utexas.edu> <454E23EE.7040505@qumranet.com> <454E2ADC.1060607@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: <454E2ADC.1060607-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: > 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? Qemu-devel has been strangely nonresponsive to my patches (the x86-64 gdb patch was sent at least two months ago). Maybe as a known contributor they'll be more responsive to you. The only other issue is how stable the interface is. I think that the kvmctl interface is almost there (I'd like to add a libkvm_open() and libkvm_close(), have kvm_create() use the context returned from libkvm_open(), and not create a vcpu and memory in kvm_create(), but these are fairly cosmetic). The kernel interface is another matter. I want to apply Arnd's suggestions, but that's some time off. If we don't push libkvm/kvmctl to qemu then that's not an issue. >> >> 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 :-) Well, a nice property of real mode is that it doesn't use 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. What is user mode virtualization in this context? > 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). Please elaborate. > > 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. > We already had real mode (and 16-bit protected, and 32-bit protected) during development. It should be very easy to add it back. I'm worried about maintenance and things like smp. >> 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. Ok. We're on the same cacheline then. An emulator definitely solves this. (though I can't see real-mode locked instructions happening... maybe that's an issue with qemu emulating multiple instructions for Xen during mmio) -- 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