On Sun, Feb 21, 2010 at 02:24:02PM +0200, Avi Kivity wrote: > On 02/21/2010 02:10 PM, Joerg Roedel wrote: >> On Sat, Feb 20, 2010 at 01:26:49PM -1000, Zachary Amsden wrote: >> >>> The infrastructure is already there to import / export and migrate MSR >>> settings. MSRs are also 64-bit, and hold "model-specific" settings, so >>> if you don't mind thinking of the nested feature as a model-specific >>> feature of the KVM-SVM CPU, it's even somewhat well defined in terms of >>> the architecture. >>> >> There is a lot of additional state to migrate if the vcpu is running >> nested. To be architecturally correct you need to transfer 6kb of data >> through MSRs only for the msr permission bitmap. > > The msr permission bitmap is in guest memory, so it is already migrated. This will work almost always but its not architecturally correct because the memory contents may have changed since the last vmrun instruction. On the other hand we already have this problem with the current nested msr intercept handling... >> The rest comes down to >> the nested intercept masks > > These are in the vmcb, which is in guest memory. Same as with the MSR permission map here. >> It is doable but I still think its >> complicated to get this right. The simplest approach would be to >> disallow migration when the vcpu is running in guest mode. >> > > Agree, though I dislike the need to introduce a "force vmexit" ioctl. Yes, this has possible issues too. If we reconstruct the nested state from the nested vmcb there is not much state left which needs migration. But we should keep in mind that this is not how real hardware works. 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
