From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH][SVM] Fix 32bit Windows guest VMs save/restore Date: Mon, 31 Jan 2011 22:17:33 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: wei.huang2@amd.com, xen-devel@lists.xensource.com Cc: james.harper@bendigoit.com.au List-Id: xen-devel@lists.xenproject.org On 31/01/2011 22:13, "Keir Fraser" wrote: > This handling of the SYSENTER MSRs is overly complicated. By the way, apart from the complexity, I suspect the current approach has further bugs because I don't believe the canonical sysenter msr values are correctly shuffled between the vmcb and vcpu structures when a guest moves in and out of long mode. Just another example why having two different canonical places for one data item is a bad idea. -- Keir > I suggest > reverting a bunch of the original handling of cross-vendor migration as > follows: > * Never intercept the SYSENTER MSRs. > * Remove the vcpu->arch.hvm_svm.guest_sysenter_* fields. > * Always hvm save/restore from/to the values in the vmcb. > * Modify svm_msr_read_intercept(MSR_IA32_SYSENTER_*) to svm_sync_vmcb() and > then read the sysenter msr value from vmcb > * Modify svm_msr_write_intercept(MSR_IA32_SYSENTER_*) to svm_sync_vmcb(), > then modify the sysenter msr in the vmcb, and then svm_vmload(). > > Result is that we get rid of some redundant fields from the vcpu structure > and have one canonical place we always keep the sysenter msr values, in the > vmcb. The extra cost in the msr read/write functions is totally > inconsequential, and only used after guest migration from an Intel CPU > anyway. Hardly something to optimise for. > > -- Keir > >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel > >