Re: [PATCH 7/7] Allow KVM from a normal QEMU binary

[Anthony Liguori <aliguori-NZpS4cJIG2HvQtjrzfazuQ@public.gmane.org>]

Avi Kivity wrote:
> Anthony Liguori wrote:
>> This patch depends on patch 6 and modifies the KVM changes to be an 
>> "accelerator" for QEMU in much the same way kqemu is.
>>
>> The basic idea was to introduce a use_kvm flag in CPUState and, where 
>> appropriate, check for use_kvm before doing KVM specific things.  
>> There are a number of places where a valid CPUState is not available 
>> or simply not created yet.  In these cases, we use the global 
>> kvm_allowed variable.
>
> Applied, with the following changes:
>
> - actually define kvm_allowed (gcc 3.4 insists)

Sorry, I had a small SNAFU with my patch queue with qemu-kvm.c not being 
in the original hg tree.  I had defined kqemu_allowed in qemu-kvm.c but 
that wasn't in this patch.

> - a couple of places had kqemu_allowed instead of kvm_allowed

I guess I lucked out since kqemu_allowed=1 under normal circumstances.  
Thanks for catching that :-)

> - renamed the command line option to -no-kvm (similar to -no-kqemu)

When kqemu first went in, since it was considered "experimental" it had 
to be explicitly enabled with an -enable-kqemu option.  Once it was 
considered to be stable, it was enabled by default (hence -no-kqemu).

It really doesn't matter to me all that much.

>
> Most of the places where USE_KVM is used are now never called - they 
> are relics from the days when we had mixed qemu/kvm execution.

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 and refactoring things a bit so that it fails gracefully in 
the absence of a working KVM device.

The idea is to get rid of external dependencies.  What are your thoughts 
on this?  Do you think there will be significant users of libkvm.a 
outside of QEMU?

> Now, the "big real" fiasco means that we need some sort of emulation, 
> but I'm not sure the qemu cpu loop is the best choice.  Qemu is very 
> complex because it is geared to multi-host, multi-target, 
> high-performance emulation.  The cpu state is baroque, and SMP isn't 
> going to be fun.

Right.

> I think we're better off with taking the x86 emulator from the kernel 
> and extending it to support the non-memory instructions.  It can run 
> in the kernel or userspace since there's no performance requirement.

This is the opposite strategy that Xen is taking FWIW.  You not only 
need a full 16 bit emulator but a 32 bit emulator too (to deal with the 
transitions to/from userspace).

The tree we're working in is:

http://xenbits.xensource.com/ext/xen-unstable-hvm.hg

Linux kernel boots quite nicely and I'm in the process of debugging why 
Windows guests aren't booting (there appears to be a problem in the 
state transfer right now).

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).

Don't discount the importance of 16 bit emulation performance.  I use 
QEMU a lot to play old DOS games :-)

Regards,

Anthony Liguori

>>
>> This isn't a very pretty approach but it seems to work.  Figuring out 
>> how to make this all work with SMP is going to largely depend on how 
>> SMP gets implemented in KVM.
>>
>
> If we proceed as outlined above all we need is to slap a lock on all 
> accesses to the device model.  Later we can fine-grain it so that each 
> device has its own lock and accesses to multiple devices can occur in 
> parallel.
>
>


-------------------------------------------------------------------------
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