Re: [Xen-devel] [PATCH v4] x86/HVM: make hvm_efer_valid() honor guest features

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 19/01/15 15:12, Jan Beulich wrote:
> Following the earlier similar change validating CR4 modifications.
>
> Note that this requires a non-obvious adjustment to hvm_cpuid(): On
> 32-bit hosts/tool stacks, the SYSCALL feature flag will be seen clear
> on Intel CPUs, yet 64-bit guests legitimately expect the feature for
> be available. Mimic hardware behavior: When executed from a 64-bit
> code segment, force the feature flag set.
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>

I finally have the debugging out of XenRT as to why this is still
failing for windows (including my improvements to the error message
which I will post in due course).

d58v1 Invalid EFER update: 0 -> 0x901 - SCE without feature

When windows brings up its second cpu, it appears to set up EFER
completely in one go, which means it will still be in protected mode at
this point.  It sets SCE in the knowledge that the cpu is 64bit, and
this indicates that it is valid to set EFER.SCE on 64-bit Intel cpus
even the feature would not appear via cpuid.

Undoing the v3 -> v4 change wrt hvm_cpuid() fixes the issue, and I rerun
the test suite like this.

I suggest that the easiest course of action is to simply ignore this
Intelism wrt EFER.SCE, and add it to the big bucket of edge cases that
we can't quite virtualise correctly.

On the other hand, I wonder whether it is permitted because LME is set
at the same time?  It might be that SCE is permitted if and only if LME
has been verified as ok.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel