Bug 87913 - CPU cacheline size of 0 can be returned by CPUID leaf 0x80000006 in some virtual machines
Summary: CPU cacheline size of 0 can be returned by CPUID leaf 0x80000006 in some virt...
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Other (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: mesa-dev
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-31 15:54 UTC by Leonid Shatz
Modified: 2015-01-05 17:01 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Leonid Shatz 2014-12-31 15:54:35 UTC
In some recent commercial virtual machine environments cache line of 0 was actually spotted and that resulted in panics and failures of GDM to initialize leading to the SAD SCREEN.

The code used to provide default nonzero cache line size should be also used in case when CPU cache line size is extracted from CPUID leaf 0x80000006. 

The following correction is suggested:

src/gallium/auxiliary/util/u_cpu_detect.c:
...
void
util_cpu_detect(void)


    if (regs[0] >= 0x80000006) {
        cpuid(0x80000006, regs2);
+       if (cacheline > 0)
            util_cpu_caps.cacheline = regs2[2] & 0xFF;
    }
Comment 1 Leonid Shatz 2014-12-31 15:55:46 UTC
The bug exists since 9.2.5 and in the most recent versions of the project.
Comment 2 Leonid Shatz 2014-12-31 16:03:46 UTC
Sorry, the correct code would be something like:

   if (regs[0] >= 0x80000006) {
        cpuid(0x80000006, regs2);
+       if ((regs2[2] & 0xFF) > 0)
            util_cpu_caps.cacheline = regs2[2] & 0xFF;
    }
Comment 3 Roland Scheidegger 2014-12-31 17:55:33 UTC
I'm wondering if we actually should use this detection method if the other one (which queries clflush size in fact) is also available. I guess though there's some (amd) cpus where the other method isn't available. Not sure what's the better method to use in any case if both are available (might even provide the same number on all existing cpus).
Regardless, the patch looks good.
Comment 4 Leonid Shatz 2015-01-01 09:34:59 UTC
In virtual environments you would never know which is the safest method. It depends on the implementation and correctness of the hypervisor. I would just add the suggested fix and wait to see if any new related issues will be reported.
Comment 5 Roland Scheidegger 2015-01-05 17:01:28 UTC
Fixed by 5fea39ace311723dab53460ae7b51b80746e0d3f.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.