Re: [Qemu-devel] Qemu and (Pacifica | Vanderpool)

[Anthony Liguori <aliguori@us.ibm.com>]

Jim C. Brown wrote:

>>VT/SVM will definitely improve the performance of kqemu/qvm86. 
>>    
>>
>
>VT/SVM won't actually help them that much in the current case, assuming that my
>understanding is correct. They can only make the userland bits a little
>faster, and kqemu/qvm86 don't support running kernel code (where the real gains
>would be realized).
>
VT/SVM allows you to run kernel code unmodified and without binary 
translation on bare metal.

>They could be extended to take over both userland and kernel code easily though.
>(In which case the user space qemu would provide only the system emulation
>bits - there'd no longer be any emulation of the guest cpu).
>
Yup.

>I believe that
>there are plans to extend kqemu to be able to do this at some point. But at
>that point I'd hesitate to call the combination "QEMU", since there would be
>nothing of the original qemu left (for the record this considered of the
>dynamic translator/JIT and the qemu-user code).
>  
>
kqemu would have to take advantage of VT/SVM to be able to run kernel 
code.  There's an excellent paper (that I referenced in my previous 
note) that explains why this is the case.

>Agreed. Of course, since Xen runs on the bare metal, one would expect that it
>would have better performance than qemu anyways (though if qemu's io model is
>used, that is not going to be true for the obvious reasons). If ease of
>installation is more important than performance, qemu is less invasive. I guess
>that can be considered a tradeoff.
>  
>
Yeah, I think that's the basic trade-off.

>I doubt qemu + kqemu/qvm86 is a pure Type II anyways, since it modifies the
>host operating system. And from my understanding of qvm86, the userland code
>is essentially run directly by qvm86 directly on the bare hardware, since the
>only parts of the host kernel that are involved are the parts that tell the
>kernel to leave that code alone. Modifying the accelerators so they handle
>running of all the guest code moves even farther away from this.
>  
>
The original Popek/Goldberg paper puts a set of requirements on the host 
Operating System such that one can implement a Type II VMM.  You can 
think of kqemu/qvm86 as extending the host operating system to satisfy 
the Type II requirements.

Regards,

Anthony Liguori

>--
>Infinite complexity begets infinite beauty.
>Infinite precision begets infinite perfection.
>
>  
>