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