Skip to content
  • George Dunlap's avatar
    perf/x86: Check all MSRs before passing hw check · a5ebe0ba
    George Dunlap authored and Ingo Molnar's avatar Ingo Molnar committed
    
    
    check_hw_exists() has a number of checks which go to two exit
    paths: msr_fail and bios_fail.  Checks classified as msr_fail
    will cause check_hw_exists() to return false, causing the PMU
    not to be used; bios_fail checks will only cause a warning to be
    printed, but will return true.
    
    The problem is that if there are both msr failures and bios
    failures, and the routine hits a bios_fail check first, it will
    exit early and return true, not finishing the rest of the msr
    checks.  If those msrs are in fact broken, it will cause them to
    be used erroneously.
    
    In the case of a Xen PV VM, the guest OS has read access to all
    the MSRs, but write access is white-listed to supported
    features.  Writes to unsupported MSRs have no effect.  The PMU
    MSRs are not (typically) supported, because they are expensive
    to save and restore on a VM context switch.  One of the
    "msr_fail" checks is supposed to detect this circumstance (ether
    for Xen or KVM) and disable the harware PMU.
    
    However, on one of my AMD boxen, there is (apparently) a broken
    BIOS which triggers one of the bios_fail checks.  In particular,
    MSR_K7_EVNTSEL0 has the ARCH_PERFMON_EVENTSEL_ENABLE bit set.
    The guest kernel detects this because it has read access to all
    MSRs, and causes it to skip the rest of the checks and try to
    use the non-existent hardware PMU.  This minimally causes a lot
    of useless instruction emulation and Xen console spam; it may
    cause other issues with the watchdog as well.
    
    This changset causes check_hw_exists() to go through all of the
    msr checks, failing and returning false if any of them fail.
    This makes sure that a guest running under Xen without a virtual
    PMU will detect that there is no functioning PMU and not attempt
    to use it.
    
    This problem affects kernels as far back as 3.2, and should thus
    be considered for backport.
    
    Signed-off-by: default avatarGeorge Dunlap <george.dunlap@eu.citrix.com>
    Cc: Konrad Wilk <konrad.wilk@oracle.com>
    Cc: Ian Campbell <ian.campbell@citrix.com>
    Cc: David Vrabel <david.vrabel@citrix.com>
    Cc: Andrew Cooper <andrew.cooper3@citrix.com>
    Link: http://lkml.kernel.org/r/1365000388-32448-1-git-send-email-george.dunlap@eu.citrix.com
    
    
    Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
    a5ebe0ba