--- /dev/null
+From 590b0c0cfc6162aeebbf43eaafb9753b56df1532 Mon Sep 17 00:00:00 2001
+From: Pascal Roeleven <dev@pascalroeleven.nl>
+Date: Fri, 20 Apr 2018 12:21:12 +0200
+Subject: ARM: dts: sun4i: Fix incorrect clocks for displays
+
+From: Pascal Roeleven <dev@pascalroeleven.nl>
+
+commit 590b0c0cfc6162aeebbf43eaafb9753b56df1532 upstream.
+
+Some displays on sun4i devices wouldn't properly stay on unless
+'clk_ignore_unused' is used.
+
+Change the duplicate clocks to the probably intended ones.
+
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Pascal Roeleven <dev@pascalroeleven.nl>
+Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/boot/dts/sun4i-a10.dtsi | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/arch/arm/boot/dts/sun4i-a10.dtsi
++++ b/arch/arm/boot/dts/sun4i-a10.dtsi
+@@ -76,7 +76,7 @@
+ allwinner,pipeline = "de_fe0-de_be0-lcd0-hdmi";
+ clocks = <&ccu CLK_AHB_LCD0>, <&ccu CLK_AHB_HDMI0>,
+ <&ccu CLK_AHB_DE_BE0>, <&ccu CLK_AHB_DE_FE0>,
+- <&ccu CLK_DE_BE0>, <&ccu CLK_AHB_DE_FE0>,
++ <&ccu CLK_DE_BE0>, <&ccu CLK_DE_FE0>,
+ <&ccu CLK_TCON0_CH1>, <&ccu CLK_HDMI>,
+ <&ccu CLK_DRAM_DE_FE0>, <&ccu CLK_DRAM_DE_BE0>;
+ status = "disabled";
+@@ -88,7 +88,7 @@
+ allwinner,pipeline = "de_fe0-de_be0-lcd0";
+ clocks = <&ccu CLK_AHB_LCD0>, <&ccu CLK_AHB_DE_BE0>,
+ <&ccu CLK_AHB_DE_FE0>, <&ccu CLK_DE_BE0>,
+- <&ccu CLK_AHB_DE_FE0>, <&ccu CLK_TCON0_CH0>,
++ <&ccu CLK_DE_FE0>, <&ccu CLK_TCON0_CH0>,
+ <&ccu CLK_DRAM_DE_FE0>, <&ccu CLK_DRAM_DE_BE0>;
+ status = "disabled";
+ };
+@@ -99,7 +99,7 @@
+ allwinner,pipeline = "de_fe0-de_be0-lcd0-tve0";
+ clocks = <&ccu CLK_AHB_TVE0>, <&ccu CLK_AHB_LCD0>,
+ <&ccu CLK_AHB_DE_BE0>, <&ccu CLK_AHB_DE_FE0>,
+- <&ccu CLK_DE_BE0>, <&ccu CLK_AHB_DE_FE0>,
++ <&ccu CLK_DE_BE0>, <&ccu CLK_DE_FE0>,
+ <&ccu CLK_TCON0_CH1>, <&ccu CLK_DRAM_TVE0>,
+ <&ccu CLK_DRAM_DE_FE0>, <&ccu CLK_DRAM_DE_BE0>;
+ status = "disabled";
--- /dev/null
+From f4a551b72358facbbe5714248dff78404272feee Mon Sep 17 00:00:00 2001
+From: David Hildenbrand <david@redhat.com>
+Date: Wed, 9 May 2018 16:12:17 +0200
+Subject: KVM: s390: vsie: fix < 8k check for the itdba
+
+From: David Hildenbrand <david@redhat.com>
+
+commit f4a551b72358facbbe5714248dff78404272feee upstream.
+
+By missing an "L", we might detect some addresses to be <8k,
+although they are not.
+
+e.g. for itdba = 100001fff
+!(gpa & ~0x1fffU) -> 1
+!(gpa & ~0x1fffUL) -> 0
+
+So we would report a SIE validity intercept although everything is fine.
+
+Fixes: 166ecb3 ("KVM: s390: vsie: support transactional execution")
+Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
+Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
+Reviewed-by: Janosch Frank <frankja@linux.ibm.com>
+Reviewed-by: Cornelia Huck <cohuck@redhat.com>
+Signed-off-by: David Hildenbrand <david@redhat.com>
+Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
+Cc: stable@vger.kernel.org # v4.8+
+Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/s390/kvm/vsie.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/s390/kvm/vsie.c
++++ b/arch/s390/kvm/vsie.c
+@@ -578,7 +578,7 @@ static int pin_blocks(struct kvm_vcpu *v
+
+ gpa = READ_ONCE(scb_o->itdba) & ~0xffUL;
+ if (gpa && (scb_s->ecb & ECB_TE)) {
+- if (!(gpa & ~0x1fffU)) {
++ if (!(gpa & ~0x1fffUL)) {
+ rc = set_validity_icpt(scb_s, 0x0080U);
+ goto unpin;
+ }
--- /dev/null
+From 0aa48468d00959c8a37cd3ac727284f4f7359151 Mon Sep 17 00:00:00 2001
+From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+Date: Mon, 21 May 2018 17:54:49 -0400
+Subject: KVM/VMX: Expose SSBD properly to guests
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+
+commit 0aa48468d00959c8a37cd3ac727284f4f7359151 upstream.
+
+The X86_FEATURE_SSBD is an synthetic CPU feature - that is
+it bit location has no relevance to the real CPUID 0x7.EBX[31]
+bit position. For that we need the new CPU feature name.
+
+Fixes: 52817587e706 ("x86/cpufeatures: Disentangle SSBD enumeration")
+Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: kvm@vger.kernel.org
+Cc: "Radim Krčmář" <rkrcmar@redhat.com>
+Cc: stable@vger.kernel.org
+Cc: "H. Peter Anvin" <hpa@zytor.com>
+Cc: Paolo Bonzini <pbonzini@redhat.com>
+Link: https://lkml.kernel.org/r/20180521215449.26423-2-konrad.wilk@oracle.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kvm/cpuid.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/kvm/cpuid.c
++++ b/arch/x86/kvm/cpuid.c
+@@ -402,8 +402,8 @@ static inline int __do_cpuid_ent(struct
+
+ /* cpuid 7.0.edx*/
+ const u32 kvm_cpuid_7_0_edx_x86_features =
+- F(AVX512_4VNNIW) | F(AVX512_4FMAPS) | F(SPEC_CTRL) | F(SSBD) |
+- F(ARCH_CAPABILITIES);
++ F(AVX512_4VNNIW) | F(AVX512_4FMAPS) | F(SPEC_CTRL) |
++ F(SPEC_CTRL_SSBD) | F(ARCH_CAPABILITIES);
+
+ /* all calls to cpuid_count() should be made on the same cpu */
+ get_cpu();
--- /dev/null
+From 1eaafe91a0df4157521b6417b3dd8430bf5f52f0 Mon Sep 17 00:00:00 2001
+From: Jim Mattson <jmattson@google.com>
+Date: Wed, 9 May 2018 14:29:35 -0700
+Subject: kvm: x86: IA32_ARCH_CAPABILITIES is always supported
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Jim Mattson <jmattson@google.com>
+
+commit 1eaafe91a0df4157521b6417b3dd8430bf5f52f0 upstream.
+
+If there is a possibility that a VM may migrate to a Skylake host,
+then the hypervisor should report IA32_ARCH_CAPABILITIES.RSBA[bit 2]
+as being set (future work, of course). This implies that
+CPUID.(EAX=7,ECX=0):EDX.ARCH_CAPABILITIES[bit 29] should be
+set. Therefore, kvm should report this CPUID bit as being supported
+whether or not the host supports it. Userspace is still free to clear
+the bit if it chooses.
+
+For more information on RSBA, see Intel's white paper, "Retpoline: A
+Branch Target Injection Mitigation" (Document Number 337131-001),
+currently available at https://bugzilla.kernel.org/show_bug.cgi?id=199511.
+
+Since the IA32_ARCH_CAPABILITIES MSR is emulated in kvm, there is no
+dependency on hardware support for this feature.
+
+Signed-off-by: Jim Mattson <jmattson@google.com>
+Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+Fixes: 28c1c9fabf48 ("KVM/VMX: Emulate MSR_IA32_ARCH_CAPABILITIES")
+Cc: stable@vger.kernel.org
+Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kvm/cpuid.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/arch/x86/kvm/cpuid.c
++++ b/arch/x86/kvm/cpuid.c
+@@ -490,6 +490,11 @@ static inline int __do_cpuid_ent(struct
+ entry->ecx &= ~F(PKU);
+ entry->edx &= kvm_cpuid_7_0_edx_x86_features;
+ cpuid_mask(&entry->edx, CPUID_7_EDX);
++ /*
++ * We emulate ARCH_CAPABILITIES in software even
++ * if the host doesn't support it.
++ */
++ entry->edx |= F(ARCH_CAPABILITIES);
+ } else {
+ entry->ebx = 0;
+ entry->ecx = 0;
--- /dev/null
+From c4d2188206bafa177ea58e9a25b952baa0bf7712 Mon Sep 17 00:00:00 2001
+From: Wei Huang <wei@redhat.com>
+Date: Tue, 1 May 2018 09:49:54 -0500
+Subject: KVM: x86: Update cpuid properly when CR4.OSXAVE or CR4.PKE is changed
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Wei Huang <wei@redhat.com>
+
+commit c4d2188206bafa177ea58e9a25b952baa0bf7712 upstream.
+
+The CPUID bits of OSXSAVE (function=0x1) and OSPKE (func=0x7, leaf=0x0)
+allows user apps to detect if OS has set CR4.OSXSAVE or CR4.PKE. KVM is
+supposed to update these CPUID bits when CR4 is updated. Current KVM
+code doesn't handle some special cases when updates come from emulator.
+Here is one example:
+
+ Step 1: guest boots
+ Step 2: guest OS enables XSAVE ==> CR4.OSXSAVE=1 and CPUID.OSXSAVE=1
+ Step 3: guest hot reboot ==> QEMU reset CR4 to 0, but CPUID.OSXAVE==1
+ Step 4: guest os checks CPUID.OSXAVE, detects 1, then executes xgetbv
+
+Step 4 above will cause an #UD and guest crash because guest OS hasn't
+turned on OSXAVE yet. This patch solves the problem by comparing the the
+old_cr4 with cr4. If the related bits have been changed,
+kvm_update_cpuid() needs to be called.
+
+Signed-off-by: Wei Huang <wei@redhat.com>
+Reviewed-by: Bandan Das <bsd@redhat.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kvm/x86.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/arch/x86/kvm/x86.c
++++ b/arch/x86/kvm/x86.c
+@@ -7777,6 +7777,7 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct
+ {
+ struct msr_data apic_base_msr;
+ int mmu_reset_needed = 0;
++ int cpuid_update_needed = 0;
+ int pending_vec, max_bits, idx;
+ struct desc_ptr dt;
+ int ret = -EINVAL;
+@@ -7817,8 +7818,10 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct
+ vcpu->arch.cr0 = sregs->cr0;
+
+ mmu_reset_needed |= kvm_read_cr4(vcpu) != sregs->cr4;
++ cpuid_update_needed |= ((kvm_read_cr4(vcpu) ^ sregs->cr4) &
++ (X86_CR4_OSXSAVE | X86_CR4_PKE));
+ kvm_x86_ops->set_cr4(vcpu, sregs->cr4);
+- if (sregs->cr4 & (X86_CR4_OSXSAVE | X86_CR4_PKE))
++ if (cpuid_update_needed)
+ kvm_update_cpuid(vcpu);
+
+ idx = srcu_read_lock(&vcpu->kvm->srcu);
kasan-fix-memory-hotplug-during-boot.patch
kernel-sys.c-fix-potential-spectre-v1-issue.patch
pm-core-fix-direct_complete-handling-for-devices-with-no-callbacks.patch
+kvm-vmx-expose-ssbd-properly-to-guests.patch
+kvm-s390-vsie-fix-8k-check-for-the-itdba.patch
+kvm-x86-update-cpuid-properly-when-cr4.osxave-or-cr4.pke-is-changed.patch
+kvm-x86-ia32_arch_capabilities-is-always-supported.patch
+x86-kvm-fix-lapic-timer-drift-when-guest-uses-periodic-mode.patch
+arm-dts-sun4i-fix-incorrect-clocks-for-displays.patch
--- /dev/null
+From d8f2f498d9ed0c5010bc1bbc1146f94c8bf9f8cc Mon Sep 17 00:00:00 2001
+From: David Vrabel <david.vrabel@nutanix.com>
+Date: Fri, 18 May 2018 16:55:46 +0100
+Subject: x86/kvm: fix LAPIC timer drift when guest uses periodic mode
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: David Vrabel <david.vrabel@nutanix.com>
+
+commit d8f2f498d9ed0c5010bc1bbc1146f94c8bf9f8cc upstream.
+
+Since 4.10, commit 8003c9ae204e (KVM: LAPIC: add APIC Timer
+periodic/oneshot mode VMX preemption timer support), guests using
+periodic LAPIC timers (such as FreeBSD 8.4) would see their timers
+drift significantly over time.
+
+Differences in the underlying clocks and numerical errors means the
+periods of the two timers (hv and sw) are not the same. This
+difference will accumulate with every expiry resulting in a large
+error between the hv and sw timer.
+
+This means the sw timer may be running slow when compared to the hv
+timer. When the timer is switched from hv to sw, the now active sw
+timer will expire late. The guest VCPU is reentered and it switches to
+using the hv timer. This timer catches up, injecting multiple IRQs
+into the guest (of which the guest only sees one as it does not get to
+run until the hv timer has caught up) and thus the guest's timer rate
+is low (and becomes increasing slower over time as the sw timer lags
+further and further behind).
+
+I believe a similar problem would occur if the hv timer is the slower
+one, but I have not observed this.
+
+Fix this by synchronizing the deadlines for both timers to the same
+time source on every tick. This prevents the errors from accumulating.
+
+Fixes: 8003c9ae204e21204e49816c5ea629357e283b06
+Cc: Wanpeng Li <wanpeng.li@hotmail.com>
+Signed-off-by: David Vrabel <david.vrabel@nutanix.com>
+Cc: stable@vger.kernel.org
+Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
+Reviewed-by: Wanpeng Li <wanpengli@tencent.com>
+Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kvm/lapic.c | 16 ++++++++++++++--
+ 1 file changed, 14 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/kvm/lapic.c
++++ b/arch/x86/kvm/lapic.c
+@@ -1514,11 +1514,23 @@ static bool set_target_expiration(struct
+
+ static void advance_periodic_target_expiration(struct kvm_lapic *apic)
+ {
+- apic->lapic_timer.tscdeadline +=
+- nsec_to_cycles(apic->vcpu, apic->lapic_timer.period);
++ ktime_t now = ktime_get();
++ u64 tscl = rdtsc();
++ ktime_t delta;
++
++ /*
++ * Synchronize both deadlines to the same time source or
++ * differences in the periods (caused by differences in the
++ * underlying clocks or numerical approximation errors) will
++ * cause the two to drift apart over time as the errors
++ * accumulate.
++ */
+ apic->lapic_timer.target_expiration =
+ ktime_add_ns(apic->lapic_timer.target_expiration,
+ apic->lapic_timer.period);
++ delta = ktime_sub(apic->lapic_timer.target_expiration, now);
++ apic->lapic_timer.tscdeadline = kvm_read_l1_tsc(apic->vcpu, tscl) +
++ nsec_to_cycles(apic->vcpu, delta);
+ }
+
+ static void start_sw_period(struct kvm_lapic *apic)
projects / thirdparty / kernel / stable-queue.git / commitdiff
