Fixes for 5.4

Signed-off-by: Sasha Levin <sashal@kernel.org>

diff --git a/queue-5.4/kvm-x86-pmu-fix-reserved-bits-for-amd-perfevtseln-re.patch b/queue-5.4/kvm-x86-pmu-fix-reserved-bits-for-amd-perfevtseln-re.patch
new file mode 100644 (file)
index 0000000..56e4138
--- /dev/null
+++ b/queue-5.4/kvm-x86-pmu-fix-reserved-bits-for-amd-perfevtseln-re.patch
@@ -0,0 +1,55 @@
+From edc086d4aa044eb8f56051cecc3cb93a7ee0fb73 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Nov 2021 21:03:20 +0800
+Subject: KVM: x86/pmu: Fix reserved bits for AMD PerfEvtSeln register
+
+From: Like Xu <likexu@tencent.com>
+
+[ Upstream commit cb1d220da0faa5ca0deb93449aff953f0c2cce6d ]
+
+If we run the following perf command in an AMD Milan guest:
+
+  perf stat \
+  -e cpu/event=0x1d0/ \
+  -e cpu/event=0x1c7/ \
+  -e cpu/umask=0x1f,event=0x18e/ \
+  -e cpu/umask=0x7,event=0x18e/ \
+  -e cpu/umask=0x18,event=0x18e/ \
+  ./workload
+
+dmesg will report a #GP warning from an unchecked MSR access
+error on MSR_F15H_PERF_CTLx.
+
+This is because according to APM (Revision: 4.03) Figure 13-7,
+the bits [35:32] of AMD PerfEvtSeln register is a part of the
+event select encoding, which extends the EVENT_SELECT field
+from 8 bits to 12 bits.
+
+Opportunistically update pmu->reserved_bits for reserved bit 19.
+
+Reported-by: Jim Mattson <jmattson@google.com>
+Fixes: ca724305a2b0 ("KVM: x86/vPMU: Implement AMD vPMU code for KVM")
+Signed-off-by: Like Xu <likexu@tencent.com>
+Message-Id: <20211118130320.95997-1-likexu@tencent.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/x86/kvm/pmu_amd.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/x86/kvm/pmu_amd.c b/arch/x86/kvm/pmu_amd.c
+index c8388389a3b05..d9990951fd0ac 100644
+--- a/arch/x86/kvm/pmu_amd.c
++++ b/arch/x86/kvm/pmu_amd.c
+@@ -266,7 +266,7 @@ static void amd_pmu_refresh(struct kvm_vcpu *vcpu)
+               pmu->nr_arch_gp_counters = AMD64_NUM_COUNTERS;
+ 
+       pmu->counter_bitmask[KVM_PMC_GP] = ((u64)1 << 48) - 1;
+-      pmu->reserved_bits = 0xffffffff00200000ull;
++      pmu->reserved_bits = 0xfffffff000280000ull;
+       pmu->version = 1;
+       /* not applicable to AMD; but clean them to prevent any fall out */
+       pmu->counter_bitmask[KVM_PMC_FIXED] = 0;
+-- 
+2.33.0
+

diff --git a/queue-5.4/sched-uclamp-fix-rq-uclamp_max-not-set-on-first-enqu.patch b/queue-5.4/sched-uclamp-fix-rq-uclamp_max-not-set-on-first-enqu.patch
new file mode 100644 (file)
index 0000000..8c3d8dd
--- /dev/null
+++ b/queue-5.4/sched-uclamp-fix-rq-uclamp_max-not-set-on-first-enqu.patch
@@ -0,0 +1,66 @@
+From ceb52bd02f6592c3e9eb06779de34fff5d08e5bc Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 2 Dec 2021 11:20:33 +0000
+Subject: sched/uclamp: Fix rq->uclamp_max not set on first enqueue
+
+From: Qais Yousef <qais.yousef@arm.com>
+
+[ Upstream commit 315c4f884800c45cb6bd8c90422fad554a8b9588 ]
+
+Commit d81ae8aac85c ("sched/uclamp: Fix initialization of struct
+uclamp_rq") introduced a bug where uclamp_max of the rq is not reset to
+match the woken up task's uclamp_max when the rq is idle.
+
+The code was relying on rq->uclamp_max initialized to zero, so on first
+enqueue
+
+       static inline void uclamp_rq_inc_id(struct rq *rq, struct task_struct *p,
+                                           enum uclamp_id clamp_id)
+       {
+               ...
+
+               if (uc_se->value > READ_ONCE(uc_rq->value))
+                       WRITE_ONCE(uc_rq->value, uc_se->value);
+       }
+
+was actually resetting it. But since commit d81ae8aac85c changed the
+default to 1024, this no longer works. And since rq->uclamp_flags is
+also initialized to 0, neither above code path nor uclamp_idle_reset()
+update the rq->uclamp_max on first wake up from idle.
+
+This is only visible from first wake up(s) until the first dequeue to
+idle after enabling the static key. And it only matters if the
+uclamp_max of this task is < 1024 since only then its uclamp_max will be
+effectively ignored.
+
+Fix it by properly initializing rq->uclamp_flags = UCLAMP_FLAG_IDLE to
+ensure uclamp_idle_reset() is called which then will update the rq
+uclamp_max value as expected.
+
+Fixes: d81ae8aac85c ("sched/uclamp: Fix initialization of struct uclamp_rq")
+Signed-off-by: Qais Yousef <qais.yousef@arm.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Reviewed-by: Valentin Schneider <Valentin.Schneider@arm.com>
+Tested-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
+Link: https://lkml.kernel.org/r/20211202112033.1705279-1-qais.yousef@arm.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/sched/core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/kernel/sched/core.c b/kernel/sched/core.c
+index f8ca0738d729e..5befdecefe947 100644
+--- a/kernel/sched/core.c
++++ b/kernel/sched/core.c
+@@ -1337,7 +1337,7 @@ static void __init init_uclamp_rq(struct rq *rq)
+               };
+       }
+ 
+-      rq->uclamp_flags = 0;
++      rq->uclamp_flags = UCLAMP_FLAG_IDLE;
+ }
+ 
+ static void __init init_uclamp(void)
+-- 
+2.33.0
+

diff --git a/queue-5.4/series b/queue-5.4/series
index 1cfea475345e094763f1e52e54b5bf609b03b248..8c9e026921589bcd70f1cfa98e53cec12fd23a4f 100644 (file)
--- a/queue-5.4/series
+++ b/queue-5.4/series
@@ -48,3 +48,5 @@ net-rds-correct-socket-tunable-error-in-rds_tcp_tune.patch
 net-smc-keep-smc_close_final-rc-during-active-close.patch
 drm-msm-do-hw_init-before-capturing-gpu-state.patch
 ipv6-fix-memory-leak-in-fib6_rule_suppress.patch
+kvm-x86-pmu-fix-reserved-bits-for-amd-perfevtseln-re.patch
+sched-uclamp-fix-rq-uclamp_max-not-set-on-first-enqu.patch