[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 4/6] x86/hvm: Move hvm_funcs.cpuid_intercept() handling into hvm_cpuid()



>>> On 16.11.16 at 18:07, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 16/11/16 15:20, Jan Beulich wrote:
>>>>> On 16.11.16 at 13:31, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> @@ -3676,6 +3671,12 @@ void hvm_cpuid(unsigned int input, unsigned int 
>>> *eax, unsigned int *ebx,
>>>              if ( !(hvm_pae_enabled(v) || hvm_long_mode_enabled(v)) )
>>>                  *edx &= ~cpufeat_mask(X86_FEATURE_PSE36);
>>>          }
>>> +
>>> +        /* SYSCALL is hidden outside of long mode on Intel. */
>>> +        if ( d->arch.x86_vendor == X86_VENDOR_INTEL &&
>>> +             !hvm_long_mode_enabled(v))
>>> +            *edx &= ~cpufeat_mask(X86_FEATURE_SYSCALL);
>> Original code also set the bit in its opposite path - don't you think
>> this should be retained (or otherwise the change be explained in
>> the description)?
> 
> Yeah - that was conceptually wrong.  It is legitimate (although
> unlikely) for an admin to explicitly configure the VM to hide syscall
> even in long mode, as they have distinct feature bits.

I don't think any 64-bit OS would work without SYSCALL support.
Look at ourselves - we don't even care to check, and we have no
alternative way of invoking hypercalls in case it was absent.

Jan


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.