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

[Anthony Liguori]

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