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 13:53:02 -0600 Message-ID: <454E411E.8000701@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> <454E2ADC.1060607@cs.utexas.edu> <454E2DA4.8070405@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: <454E2DA4.8070405-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: >> 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. Fabrice can often miss patches for no other reason than I think he tends to deal with them in batches. Don't hesitate to resend patches and to CC him directly. He won't ignore patches because he doesn't like them. > 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. Right, I think that's the biggest argument for keeping libkvm so I'm happy with that for now. >> >> 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? Running ring 3 code on bare metal and then using QEMU to run ring 0/1/2 code. Surprisingly enough, it makes a pretty big impact. While not a total replacement for having VT/SVM, it's IMHO a pretty reasonable alternative for non VT/SVM chips. >> 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. Fundamentally, all these forms of virtualization follow the same idea--run some code directly on bare metal and run other code in an emulator. The only thing that separates the mechanisms is which code is run in the emulator and how the transition from bare metal to emulation is made. For VT, the when is for 16 bit code and the how is via vmlaunch/vmexit combinations. For SVM, then when is never (theoritically) and the how is via vmrun/vmexit. For paravirtualization, the when is never (although I think using an emulator for 16 bit mode would still be useful here) and the how is hypercalls. For user virtualization, the when is supervisor code and the how is privilege transitions. All of these approaches require the same supporting code (IO emulation, shadow paging, etc.). While I think it's far too much to try and design for all of these things up front, I don't think it hurts to keep it in mind. Ideally, Linux could support all of these things and share the supporting code. So, one of the reasons I think doing the transitioning with QEMU is a good idea is that I think it'll eventually be needed. BTW, here are the respective links for qvm86 and lhype. http://savannah.nongnu.org/projects/qvm86/ - qvm86 http://ozlabs.org/~rusty/paravirt - lhype.patch >>> 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) Right, I presume that eventually you'll want to do emulation for MMIO so it would be necessary to deal with protected mode code. I think enhancing the emulator to handle big real mode for now is a reasonable thing to do. Perhaps when we solve some of the SMP issues with V2E in Xen we can revisit this issue. Regards, Anthony Liguori ------------------------------------------------------------------------- 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