| Message ID | 1250855924-13762-1-git-send-email-andre.przywara@amd.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 08/21/2009 02:58 PM, Andre Przywara wrote: > To enable cross-vendor migration we use VMCB external variables to hold > the full 64bit value of the SYSENTER MSRs, which get truncated to 32bit > on AMD hardware. Since we didn't intercept these MSRs, these > variables were only used in the emulation case, but were _always_ used > for migration purposes. This worked fine for cross-vendor migration in > compat mode, but did not work in pure legacy mode. > To fix this we always intercept the SYSENTER MSRs and store the values > both in the VMCB and the external variables. This works for all cases. > > Signed-off-by: Andre Przywara<andre.przywara@amd.com> > --- > arch/x86/kvm/svm.c | 9 ++++----- > 1 files changed, 4 insertions(+), 5 deletions(-) > > Hi Avi, > > this should fix the problem seen by Stephane and Thomas this week. > Please revert 8b2f9d194288982d654c1afef491dfdf75ec1ba9 (your proposed fix, > which broke cross-vendor migration) and apply this patch afterwards. > It worked for me with both 32on32 and 32on64 migration both cross-vendor > and between two AMD machines. > Reverted and applied; thanks.
Andre Przywara wrote:
> Stephane, Thomas: Can you verify this?
I'm not very familiar with compiling kvm-mod from git sources. And your
patch does not apply to svm.c shipped with kernel 2.6.30.5
So at the moment I have no clue, how to verify. Is there any short howto out
there, how to get kvm module from git source?
Regards
Thomas
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c index e158a2f..7853dd3 100644 --- a/arch/x86/kvm/svm.c +++ b/arch/x86/kvm/svm.c @@ -101,7 +101,6 @@ struct vcpu_svm { unsigned long vmcb_pa; struct svm_cpu_data *svm_data; uint64_t asid_generation; - uint64_t sysenter_cs; uint64_t sysenter_esp; uint64_t sysenter_eip; @@ -426,8 +425,6 @@ static void svm_vcpu_init_msrpm(u32 *msrpm) #endif set_msr_interception(msrpm, MSR_K6_STAR, 1, 1); set_msr_interception(msrpm, MSR_IA32_SYSENTER_CS, 1, 1); - set_msr_interception(msrpm, MSR_IA32_SYSENTER_ESP, 1, 1); - set_msr_interception(msrpm, MSR_IA32_SYSENTER_EIP, 1, 1); } static void svm_enable_lbrv(struct vcpu_svm *svm) @@ -2087,7 +2084,7 @@ static int svm_get_msr(struct kvm_vcpu *vcpu, unsigned ecx, u64 *data) break; #endif case MSR_IA32_SYSENTER_CS: - *data = svm->sysenter_cs; + *data = svm->vmcb->save.sysenter_cs; break; case MSR_IA32_SYSENTER_EIP: *data = svm->sysenter_eip; @@ -2176,13 +2173,15 @@ static int svm_set_msr(struct kvm_vcpu *vcpu, unsigned ecx, u64 data) break; #endif case MSR_IA32_SYSENTER_CS: - svm->sysenter_cs = data; + svm->vmcb->save.sysenter_cs = data; break; case MSR_IA32_SYSENTER_EIP: svm->sysenter_eip = data; + svm->vmcb->save.sysenter_eip = data; break; case MSR_IA32_SYSENTER_ESP: svm->sysenter_esp = data; + svm->vmcb->save.sysenter_esp = data; break; case MSR_IA32_DEBUGCTLMSR: if (!svm_has(SVM_FEATURE_LBRV)) {
To enable cross-vendor migration we use VMCB external variables to hold the full 64bit value of the SYSENTER MSRs, which get truncated to 32bit on AMD hardware. Since we didn't intercept these MSRs, these variables were only used in the emulation case, but were _always_ used for migration purposes. This worked fine for cross-vendor migration in compat mode, but did not work in pure legacy mode. To fix this we always intercept the SYSENTER MSRs and store the values both in the VMCB and the external variables. This works for all cases. Signed-off-by: Andre Przywara <andre.przywara@amd.com> --- arch/x86/kvm/svm.c | 9 ++++----- 1 files changed, 4 insertions(+), 5 deletions(-) Hi Avi, this should fix the problem seen by Stephane and Thomas this week. Please revert 8b2f9d194288982d654c1afef491dfdf75ec1ba9 (your proposed fix, which broke cross-vendor migration) and apply this patch afterwards. It worked for me with both 32on32 and 32on64 migration both cross-vendor and between two AMD machines. Stephane, Thomas: Can you verify this? Thanks! Regards, Andre.