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.

> 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.

> 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.

If you're booting under a hypervisor, your hypervisor ought to have a
way to turn that off.

~Andrew

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

Reply via email to