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

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Anthony Liguori wrote:
>
>>
>> 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

I'd like to keep kvmctl out, so that non-qemu based userspace can be 
built.  True, I wouldn't like to be the one to do it, but I'd like to 
keep the possibility open.


> and refactoring things a bit so that it fails gracefully in the 
> absence of a working KVM device.

Sure, if it can't create a kvm vm it should fall back to kqemu or normal 
emulation.

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

Right now there's just the (mostly broken) test suite.

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

We need a real-mode emulator.  That includes 16 and 32 bits (via prefixes).

We already have some significant fraction of it in x86_emulator.c.  
Whether to extend it (in the kernel or in userspace) or to use some 
other emulator is a good question.  Of course, we can use qemu, but 
that's fairly complex.

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

State transfer is what turned us of qemu.  Reconstructing the state 
(esp. eflags and the segments) is quite difficult and there are some 
annoying qemu bugs (like the busy task flag checks).

BTW, dumping qemu cpu emulation will allow us to use gcc 4.x instead of 
gcc 3.x.

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

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?

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

We'll add an option to udelay() in strategic places :)

-- 
error compiling committee.c: too many arguments to function


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