From: Sasha Levin Date: Tue, 10 May 2022 00:57:00 +0000 (-0400) Subject: Fixes for 5.10 X-Git-Tag: v4.9.313~35 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=a2470f75bad6c6b5147d8bab2a6f37ce42e24856;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 5.10 Signed-off-by: Sasha Levin --- diff --git a/queue-5.10/hwmon-adt7470-fix-warning-on-module-removal.patch-3384 b/queue-5.10/hwmon-adt7470-fix-warning-on-module-removal.patch-3384 new file mode 100644 index 00000000000..99b4b1c4e1a --- /dev/null +++ b/queue-5.10/hwmon-adt7470-fix-warning-on-module-removal.patch-3384 @@ -0,0 +1,49 @@ +From 4d6488d25de932587ef80b4a3cb1d6ddbbd89a79 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 7 Apr 2022 12:13:12 +0200 +Subject: hwmon: (adt7470) Fix warning on module removal + +From: Armin Wolf + +[ Upstream commit 7b2666ce445c700b8dcee994da44ddcf050a0842 ] + +When removing the adt7470 module, a warning might be printed: + +do not call blocking ops when !TASK_RUNNING; state=1 +set at [] adt7470_update_thread+0x7b/0x130 [adt7470] + +This happens because adt7470_update_thread() can leave the kthread in +TASK_INTERRUPTIBLE state when the kthread is being stopped before +the call of set_current_state(). Since kthread_exit() might sleep in +exit_signals(), the warning is printed. +Fix that by using schedule_timeout_interruptible() and removing +the call of set_current_state(). +This causes TASK_INTERRUPTIBLE to be set after kthread_should_stop() +which might cause the kthread to exit. + +Reported-by: Zheyu Ma +Fixes: 93cacfd41f82 (hwmon: (adt7470) Allow faster removal) +Signed-off-by: Armin Wolf +Tested-by: Zheyu Ma +Link: https://lore.kernel.org/r/20220407101312.13331-1-W_Armin@gmx.de +Signed-off-by: Guenter Roeck +Signed-off-by: Sasha Levin +--- + drivers/hwmon/adt7470.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/hwmon/adt7470.c b/drivers/hwmon/adt7470.c +index 71e357956ce4..8028af4e4645 100644 +--- a/drivers/hwmon/adt7470.c ++++ b/drivers/hwmon/adt7470.c +@@ -18,6 +18,7 @@ + #include + #include + #include ++#include + #include + #include + #include +-- +2.35.1 + diff --git a/queue-5.10/kvm-lapic-enable-timer-posted-interrupt-only-when-mw.patch b/queue-5.10/kvm-lapic-enable-timer-posted-interrupt-only-when-mw.patch new file mode 100644 index 00000000000..f68590cdd4e --- /dev/null +++ b/queue-5.10/kvm-lapic-enable-timer-posted-interrupt-only-when-mw.patch @@ -0,0 +1,54 @@ +From 022a47adc54463f9ae024e44b073c3d1ff912bfa Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 25 Jan 2022 04:08:58 -0800 +Subject: KVM: LAPIC: Enable timer posted-interrupt only when mwait/hlt is + advertised + +From: Wanpeng Li + +[ Upstream commit 1714a4eb6fb0cb79f182873cd011a8ed60ac65e8 ] + +As commit 0c5f81dad46 ("KVM: LAPIC: Inject timer interrupt via posted +interrupt") mentioned that the host admin should well tune the guest +setup, so that vCPUs are placed on isolated pCPUs, and with several pCPUs +surplus for *busy* housekeeping. In this setup, it is preferrable to +disable mwait/hlt/pause vmexits to keep the vCPUs in non-root mode. + +However, if only some guests isolated and others not, they would not +have any benefit from posted timer interrupts, and at the same time lose +VMX preemption timer fast paths because kvm_can_post_timer_interrupt() +returns true and therefore forces kvm_can_use_hv_timer() to false. + +By guaranteeing that posted-interrupt timer is only used if MWAIT or +HLT are done without vmexit, KVM can make a better choice and use the +VMX preemption timer and the corresponding fast paths. + +Reported-by: Aili Yao +Reviewed-by: Sean Christopherson +Cc: Aili Yao +Cc: Sean Christopherson +Signed-off-by: Wanpeng Li +Message-Id: <1643112538-36743-1-git-send-email-wanpengli@tencent.com> +Signed-off-by: Paolo Bonzini +Signed-off-by: Sasha Levin +--- + arch/x86/kvm/lapic.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c +index e45ebf0870b6..a3ef793fce5f 100644 +--- a/arch/x86/kvm/lapic.c ++++ b/arch/x86/kvm/lapic.c +@@ -113,7 +113,8 @@ static inline u32 kvm_x2apic_id(struct kvm_lapic *apic) + + static bool kvm_can_post_timer_interrupt(struct kvm_vcpu *vcpu) + { +- return pi_inject_timer && kvm_vcpu_apicv_active(vcpu); ++ return pi_inject_timer && kvm_vcpu_apicv_active(vcpu) && ++ (kvm_mwait_in_guest(vcpu->kvm) || kvm_hlt_in_guest(vcpu->kvm)); + } + + bool kvm_can_use_hv_timer(struct kvm_vcpu *vcpu) +-- +2.35.1 + diff --git a/queue-5.10/kvm-x86-cpuid-only-provide-cpuid-leaf-0xa-if-host-ha.patch b/queue-5.10/kvm-x86-cpuid-only-provide-cpuid-leaf-0xa-if-host-ha.patch new file mode 100644 index 00000000000..d750029f6ea --- /dev/null +++ b/queue-5.10/kvm-x86-cpuid-only-provide-cpuid-leaf-0xa-if-host-ha.patch @@ -0,0 +1,54 @@ +From fd3a90ddebfcd099d3c4f8dab38fcfce0d54409b Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 27 Apr 2022 17:01:49 +0530 +Subject: kvm: x86/cpuid: Only provide CPUID leaf 0xA if host has architectural + PMU + +From: Sandipan Das + +[ Upstream commit 5a1bde46f98b893cda6122b00e94c0c40a6ead3c ] + +On some x86 processors, CPUID leaf 0xA provides information +on Architectural Performance Monitoring features. It +advertises a PMU version which Qemu uses to determine the +availability of additional MSRs to manage the PMCs. + +Upon receiving a KVM_GET_SUPPORTED_CPUID ioctl request for +the same, the kernel constructs return values based on the +x86_pmu_capability irrespective of the vendor. + +This leaf and the additional MSRs are not supported on AMD +and Hygon processors. If AMD PerfMonV2 is detected, the PMU +version is set to 2 and guest startup breaks because of an +attempt to access a non-existent MSR. Return zeros to avoid +this. + +Fixes: a6c06ed1a60a ("KVM: Expose the architectural performance monitoring CPUID leaf") +Reported-by: Vasant Hegde +Signed-off-by: Sandipan Das +Message-Id: <3fef83d9c2b2f7516e8ff50d60851f29a4bcb716.1651058600.git.sandipan.das@amd.com> +Signed-off-by: Paolo Bonzini +Signed-off-by: Sasha Levin +--- + arch/x86/kvm/cpuid.c | 5 +++++ + 1 file changed, 5 insertions(+) + +diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c +index 41b0dc37720e..6e1ea5e85e59 100644 +--- a/arch/x86/kvm/cpuid.c ++++ b/arch/x86/kvm/cpuid.c +@@ -668,6 +668,11 @@ static inline int __do_cpuid_func(struct kvm_cpuid_array *array, u32 function) + union cpuid10_eax eax; + union cpuid10_edx edx; + ++ if (!static_cpu_has(X86_FEATURE_ARCH_PERFMON)) { ++ entry->eax = entry->ebx = entry->ecx = entry->edx = 0; ++ break; ++ } ++ + perf_get_x86_pmu_capability(&cap); + + /* +-- +2.35.1 + diff --git a/queue-5.10/kvm-x86-do-not-change-icr-on-write-to-apic_self_ipi.patch b/queue-5.10/kvm-x86-do-not-change-icr-on-write-to-apic_self_ipi.patch new file mode 100644 index 00000000000..daeb14de832 --- /dev/null +++ b/queue-5.10/kvm-x86-do-not-change-icr-on-write-to-apic_self_ipi.patch @@ -0,0 +1,43 @@ +From f9894db81308dd03b9a2e35f3a8b7921f913fa8e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 24 Feb 2022 09:53:36 -0500 +Subject: KVM: x86: Do not change ICR on write to APIC_SELF_IPI + +From: Paolo Bonzini + +[ Upstream commit d22a81b304a27fca6124174a8e842e826c193466 ] + +Emulating writes to SELF_IPI with a write to ICR has an unwanted side effect: +the value of ICR in vAPIC page gets changed. The lists SELF_IPI as write-only, +with no associated MMIO offset, so any write should have no visible side +effect in the vAPIC page. + +Reported-by: Chao Gao +Reviewed-by: Sean Christopherson +Signed-off-by: Paolo Bonzini +Signed-off-by: Sasha Levin +--- + arch/x86/kvm/lapic.c | 7 +++---- + 1 file changed, 3 insertions(+), 4 deletions(-) + +diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c +index de11149e28e0..e45ebf0870b6 100644 +--- a/arch/x86/kvm/lapic.c ++++ b/arch/x86/kvm/lapic.c +@@ -2106,10 +2106,9 @@ int kvm_lapic_reg_write(struct kvm_lapic *apic, u32 reg, u32 val) + break; + + case APIC_SELF_IPI: +- if (apic_x2apic_mode(apic)) { +- kvm_lapic_reg_write(apic, APIC_ICR, +- APIC_DEST_SELF | (val & APIC_VECTOR_MASK)); +- } else ++ if (apic_x2apic_mode(apic)) ++ kvm_apic_send_ipi(apic, APIC_DEST_SELF | (val & APIC_VECTOR_MASK), 0); ++ else + ret = 1; + break; + default: +-- +2.35.1 + diff --git a/queue-5.10/kvm-x86-mmu-avoid-null-pointer-dereference-on-page-f.patch b/queue-5.10/kvm-x86-mmu-avoid-null-pointer-dereference-on-page-f.patch new file mode 100644 index 00000000000..e051972286f --- /dev/null +++ b/queue-5.10/kvm-x86-mmu-avoid-null-pointer-dereference-on-page-f.patch @@ -0,0 +1,39 @@ +From 08b7d019fbead2a6872ce9dd974c6a228cc0c300 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 8 Feb 2022 19:08:33 -0500 +Subject: KVM: x86/mmu: avoid NULL-pointer dereference on page freeing bugs + +From: Paolo Bonzini + +[ Upstream commit 9191b8f0745e63edf519e4a54a4aaae1d3d46fbd ] + +WARN and bail if KVM attempts to free a root that isn't backed by a shadow +page. KVM allocates a bare page for "special" roots, e.g. when using PAE +paging or shadowing 2/3/4-level page tables with 4/5-level, and so root_hpa +will be valid but won't be backed by a shadow page. It's all too easy to +blindly call mmu_free_root_page() on root_hpa, be nice and WARN instead of +crashing KVM and possibly the kernel. + +Reviewed-by: Sean Christopherson +Signed-off-by: Paolo Bonzini +Signed-off-by: Sasha Levin +--- + arch/x86/kvm/mmu/mmu.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c +index 99ea1ec12ffe..70ef5b542681 100644 +--- a/arch/x86/kvm/mmu/mmu.c ++++ b/arch/x86/kvm/mmu/mmu.c +@@ -3140,6 +3140,8 @@ static void mmu_free_root_page(struct kvm *kvm, hpa_t *root_hpa, + return; + + sp = to_shadow_page(*root_hpa & PT64_BASE_ADDR_MASK); ++ if (WARN_ON(!sp)) ++ return; + + if (kvm_mmu_put_root(kvm, sp)) { + if (sp->tdp_mmu_page) +-- +2.35.1 + diff --git a/queue-5.10/net-mlx5-fix-slab-out-of-bounds-while-reading-resour.patch b/queue-5.10/net-mlx5-fix-slab-out-of-bounds-while-reading-resour.patch new file mode 100644 index 00000000000..07358a5957d --- /dev/null +++ b/queue-5.10/net-mlx5-fix-slab-out-of-bounds-while-reading-resour.patch @@ -0,0 +1,151 @@ +From d7c06c9b186aa1425c39b580b2e0c3c5b1f66a11 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 3 Mar 2022 19:02:03 +0200 +Subject: net/mlx5: Fix slab-out-of-bounds while reading resource dump menu + +From: Aya Levin + +[ Upstream commit 7ba2d9d8de96696c1451fee1b01da11f45bdc2b9 ] + +Resource dump menu may span over more than a single page, support it. +Otherwise, menu read may result in a memory access violation: reading +outside of the allocated page. +Note that page format of the first menu page contains menu headers while +the proceeding menu pages contain only records. + +The KASAN logs are as follows: +BUG: KASAN: slab-out-of-bounds in strcmp+0x9b/0xb0 +Read of size 1 at addr ffff88812b2e1fd0 by task systemd-udevd/496 + +CPU: 5 PID: 496 Comm: systemd-udevd Tainted: G B 5.16.0_for_upstream_debug_2022_01_10_23_12 #1 +Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 +Call Trace: + + dump_stack_lvl+0x57/0x7d + print_address_description.constprop.0+0x1f/0x140 + ? strcmp+0x9b/0xb0 + ? strcmp+0x9b/0xb0 + kasan_report.cold+0x83/0xdf + ? strcmp+0x9b/0xb0 + strcmp+0x9b/0xb0 + mlx5_rsc_dump_init+0x4ab/0x780 [mlx5_core] + ? mlx5_rsc_dump_destroy+0x80/0x80 [mlx5_core] + ? lockdep_hardirqs_on_prepare+0x286/0x400 + ? raw_spin_unlock_irqrestore+0x47/0x50 + ? aomic_notifier_chain_register+0x32/0x40 + mlx5_load+0x104/0x2e0 [mlx5_core] + mlx5_init_one+0x41b/0x610 [mlx5_core] + .... +The buggy address belongs to the object at ffff88812b2e0000 + which belongs to the cache kmalloc-4k of size 4096 +The buggy address is located 4048 bytes to the right of + 4096-byte region [ffff88812b2e0000, ffff88812b2e1000) +The buggy address belongs to the page: +page:000000009d69807a refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88812b2e6000 pfn:0x12b2e0 +head:000000009d69807a order:3 compound_mapcount:0 compound_pincount:0 +flags: 0x8000000000010200(slab|head|zone=2) +raw: 8000000000010200 0000000000000000 dead000000000001 ffff888100043040 +raw: ffff88812b2e6000 0000000080040000 00000001ffffffff 0000000000000000 +page dumped because: kasan: bad access detected + +Memory state around the buggy address: + ffff88812b2e1e80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc + ffff88812b2e1f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc +>ffff88812b2e1f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc + ^ + ffff88812b2e2000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb + ffff88812b2e2080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb +================================================================== + +Fixes: 12206b17235a ("net/mlx5: Add support for resource dump") +Signed-off-by: Aya Levin +Reviewed-by: Moshe Shemesh +Signed-off-by: Saeed Mahameed +Signed-off-by: Sasha Levin +--- + .../mellanox/mlx5/core/diag/rsc_dump.c | 31 +++++++++++++++---- + 1 file changed, 25 insertions(+), 6 deletions(-) + +diff --git a/drivers/net/ethernet/mellanox/mlx5/core/diag/rsc_dump.c b/drivers/net/ethernet/mellanox/mlx5/core/diag/rsc_dump.c +index ed4fb79b4db7..75b6060f7a9a 100644 +--- a/drivers/net/ethernet/mellanox/mlx5/core/diag/rsc_dump.c ++++ b/drivers/net/ethernet/mellanox/mlx5/core/diag/rsc_dump.c +@@ -31,6 +31,7 @@ static const char *const mlx5_rsc_sgmt_name[] = { + struct mlx5_rsc_dump { + u32 pdn; + struct mlx5_core_mkey mkey; ++ u32 number_of_menu_items; + u16 fw_segment_type[MLX5_SGMT_TYPE_NUM]; + }; + +@@ -50,21 +51,37 @@ static int mlx5_rsc_dump_sgmt_get_by_name(char *name) + return -EINVAL; + } + +-static void mlx5_rsc_dump_read_menu_sgmt(struct mlx5_rsc_dump *rsc_dump, struct page *page) ++#define MLX5_RSC_DUMP_MENU_HEADER_SIZE (MLX5_ST_SZ_BYTES(resource_dump_info_segment) + \ ++ MLX5_ST_SZ_BYTES(resource_dump_command_segment) + \ ++ MLX5_ST_SZ_BYTES(resource_dump_menu_segment)) ++ ++static int mlx5_rsc_dump_read_menu_sgmt(struct mlx5_rsc_dump *rsc_dump, struct page *page, ++ int read_size, int start_idx) + { + void *data = page_address(page); + enum mlx5_sgmt_type sgmt_idx; + int num_of_items; + char *sgmt_name; + void *member; ++ int size = 0; + void *menu; + int i; + +- menu = MLX5_ADDR_OF(menu_resource_dump_response, data, menu); +- num_of_items = MLX5_GET(resource_dump_menu_segment, menu, num_of_records); ++ if (!start_idx) { ++ menu = MLX5_ADDR_OF(menu_resource_dump_response, data, menu); ++ rsc_dump->number_of_menu_items = MLX5_GET(resource_dump_menu_segment, menu, ++ num_of_records); ++ size = MLX5_RSC_DUMP_MENU_HEADER_SIZE; ++ data += size; ++ } ++ num_of_items = rsc_dump->number_of_menu_items; ++ ++ for (i = 0; start_idx + i < num_of_items; i++) { ++ size += MLX5_ST_SZ_BYTES(resource_dump_menu_record); ++ if (size >= read_size) ++ return start_idx + i; + +- for (i = 0; i < num_of_items; i++) { +- member = MLX5_ADDR_OF(resource_dump_menu_segment, menu, record[i]); ++ member = data + MLX5_ST_SZ_BYTES(resource_dump_menu_record) * i; + sgmt_name = MLX5_ADDR_OF(resource_dump_menu_record, member, segment_name); + sgmt_idx = mlx5_rsc_dump_sgmt_get_by_name(sgmt_name); + if (sgmt_idx == -EINVAL) +@@ -72,6 +89,7 @@ static void mlx5_rsc_dump_read_menu_sgmt(struct mlx5_rsc_dump *rsc_dump, struct + rsc_dump->fw_segment_type[sgmt_idx] = MLX5_GET(resource_dump_menu_record, + member, segment_type); + } ++ return 0; + } + + static int mlx5_rsc_dump_trigger(struct mlx5_core_dev *dev, struct mlx5_rsc_dump_cmd *cmd, +@@ -168,6 +186,7 @@ static int mlx5_rsc_dump_menu(struct mlx5_core_dev *dev) + struct mlx5_rsc_dump_cmd *cmd = NULL; + struct mlx5_rsc_key key = {}; + struct page *page; ++ int start_idx = 0; + int size; + int err; + +@@ -189,7 +208,7 @@ static int mlx5_rsc_dump_menu(struct mlx5_core_dev *dev) + if (err < 0) + goto destroy_cmd; + +- mlx5_rsc_dump_read_menu_sgmt(dev->rsc_dump, page); ++ start_idx = mlx5_rsc_dump_read_menu_sgmt(dev->rsc_dump, page, size, start_idx); + + } while (err > 0); + +-- +2.35.1 + diff --git a/queue-5.10/nfc-netlink-fix-sleep-in-atomic-bug-when-firmware-do.patch b/queue-5.10/nfc-netlink-fix-sleep-in-atomic-bug-when-firmware-do.patch new file mode 100644 index 00000000000..f81aa694fdd --- /dev/null +++ b/queue-5.10/nfc-netlink-fix-sleep-in-atomic-bug-when-firmware-do.patch @@ -0,0 +1,70 @@ +From 75cf9d713983e059a99996bad911f3a495a32a4f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 4 May 2022 13:58:47 +0800 +Subject: NFC: netlink: fix sleep in atomic bug when firmware download timeout + +From: Duoming Zhou + +[ Upstream commit 4071bf121d59944d5cd2238de0642f3d7995a997 ] + +There are sleep in atomic bug that could cause kernel panic during +firmware download process. The root cause is that nlmsg_new with +GFP_KERNEL parameter is called in fw_dnld_timeout which is a timer +handler. The call trace is shown below: + +BUG: sleeping function called from invalid context at include/linux/sched/mm.h:265 +Call Trace: +kmem_cache_alloc_node +__alloc_skb +nfc_genl_fw_download_done +call_timer_fn +__run_timers.part.0 +run_timer_softirq +__do_softirq +... + +The nlmsg_new with GFP_KERNEL parameter may sleep during memory +allocation process, and the timer handler is run as the result of +a "software interrupt" that should not call any other function +that could sleep. + +This patch changes allocation mode of netlink message from GFP_KERNEL +to GFP_ATOMIC in order to prevent sleep in atomic bug. The GFP_ATOMIC +flag makes memory allocation operation could be used in atomic context. + +Fixes: 9674da8759df ("NFC: Add firmware upload netlink command") +Fixes: 9ea7187c53f6 ("NFC: netlink: Rename CMD_FW_UPLOAD to CMD_FW_DOWNLOAD") +Signed-off-by: Duoming Zhou +Reviewed-by: Krzysztof Kozlowski +Link: https://lore.kernel.org/r/20220504055847.38026-1-duoming@zju.edu.cn +Signed-off-by: Paolo Abeni +Signed-off-by: Sasha Levin +--- + net/nfc/netlink.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/net/nfc/netlink.c b/net/nfc/netlink.c +index b8939ebaa6d3..c86e4b95f61b 100644 +--- a/net/nfc/netlink.c ++++ b/net/nfc/netlink.c +@@ -534,7 +534,7 @@ int nfc_genl_se_connectivity(struct nfc_dev *dev, u8 se_idx) + struct sk_buff *msg; + void *hdr; + +- msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL); ++ msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_ATOMIC); + if (!msg) + return -ENOMEM; + +@@ -554,7 +554,7 @@ int nfc_genl_se_connectivity(struct nfc_dev *dev, u8 se_idx) + + genlmsg_end(msg, hdr); + +- genlmsg_multicast(&nfc_genl_family, msg, 0, 0, GFP_KERNEL); ++ genlmsg_multicast(&nfc_genl_family, msg, 0, 0, GFP_ATOMIC); + + return 0; + +-- +2.35.1 + diff --git a/queue-5.10/series b/queue-5.10/series index 4ad81ae19d9..50b01d037c7 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -55,3 +55,11 @@ selftests-ocelot-tc_flower_chains-specify-conform-exceed-action-for-policer.patc smsc911x-allow-using-irq0.patch btrfs-always-log-symlinks-in-full-mode.patch net-igmp-respect-rcu-rules-in-ip_mc_source-and-ip_mc_msfilter.patch +hwmon-adt7470-fix-warning-on-module-removal.patch-3384 +kvm-x86-cpuid-only-provide-cpuid-leaf-0xa-if-host-ha.patch +net-mlx5-fix-slab-out-of-bounds-while-reading-resour.patch +nfc-netlink-fix-sleep-in-atomic-bug-when-firmware-do.patch +x86-kvm-preserve-bsp-msr_kvm_poll_control-across-sus.patch +kvm-x86-do-not-change-icr-on-write-to-apic_self_ipi.patch +kvm-x86-mmu-avoid-null-pointer-dereference-on-page-f.patch +kvm-lapic-enable-timer-posted-interrupt-only-when-mw.patch diff --git a/queue-5.10/x86-kvm-preserve-bsp-msr_kvm_poll_control-across-sus.patch b/queue-5.10/x86-kvm-preserve-bsp-msr_kvm_poll_control-across-sus.patch new file mode 100644 index 00000000000..5363bb4eb36 --- /dev/null +++ b/queue-5.10/x86-kvm-preserve-bsp-msr_kvm_poll_control-across-sus.patch @@ -0,0 +1,71 @@ +From fe5745faf08518cd4019555e97f86d938cc6dba1 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 18 Apr 2022 00:42:32 -0700 +Subject: x86/kvm: Preserve BSP MSR_KVM_POLL_CONTROL across suspend/resume + +From: Wanpeng Li + +[ Upstream commit 0361bdfddca20c8855ea3bdbbbc9c999912b10ff ] + +MSR_KVM_POLL_CONTROL is cleared on reset, thus reverting guests to +host-side polling after suspend/resume. Non-bootstrap CPUs are +restored correctly by the haltpoll driver because they are hot-unplugged +during suspend and hot-plugged during resume; however, the BSP +is not hotpluggable and remains in host-sde polling mode after +the guest resume. The makes the guest pay for the cost of vmexits +every time the guest enters idle. + +Fix it by recording BSP's haltpoll state and resuming it during guest +resume. + +Cc: Marcelo Tosatti +Signed-off-by: Wanpeng Li +Message-Id: <1650267752-46796-1-git-send-email-wanpengli@tencent.com> +Signed-off-by: Paolo Bonzini +Signed-off-by: Sasha Levin +--- + arch/x86/kernel/kvm.c | 13 +++++++++++++ + 1 file changed, 13 insertions(+) + +diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c +index 18e952fed021..6c3d38b5a8ad 100644 +--- a/arch/x86/kernel/kvm.c ++++ b/arch/x86/kernel/kvm.c +@@ -66,6 +66,7 @@ static DEFINE_PER_CPU_DECRYPTED(struct kvm_vcpu_pv_apf_data, apf_reason) __align + DEFINE_PER_CPU_DECRYPTED(struct kvm_steal_time, steal_time) __aligned(64) __visible; + static int has_steal_clock = 0; + ++static int has_guest_poll = 0; + /* + * No need for any "IO delay" on KVM + */ +@@ -624,14 +625,26 @@ static int kvm_cpu_down_prepare(unsigned int cpu) + + static int kvm_suspend(void) + { ++ u64 val = 0; ++ + kvm_guest_cpu_offline(false); + ++#ifdef CONFIG_ARCH_CPUIDLE_HALTPOLL ++ if (kvm_para_has_feature(KVM_FEATURE_POLL_CONTROL)) ++ rdmsrl(MSR_KVM_POLL_CONTROL, val); ++ has_guest_poll = !(val & 1); ++#endif + return 0; + } + + static void kvm_resume(void) + { + kvm_cpu_online(raw_smp_processor_id()); ++ ++#ifdef CONFIG_ARCH_CPUIDLE_HALTPOLL ++ if (kvm_para_has_feature(KVM_FEATURE_POLL_CONTROL) && has_guest_poll) ++ wrmsrl(MSR_KVM_POLL_CONTROL, 0); ++#endif + } + + static struct syscore_ops kvm_syscore_ops = { +-- +2.35.1 +