Re: [Xen-devel] [PATCH][SVM] Fix 32bit Windows guest VMs save/restore

[Keir Fraser <keir@xxxxxxx>]

On 31/01/2011 22:13, "Keir Fraser" <keir@xxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel