• Luis R. Rodriguez's avatar
    x86/mm/mtrr: Generalize runtime disabling of MTRRs · f9626104
    Luis R. Rodriguez authored
    It is possible to enable CONFIG_MTRR and CONFIG_X86_PAT and end
    up with a system with MTRR functionality disabled but PAT
    functionality enabled. This can happen, for instance, when the
    Xen hypervisor is used where MTRRs are not supported but PAT is.
    This can happen on Linux as of commit
    
      47591df5 ("xen: Support Xen pv-domains using PAT")
    
    by Juergen, introduced in v3.19.
    
    Technically, we should assume the proper CPU bits would be set
    to disable MTRRs but we can't always rely on this. At least on
    the Xen Hypervisor, for instance, only X86_FEATURE_MTRR was
    disabled as of Xen 4.4 through Xen commit 586ab6a [0], but not
    X86_FEATURE_K6_MTRR, X86_FEATURE_CENTAUR_MCR, or
    X86_FEATURE_CYRIX_ARR for instance.
    
    Roger Pau Monné has clarified though that although this is
    technically true we will never support PVH on these CPU types so
    Xen has no need to disable these bits on those systems. As per
    Roger, AMD K6, Centaur and VIA chips don't have the necessary
    hardware extensions to allow running PVH guests [1].
    
    As per Toshi it is also possible for the BIOS to disable MTRR
    support, in such cases get_mtrr_state() would update the MTRR
    state as per the BIOS, we need to propagate this information as
    well.
    
    x86 MTRR code relies on quite a bit of checks for mtrr_if being
    set to check to see if MTRRs did get set up. Instead, lets
    provide a generic getter for that. This also adds a few checks
    where they were not before which could potentially safeguard
    ourselves against incorrect usage of MTRR where this was not
    desirable.
    
    Where possible match error codes as if MTRRs were disabled on
    arch/x86/include/asm/mtrr.h.
    
    Lastly, since disabling MTRRs can happen at run time and we
    could end up with PAT enabled, best record now in our logs when
    MTRRs are disabled.
    
    [0] ~/devel/xen (git::stable-4.5)$ git describe --contains 586ab6a 4.4.0-rc1~18
    [1] http://lists.xenproject.org/archives/html/xen-devel/2015-03/msg03460.htmlSigned-off-by: default avatarLuis R. Rodriguez <mcgrof@suse.com>
    Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
    Cc: Andy Lutomirski <luto@amacapital.net>
    Cc: Antonino Daplas <adaplas@gmail.com>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Brian Gerst <brgerst@gmail.com>
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: Dave Airlie <airlied@redhat.com>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: Davidlohr Bueso <dbueso@suse.de>
    Cc: Denys Vlasenko <dvlasenk@redhat.com>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
    Cc: Juergen Gross <jgross@suse.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Roger Pau Monné <roger.pau@citrix.com>
    Cc: Stefan Bader <stefan.bader@canonical.com>
    Cc: Suresh Siddha <sbsiddha@gmail.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Cc: Toshi Kani <toshi.kani@hp.com>
    Cc: Ville Syrjälä <syrjala@sci.fi>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: bhelgaas@google.com
    Cc: david.vrabel@citrix.com
    Cc: jbeulich@suse.com
    Cc: konrad.wilk@oracle.com
    Cc: venkatesh.pallipadi@intel.com
    Cc: ville.syrjala@linux.intel.com
    Cc: xen-devel@lists.xensource.com
    Link: http://lkml.kernel.org/r/1426893517-2511-3-git-send-email-mcgrof@do-not-panic.com
    Link: http://lkml.kernel.org/r/1432628901-18044-12-git-send-email-bp@alien8.deSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
    f9626104
generic.c 23 KB