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

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

Avi Kivity wrote:
> Anthony Liguori wrote:
>> I'll go as far as to say that once there's proper configure checks 
>> (and kvm fails gracefully), it would be appropriate to send it to 
>> qemu-devel.  What are your thoughts?
>
> Qemu-devel has been strangely nonresponsive to my patches (the x86-64 
> gdb patch was sent at least two months ago).  Maybe as a known 
> contributor they'll be more responsive to you.

Fabrice can often miss patches for no other reason than I think he tends 
to deal with them in batches.  Don't hesitate to resend patches and to 
CC him directly.  He won't ignore patches because he doesn't like them.

> The only other issue is how stable the interface is.  I think that the 
> kvmctl interface is almost there (I'd like to add a libkvm_open() and 
> libkvm_close(), have kvm_create() use the context returned from 
> libkvm_open(), and not create a vcpu and memory in kvm_create(), but 
> these are fairly cosmetic).
>
> The kernel interface is another matter.  I want to apply Arnd's 
> suggestions, but that's some time off.  If we don't push libkvm/kvmctl 
> to qemu then that's not an issue.

Right, I think that's the biggest argument for keeping libkvm so I'm 
happy with that for now.

>>
>> While not necessarily in your scope, in the long term, having the 
>> state transfer would be really useful.
>>
>> I can imagine KVM eventually supporting VT, SVM, user mode 
>> virtualization, and paravirtualization. State transfer use is useful 
>> for VT at least but is absolutely required for user mode 
>> virtualization.  
>
> What is user mode virtualization in this context?

Running ring 3 code on bare metal and then using QEMU to run ring 0/1/2 
code.  Surprisingly enough, it makes a pretty big impact.  While not a 
total replacement for having VT/SVM, it's IMHO a pretty reasonable 
alternative for non VT/SVM chips.

>> All of these things exist in some form right now (user mode via qvm86 
>> and para via lhype) and all are duplicating a lot of tough code (such 
>> as shadow paging).
>
> Please elaborate.

Fundamentally, all these forms of virtualization follow the same 
idea--run some code directly on bare metal and run other code in an 
emulator.  The only thing that separates the mechanisms is which code is 
run in the emulator and how the transition from bare metal to emulation 
is made.

For VT, the when is for 16 bit code and the how is via vmlaunch/vmexit 
combinations.

For SVM, then when is never (theoritically) and the how is via vmrun/vmexit.

For paravirtualization, the when is never (although I think using an 
emulator for 16 bit mode would still be useful here) and the how is 
hypercalls.

For user virtualization, the when is supervisor code and the how is 
privilege transitions.

All of these approaches require the same supporting code (IO emulation, 
shadow paging, etc.).  While I think it's far too much to try and design 
for all of these things up front, I don't think it hurts to keep it in 
mind.  Ideally, Linux could support all of these things and share the 
supporting code.

So, one of the reasons I think doing the transitioning with QEMU is a 
good idea is that I think it'll eventually be needed.

BTW, here are the respective links for qvm86 and lhype.

http://savannah.nongnu.org/projects/qvm86/ - qvm86

http://ozlabs.org/~rusty/paravirt - lhype.patch

>>> 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?
>>
>> It's not so bad provided you don't use QEMU for emulation.  That's 
>> what I was referring to.  There are some tricky cases where QEMU is 
>> accessing a piece of memory with an atomic instruction while another 
>> VCPU is running on bare metal and trying to touch the same memory.  I 
>> suspect that as-is, QEMU would violate the atomic guarantees when it 
>> translates the instruction.
>
> Ok.  We're on the same cacheline then.  An emulator definitely solves 
> this.
>
> (though I can't see real-mode locked instructions happening... maybe 
> that's an issue with qemu emulating multiple instructions for Xen 
> during mmio)

Right, I presume that eventually you'll want to do emulation for MMIO so 
it would be necessary to deal with protected mode code.

I think enhancing the emulator to handle big real mode for now is a 
reasonable thing to do.  Perhaps when we solve some of the SMP issues 
with V2E in Xen we can revisit this issue.

Regards,

Anthony Liguori


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