Hello! > I have confirmed that the IDT Winchip 2 does not expressly set %ecx > after a call to cpuid() with %eax = 1, and this causes incorrect > reporting of cpu capabilities. The %ecx register should return 0x0 > (and likely %ebx should too) on this hardware. This patch proposes a > fix. > > The symptoms of this arose on a Winchip 2 system when systemd called > cpuid() with %eax = 1 and it incorrectly reported rdrand() support > (bit 30 set in %ecx). A call to the supposedly supported rdrand() > function triggered an illegal instruction exception, causing the > system to panic early in booting. > > The IDT Winchip documentation is silent on what happens to %ecx and > %ebx after such a call (see below). It appears to leave whatever is in > %ecx untouched instead of zeroing it. This patch defensively zeroes > out %ebx:%ecx:%edx before such a call in cpuid.h.
The CPUID documentation from Intel Architectures Developer's manual is crystal clear on the implementation: --quote-- CPUID—CPU Identification Returns processor identification and feature information to the EAX, EBX, ECX, and EDX registers, as determined by input entered in EAX (in some cases, ECX as well). --quote-- So, I dont see why we should implement the workaround for an implementation bug in a widely used header for a relatively obscure target. Please also note that there are other places in the compiler that assume that the instruction returns values as specified above, not to mention other applications that assumes the same. I think proposed target specific bugfix should be implemented elsewhere, not in the cpuid.h header that assumes the specified functionality. Uros.
