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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
