Re: [Xen-devel] [PATCH 2/3] x86/boot: Cache cpu_has_hypervisor very early on boot

[Jan Beulich <jbeulich@xxxxxxxx>]

On 04.11.2019 16:31, Andrew Cooper wrote:
> On 04/11/2019 13:32, Jan Beulich wrote:
>> On 01.11.2019 21:25, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/boot/head.S
>>> +++ b/xen/arch/x86/boot/head.S
>>> @@ -630,6 +630,10 @@ trampoline_setup:
>>>  
>>>  1:
>>>          /* Interrogate CPU extended features via CPUID. */
>>> +        mov     $1, %eax
>>> +        cpuid
>>> +        mov     %ecx, sym_fs(boot_cpu_data) + 
>>> CPUINFO_FEATURE_OFFSET(X86_FEATURE_HYPERVISOR)
>> I understand the ECX output is all we need right now. But wouldn't
>> it be better to then store EDX as well (and similarly ECX of
>> 0x80000001 output)?
> 
> No - I don't think so.
> 
> I did debate applying an and mask for the features we only intend to be
> usable this early, to avoid getting buggy code which checks for
> unexpected features this early.

Indeed doing so would seem a good reason to not also store the EDX
value here.

>> Also, along the lines of a question back to Sergey on his
>> standalone patch, wouldn't it be better to take the opportunity
>> and check here that CPUID leaf 1 is actually valid?
> 
> There is no such thing as a 64-bit capable CPU without leaf 1.

About anything can be constructed under a hypervisor. But well, I
guess I'll stop mumbling on this aspect.

>> Of course the question on the (intended) effect of
>> "cpuid=no-hypervisor" also remains. As said before, I think this
>> should be honored by all of our code that possibly can (i.e. at
>> least everything following command line parsing).
> 
> There is no chance of making that work in a sane way - we use
> cpu_has_hypervisor for quite a few things before the command line gets
> parsed.

You said so the other day, but iirc when checking I wasn't able to
identify any such case, let alone "quite a few".

Anyway, feel free to add
Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel