On Wed, Apr 13, 2016 at 06:26:05AM -0700, Mike Larkin wrote: > The Intel SDM is a little unclear as to precisely how to check for the > presence > of the general purpose architectural performance monitoring counters (via the > 'rdpmc' instruction). In one place in the manual, it describes capabilities > based on cpu family (using family names like "Intel Core Duo, Intel Core Solo, > Nehalem"), and in another place it advises using information gathered from > CPUID function 0xa to determine the actual level of support. > > It appears that pctr(4) always assumed the presence of at least one general > purpose counter (eg, "version 1" support) based on checking CPU family and > model IDs (followning the SDM's model and CPU family descriptions). KVM, on > the other hand, can disable the feature entirely based on a decision it makes > when inspecting host platform features. Therefore, on certain host machines, > pctr(1) would panic the machine since KVM would fail the rdpmc instruction. > > This diff changes the pctr(4) detection mechanism and only enables 'rdpmc' > if the CPUID function 0xa actually says version 1 or later is supported. > This should not have any impact on non-virtualized environments, and it > resolves the panic reported earlier. Obviously, if KVM doesn't emulate the > counters on a given host, you don't get those features via pctr(1) either. > The diff retains the previous detection method for AMD cpus. > > This was reported about a month ago by Hiltjo Posthuma who has also been > helping me with testing. Thanks. > > PS - note that pctr(1)/pctr(4) have other known issues in MP environments, > and this diff does nothing to fix those issues. > > ok? > > -ml
Tested on latest -current (amd64) and 5.9 stable (amd64) using an Intel CPU guest the panic is resolved, thanks :). pctr_intel_cap was set to 0. Kind regards, Hiltjo
