Re: Nested SVM and migration

[Joerg Roedel <joerg.roedel@amd.com>]

On Mon, Feb 22, 2010 at 06:46:19AM -1000, Zachary Amsden wrote:
> On 02/21/2010 03:09 AM, Joerg Roedel wrote:
> >On Sun, Feb 21, 2010 at 02:54:01PM +0200, Avi Kivity wrote:
> >>So, if some other cpu (or the guest itself, with appropriate
> >>permissions) modifies the msr permission bitmap, svm will not notice
> >>this?  svm loads the bitmap during entry?
> >Yes.
> 
> Ugh.  So we have non-reversible architectural state all over again.
> There are ways around this problem, all ugly, but the easiest is
> shadowing the MSR permission bitmap.
> 
> >>I don't think you can tell, unless the host cpu modifying the vmcb is
> >>synchronized with the guest (or the guest modifies its own vmcb).  But
> >>this is all academic.
> >Hmm, another thing comes to mind. We would need some redesign of the
> >nested_svm code to allow userspace to put a vcpu directly into nested
> >state. With the MSR approach, all userspace does is to write MSRs into
> >the vcpu before the first run?
> 
> How does MSR_KVM_NESTED_SVM_ACTIVE not solve this problem?

Image migration from host1 -> host2

When you want to put a vcpu directly into nested state you need to
recalculate certain stuff like the intercept bitmaps (intercept bitmaps
from host1 and host2 might be different) or the tsc_offset. But this can all
be done in the vcpu_unfreeze ioctl.

	Joerg