Helping with KVM development

Helping with KVM development

[Brandon Dwiel]

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).
2. On-demand register access, really, copying all registers all the
time is gross.
3. Implement mmx and sse memory move instructions; useful for guests
that use multimedia extensions for accessing vga (partially 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.
5. convert more instructions to direct dispatch (function pointer in
decode table)
6. move init_emulate_ctxt() into x86_decode_insn() and other emulator
entry points

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

Re: Helping with KVM development

[Gleb Natapov]

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.