commit dfbed80c63bb8d965067da3a6dbcc4682edcce0c
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Mar 16 08:42:30 2016 -0700

    Linux 3.14.65

commit c4eb62da6f34bfa9bbcbd005210a90fdfca7e367
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Mar 12 21:30:16 2016 -0800

    Revert: "crypto: af_alg - Disallow bind/setkey/... after accept(2)"
    
    This reverts commit 06b4194533ff92ed5888840e3a6beaf29a8fe5d4 which is
    commit c840ac6af3f8713a71b4d2363419145760bd6044 upstream.
    
    It's been widely reported that this patch breaks existing userspace
    applications when backported to the stable kernel releases.  As no fix
    seems to be forthcoming, just revert it to let systems work again.
    
    Reported-by: "J. Paul Reed" <preed@sigkill.com>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 952b0e42f8f8c7c316491d0cbf9c0d41ad4d3838
Author: Rusty Russell <rusty@rustcorp.com.au>
Date:   Wed Feb 3 16:55:26 2016 +1030

    modules: fix longstanding /proc/kallsyms vs module insertion race.
    
    commit 8244062ef1e54502ef55f54cced659913f244c3e upstream.
    
    For CONFIG_KALLSYMS, we keep two symbol tables and two string tables.
    There's one full copy, marked SHF_ALLOC and laid out at the end of the
    module's init section.  There's also a cut-down version that only
    contains core symbols and strings, and lives in the module's core
    section.
    
    After module init (and before we free the module memory), we switch
    the mod->symtab, mod->num_symtab and mod->strtab to point to the core
    versions.  We do this under the module_mutex.
    
    However, kallsyms doesn't take the module_mutex: it uses
    preempt_disable() and rcu tricks to walk through the modules, because
    it's used in the oops path.  It's also used in /proc/kallsyms.
    There's nothing atomic about the change of these variables, so we can
    get the old (larger!) num_symtab and the new symtab pointer; in fact
    this is what I saw when trying to reproduce.
    
    By grouping these variables together, we can use a
    carefully-dereferenced pointer to ensure we always get one or the
    other (the free of the module init section is already done in an RCU
    callback, so that's safe).  We allocate the init one at the end of the
    module init section, and keep the core one inside the struct module
    itself (it could also have been allocated at the end of the module
    core, but that's probably overkill).
    
    [ Rebased for 4.4-stable and older, because the following changes aren't
      in the older trees:
      - e0224418516b4d8a6c2160574bac18447c354ef0: adds arg to is_core_symbol
      - 7523e4dc5057e157212b4741abd6256e03404cf1: module_init/module_core/init_size/core_size
        become init_layout.base/core_layout.base/init_layout.size/core_layout.size.
    
      Original commit: 8244062ef1e54502ef55f54cced659913f244c3e
    ]
    
    Reported-by: Weilong Chen <chenweilong@huawei.com>
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=111541
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e90f4779cbca934940a4c4e67c96fdf314c291c8
Author: Jason Andryuk <jandryuk@gmail.com>
Date:   Fri Feb 12 23:13:33 2016 +0000

    lib/ucs2_string: Correct ucs2 -> utf8 conversion
    
    commit a68075908a37850918ad96b056acc9ac4ce1bd90 upstream.
    
    The comparisons should be >= since 0x800 and 0x80 require an additional bit
    to store.
    
    For the 3 byte case, the existing shift would drop off 2 more bits than
    intended.
    
    For the 2 byte case, there should be 5 bits bits in byte 1, and 6 bits in
    byte 2.
    
    Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
    Reviewed-by: Laszlo Ersek <lersek@redhat.com>
    Cc: Peter Jones <pjones@redhat.com>
    Cc: Matthew Garrett <mjg59@coreos.com>
    Cc: "Lee, Chun-Yi" <jlee@suse.com>
    Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fb7ef72dcf235ffeb3b3316c5b844fa035d45683
Author: Matt Fleming <matt@codeblueprint.co.uk>
Date:   Mon Feb 15 10:34:05 2016 +0000

    efi: Add pstore variables to the deletion whitelist
    
    commit e246eb568bc4cbbdd8a30a3c11151ff9b7ca7312 upstream.
    
    Laszlo explains why this is a good idea,
    
     'This is because the pstore filesystem can be backed by UEFI variables,
      and (for example) a crash might dump the last kilobytes of the dmesg
      into a number of pstore entries, each entry backed by a separate UEFI
      variable in the above GUID namespace, and with a variable name
      according to the above pattern.
    
      Please see "drivers/firmware/efi/efi-pstore.c".
    
      While this patch series will not prevent the user from deleting those
      UEFI variables via the pstore filesystem (i.e., deleting a pstore fs
      entry will continue to delete the backing UEFI variable), I think it
      would be nice to preserve the possibility for the sysadmin to delete
      Linux-created UEFI variables that carry portions of the crash log,
      *without* having to mount the pstore filesystem.'
    
    There's also no chance of causing machines to become bricked by
    deleting these variables, which is the whole purpose of excluding
    things from the whitelist.
    
    Use the LINUX_EFI_CRASH_GUID guid and a wildcard '*' for the match so
    that we don't have to update the string in the future if new variable
    name formats are created for crash dump variables.
    
    Reported-by: Laszlo Ersek <lersek@redhat.com>
    Acked-by: Peter Jones <pjones@redhat.com>
    Tested-by: Peter Jones <pjones@redhat.com>
    Cc: Matthew Garrett <mjg59@srcf.ucam.org>
    Cc: "Lee, Chun-Yi" <jlee@suse.com>
    Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c67d696fa1339567014dc2aa5919ff36a0642697
Author: Peter Jones <pjones@redhat.com>
Date:   Mon Feb 8 14:48:15 2016 -0500

    efi: Make efivarfs entries immutable by default
    
    commit ed8b0de5a33d2a2557dce7f9429dca8cb5bc5879 upstream.
    
    "rm -rf" is bricking some peoples' laptops because of variables being
    used to store non-reinitializable firmware driver data that's required
    to POST the hardware.
    
    These are 100% bugs, and they need to be fixed, but in the mean time it
    shouldn't be easy to *accidentally* brick machines.
    
    We have to have delete working, and picking which variables do and don't
    work for deletion is quite intractable, so instead make everything
    immutable by default (except for a whitelist), and make tools that
    aren't quite so broad-spectrum unset the immutable flag.
    
    Signed-off-by: Peter Jones <pjones@redhat.com>
    Tested-by: Lee, Chun-Yi <jlee@suse.com>
    Acked-by: Matthew Garrett <mjg59@coreos.com>
    Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a74e2a9e766e214c834f3d2964cfffa1c387b9a0
Author: Peter Jones <pjones@redhat.com>
Date:   Mon Feb 8 14:48:14 2016 -0500

    efi: Make our variable validation list include the guid
    
    commit 8282f5d9c17fe15a9e658c06e3f343efae1a2a2f upstream.
    
    All the variables in this list so far are defined to be in the global
    namespace in the UEFI spec, so this just further ensures we're
    validating the variables we think we are.
    
    Including the guid for entries will become more important in future
    patches when we decide whether or not to allow deletion of variables
    based on presence in this list.
    
    Signed-off-by: Peter Jones <pjones@redhat.com>
    Tested-by: Lee, Chun-Yi <jlee@suse.com>
    Acked-by: Matthew Garrett <mjg59@coreos.com>
    Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3285d6ab25cb597f71ce911a1237ac993c177fc5
Author: Peter Jones <pjones@redhat.com>
Date:   Mon Feb 8 14:48:13 2016 -0500

    efi: Do variable name validation tests in utf8
    
    commit 3dcb1f55dfc7631695e69df4a0d589ce5274bd07 upstream.
    
    Actually translate from ucs2 to utf8 before doing the test, and then
    test against our other utf8 data, instead of fudging it.
    
    Signed-off-by: Peter Jones <pjones@redhat.com>
    Acked-by: Matthew Garrett <mjg59@coreos.com>
    Tested-by: Lee, Chun-Yi <jlee@suse.com>
    Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 84603ed7e7357217f48e35cc4b4b2c3337d9b725
Author: Peter Jones <pjones@redhat.com>
Date:   Mon Feb 8 14:48:12 2016 -0500

    efi: Use ucs2_as_utf8 in efivarfs instead of open coding a bad version
    
    commit e0d64e6a880e64545ad7d55786aa84ab76bac475 upstream.
    
    Translate EFI's UCS-2 variable names to UTF-8 instead of just assuming
    all variable names fit in ASCII.
    
    Signed-off-by: Peter Jones <pjones@redhat.com>
    Acked-by: Matthew Garrett <mjg59@coreos.com>
    Tested-by: Lee, Chun-Yi <jlee@suse.com>
    Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 002f14d470825598cca1ab3c3a97d8eb1c026613
Author: Peter Jones <pjones@redhat.com>
Date:   Mon Feb 8 14:48:11 2016 -0500

    lib/ucs2_string: Add ucs2 -> utf8 helper functions
    
    commit 73500267c930baadadb0d02284909731baf151f7 upstream.
    
    This adds ucs2_utf8size(), which tells us how big our ucs2 string is in
    bytes, and ucs2_as_utf8, which translates from ucs2 to utf8..
    
    Signed-off-by: Peter Jones <pjones@redhat.com>
    Tested-by: Lee, Chun-Yi <jlee@suse.com>
    Acked-by: Matthew Garrett <mjg59@coreos.com>
    Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 444b361a4f2ca31a37da7610cec22dfab98b82c3
Author: Marcelo Tosatti <mtosatti@redhat.com>
Date:   Wed Oct 14 19:33:09 2015 -0300

    KVM: x86: move steal time initialization to vcpu entry time
    
    commit 7cae2bedcbd4680b155999655e49c27b9cf020fa upstream.
    
    As reported at https://bugs.launchpad.net/qemu/+bug/1494350,
    it is possible to have vcpu->arch.st.last_steal initialized
    from a thread other than vcpu thread, say the iothread, via
    KVM_SET_MSRS.
    
    Which can cause an overflow later (when subtracting from vcpu threads
    sched_info.run_delay).
    
    To avoid that, move steal time accumulation to vcpu entry time,
    before copying steal time data to guest.
    
    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
    Reviewed-by: David Matlack <dmatlack@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 912027661329cbd708d23e99aa25df971410842c
Author: Andreas Schwab <schwab@linux-m68k.org>
Date:   Fri Feb 5 19:50:03 2016 +0100

    powerpc: Fix dedotify for binutils >= 2.26
    
    commit f15838e9cac8f78f0cc506529bb9d3b9fa589c1f upstream.
    
    Since binutils 2.26 BFD is doing suffix merging on STRTAB sections.  But
    dedotify modifies the symbol names in place, which can also modify
    unrelated symbols with a name that matches a suffix of a dotted name.  To
    remove the leading dot of a symbol name we can just increment the pointer
    into the STRTAB section instead.
    
    Backport to all stables to avoid breakage when people update their
    binutils - mpe.
    
    Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2c0026457e7b3eb75a8952cda06065ec0aca9bde
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Thu Feb 18 19:49:18 2016 +0100

    mac80211: minstrel_ht: set default tx aggregation timeout to 0
    
    commit 7a36b930e6ed4702c866dc74a5ad07318a57c688 upstream.
    
    The value 5000 was put here with the addition of the timeout field to
    ieee80211_start_tx_ba_session. It was originally added in mac80211 to
    save resources for drivers like iwlwifi, which only supports a limited
    number of concurrent aggregation sessions.
    
    Since iwlwifi does not use minstrel_ht and other drivers don't need
    this, 0 is a better default - especially since there have been
    recent reports of aggregation setup related issues reproduced with
    ath9k. This should improve stability without causing any adverse
    effects.
    
    Acked-by: Avery Pennarun <apenwarr@gmail.com>
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 46d3dcc28f3f0c2f4bb612f1d59f50f529f7875c
Author: Chris Bainbridge <chris.bainbridge@gmail.com>
Date:   Wed Jan 27 15:46:18 2016 +0000

    mac80211: fix use of uninitialised values in RX aggregation
    
    commit f39ea2690bd61efec97622c48323f40ed6e16317 upstream.
    
    Use kzalloc instead of kmalloc for struct tid_ampdu_rx to
    initialize the "removed" field (all others are initialized
    manually). That fixes:
    
    UBSAN: Undefined behaviour in net/mac80211/rx.c:932:29
    load of value 2 is not a valid value for type '_Bool'
    CPU: 3 PID: 1134 Comm: kworker/u16:7 Not tainted 4.5.0-rc1+ #265
    Workqueue: phy0 rt2x00usb_work_rxdone
     0000000000000004 ffff880254a7ba50 ffffffff8181d866 0000000000000007
     ffff880254a7ba78 ffff880254a7ba68 ffffffff8188422d ffffffff8379b500
     ffff880254a7bab8 ffffffff81884747 0000000000000202 0000000348620032
    Call Trace:
     [<ffffffff8181d866>] dump_stack+0x45/0x5f
     [<ffffffff8188422d>] ubsan_epilogue+0xd/0x40
     [<ffffffff81884747>] __ubsan_handle_load_invalid_value+0x67/0x70
     [<ffffffff82227b4d>] ieee80211_sta_reorder_release.isra.16+0x5ed/0x730
     [<ffffffff8222ca14>] ieee80211_prepare_and_rx_handle+0xd04/0x1c00
     [<ffffffff8222db03>] __ieee80211_rx_handle_packet+0x1f3/0x750
     [<ffffffff8222e4a7>] ieee80211_rx_napi+0x447/0x990
    
    While at it, convert to use sizeof(*tid_agg_rx) instead.
    
    Fixes: 788211d81bfdf ("mac80211: fix RX A-MPDU session reorder timer deletion")
    Signed-off-by: Chris Bainbridge <chris.bainbridge@gmail.com>
    [reword commit message, use sizeof(*tid_agg_rx)]
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 03b4072c939003be9a4ef44da01ce493b29b7def
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Jan 27 12:37:52 2016 +0100

    wext: fix message delay/ordering
    
    commit 8bf862739a7786ae72409220914df960a0aa80d8 upstream.
    
    Beniamino reported that he was getting an RTM_NEWLINK message for a
    given interface, after the RTM_DELLINK for it. It turns out that the
    message is a wireless extensions message, which was sent because the
    interface had been connected and disconnection while it was deleted
    caused a wext message.
    
    For its netlink messages, wext uses RTM_NEWLINK, but the message is
    without all the regular rtnetlink attributes, so "ip monitor link"
    prints just rudimentary information:
    
    5: wlan1: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN group default
        link/ether 02:00:00:00:01:00 brd ff:ff:ff:ff:ff:ff
    Deleted 5: wlan1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default
        link/ether 02:00:00:00:01:00 brd ff:ff:ff:ff:ff:ff
    5: wlan1: <BROADCAST,MULTICAST,UP>
        link/ether
    (from my hwsim reproduction)
    
    This can cause userspace to get confused since it doesn't expect an
    RTM_NEWLINK message after RTM_DELLINK.
    
    The reason for this is that wext schedules a worker to send out the
    messages, and the scheduling delay can cause the messages to get out
    to userspace in different order.
    
    To fix this, have wext register a netdevice notifier and flush out
    any pending messages when netdevice state changes. This fixes any
    ordering whenever the original message wasn't sent by a notifier
    itself.
    
    Reported-by: Beniamino Galvani <bgalvani@redhat.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d5abfabac4aff18bfbc335563272f836c8fb77d7
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Feb 29 18:01:12 2016 +0100

    ASoC: wm8958: Fix enum ctl accesses in a wrong type
    
    commit d0784829ae3b0beeb69b476f017d5c8a2eb95198 upstream.
    
    "MBC Mode", "VSS Mode", "VSS HPF Mode" and "Enhanced EQ Mode" ctls in
    wm8958 codec driver are enum, while the current driver accesses
    wrongly via value.integer.value[].  They have to be via
    value.enumerated.item[] instead.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d6d9f80e159be4ce0fd3bef8c586beb1a375387a
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Feb 29 18:01:15 2016 +0100

    ASoC: wm8994: Fix enum ctl accesses in a wrong type
    
    commit 8019c0b37cd5a87107808300a496388b777225bf upstream.
    
    The DRC Mode like "AIF1DRC1 Mode" and EQ Mode like "AIF1.1 EQ Mode" in
    wm8994 codec driver are enum ctls, while the current driver accesses
    wrongly via value.integer.value[].  They have to be via
    value.enumerated.item[] instead.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 22d5635260f642857727c625ec3fa21e1ebdd1c4
Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
Date:   Wed Mar 9 11:58:41 2016 -0500

    tracing: Fix check for cpu online when event is disabled
    
    commit dc17147de328a74bbdee67c1bf37d2f1992de756 upstream.
    
    Commit f37755490fe9b ("tracepoints: Do not trace when cpu is offline") added
    a check to make sure that tracepoints only get called when the cpu is
    online, as it uses rcu_read_lock_sched() for protection.
    
    Commit 3a630178fd5f3 ("tracing: generate RCU warnings even when tracepoints
    are disabled") added lockdep checks (including rcu checks) for events that
    are not enabled to catch possible RCU issues that would only be triggered if
    a trace event was enabled. Commit f37755490fe9b only stopped the warnings
    when the trace event was enabled but did not prevent warnings if the trace
    event was called when disabled.
    
    To fix this, the cpu online check is moved to where the condition is added
    to the trace event. This will place the cpu online check in all places that
    it may be used now and in the future.
    
    Fixes: f37755490fe9b ("tracepoints: Do not trace when cpu is offline")
    Fixes: 3a630178fd5f3 ("tracing: generate RCU warnings even when tracepoints are disabled")
    Reported-by: Sudeep Holla <sudeep.holla@arm.com>
    Tested-by: Sudeep Holla <sudeep.holla@arm.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ef9dd54d0208f2bfb904f80a04bd963d10377b4e
Author: Paul Mackerras <paulus@samba.org>
Date:   Sat Mar 5 19:34:39 2016 +1100

    KVM: PPC: Book3S HV: Sanitize special-purpose register values on guest exit
    
    commit ccec44563b18a0ce90e2d4f332784b3cb25c8e9c upstream.
    
    Thomas Huth discovered that a guest could cause a hard hang of a
    host CPU by setting the Instruction Authority Mask Register (IAMR)
    to a suitable value.  It turns out that this is because when the
    code was added to context-switch the new special-purpose registers
    (SPRs) that were added in POWER8, we forgot to add code to ensure
    that they were restored to a sane value on guest exit.
    
    This adds code to set those registers where a bad value could
    compromise the execution of the host kernel to a suitable neutral
    value on guest exit.
    
    Fixes: b005255e12a3
    Reported-by: Thomas Huth <thuth@redhat.com>
    Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
    Signed-off-by: Paul Mackerras <paulus@samba.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2b9f49f3253666a47a18ad92772750563972ef2f
Author: Radim Krčmář <rkrcmar@redhat.com>
Date:   Fri Mar 4 15:08:42 2016 +0100

    KVM: VMX: disable PEBS before a guest entry
    
    commit 7099e2e1f4d9051f31bbfa5803adf954bb5d76ef upstream.
    
    Linux guests on Haswell (and also SandyBridge and Broadwell, at least)
    would crash if you decided to run a host command that uses PEBS, like
      perf record -e 'cpu/mem-stores/pp' -a
    
    This happens because KVM is using VMX MSR switching to disable PEBS, but
    SDM [2015-12] 18.4.4.4 Re-configuring PEBS Facilities explains why it
    isn't safe:
      When software needs to reconfigure PEBS facilities, it should allow a
      quiescent period between stopping the prior event counting and setting
      up a new PEBS event. The quiescent period is to allow any latent
      residual PEBS records to complete its capture at their previously
      specified buffer address (provided by IA32_DS_AREA).
    
    There might not be a quiescent period after the MSR switch, so a CPU
    ends up using host's MSR_IA32_DS_AREA to access an area in guest's
    memory.  (Or MSR switching is just buggy on some models.)
    
    The guest can learn something about the host this way:
    If the guest doesn't map address pointed by MSR_IA32_DS_AREA, it results
    in #PF where we leak host's MSR_IA32_DS_AREA through CR2.
    
    After that, a malicious guest can map and configure memory where
    MSR_IA32_DS_AREA is pointing and can therefore get an output from
    host's tracing.
    
    This is not a critical leak as the host must initiate with PEBS tracing
    and I have not been able to get a record from more than one instruction
    before vmentry in vmx_vcpu_run() (that place has most registers already
    overwritten with guest's).
    
    We could disable PEBS just few instructions before vmentry, but
    disabling it earlier shouldn't affect host tracing too much.
    We also don't need to switch MSR_IA32_PEBS_ENABLE on VMENTRY, but that
    optimization isn't worth its code, IMO.
    
    (If you are implementing PEBS for guests, be sure to handle the case
     where both host and guest enable PEBS, because this patch doesn't.)
    
    Fixes: 26a4f3c08de4 ("perf/x86: disable PEBS on a guest entry.")
    Reported-by: Jiří Olša <jolsa@redhat.com>
    Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>