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 <jbeul...@suse.com>
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@lists.xen.org http://lists.xen.org/xen-devel
