On 19.10.2008, at 11:56, Avi Kivity wrote:

Alexander Graf wrote:
The current generation of virtualization extensions only supports one VM layer. While we can't change that, it is pretty easy to emulate the CPU's behavior
and implement the virtualization opcodes ourselves.

This patchset does exactly this for SVM. Using it, KVM can run within a VM. Since we're emulating the real CPU's behavior, this should also enable other
VMMs to run within KVM.
So far I've only tested to run KVM inside the VM though.

As always, comments and suggestions are highly welcome.

v2 takes most comments from Avi into account.

v3 addresses Joergs comments, including

- V_INTR_MASKING support
- a generic permission checking helper

v4 addresses even more comments from Joerg, including

- don't use the guest's hsave to store the guest's vmcb in
- add nested=<int> flag for kvm-amd.ko, defaults to 0 (off)
- include Joerg's VM_CR MSR patch

To be usable, this patchset requires the two simple changes in the userspace
part, that I sent to the list with the first version.

Known issues:

- TODO: #VMEXIT on save/restore
- SMP l2 guests break with in-kernel-apic


Looks ready to apply, though it would be good to get smp working. Defaulting to off relaxes some of the worries.

Oh, cool. I think as long as everything's guarded by EFLAGS_SVME, and nested=0 by default, it really shouldn't bother anyone. Nothing except for svm.c should be affected.

I assume the move to host-backed hsave fixes the security hole Joerg spotted?

Yes. The problem was that potentially a l2 guest could have access to the hsave page when the l1 guest maps it into the allowed virtual memory of the l2 guest. If so, the l2 guest could modify the hsave, which is assumed to be not tempered with by the rest of the code. So by not exposing the actual hsave to the l1 guest, no l2 guest will ever be able to temper with it.

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to