From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: Helping with KVM development Date: Tue, 19 Feb 2013 15:01:17 +0200 Message-ID: <20130219130117.GI3600@redhat.com> References: <511E8C27.7060504@ncsu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org To: Brandon Dwiel Return-path: Received: from mx1.redhat.com ([209.132.183.28]:36536 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754572Ab3BSNBZ (ORCPT ); Tue, 19 Feb 2013 08:01:25 -0500 Content-Disposition: inline In-Reply-To: <511E8C27.7060504@ncsu.edu> Sender: kvm-owner@vger.kernel.org List-ID: Hi Brandon, On Fri, Feb 15, 2013 at 02:27:35PM -0500, Brandon Dwiel wrote: > Hi, > > I'm a computer engineering PhD student and I have the opportunity to > contribute something to KVM as a class project. I found a few > interesting items on the KVM TODO list (http://www.linux-kvm.org/page/TODO) > that I could do. If I choose to do > this I would start immediately and have about 2 months to finish. I > wouldn't choose this project if I thought I would have to rely on the > help of you guys, but I think my biggest challenge will be diving in and > getting started. Hopefully you can help with that. > > My focus is on computer architecture so the x86 topics really interested > me. Here are the specific ones that I think I could do. I would start by > implementing one, and if that ends up not being substantial enough for a > final project, I'd do another. > > 1. Improve mmu page eviction algorithm (currently FIFO, change to > approximate LRU). This is not very useful at present. I have a code for this. For it to be useful memory pressure is needed, so I ran qemu with memory container to test (and with EPT disabled since my machine does not have accessed bit for EPT). It shows some improvement, but since kvm is swapping the guest is slow anyway. With fast swap to ssd storage it may be more useful, but we are not there yet. > 2. On-demand register access, really, copying all registers all the > time is gross. Not sure what this means. I think it was about copying all registers in/out during emulation on x86, but now registers are copied on demand. > 3. Implement mmx and sse memory move instructions; useful for guests > that use multimedia extensions for accessing vga (partially done) Done. > 4. Implement an operation queue for the emulator. The emulator often > calls userspace to perform a read or a write, but due to inversion > of control it actually restarts instead of continuing. The queue > would allow it to replay all previous operations until it reaches > the point it last stopped. Not sure what this is about. > 5. convert more instructions to direct dispatch (function pointer in > decode table) That's rather boring, but will make student learn about x86 instruction encoding. Warning though it may hurt him/her for life :) > 6. move init_emulate_ctxt() into x86_decode_insn() and other emulator > entry points Again, not sure what this is about. That tells me that we need to update our wiki. > > Have any of these already been implemented? It seems number 2 and > possibly 1 already have been. I think this list is quite outdated, so is > there something else along these lines of these updates that I could > help with? > > Thanks, > Brandon > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Gleb.