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

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 22/01/15 09:02, Jan Beulich wrote:
>>>> On 21.01.15 at 21:08, <andrew.cooper3@citrix.com> wrote:
>> 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@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.
> Now that's odd - v4 only changes _where_ the SYSCALL feature
> flag gets set, not the dependency on CS.L. Or are you saying
> that this vCPU hotplug issue is independent of the 32-bit tool
> stack one that v3 fixed, and hence it is a problem that the VMX
> code actively clears the feature flag?

vmx_cpuid_intercept() unconditionally sets or clears the SYSCALL feature
depending on whether the current vcpu is in a CS.L segment.

Therefore, when hvm_valid_efer() queries ext1_edx (currently running in
32bit mode, setting up for long mode), the syscall feature bit is clear,
which causes the SCE check to fail.

~Andrew

>
>> 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.
> And I think I'll go that route - permit SCE when the feature flag is
> set, or would be set after entering long mode when enabling long
> mode at the same time.
>
> Jan
>