From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: [RFC] Using VMI with KVM Date: Wed, 03 Jan 2007 22:45:32 -0600 Message-ID: <459C866C.5050804@cs.utexas.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: To: kvm-devel 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 As I mentioned in a previous note, I've been playing around with using VMI to paravirtualize KVM. There are a couple of interesting things about this that I thought I'd share what I currently have. Unlike lhype or Xen, VMI simply redirects most sensitive operations into a block of code that's presented to the guest as a PCI option ROM. The guest copies the ROM somewhere into it's address space and will call into the ROM whenever it needs to do something interesting. A nice property of such a low-level interface is that it doesn't mandate very much. With both Xen and lhype, you are forced to run guests in ring 1. With VMI, you can happily run a guest in ring 0. I think there's a lot of benefits to paravirtualizing a guest in ring 0 (no performance penalty for syscalls for instance). It also means we can start out with a very simply "identity" ROM that implements all of the sensitive instructions as their native equivalents. We have no real need to touch pushf's for instance so we don't need to paravirtualize these. Instead, we can focus on things like PTE batching (which is something we can't do without paravirtualization). At the moment, I have a working VMI ROM that uses native equivalents for all sensitive ops. It's posted at the following location: http://hg.codemonkey.ws/kvm-vmi My plan was to implement IDE emulation entirely within the ROM using PIO VMI exits but I didn't discover until recently that PIO exits aren't in VMI yet :-) My current plan is to try and implement PTE update batching but I need to spend some time figuring out how to setup the .ld file so that my data/bss segments aren't fubar (as they are at the moment). You'll need my qemu-option-rom.diff and qemu-vmi.diff patches to be able to load the VMI ROM. These are against CVS so they will fuzz a bit against KVM's QEMU. You can get both of these patches from my qemu patch queue: http://hg.codemonkey.ws/qemu-pq You'll also need a VMI enabled kernel. I'm currently using the VMI patches available in the paravirt_ops patch queue: http://ozlabs.org/~rusty/paravirt/ I'm not hard set on using VMI but at the moment it seems like the easiest and most flexible approach to paravirtualizing KVM. I'm certainly interested in what other people think though. Regards, Anthony Liguori ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV