--- /dev/null
+From 71c6da846be478a61556717ef1ee1cea91f5d6a8 Mon Sep 17 00:00:00 2001
+From: Andrey Ryabinin <aryabinin@odin.com>
+Date: Thu, 3 Sep 2015 14:32:01 +0300
+Subject: crypto: ghash-clmulni: specify context size for ghash async algorithm
+
+From: Andrey Ryabinin <aryabinin@odin.com>
+
+commit 71c6da846be478a61556717ef1ee1cea91f5d6a8 upstream.
+
+Currently context size (cra_ctxsize) doesn't specified for
+ghash_async_alg. Which means it's zero. Thus crypto_create_tfm()
+doesn't allocate needed space for ghash_async_ctx, so any
+read/write to ctx (e.g. in ghash_async_init_tfm()) is not valid.
+
+Signed-off-by: Andrey Ryabinin <aryabinin@odin.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/crypto/ghash-clmulni-intel_glue.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/x86/crypto/ghash-clmulni-intel_glue.c
++++ b/arch/x86/crypto/ghash-clmulni-intel_glue.c
+@@ -294,6 +294,7 @@ static struct ahash_alg ghash_async_alg
+ .cra_name = "ghash",
+ .cra_driver_name = "ghash-clmulni",
+ .cra_priority = 400,
++ .cra_ctxsize = sizeof(struct ghash_async_ctx),
+ .cra_flags = CRYPTO_ALG_TYPE_AHASH | CRYPTO_ALG_ASYNC,
+ .cra_blocksize = GHASH_BLOCK_SIZE,
+ .cra_type = &crypto_ahash_type,
--- /dev/null
+From 1d4aa0b4c1816e8ca92a6aadb0d8f6b43c56c0d0 Mon Sep 17 00:00:00 2001
+From: Leonidas Da Silva Barbosa <leosilva@linux.vnet.ibm.com>
+Date: Fri, 14 Aug 2015 10:12:22 -0300
+Subject: crypto: vmx - Fixing AES-CTR counter bug
+
+From: Leonidas Da Silva Barbosa <leosilva@linux.vnet.ibm.com>
+
+commit 1d4aa0b4c1816e8ca92a6aadb0d8f6b43c56c0d0 upstream.
+
+AES-CTR is using a counter 8bytes-8bytes what miss match with
+kernel specs.
+
+In the previous code a vadduwm was done to increment counter.
+Replacing this for a vadduqm now considering both cases counter
+8-8 bytes and full 16bytes.
+
+Signed-off-by: Leonidas S Barbosa <leosilva@linux.vnet.ibm.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/crypto/vmx/aes_ctr.c | 8 +++++++-
+ drivers/crypto/vmx/aesp8-ppc.pl | 34 +++++++++++++++++-----------------
+ 2 files changed, 24 insertions(+), 18 deletions(-)
+
+--- a/drivers/crypto/vmx/aes_ctr.c
++++ b/drivers/crypto/vmx/aes_ctr.c
+@@ -113,6 +113,7 @@ static int p8_aes_ctr_crypt(struct blkci
+ struct scatterlist *src, unsigned int nbytes)
+ {
+ int ret;
++ u64 inc;
+ struct blkcipher_walk walk;
+ struct p8_aes_ctr_ctx *ctx =
+ crypto_tfm_ctx(crypto_blkcipher_tfm(desc->tfm));
+@@ -140,7 +141,12 @@ static int p8_aes_ctr_crypt(struct blkci
+ walk.iv);
+ pagefault_enable();
+
+- crypto_inc(walk.iv, AES_BLOCK_SIZE);
++ /* We need to update IV mostly for last bytes/round */
++ inc = (nbytes & AES_BLOCK_MASK) / AES_BLOCK_SIZE;
++ if (inc > 0)
++ while (inc--)
++ crypto_inc(walk.iv, AES_BLOCK_SIZE);
++
+ nbytes &= AES_BLOCK_SIZE - 1;
+ ret = blkcipher_walk_done(desc, &walk, nbytes);
+ }
+--- a/drivers/crypto/vmx/aesp8-ppc.pl
++++ b/drivers/crypto/vmx/aesp8-ppc.pl
+@@ -1437,28 +1437,28 @@ Load_ctr32_enc_key:
+ ?vperm v31,v31,$out0,$keyperm
+ lvx v25,$x10,$key_ # pre-load round[2]
+
+- vadduwm $two,$one,$one
++ vadduqm $two,$one,$one
+ subi $inp,$inp,15 # undo "caller"
+ $SHL $len,$len,4
+
+- vadduwm $out1,$ivec,$one # counter values ...
+- vadduwm $out2,$ivec,$two
++ vadduqm $out1,$ivec,$one # counter values ...
++ vadduqm $out2,$ivec,$two
+ vxor $out0,$ivec,$rndkey0 # ... xored with rndkey[0]
+ le?li $idx,8
+- vadduwm $out3,$out1,$two
++ vadduqm $out3,$out1,$two
+ vxor $out1,$out1,$rndkey0
+ le?lvsl $inpperm,0,$idx
+- vadduwm $out4,$out2,$two
++ vadduqm $out4,$out2,$two
+ vxor $out2,$out2,$rndkey0
+ le?vspltisb $tmp,0x0f
+- vadduwm $out5,$out3,$two
++ vadduqm $out5,$out3,$two
+ vxor $out3,$out3,$rndkey0
+ le?vxor $inpperm,$inpperm,$tmp # transform for lvx_u/stvx_u
+- vadduwm $out6,$out4,$two
++ vadduqm $out6,$out4,$two
+ vxor $out4,$out4,$rndkey0
+- vadduwm $out7,$out5,$two
++ vadduqm $out7,$out5,$two
+ vxor $out5,$out5,$rndkey0
+- vadduwm $ivec,$out6,$two # next counter value
++ vadduqm $ivec,$out6,$two # next counter value
+ vxor $out6,$out6,$rndkey0
+ vxor $out7,$out7,$rndkey0
+
+@@ -1594,27 +1594,27 @@ Loop_ctr32_enc8x_middle:
+
+ vcipherlast $in0,$out0,$in0
+ vcipherlast $in1,$out1,$in1
+- vadduwm $out1,$ivec,$one # counter values ...
++ vadduqm $out1,$ivec,$one # counter values ...
+ vcipherlast $in2,$out2,$in2
+- vadduwm $out2,$ivec,$two
++ vadduqm $out2,$ivec,$two
+ vxor $out0,$ivec,$rndkey0 # ... xored with rndkey[0]
+ vcipherlast $in3,$out3,$in3
+- vadduwm $out3,$out1,$two
++ vadduqm $out3,$out1,$two
+ vxor $out1,$out1,$rndkey0
+ vcipherlast $in4,$out4,$in4
+- vadduwm $out4,$out2,$two
++ vadduqm $out4,$out2,$two
+ vxor $out2,$out2,$rndkey0
+ vcipherlast $in5,$out5,$in5
+- vadduwm $out5,$out3,$two
++ vadduqm $out5,$out3,$two
+ vxor $out3,$out3,$rndkey0
+ vcipherlast $in6,$out6,$in6
+- vadduwm $out6,$out4,$two
++ vadduqm $out6,$out4,$two
+ vxor $out4,$out4,$rndkey0
+ vcipherlast $in7,$out7,$in7
+- vadduwm $out7,$out5,$two
++ vadduqm $out7,$out5,$two
+ vxor $out5,$out5,$rndkey0
+ le?vperm $in0,$in0,$in0,$inpperm
+- vadduwm $ivec,$out6,$two # next counter value
++ vadduqm $ivec,$out6,$two # next counter value
+ vxor $out6,$out6,$rndkey0
+ le?vperm $in1,$in1,$in1,$inpperm
+ vxor $out7,$out7,$rndkey0
--- /dev/null
+From 3c5f0ed78e976be705218cad62acf6a68e9d121e Mon Sep 17 00:00:00 2001
+From: Leonidas Da Silva Barbosa <leosilva@linux.vnet.ibm.com>
+Date: Fri, 14 Aug 2015 10:14:16 -0300
+Subject: crypto: vmx - Fixing GHASH Key issue on little endian
+
+From: Leonidas Da Silva Barbosa <leosilva@linux.vnet.ibm.com>
+
+commit 3c5f0ed78e976be705218cad62acf6a68e9d121e upstream.
+
+GHASH table algorithm is using a big endian key.
+In little endian machines key will be LE ordered.
+After a lxvd2x instruction key is loaded as it is,
+LE/BE order, in first case it'll generate a wrong
+table resulting in wrong hashes from the algorithm.
+
+Bug affects only LE machines.
+In order to fix it we do a swap for loaded key.
+
+Signed-off-by: Leonidas S Barbosa <leosilva@linux.vnet.ibm.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/crypto/vmx/ghashp8-ppc.pl | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/drivers/crypto/vmx/ghashp8-ppc.pl
++++ b/drivers/crypto/vmx/ghashp8-ppc.pl
+@@ -61,6 +61,12 @@ $code=<<___;
+ mtspr 256,r0
+ li r10,0x30
+ lvx_u $H,0,r4 # load H
++ le?xor r7,r7,r7
++ le?addi r7,r7,0x8 # need a vperm start with 08
++ le?lvsr 5,0,r7
++ le?vspltisb 6,0x0f
++ le?vxor 5,5,6 # set a b-endian mask
++ le?vperm $H,$H,$H,5
+
+ vspltisb $xC2,-16 # 0xf0
+ vspltisb $t0,1 # one
--- /dev/null
+From 29e2d6d1f6f61ba2b5cc9d9867e01d8c31a6c4f7 Mon Sep 17 00:00:00 2001
+From: Ellen Wang <ellen@cumulusnetworks.com>
+Date: Thu, 9 Jul 2015 22:04:31 -0700
+Subject: HID: cp2112: fix byte order in SMBUS operations
+
+From: Ellen Wang <ellen@cumulusnetworks.com>
+
+commit 29e2d6d1f6f61ba2b5cc9d9867e01d8c31a6c4f7 upstream.
+
+Change all occurrences of be16 to le16 in cp2112_xfer(),
+because SMBUS words are little endian, not big endian.
+
+Signed-off-by: Ellen Wang <ellen@cumulusnetworks.com>
+Signed-off-by: Jiri Kosina <jkosina@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hid/hid-cp2112.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/drivers/hid/hid-cp2112.c
++++ b/drivers/hid/hid-cp2112.c
+@@ -537,7 +537,7 @@ static int cp2112_xfer(struct i2c_adapte
+ struct cp2112_device *dev = (struct cp2112_device *)adap->algo_data;
+ struct hid_device *hdev = dev->hdev;
+ u8 buf[64];
+- __be16 word;
++ __le16 word;
+ ssize_t count;
+ size_t read_length = 0;
+ unsigned int retries;
+@@ -569,7 +569,7 @@ static int cp2112_xfer(struct i2c_adapte
+ break;
+ case I2C_SMBUS_WORD_DATA:
+ read_length = 2;
+- word = cpu_to_be16(data->word);
++ word = cpu_to_le16(data->word);
+
+ if (I2C_SMBUS_READ == read_write)
+ count = cp2112_write_read_req(buf, addr, read_length,
+@@ -582,7 +582,7 @@ static int cp2112_xfer(struct i2c_adapte
+ size = I2C_SMBUS_WORD_DATA;
+ read_write = I2C_SMBUS_READ;
+ read_length = 2;
+- word = cpu_to_be16(data->word);
++ word = cpu_to_le16(data->word);
+
+ count = cp2112_write_read_req(buf, addr, read_length, command,
+ (u8 *)&word, 2);
+@@ -675,7 +675,7 @@ static int cp2112_xfer(struct i2c_adapte
+ data->byte = buf[0];
+ break;
+ case I2C_SMBUS_WORD_DATA:
+- data->word = be16_to_cpup((__be16 *)buf);
++ data->word = le16_to_cpup((__le16 *)buf);
+ break;
+ case I2C_SMBUS_BLOCK_DATA:
+ if (read_length > I2C_SMBUS_BLOCK_MAX) {
--- /dev/null
+From 6d00d153f00097d259f86304e11858a50a1b8ad1 Mon Sep 17 00:00:00 2001
+From: Ellen Wang <ellen@cumulusnetworks.com>
+Date: Mon, 13 Jul 2015 15:23:54 -0700
+Subject: HID: cp2112: fix I2C_SMBUS_BYTE write
+
+From: Ellen Wang <ellen@cumulusnetworks.com>
+
+commit 6d00d153f00097d259f86304e11858a50a1b8ad1 upstream.
+
+When doing an I2C_SMBUS_BYTE write (one byte write, no address),
+the data to be written is in "command" not "data->byte".
+
+Signed-off-by: Ellen Wang <ellen@cumulusnetworks.com>
+Acked-by: Wolfram Sang <wsa@the-dreams.de>
+Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
+Signed-off-by: Jiri Kosina <jkosina@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hid/hid-cp2112.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/hid/hid-cp2112.c
++++ b/drivers/hid/hid-cp2112.c
+@@ -554,7 +554,7 @@ static int cp2112_xfer(struct i2c_adapte
+ if (I2C_SMBUS_READ == read_write)
+ count = cp2112_read_req(buf, addr, read_length);
+ else
+- count = cp2112_write_req(buf, addr, data->byte, NULL,
++ count = cp2112_write_req(buf, addr, command, NULL,
+ 0);
+ break;
+ case I2C_SMBUS_BYTE_DATA:
--- /dev/null
+From 3af4e5a95184d6d3c1c6a065f163faa174a96a1d Mon Sep 17 00:00:00 2001
+From: Don Zickus <dzickus@redhat.com>
+Date: Mon, 10 Aug 2015 12:06:53 -0400
+Subject: HID: usbhid: Fix the check for HID_RESET_PENDING in hid_io_error
+
+From: Don Zickus <dzickus@redhat.com>
+
+commit 3af4e5a95184d6d3c1c6a065f163faa174a96a1d upstream.
+
+It was reported that after 10-20 reboots, a usb keyboard plugged
+into a docking station would not work unless it was replugged in.
+
+Using usbmon, it turns out the interrupt URBs were streaming with
+callback errors of -71 for some reason. The hid-core.c::hid_io_error was
+supposed to retry and then reset, but the reset wasn't really happening.
+
+The check for HID_NO_BANDWIDTH was inverted. Fix was simple.
+
+Tested by reporter and locally by me by unplugging a keyboard halfway until I
+could recreate a stream of errors but no disconnect.
+
+Signed-off-by: Don Zickus <dzickus@redhat.com>
+Signed-off-by: Jiri Kosina <jkosina@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hid/usbhid/hid-core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/hid/usbhid/hid-core.c
++++ b/drivers/hid/usbhid/hid-core.c
+@@ -164,7 +164,7 @@ static void hid_io_error(struct hid_devi
+ if (time_after(jiffies, usbhid->stop_retry)) {
+
+ /* Retries failed, so do a port reset unless we lack bandwidth*/
+- if (test_bit(HID_NO_BANDWIDTH, &usbhid->iofl)
++ if (!test_bit(HID_NO_BANDWIDTH, &usbhid->iofl)
+ && !test_and_set_bit(HID_RESET_PENDING, &usbhid->iofl)) {
+
+ schedule_work(&usbhid->reset_work);
--- /dev/null
+From 6f691251c0350ac52a007c54bf3ef62e9d8cdc5e Mon Sep 17 00:00:00 2001
+From: Xiao Guangrong <guangrong.xiao@linux.intel.com>
+Date: Wed, 5 Aug 2015 12:04:19 +0800
+Subject: KVM: MMU: fix validation of mmio page fault
+
+From: Xiao Guangrong <guangrong.xiao@linux.intel.com>
+
+commit 6f691251c0350ac52a007c54bf3ef62e9d8cdc5e upstream.
+
+We got the bug that qemu complained with "KVM: unknown exit, hardware
+reason 31" and KVM shown these info:
+[84245.284948] EPT: Misconfiguration.
+[84245.285056] EPT: GPA: 0xfeda848
+[84245.285154] ept_misconfig_inspect_spte: spte 0x5eaef50107 level 4
+[84245.285344] ept_misconfig_inspect_spte: spte 0x5f5fadc107 level 3
+[84245.285532] ept_misconfig_inspect_spte: spte 0x5141d18107 level 2
+[84245.285723] ept_misconfig_inspect_spte: spte 0x52e40dad77 level 1
+
+This is because we got a mmio #PF and the handler see the mmio spte becomes
+normal (points to the ram page)
+
+However, this is valid after introducing fast mmio spte invalidation which
+increases the generation-number instead of zapping mmio sptes, a example
+is as follows:
+1. QEMU drops mmio region by adding a new memslot
+2. invalidate all mmio sptes
+3.
+
+ VCPU 0 VCPU 1
+ access the invalid mmio spte
+ access the region originally was MMIO before
+ set the spte to the normal ram map
+
+ mmio #PF
+ check the spte and see it becomes normal ram mapping !!!
+
+This patch fixes the bug just by dropping the check in mmio handler, it's
+good for backport. Full check will be introduced in later patches
+
+Reported-by: Pavel Shirshov <ru.pchel@gmail.com>
+Tested-by: Pavel Shirshov <ru.pchel@gmail.com>
+Signed-off-by: Xiao Guangrong <guangrong.xiao@linux.intel.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kvm/mmu.c | 45 ---------------------------------------------
+ 1 file changed, 45 deletions(-)
+
+--- a/arch/x86/kvm/mmu.c
++++ b/arch/x86/kvm/mmu.c
+@@ -357,12 +357,6 @@ static u64 __get_spte_lockless(u64 *spte
+ {
+ return ACCESS_ONCE(*sptep);
+ }
+-
+-static bool __check_direct_spte_mmio_pf(u64 spte)
+-{
+- /* It is valid if the spte is zapped. */
+- return spte == 0ull;
+-}
+ #else
+ union split_spte {
+ struct {
+@@ -478,23 +472,6 @@ retry:
+
+ return spte.spte;
+ }
+-
+-static bool __check_direct_spte_mmio_pf(u64 spte)
+-{
+- union split_spte sspte = (union split_spte)spte;
+- u32 high_mmio_mask = shadow_mmio_mask >> 32;
+-
+- /* It is valid if the spte is zapped. */
+- if (spte == 0ull)
+- return true;
+-
+- /* It is valid if the spte is being zapped. */
+- if (sspte.spte_low == 0ull &&
+- (sspte.spte_high & high_mmio_mask) == high_mmio_mask)
+- return true;
+-
+- return false;
+-}
+ #endif
+
+ static bool spte_is_locklessly_modifiable(u64 spte)
+@@ -3299,21 +3276,6 @@ static bool quickly_check_mmio_pf(struct
+ return vcpu_match_mmio_gva(vcpu, addr);
+ }
+
+-
+-/*
+- * On direct hosts, the last spte is only allows two states
+- * for mmio page fault:
+- * - It is the mmio spte
+- * - It is zapped or it is being zapped.
+- *
+- * This function completely checks the spte when the last spte
+- * is not the mmio spte.
+- */
+-static bool check_direct_spte_mmio_pf(u64 spte)
+-{
+- return __check_direct_spte_mmio_pf(spte);
+-}
+-
+ static u64 walk_shadow_page_get_mmio_spte(struct kvm_vcpu *vcpu, u64 addr)
+ {
+ struct kvm_shadow_walk_iterator iterator;
+@@ -3356,13 +3318,6 @@ int handle_mmio_page_fault_common(struct
+ }
+
+ /*
+- * It's ok if the gva is remapped by other cpus on shadow guest,
+- * it's a BUG if the gfn is not a mmio page.
+- */
+- if (direct && !check_direct_spte_mmio_pf(spte))
+- return RET_MMIO_PF_BUG;
+-
+- /*
+ * If the page table is zapped by other cpus, let CPU fault again on
+ * the address.
+ */
--- /dev/null
+From 06554d9f6cc8f0b5ec903db19726a15dfc7b09d6 Mon Sep 17 00:00:00 2001
+From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
+Date: Fri, 7 Aug 2015 17:41:20 +0530
+Subject: KVM: PPC: Book3S HV: Exit on H_DOORBELL if HOST_IPI is set
+
+From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
+
+commit 06554d9f6cc8f0b5ec903db19726a15dfc7b09d6 upstream.
+
+The code that handles the case when we receive a H_DOORBELL interrupt
+has a comment which says "Hypervisor doorbell - exit only if host IPI
+flag set". However, the current code does not actually check if the
+host IPI flag is set. This is due to a comparison instruction that
+got missed.
+
+As a result, the current code performs the exit to host only
+if some sibling thread or a sibling sub-core is exiting to the
+host. This implies that, an IPI sent to a sibling core in
+(subcores-per-core != 1) mode will be missed by the host unless the
+sibling core is on the exit path to the host.
+
+This patch adds the missing comparison operation which will ensure
+that when HOST_IPI flag is set, we unconditionally exit to the host.
+
+Fixes: 66feed61cdf6
+Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.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>
+
+---
+ arch/powerpc/kvm/book3s_hv_rmhandlers.S | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
++++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+@@ -1127,6 +1127,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
+ cmpwi r12, BOOK3S_INTERRUPT_H_DOORBELL
+ bne 3f
+ lbz r0, HSTATE_HOST_IPI(r13)
++ cmpwi r0, 0
+ beq 4f
+ b guest_exit_cont
+ 3:
--- /dev/null
+From 1e5bf454f58731e360e504253e85bae7aaa2d298 Mon Sep 17 00:00:00 2001
+From: Paul Mackerras <paulus@samba.org>
+Date: Wed, 24 Jun 2015 21:18:05 +1000
+Subject: KVM: PPC: Book3S HV: Fix race in reading change bit when removing HPTE
+
+From: Paul Mackerras <paulus@samba.org>
+
+commit 1e5bf454f58731e360e504253e85bae7aaa2d298 upstream.
+
+The reference (R) and change (C) bits in a HPT entry can be set by
+hardware at any time up until the HPTE is invalidated and the TLB
+invalidation sequence has completed. This means that when removing
+a HPTE, we need to read the HPTE after the invalidation sequence has
+completed in order to obtain reliable values of R and C. The code
+in kvmppc_do_h_remove() used to do this. However, commit 6f22bd3265fb
+("KVM: PPC: Book3S HV: Make HTAB code LE host aware") removed the
+read after invalidation as a side effect of other changes. This
+restores the read of the HPTE after invalidation.
+
+The user-visible effect of this bug would be that when migrating a
+guest, there is a small probability that a page modified by the guest
+and then unmapped by the guest might not get re-transmitted and thus
+the destination might end up with a stale copy of the page.
+
+Fixes: 6f22bd3265fb
+Signed-off-by: Paul Mackerras <paulus@samba.org>
+Signed-off-by: Alexander Graf <agraf@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/kvm/book3s_hv_rm_mmu.c | 18 ++++++++++++------
+ 1 file changed, 12 insertions(+), 6 deletions(-)
+
+--- a/arch/powerpc/kvm/book3s_hv_rm_mmu.c
++++ b/arch/powerpc/kvm/book3s_hv_rm_mmu.c
+@@ -421,14 +421,20 @@ long kvmppc_do_h_remove(struct kvm *kvm,
+ rev = real_vmalloc_addr(&kvm->arch.revmap[pte_index]);
+ v = pte & ~HPTE_V_HVLOCK;
+ if (v & HPTE_V_VALID) {
+- u64 pte1;
+-
+- pte1 = be64_to_cpu(hpte[1]);
+ hpte[0] &= ~cpu_to_be64(HPTE_V_VALID);
+- rb = compute_tlbie_rb(v, pte1, pte_index);
++ rb = compute_tlbie_rb(v, be64_to_cpu(hpte[1]), pte_index);
+ do_tlbies(kvm, &rb, 1, global_invalidates(kvm, flags), true);
+- /* Read PTE low word after tlbie to get final R/C values */
+- remove_revmap_chain(kvm, pte_index, rev, v, pte1);
++ /*
++ * The reference (R) and change (C) bits in a HPT
++ * entry can be set by hardware at any time up until
++ * the HPTE is invalidated and the TLB invalidation
++ * sequence has completed. This means that when
++ * removing a HPTE, we need to re-read the HPTE after
++ * the invalidation sequence has completed in order to
++ * obtain reliable values of R and C.
++ */
++ remove_revmap_chain(kvm, pte_index, rev, v,
++ be64_to_cpu(hpte[1]));
+ }
+ r = rev->guest_rpte & ~HPTE_GR_RESERVED;
+ note_hpte_modification(kvm, rev);
--- /dev/null
+From 1d7002777a8fe8188caaa98d4a8eb4ed298fcdae Mon Sep 17 00:00:00 2001
+From: "Maciej S. Szmigiero" <mail@maciej.szmigiero.name>
+Date: Sun, 2 Aug 2015 23:15:05 +0200
+Subject: serial: 8250: bind to ALi Fast Infrared Controller (ALI5123)
+
+From: "Maciej S. Szmigiero" <mail@maciej.szmigiero.name>
+
+commit 1d7002777a8fe8188caaa98d4a8eb4ed298fcdae upstream.
+
+This way this device can be used with irtty-sir -
+at least on Toshiba Satellite A20-S103 it is not configured by default
+and needs PNP activation before it starts to respond on I/O ports.
+
+This device has actually its own driver (ali-ircc),
+but this driver seems to be non-functional for a very long time
+(see http://permalink.gmane.org/gmane.linux.irda.general/484
+http://permalink.gmane.org/gmane.network.protocols.obex.openobex.user/943
+https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535070 ).
+
+Signed-off-by: Maciej Szmigiero <mail@maciej.szmigiero.name>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/acpi/acpi_pnp.c | 1 +
+ drivers/tty/serial/8250/8250_pnp.c | 6 ++++++
+ 2 files changed, 7 insertions(+)
+
+--- a/drivers/acpi/acpi_pnp.c
++++ b/drivers/acpi/acpi_pnp.c
+@@ -153,6 +153,7 @@ static const struct acpi_device_id acpi_
+ {"AEI0250"}, /* PROLiNK 1456VH ISA PnP K56flex Fax Modem */
+ {"AEI1240"}, /* Actiontec ISA PNP 56K X2 Fax Modem */
+ {"AKY1021"}, /* Rockwell 56K ACF II Fax+Data+Voice Modem */
++ {"ALI5123"}, /* ALi Fast Infrared Controller */
+ {"AZT4001"}, /* AZT3005 PnP SOUND DEVICE */
+ {"BDP3336"}, /* Best Data Products Inc. Smart One 336F PnP Modem */
+ {"BRI0A49"}, /* Boca Complete Ofc Communicator 14.4 Data-FAX */
+--- a/drivers/tty/serial/8250/8250_pnp.c
++++ b/drivers/tty/serial/8250/8250_pnp.c
+@@ -41,6 +41,12 @@ static const struct pnp_device_id pnp_de
+ { "AEI1240", 0 },
+ /* Rockwell 56K ACF II Fax+Data+Voice Modem */
+ { "AKY1021", 0 /*SPCI_FL_NO_SHIRQ*/ },
++ /*
++ * ALi Fast Infrared Controller
++ * Native driver (ali-ircc) is broken so at least
++ * it can be used with irtty-sir.
++ */
++ { "ALI5123", 0 },
+ /* AZT3005 PnP SOUND DEVICE */
+ { "AZT4001", 0 },
+ /* Best Data Products Inc. Smart One 336F PnP Modem */
--- /dev/null
+From ffa34de03bcfbfa88d8352942bc238bb48e94e2d Mon Sep 17 00:00:00 2001
+From: "Maciej S. Szmigiero" <mail@maciej.szmigiero.name>
+Date: Sun, 2 Aug 2015 23:11:52 +0200
+Subject: serial: 8250: don't bind to SMSC IrCC IR port
+
+From: "Maciej S. Szmigiero" <mail@maciej.szmigiero.name>
+
+commit ffa34de03bcfbfa88d8352942bc238bb48e94e2d upstream.
+
+SMSC IrCC SIR/FIR port should not be bound to by
+(legacy) serial driver so its own driver (smsc-ircc2)
+can bind to it.
+
+Signed-off-by: Maciej Szmigiero <mail@maciej.szmigiero.name>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/serial/8250/8250_pnp.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/tty/serial/8250/8250_pnp.c
++++ b/drivers/tty/serial/8250/8250_pnp.c
+@@ -364,6 +364,11 @@ static const struct pnp_device_id pnp_de
+ /* Winbond CIR port, should not be probed. We should keep track
+ of it to prevent the legacy serial driver from probing it */
+ { "WEC1022", CIR_PORT },
++ /*
++ * SMSC IrCC SIR/FIR port, should not be probed by serial driver
++ * as well so its own driver can bind to it.
++ */
++ { "SMCF010", CIR_PORT },
+ { "", 0 }
+ };
+
--- /dev/null
+From 89c043a6cb2d4525d48a38ed78d5f0f5672338b3 Mon Sep 17 00:00:00 2001
+From: Adam Lee <adam.lee@canonical.com>
+Date: Mon, 3 Aug 2015 13:28:13 +0800
+Subject: serial: 8250_pci: Add support for Pericom PI7C9X795[1248]
+
+From: Adam Lee <adam.lee@canonical.com>
+
+commit 89c043a6cb2d4525d48a38ed78d5f0f5672338b3 upstream.
+
+Pericom PI7C9X795[1248] are Uno/Dual/Quad/Octal UART devices, this
+patch enables them, also defines PCI_VENDOR_ID_PERICOM here.
+
+Signed-off-by: Adam Lee <adam.lee@canonical.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/serial/8250/8250_pci.c | 82 +++++++++++++++++++++++++++----------
+ 1 file changed, 61 insertions(+), 21 deletions(-)
+
+--- a/drivers/tty/serial/8250/8250_pci.c
++++ b/drivers/tty/serial/8250/8250_pci.c
+@@ -2017,6 +2017,12 @@ pci_wch_ch38x_setup(struct serial_privat
+ #define PCIE_DEVICE_ID_WCH_CH382_2S1P 0x3250
+ #define PCIE_DEVICE_ID_WCH_CH384_4S 0x3470
+
++#define PCI_VENDOR_ID_PERICOM 0x12D8
++#define PCI_DEVICE_ID_PERICOM_PI7C9X7951 0x7951
++#define PCI_DEVICE_ID_PERICOM_PI7C9X7952 0x7952
++#define PCI_DEVICE_ID_PERICOM_PI7C9X7954 0x7954
++#define PCI_DEVICE_ID_PERICOM_PI7C9X7958 0x7958
++
+ /* Unknown vendors/cards - this should not be in linux/pci_ids.h */
+ #define PCI_SUBDEVICE_ID_UNKNOWN_0x1584 0x1584
+ #define PCI_SUBDEVICE_ID_UNKNOWN_0x1588 0x1588
+@@ -2331,27 +2337,12 @@ static struct pci_serial_quirk pci_seria
+ * Pericom
+ */
+ {
+- .vendor = 0x12d8,
+- .device = 0x7952,
+- .subvendor = PCI_ANY_ID,
+- .subdevice = PCI_ANY_ID,
+- .setup = pci_pericom_setup,
+- },
+- {
+- .vendor = 0x12d8,
+- .device = 0x7954,
+- .subvendor = PCI_ANY_ID,
+- .subdevice = PCI_ANY_ID,
+- .setup = pci_pericom_setup,
+- },
+- {
+- .vendor = 0x12d8,
+- .device = 0x7958,
+- .subvendor = PCI_ANY_ID,
+- .subdevice = PCI_ANY_ID,
+- .setup = pci_pericom_setup,
++ .vendor = PCI_VENDOR_ID_PERICOM,
++ .device = PCI_ANY_ID,
++ .subvendor = PCI_ANY_ID,
++ .subdevice = PCI_ANY_ID,
++ .setup = pci_pericom_setup,
+ },
+-
+ /*
+ * PLX
+ */
+@@ -3056,6 +3047,10 @@ enum pci_board_num_t {
+ pbn_fintek_8,
+ pbn_fintek_12,
+ pbn_wch384_4,
++ pbn_pericom_PI7C9X7951,
++ pbn_pericom_PI7C9X7952,
++ pbn_pericom_PI7C9X7954,
++ pbn_pericom_PI7C9X7958,
+ };
+
+ /*
+@@ -3881,7 +3876,6 @@ static struct pciserial_board pci_boards
+ .base_baud = 115200,
+ .first_offset = 0x40,
+ },
+-
+ [pbn_wch384_4] = {
+ .flags = FL_BASE0,
+ .num_ports = 4,
+@@ -3889,6 +3883,33 @@ static struct pciserial_board pci_boards
+ .uart_offset = 8,
+ .first_offset = 0xC0,
+ },
++ /*
++ * Pericom PI7C9X795[1248] Uno/Dual/Quad/Octal UART
++ */
++ [pbn_pericom_PI7C9X7951] = {
++ .flags = FL_BASE0,
++ .num_ports = 1,
++ .base_baud = 921600,
++ .uart_offset = 0x8,
++ },
++ [pbn_pericom_PI7C9X7952] = {
++ .flags = FL_BASE0,
++ .num_ports = 2,
++ .base_baud = 921600,
++ .uart_offset = 0x8,
++ },
++ [pbn_pericom_PI7C9X7954] = {
++ .flags = FL_BASE0,
++ .num_ports = 4,
++ .base_baud = 921600,
++ .uart_offset = 0x8,
++ },
++ [pbn_pericom_PI7C9X7958] = {
++ .flags = FL_BASE0,
++ .num_ports = 8,
++ .base_baud = 921600,
++ .uart_offset = 0x8,
++ },
+ };
+
+ static const struct pci_device_id blacklist[] = {
+@@ -5154,6 +5175,25 @@ static struct pci_device_id serial_pci_t
+ 0,
+ 0, pbn_exar_XR17V8358 },
+ /*
++ * Pericom PI7C9X795[1248] Uno/Dual/Quad/Octal UART
++ */
++ { PCI_VENDOR_ID_PERICOM, PCI_DEVICE_ID_PERICOM_PI7C9X7951,
++ PCI_ANY_ID, PCI_ANY_ID,
++ 0,
++ 0, pbn_pericom_PI7C9X7951 },
++ { PCI_VENDOR_ID_PERICOM, PCI_DEVICE_ID_PERICOM_PI7C9X7952,
++ PCI_ANY_ID, PCI_ANY_ID,
++ 0,
++ 0, pbn_pericom_PI7C9X7952 },
++ { PCI_VENDOR_ID_PERICOM, PCI_DEVICE_ID_PERICOM_PI7C9X7954,
++ PCI_ANY_ID, PCI_ANY_ID,
++ 0,
++ 0, pbn_pericom_PI7C9X7954 },
++ { PCI_VENDOR_ID_PERICOM, PCI_DEVICE_ID_PERICOM_PI7C9X7958,
++ PCI_ANY_ID, PCI_ANY_ID,
++ 0,
++ 0, pbn_pericom_PI7C9X7958 },
++ /*
+ * Topic TP560 Data/Fax/Voice 56k modem (reported by Evan Clarke)
+ */
+ { PCI_VENDOR_ID_TOPIC, PCI_DEVICE_ID_TOPIC_TP560,
--- /dev/null
+From 736cd79f483fd7a1e0b71e6eaddf01d8d87fbbbb Mon Sep 17 00:00:00 2001
+From: Robert Baldyga <r.baldyga@samsung.com>
+Date: Fri, 31 Jul 2015 10:58:28 +0200
+Subject: serial: samsung: fix DMA for FIFO smaller than cache line size
+
+From: Robert Baldyga <r.baldyga@samsung.com>
+
+commit 736cd79f483fd7a1e0b71e6eaddf01d8d87fbbbb upstream.
+
+So far DMA mode were activated when only number of bytes to send was
+equal or greater than min_dma_size. Due to requirement that DMA transaction
+buffer should be aligned to cache line size, the excessive bytes were
+written to FIFO before starting DMA transaction. The problem occurred
+when FIFO size were smaller than cache alignment, because writing all
+excessive bytes to FIFO would fail. It happened in DMA mode when PIO
+interrupts disabled, which caused driver hung.
+
+The solution is to test if buffer is alligned to cache line size before
+activating DMA mode, and if it's not, running PIO mode to align buffer
+and then starting DMA transaction. In PIO mode, when interrupts are
+enabled, lack of space in FIFO isn't the problem, so buffer aligning
+will always finish with success.
+
+Reported-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
+Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/serial/samsung.c | 36 +++++++++++++++++++++---------------
+ 1 file changed, 21 insertions(+), 15 deletions(-)
+
+--- a/drivers/tty/serial/samsung.c
++++ b/drivers/tty/serial/samsung.c
+@@ -295,15 +295,6 @@ static int s3c24xx_serial_start_tx_dma(s
+ if (ourport->tx_mode != S3C24XX_TX_DMA)
+ enable_tx_dma(ourport);
+
+- while (xmit->tail & (dma_get_cache_alignment() - 1)) {
+- if (rd_regl(port, S3C2410_UFSTAT) & ourport->info->tx_fifofull)
+- return 0;
+- wr_regb(port, S3C2410_UTXH, xmit->buf[xmit->tail]);
+- xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
+- port->icount.tx++;
+- count--;
+- }
+-
+ dma->tx_size = count & ~(dma_get_cache_alignment() - 1);
+ dma->tx_transfer_addr = dma->tx_addr + xmit->tail;
+
+@@ -343,7 +334,8 @@ static void s3c24xx_serial_start_next_tx
+ }
+
+ if (!ourport->dma || !ourport->dma->tx_chan ||
+- count < ourport->min_dma_size)
++ count < ourport->min_dma_size ||
++ xmit->tail & (dma_get_cache_alignment() - 1))
+ s3c24xx_serial_start_tx_pio(ourport);
+ else
+ s3c24xx_serial_start_tx_dma(ourport, count);
+@@ -737,7 +729,7 @@ static irqreturn_t s3c24xx_serial_tx_cha
+ struct uart_port *port = &ourport->port;
+ struct circ_buf *xmit = &port->state->xmit;
+ unsigned long flags;
+- int count;
++ int count, dma_count = 0;
+
+ spin_lock_irqsave(&port->lock, flags);
+
+@@ -745,8 +737,12 @@ static irqreturn_t s3c24xx_serial_tx_cha
+
+ if (ourport->dma && ourport->dma->tx_chan &&
+ count >= ourport->min_dma_size) {
+- s3c24xx_serial_start_tx_dma(ourport, count);
+- goto out;
++ int align = dma_get_cache_alignment() -
++ (xmit->tail & (dma_get_cache_alignment() - 1));
++ if (count-align >= ourport->min_dma_size) {
++ dma_count = count-align;
++ count = align;
++ }
+ }
+
+ if (port->x_char) {
+@@ -767,14 +763,24 @@ static irqreturn_t s3c24xx_serial_tx_cha
+
+ /* try and drain the buffer... */
+
+- count = port->fifosize;
+- while (!uart_circ_empty(xmit) && count-- > 0) {
++ if (count > port->fifosize) {
++ count = port->fifosize;
++ dma_count = 0;
++ }
++
++ while (!uart_circ_empty(xmit) && count > 0) {
+ if (rd_regl(port, S3C2410_UFSTAT) & ourport->info->tx_fifofull)
+ break;
+
+ wr_regb(port, S3C2410_UTXH, xmit->buf[xmit->tail]);
+ xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
+ port->icount.tx++;
++ count--;
++ }
++
++ if (!count && dma_count) {
++ s3c24xx_serial_start_tx_dma(ourport, dma_count);
++ goto out;
+ }
+
+ if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS) {
--- /dev/null
+From 81ccb2a69f76b88295a1da9fc9484df715fe3bfa Mon Sep 17 00:00:00 2001
+From: Marek Szyprowski <m.szyprowski@samsung.com>
+Date: Fri, 31 Jul 2015 10:58:27 +0200
+Subject: serial: samsung: fix DMA mode enter condition for small FIFO sizes
+
+From: Marek Szyprowski <m.szyprowski@samsung.com>
+
+commit 81ccb2a69f76b88295a1da9fc9484df715fe3bfa upstream.
+
+Due to some of serial ports can have FIFO size smaller than cache line
+size, and because of need to align DMA buffer address to cache line size,
+it's necessary to calculate minimum number of bytes for which we want
+to start DMA transaction to be at least cache line size. The simplest
+way to meet this requirement is to get maximum of cache line size and
+FIFO size.
+
+Reported-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
+Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
+Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/serial/samsung.c | 13 +++++++++++--
+ drivers/tty/serial/samsung.h | 1 +
+ 2 files changed, 12 insertions(+), 2 deletions(-)
+
+--- a/drivers/tty/serial/samsung.c
++++ b/drivers/tty/serial/samsung.c
+@@ -342,7 +342,8 @@ static void s3c24xx_serial_start_next_tx
+ return;
+ }
+
+- if (!ourport->dma || !ourport->dma->tx_chan || count < port->fifosize)
++ if (!ourport->dma || !ourport->dma->tx_chan ||
++ count < ourport->min_dma_size)
+ s3c24xx_serial_start_tx_pio(ourport);
+ else
+ s3c24xx_serial_start_tx_dma(ourport, count);
+@@ -742,7 +743,8 @@ static irqreturn_t s3c24xx_serial_tx_cha
+
+ count = CIRC_CNT_TO_END(xmit->head, xmit->tail, UART_XMIT_SIZE);
+
+- if (ourport->dma && ourport->dma->tx_chan && count >= port->fifosize) {
++ if (ourport->dma && ourport->dma->tx_chan &&
++ count >= ourport->min_dma_size) {
+ s3c24xx_serial_start_tx_dma(ourport, count);
+ goto out;
+ }
+@@ -1838,6 +1840,13 @@ static int s3c24xx_serial_probe(struct p
+ else if (ourport->info->fifosize)
+ ourport->port.fifosize = ourport->info->fifosize;
+
++ /*
++ * DMA transfers must be aligned at least to cache line size,
++ * so find minimal transfer size suitable for DMA mode
++ */
++ ourport->min_dma_size = max_t(int, ourport->port.fifosize,
++ dma_get_cache_alignment());
++
+ probe_index++;
+
+ dbg("%s: initialising port %p...\n", __func__, ourport);
+--- a/drivers/tty/serial/samsung.h
++++ b/drivers/tty/serial/samsung.h
+@@ -82,6 +82,7 @@ struct s3c24xx_uart_port {
+ unsigned char tx_claimed;
+ unsigned int pm_level;
+ unsigned long baudclk_rate;
++ unsigned int min_dma_size;
+
+ unsigned int rx_irq;
+ unsigned int tx_irq;
asoc-adav80x-remove-.read_flag_mask-setting-from-adav80x_regmap_config.patch
asoc-arizona-fix-gain-settings-of-fll-in-free-run-mode.patch
asoc-arizona-poll-for-fll-clock-ok-rather-than-use-interrupts.patch
+serial-8250-don-t-bind-to-smsc-ircc-ir-port.patch
+serial-8250-bind-to-ali-fast-infrared-controller-ali5123.patch
+serial-8250_pci-add-support-for-pericom-pi7c9x795.patch
+serial-samsung-fix-dma-mode-enter-condition-for-small-fifo-sizes.patch
+serial-samsung-fix-dma-for-fifo-smaller-than-cache-line-size.patch
+crypto-vmx-fixing-aes-ctr-counter-bug.patch
+crypto-vmx-fixing-ghash-key-issue-on-little-endian.patch
+crypto-ghash-clmulni-specify-context-size-for-ghash-async-algorithm.patch
+hid-usbhid-fix-the-check-for-hid_reset_pending-in-hid_io_error.patch
+hid-cp2112-fix-byte-order-in-smbus-operations.patch
+hid-cp2112-fix-i2c_smbus_byte-write.patch
+kvm-mmu-fix-validation-of-mmio-page-fault.patch
+kvm-ppc-book3s-hv-exit-on-h_doorbell-if-host_ipi-is-set.patch
+kvm-ppc-book3s-hv-fix-race-in-reading-change-bit-when-removing-hpte.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
