From: Greg Kroah-Hartman Date: Mon, 10 Mar 2025 10:53:46 +0000 (+0100) Subject: 6.12-stable patches X-Git-Tag: v5.4.291~63 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=bde148ba5d443cb6f7d8957e26cdb7adeacc799e;p=thirdparty%2Fkernel%2Fstable-queue.git 6.12-stable patches added patches: bus-mhi-host-pci_generic-use-pci_try_reset_function-to-avoid-deadlock.patch cdx-fix-possible-uaf-error-in-driver_override_show.patch char-misc-deallocate-static-minor-in-error-path.patch drivers-core-fix-device-leak-in-__fw_devlink_relax_cycles.patch drivers-virt-acrn-hsm-use-kzalloc-to-avoid-info-leak-in-pmcmd_ioctl.patch eeprom-digsy_mtc-make-gpio-lookup-table-match-the-device.patch iio-adc-ad7192-fix-channel-select.patch iio-adc-at91-sama5d2_adc-fix-sama7g5-realbits-value.patch iio-dac-ad3552r-clear-reset-status-flag.patch iio-filter-admv8818-force-initialization-of-sdo.patch iio-light-apds9306-fix-max_scale_nano-values.patch intel_th-pci-add-arrow-lake-support.patch intel_th-pci-add-panther-lake-h-support.patch intel_th-pci-add-panther-lake-p-u-support.patch kvm-svm-drop-debugctl-from-guest-s-effective-value.patch kvm-svm-manually-context-switch-debugctl-if-lbr-virtualization-is-disabled.patch kvm-svm-save-host-dr-masks-on-cpus-with-debugswap.patch kvm-svm-set-rflags.if-1-in-c-code-to-get-vmrun-out-of-the-sti-shadow.patch kvm-svm-suppress-debugctl.btf-on-amd.patch kvm-x86-explicitly-zero-eax-and-ebx-when-perfmon_v2-isn-t-supported-by-kvm.patch kvm-x86-snapshot-the-host-s-debugctl-after-disabling-irqs.patch kvm-x86-snapshot-the-host-s-debugctl-in-common-x86.patch mei-me-add-panther-lake-p-did.patch mei-vsc-use-wakeuphostint-when-getting-the-host-wakeup-gpio.patch slimbus-messaging-free-transaction-id-in-delayed-interrupt-scenario.patch --- diff --git a/queue-6.12/bus-mhi-host-pci_generic-use-pci_try_reset_function-to-avoid-deadlock.patch b/queue-6.12/bus-mhi-host-pci_generic-use-pci_try_reset_function-to-avoid-deadlock.patch new file mode 100644 index 0000000000..51c44ba1cc --- /dev/null +++ b/queue-6.12/bus-mhi-host-pci_generic-use-pci_try_reset_function-to-avoid-deadlock.patch @@ -0,0 +1,69 @@ +From a321d163de3d8aa38a6449ab2becf4b1581aed96 Mon Sep 17 00:00:00 2001 +From: Manivannan Sadhasivam +Date: Wed, 8 Jan 2025 19:09:27 +0530 +Subject: bus: mhi: host: pci_generic: Use pci_try_reset_function() to avoid deadlock + +From: Manivannan Sadhasivam + +commit a321d163de3d8aa38a6449ab2becf4b1581aed96 upstream. + +There are multiple places from where the recovery work gets scheduled +asynchronously. Also, there are multiple places where the caller waits +synchronously for the recovery to be completed. One such place is during +the PM shutdown() callback. + +If the device is not alive during recovery_work, it will try to reset the +device using pci_reset_function(). This function internally will take the +device_lock() first before resetting the device. By this time, if the lock +has already been acquired, then recovery_work will get stalled while +waiting for the lock. And if the lock was already acquired by the caller +which waits for the recovery_work to be completed, it will lead to +deadlock. + +This is what happened on the X1E80100 CRD device when the device died +before shutdown() callback. Driver core calls the driver's shutdown() +callback while holding the device_lock() leading to deadlock. + +And this deadlock scenario can occur on other paths as well, like during +the PM suspend() callback, where the driver core would hold the +device_lock() before calling driver's suspend() callback. And if the +recovery_work was already started, it could lead to deadlock. This is also +observed on the X1E80100 CRD. + +So to fix both issues, use pci_try_reset_function() in recovery_work. This +function first checks for the availability of the device_lock() before +trying to reset the device. If the lock is available, it will acquire it +and reset the device. Otherwise, it will return -EAGAIN. If that happens, +recovery_work will fail with the error message "Recovery failed" as not +much could be done. + +Cc: stable@vger.kernel.org # 5.12 +Reported-by: Johan Hovold +Closes: https://lore.kernel.org/mhi/Z1me8iaK7cwgjL92@hovoldconsulting.com +Fixes: 7389337f0a78 ("mhi: pci_generic: Add suspend/resume/recovery procedure") +Reviewed-by: Johan Hovold +Tested-by: Johan Hovold +Analyzed-by: Johan Hovold +Link: https://lore.kernel.org/mhi/Z2KKjWY2mPen6GPL@hovoldconsulting.com/ +Reviewed-by: Loic Poulain +Link: https://lore.kernel.org/r/20250108-mhi_recovery_fix-v1-1-a0a00a17da46@linaro.org +Signed-off-by: Manivannan Sadhasivam +Signed-off-by: Greg Kroah-Hartman +--- + drivers/bus/mhi/host/pci_generic.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/drivers/bus/mhi/host/pci_generic.c ++++ b/drivers/bus/mhi/host/pci_generic.c +@@ -1040,8 +1040,9 @@ static void mhi_pci_recovery_work(struct + err_unprepare: + mhi_unprepare_after_power_down(mhi_cntrl); + err_try_reset: +- if (pci_reset_function(pdev)) +- dev_err(&pdev->dev, "Recovery failed\n"); ++ err = pci_try_reset_function(pdev); ++ if (err) ++ dev_err(&pdev->dev, "Recovery failed: %d\n", err); + } + + static void health_check(struct timer_list *t) diff --git a/queue-6.12/cdx-fix-possible-uaf-error-in-driver_override_show.patch b/queue-6.12/cdx-fix-possible-uaf-error-in-driver_override_show.patch new file mode 100644 index 0000000000..3bedc428c4 --- /dev/null +++ b/queue-6.12/cdx-fix-possible-uaf-error-in-driver_override_show.patch @@ -0,0 +1,56 @@ +From 91d44c1afc61a2fec37a9c7a3485368309391e0b Mon Sep 17 00:00:00 2001 +From: Qiu-ji Chen +Date: Sat, 18 Jan 2025 15:08:33 +0800 +Subject: cdx: Fix possible UAF error in driver_override_show() + +From: Qiu-ji Chen + +commit 91d44c1afc61a2fec37a9c7a3485368309391e0b upstream. + +Fixed a possible UAF problem in driver_override_show() in drivers/cdx/cdx.c + +This function driver_override_show() is part of DEVICE_ATTR_RW, which +includes both driver_override_show() and driver_override_store(). +These functions can be executed concurrently in sysfs. + +The driver_override_store() function uses driver_set_override() to +update the driver_override value, and driver_set_override() internally +locks the device (device_lock(dev)). If driver_override_show() reads +cdx_dev->driver_override without locking, it could potentially access +a freed pointer if driver_override_store() frees the string +concurrently. This could lead to printing a kernel address, which is a +security risk since DEVICE_ATTR can be read by all users. + +Additionally, a similar pattern is used in drivers/amba/bus.c, as well +as many other bus drivers, where device_lock() is taken in the show +function, and it has been working without issues. + +This potential bug was detected by our experimental static analysis +tool, which analyzes locking APIs and paired functions to identify +data races and atomicity violations. + +Fixes: 1f86a00c1159 ("bus/fsl-mc: add support for 'driver_override' in the mc-bus") +Cc: stable +Signed-off-by: Qiu-ji Chen +Link: https://lore.kernel.org/r/20250118070833.27201-1-chenqiuji666@gmail.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/cdx/cdx.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +--- a/drivers/cdx/cdx.c ++++ b/drivers/cdx/cdx.c +@@ -470,8 +470,12 @@ static ssize_t driver_override_show(stru + struct device_attribute *attr, char *buf) + { + struct cdx_device *cdx_dev = to_cdx_device(dev); ++ ssize_t len; + +- return sysfs_emit(buf, "%s\n", cdx_dev->driver_override); ++ device_lock(dev); ++ len = sysfs_emit(buf, "%s\n", cdx_dev->driver_override); ++ device_unlock(dev); ++ return len; + } + static DEVICE_ATTR_RW(driver_override); + diff --git a/queue-6.12/char-misc-deallocate-static-minor-in-error-path.patch b/queue-6.12/char-misc-deallocate-static-minor-in-error-path.patch new file mode 100644 index 0000000000..fc6d5db3f5 --- /dev/null +++ b/queue-6.12/char-misc-deallocate-static-minor-in-error-path.patch @@ -0,0 +1,34 @@ +From 6d991f569c5ef6eaeadf1238df2c36e3975233ad Mon Sep 17 00:00:00 2001 +From: Thadeu Lima de Souza Cascardo +Date: Thu, 23 Jan 2025 09:32:49 -0300 +Subject: char: misc: deallocate static minor in error path + +From: Thadeu Lima de Souza Cascardo + +commit 6d991f569c5ef6eaeadf1238df2c36e3975233ad upstream. + +When creating sysfs files fail, the allocated minor must be freed such that +it can be later reused. That is specially harmful for static minor numbers, +since those would always fail to register later on. + +Fixes: 6d04d2b554b1 ("misc: misc_minor_alloc to use ida for all dynamic/misc dynamic minors") +Cc: stable +Signed-off-by: Thadeu Lima de Souza Cascardo +Link: https://lore.kernel.org/r/20250123123249.4081674-5-cascardo@igalia.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/char/misc.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/char/misc.c ++++ b/drivers/char/misc.c +@@ -264,8 +264,8 @@ int misc_register(struct miscdevice *mis + device_create_with_groups(&misc_class, misc->parent, dev, + misc, misc->groups, "%s", misc->name); + if (IS_ERR(misc->this_device)) { ++ misc_minor_free(misc->minor); + if (is_dynamic) { +- misc_minor_free(misc->minor); + misc->minor = MISC_DYNAMIC_MINOR; + } + err = PTR_ERR(misc->this_device); diff --git a/queue-6.12/drivers-core-fix-device-leak-in-__fw_devlink_relax_cycles.patch b/queue-6.12/drivers-core-fix-device-leak-in-__fw_devlink_relax_cycles.patch new file mode 100644 index 0000000000..2914c27eb3 --- /dev/null +++ b/queue-6.12/drivers-core-fix-device-leak-in-__fw_devlink_relax_cycles.patch @@ -0,0 +1,35 @@ +From 78eb41f518f414378643ab022241df2a9dcd008b Mon Sep 17 00:00:00 2001 +From: Luca Ceresoli +Date: Thu, 13 Feb 2025 15:05:13 +0100 +Subject: drivers: core: fix device leak in __fw_devlink_relax_cycles() + +From: Luca Ceresoli + +commit 78eb41f518f414378643ab022241df2a9dcd008b upstream. + +Commit bac3b10b78e5 ("driver core: fw_devlink: Stop trying to optimize +cycle detection logic") introduced a new struct device *con_dev and a +get_dev_from_fwnode() call to get it, but without adding a corresponding +put_device(). + +Closes: https://lore.kernel.org/all/20241204124826.2e055091@booty/ +Fixes: bac3b10b78e5 ("driver core: fw_devlink: Stop trying to optimize cycle detection logic") +Cc: stable@vger.kernel.org +Reviewed-by: Saravana Kannan +Signed-off-by: Luca Ceresoli +Link: https://lore.kernel.org/r/20250213-fix__fw_devlink_relax_cycles_missing_device_put-v2-1-8cd3b03e6a3f@bootlin.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/base/core.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/base/core.c ++++ b/drivers/base/core.c +@@ -2079,6 +2079,7 @@ static bool __fw_devlink_relax_cycles(st + out: + sup_handle->flags &= ~FWNODE_FLAG_VISITED; + put_device(sup_dev); ++ put_device(con_dev); + put_device(par_dev); + return ret; + } diff --git a/queue-6.12/drivers-virt-acrn-hsm-use-kzalloc-to-avoid-info-leak-in-pmcmd_ioctl.patch b/queue-6.12/drivers-virt-acrn-hsm-use-kzalloc-to-avoid-info-leak-in-pmcmd_ioctl.patch new file mode 100644 index 0000000000..cbf819d0d1 --- /dev/null +++ b/queue-6.12/drivers-virt-acrn-hsm-use-kzalloc-to-avoid-info-leak-in-pmcmd_ioctl.patch @@ -0,0 +1,54 @@ +From 819cec1dc47cdeac8f5dd6ba81c1dbee2a68c3bb Mon Sep 17 00:00:00 2001 +From: Haoyu Li +Date: Thu, 30 Jan 2025 19:58:11 +0800 +Subject: drivers: virt: acrn: hsm: Use kzalloc to avoid info leak in pmcmd_ioctl + +From: Haoyu Li + +commit 819cec1dc47cdeac8f5dd6ba81c1dbee2a68c3bb upstream. + +In the "pmcmd_ioctl" function, three memory objects allocated by +kmalloc are initialized by "hcall_get_cpu_state", which are then +copied to user space. The initializer is indeed implemented in +"acrn_hypercall2" (arch/x86/include/asm/acrn.h). There is a risk of +information leakage due to uninitialized bytes. + +Fixes: 3d679d5aec64 ("virt: acrn: Introduce interfaces to query C-states and P-states allowed by hypervisor") +Signed-off-by: Haoyu Li +Cc: stable +Acked-by: Fei Li +Link: https://lore.kernel.org/r/20250130115811.92424-1-lihaoyu499@gmail.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/virt/acrn/hsm.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/drivers/virt/acrn/hsm.c ++++ b/drivers/virt/acrn/hsm.c +@@ -49,7 +49,7 @@ static int pmcmd_ioctl(u64 cmd, void __u + switch (cmd & PMCMD_TYPE_MASK) { + case ACRN_PMCMD_GET_PX_CNT: + case ACRN_PMCMD_GET_CX_CNT: +- pm_info = kmalloc(sizeof(u64), GFP_KERNEL); ++ pm_info = kzalloc(sizeof(u64), GFP_KERNEL); + if (!pm_info) + return -ENOMEM; + +@@ -64,7 +64,7 @@ static int pmcmd_ioctl(u64 cmd, void __u + kfree(pm_info); + break; + case ACRN_PMCMD_GET_PX_DATA: +- px_data = kmalloc(sizeof(*px_data), GFP_KERNEL); ++ px_data = kzalloc(sizeof(*px_data), GFP_KERNEL); + if (!px_data) + return -ENOMEM; + +@@ -79,7 +79,7 @@ static int pmcmd_ioctl(u64 cmd, void __u + kfree(px_data); + break; + case ACRN_PMCMD_GET_CX_DATA: +- cx_data = kmalloc(sizeof(*cx_data), GFP_KERNEL); ++ cx_data = kzalloc(sizeof(*cx_data), GFP_KERNEL); + if (!cx_data) + return -ENOMEM; + diff --git a/queue-6.12/eeprom-digsy_mtc-make-gpio-lookup-table-match-the-device.patch b/queue-6.12/eeprom-digsy_mtc-make-gpio-lookup-table-match-the-device.patch new file mode 100644 index 0000000000..48a78cfe99 --- /dev/null +++ b/queue-6.12/eeprom-digsy_mtc-make-gpio-lookup-table-match-the-device.patch @@ -0,0 +1,35 @@ +From 038ef0754aae76f79b147b8867f9250e6a976872 Mon Sep 17 00:00:00 2001 +From: Andy Shevchenko +Date: Fri, 7 Feb 2025 00:03:11 +0200 +Subject: eeprom: digsy_mtc: Make GPIO lookup table match the device + +From: Andy Shevchenko + +commit 038ef0754aae76f79b147b8867f9250e6a976872 upstream. + +The dev_id value in the GPIO lookup table must match to +the device instance name, which in this case is combined +of name and platform device ID, i.e. "spi_gpio.1". But +the table assumed that there was no platform device ID +defined, which is wrong. Fix the dev_id value accordingly. + +Fixes: 9b00bc7b901f ("spi: spi-gpio: Rewrite to use GPIO descriptors") +Cc: stable +Signed-off-by: Andy Shevchenko +Link: https://lore.kernel.org/r/20250206220311.1554075-1-andriy.shevchenko@linux.intel.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/misc/eeprom/digsy_mtc_eeprom.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/misc/eeprom/digsy_mtc_eeprom.c ++++ b/drivers/misc/eeprom/digsy_mtc_eeprom.c +@@ -50,7 +50,7 @@ static struct platform_device digsy_mtc_ + }; + + static struct gpiod_lookup_table eeprom_spi_gpiod_table = { +- .dev_id = "spi_gpio", ++ .dev_id = "spi_gpio.1", + .table = { + GPIO_LOOKUP("gpio@b00", GPIO_EEPROM_CLK, + "sck", GPIO_ACTIVE_HIGH), diff --git a/queue-6.12/iio-adc-ad7192-fix-channel-select.patch b/queue-6.12/iio-adc-ad7192-fix-channel-select.patch new file mode 100644 index 0000000000..24d56174a7 --- /dev/null +++ b/queue-6.12/iio-adc-ad7192-fix-channel-select.patch @@ -0,0 +1,37 @@ +From 21d7241faf406e8aee3ce348451cc362d5db6a02 Mon Sep 17 00:00:00 2001 +From: Markus Burri +Date: Fri, 24 Jan 2025 16:07:03 +0100 +Subject: iio: adc: ad7192: fix channel select +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Markus Burri + +commit 21d7241faf406e8aee3ce348451cc362d5db6a02 upstream. + +Channel configuration doesn't work as expected. +For FIELD_PREP the bit mask is needed and not the bit number. + +Fixes: 874bbd1219c7 ("iio: adc: ad7192: Use bitfield access macros") +Signed-off-by: Markus Burri +Reviewed-by: Nuno Sá +Link: https://patch.msgid.link/20250124150703.97848-1-markus.burri@mt.com +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/adc/ad7192.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/iio/adc/ad7192.c ++++ b/drivers/iio/adc/ad7192.c +@@ -1082,7 +1082,7 @@ static int ad7192_update_scan_mode(struc + + conf &= ~AD7192_CONF_CHAN_MASK; + for_each_set_bit(i, scan_mask, 8) +- conf |= FIELD_PREP(AD7192_CONF_CHAN_MASK, i); ++ conf |= FIELD_PREP(AD7192_CONF_CHAN_MASK, BIT(i)); + + ret = ad_sd_write_reg(&st->sd, AD7192_REG_CONF, 3, conf); + if (ret < 0) diff --git a/queue-6.12/iio-adc-at91-sama5d2_adc-fix-sama7g5-realbits-value.patch b/queue-6.12/iio-adc-at91-sama5d2_adc-fix-sama7g5-realbits-value.patch new file mode 100644 index 0000000000..8936f6ae81 --- /dev/null +++ b/queue-6.12/iio-adc-at91-sama5d2_adc-fix-sama7g5-realbits-value.patch @@ -0,0 +1,134 @@ +From aa5119c36d19639397d29ef305aa53a5ecd72b27 Mon Sep 17 00:00:00 2001 +From: Nayab Sayed +Date: Wed, 15 Jan 2025 11:37:04 +0530 +Subject: iio: adc: at91-sama5d2_adc: fix sama7g5 realbits value + +From: Nayab Sayed + +commit aa5119c36d19639397d29ef305aa53a5ecd72b27 upstream. + +The number of valid bits in SAMA7G5 ADC channel data register are 16. +Hence changing the realbits value to 16 + +Fixes: 840bf6cb983f ("iio: adc: at91-sama5d2_adc: add support for sama7g5 device") +Signed-off-by: Nayab Sayed +Link: https://patch.msgid.link/20250115-fix-sama7g5-adc-realbits-v2-1-58a6e4087584@microchip.com +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/adc/at91-sama5d2_adc.c | 68 +++++++++++++++++++++---------------- + 1 file changed, 40 insertions(+), 28 deletions(-) + +--- a/drivers/iio/adc/at91-sama5d2_adc.c ++++ b/drivers/iio/adc/at91-sama5d2_adc.c +@@ -329,7 +329,7 @@ static const struct at91_adc_reg_layout + #define AT91_HWFIFO_MAX_SIZE_STR "128" + #define AT91_HWFIFO_MAX_SIZE 128 + +-#define AT91_SAMA5D2_CHAN_SINGLE(index, num, addr) \ ++#define AT91_SAMA_CHAN_SINGLE(index, num, addr, rbits) \ + { \ + .type = IIO_VOLTAGE, \ + .channel = num, \ +@@ -337,7 +337,7 @@ static const struct at91_adc_reg_layout + .scan_index = index, \ + .scan_type = { \ + .sign = 'u', \ +- .realbits = 14, \ ++ .realbits = rbits, \ + .storagebits = 16, \ + }, \ + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \ +@@ -350,7 +350,13 @@ static const struct at91_adc_reg_layout + .indexed = 1, \ + } + +-#define AT91_SAMA5D2_CHAN_DIFF(index, num, num2, addr) \ ++#define AT91_SAMA5D2_CHAN_SINGLE(index, num, addr) \ ++ AT91_SAMA_CHAN_SINGLE(index, num, addr, 14) ++ ++#define AT91_SAMA7G5_CHAN_SINGLE(index, num, addr) \ ++ AT91_SAMA_CHAN_SINGLE(index, num, addr, 16) ++ ++#define AT91_SAMA_CHAN_DIFF(index, num, num2, addr, rbits) \ + { \ + .type = IIO_VOLTAGE, \ + .differential = 1, \ +@@ -360,7 +366,7 @@ static const struct at91_adc_reg_layout + .scan_index = index, \ + .scan_type = { \ + .sign = 's', \ +- .realbits = 14, \ ++ .realbits = rbits, \ + .storagebits = 16, \ + }, \ + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \ +@@ -373,6 +379,12 @@ static const struct at91_adc_reg_layout + .indexed = 1, \ + } + ++#define AT91_SAMA5D2_CHAN_DIFF(index, num, num2, addr) \ ++ AT91_SAMA_CHAN_DIFF(index, num, num2, addr, 14) ++ ++#define AT91_SAMA7G5_CHAN_DIFF(index, num, num2, addr) \ ++ AT91_SAMA_CHAN_DIFF(index, num, num2, addr, 16) ++ + #define AT91_SAMA5D2_CHAN_TOUCH(num, name, mod) \ + { \ + .type = IIO_POSITIONRELATIVE, \ +@@ -666,30 +678,30 @@ static const struct iio_chan_spec at91_s + }; + + static const struct iio_chan_spec at91_sama7g5_adc_channels[] = { +- AT91_SAMA5D2_CHAN_SINGLE(0, 0, 0x60), +- AT91_SAMA5D2_CHAN_SINGLE(1, 1, 0x64), +- AT91_SAMA5D2_CHAN_SINGLE(2, 2, 0x68), +- AT91_SAMA5D2_CHAN_SINGLE(3, 3, 0x6c), +- AT91_SAMA5D2_CHAN_SINGLE(4, 4, 0x70), +- AT91_SAMA5D2_CHAN_SINGLE(5, 5, 0x74), +- AT91_SAMA5D2_CHAN_SINGLE(6, 6, 0x78), +- AT91_SAMA5D2_CHAN_SINGLE(7, 7, 0x7c), +- AT91_SAMA5D2_CHAN_SINGLE(8, 8, 0x80), +- AT91_SAMA5D2_CHAN_SINGLE(9, 9, 0x84), +- AT91_SAMA5D2_CHAN_SINGLE(10, 10, 0x88), +- AT91_SAMA5D2_CHAN_SINGLE(11, 11, 0x8c), +- AT91_SAMA5D2_CHAN_SINGLE(12, 12, 0x90), +- AT91_SAMA5D2_CHAN_SINGLE(13, 13, 0x94), +- AT91_SAMA5D2_CHAN_SINGLE(14, 14, 0x98), +- AT91_SAMA5D2_CHAN_SINGLE(15, 15, 0x9c), +- AT91_SAMA5D2_CHAN_DIFF(16, 0, 1, 0x60), +- AT91_SAMA5D2_CHAN_DIFF(17, 2, 3, 0x68), +- AT91_SAMA5D2_CHAN_DIFF(18, 4, 5, 0x70), +- AT91_SAMA5D2_CHAN_DIFF(19, 6, 7, 0x78), +- AT91_SAMA5D2_CHAN_DIFF(20, 8, 9, 0x80), +- AT91_SAMA5D2_CHAN_DIFF(21, 10, 11, 0x88), +- AT91_SAMA5D2_CHAN_DIFF(22, 12, 13, 0x90), +- AT91_SAMA5D2_CHAN_DIFF(23, 14, 15, 0x98), ++ AT91_SAMA7G5_CHAN_SINGLE(0, 0, 0x60), ++ AT91_SAMA7G5_CHAN_SINGLE(1, 1, 0x64), ++ AT91_SAMA7G5_CHAN_SINGLE(2, 2, 0x68), ++ AT91_SAMA7G5_CHAN_SINGLE(3, 3, 0x6c), ++ AT91_SAMA7G5_CHAN_SINGLE(4, 4, 0x70), ++ AT91_SAMA7G5_CHAN_SINGLE(5, 5, 0x74), ++ AT91_SAMA7G5_CHAN_SINGLE(6, 6, 0x78), ++ AT91_SAMA7G5_CHAN_SINGLE(7, 7, 0x7c), ++ AT91_SAMA7G5_CHAN_SINGLE(8, 8, 0x80), ++ AT91_SAMA7G5_CHAN_SINGLE(9, 9, 0x84), ++ AT91_SAMA7G5_CHAN_SINGLE(10, 10, 0x88), ++ AT91_SAMA7G5_CHAN_SINGLE(11, 11, 0x8c), ++ AT91_SAMA7G5_CHAN_SINGLE(12, 12, 0x90), ++ AT91_SAMA7G5_CHAN_SINGLE(13, 13, 0x94), ++ AT91_SAMA7G5_CHAN_SINGLE(14, 14, 0x98), ++ AT91_SAMA7G5_CHAN_SINGLE(15, 15, 0x9c), ++ AT91_SAMA7G5_CHAN_DIFF(16, 0, 1, 0x60), ++ AT91_SAMA7G5_CHAN_DIFF(17, 2, 3, 0x68), ++ AT91_SAMA7G5_CHAN_DIFF(18, 4, 5, 0x70), ++ AT91_SAMA7G5_CHAN_DIFF(19, 6, 7, 0x78), ++ AT91_SAMA7G5_CHAN_DIFF(20, 8, 9, 0x80), ++ AT91_SAMA7G5_CHAN_DIFF(21, 10, 11, 0x88), ++ AT91_SAMA7G5_CHAN_DIFF(22, 12, 13, 0x90), ++ AT91_SAMA7G5_CHAN_DIFF(23, 14, 15, 0x98), + IIO_CHAN_SOFT_TIMESTAMP(24), + AT91_SAMA5D2_CHAN_TEMP(AT91_SAMA7G5_ADC_TEMP_CHANNEL, "temp", 0xdc), + }; diff --git a/queue-6.12/iio-dac-ad3552r-clear-reset-status-flag.patch b/queue-6.12/iio-dac-ad3552r-clear-reset-status-flag.patch new file mode 100644 index 0000000000..94c63b0055 --- /dev/null +++ b/queue-6.12/iio-dac-ad3552r-clear-reset-status-flag.patch @@ -0,0 +1,42 @@ +From e17b9f20da7d2bc1f48878ab2230523b2512d965 Mon Sep 17 00:00:00 2001 +From: Angelo Dureghello +Date: Sat, 25 Jan 2025 17:24:32 +0100 +Subject: iio: dac: ad3552r: clear reset status flag + +From: Angelo Dureghello + +commit e17b9f20da7d2bc1f48878ab2230523b2512d965 upstream. + +Clear reset status flag, to keep error status register clean after reset +(ad3552r manual, rev B table 38). + +Reset error flag was left to 1, so debugging registers, the "Error +Status Register" was dirty (0x01). It is important to clear this bit, so +if there is any reset event over normal working mode, it is possible to +detect it. + +Fixes: 8f2b54824b28 ("drivers:iio:dac: Add AD3552R driver support") +Signed-off-by: Angelo Dureghello +Link: https://patch.msgid.link/20250125-wip-bl-ad3552r-clear-reset-v2-1-aa3a27f3ff8c@baylibre.com +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/dac/ad3552r.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +--- a/drivers/iio/dac/ad3552r.c ++++ b/drivers/iio/dac/ad3552r.c +@@ -714,6 +714,12 @@ static int ad3552r_reset(struct ad3552r_ + return ret; + } + ++ /* Clear reset error flag, see ad3552r manual, rev B table 38. */ ++ ret = ad3552r_write_reg(dac, AD3552R_REG_ADDR_ERR_STATUS, ++ AD3552R_MASK_RESET_STATUS); ++ if (ret) ++ return ret; ++ + return ad3552r_update_reg_field(dac, + addr_mask_map[AD3552R_ADDR_ASCENSION][0], + addr_mask_map[AD3552R_ADDR_ASCENSION][1], diff --git a/queue-6.12/iio-filter-admv8818-force-initialization-of-sdo.patch b/queue-6.12/iio-filter-admv8818-force-initialization-of-sdo.patch new file mode 100644 index 0000000000..5f1c8ced55 --- /dev/null +++ b/queue-6.12/iio-filter-admv8818-force-initialization-of-sdo.patch @@ -0,0 +1,56 @@ +From cc2c3540d9477a9931fb0fd851fcaeba524a5b35 Mon Sep 17 00:00:00 2001 +From: Sam Winchenbach +Date: Mon, 3 Feb 2025 13:34:34 +0000 +Subject: iio: filter: admv8818: Force initialization of SDO + +From: Sam Winchenbach + +commit cc2c3540d9477a9931fb0fd851fcaeba524a5b35 upstream. + +When a weak pull-up is present on the SDO line, regmap_update_bits fails +to write both the SOFTRESET and SDOACTIVE bits because it incorrectly +reads them as already set. + +Since the soft reset disables the SDO line, performing a +read-modify-write operation on ADI_SPI_CONFIG_A to enable the SDO line +doesn't make sense. This change directly writes to the register instead +of using regmap_update_bits. + +Fixes: f34fe888ad05 ("iio:filter:admv8818: add support for ADMV8818") +Signed-off-by: Sam Winchenbach +Link: https://patch.msgid.link/SA1P110MB106904C961B0F3FAFFED74C0BCF5A@SA1P110MB1069.NAMP110.PROD.OUTLOOK.COM +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/filter/admv8818.c | 14 ++++---------- + 1 file changed, 4 insertions(+), 10 deletions(-) + +--- a/drivers/iio/filter/admv8818.c ++++ b/drivers/iio/filter/admv8818.c +@@ -574,21 +574,15 @@ static int admv8818_init(struct admv8818 + struct spi_device *spi = st->spi; + unsigned int chip_id; + +- ret = regmap_update_bits(st->regmap, ADMV8818_REG_SPI_CONFIG_A, +- ADMV8818_SOFTRESET_N_MSK | +- ADMV8818_SOFTRESET_MSK, +- FIELD_PREP(ADMV8818_SOFTRESET_N_MSK, 1) | +- FIELD_PREP(ADMV8818_SOFTRESET_MSK, 1)); ++ ret = regmap_write(st->regmap, ADMV8818_REG_SPI_CONFIG_A, ++ ADMV8818_SOFTRESET_N_MSK | ADMV8818_SOFTRESET_MSK); + if (ret) { + dev_err(&spi->dev, "ADMV8818 Soft Reset failed.\n"); + return ret; + } + +- ret = regmap_update_bits(st->regmap, ADMV8818_REG_SPI_CONFIG_A, +- ADMV8818_SDOACTIVE_N_MSK | +- ADMV8818_SDOACTIVE_MSK, +- FIELD_PREP(ADMV8818_SDOACTIVE_N_MSK, 1) | +- FIELD_PREP(ADMV8818_SDOACTIVE_MSK, 1)); ++ ret = regmap_write(st->regmap, ADMV8818_REG_SPI_CONFIG_A, ++ ADMV8818_SDOACTIVE_N_MSK | ADMV8818_SDOACTIVE_MSK); + if (ret) { + dev_err(&spi->dev, "ADMV8818 SDO Enable failed.\n"); + return ret; diff --git a/queue-6.12/iio-light-apds9306-fix-max_scale_nano-values.patch b/queue-6.12/iio-light-apds9306-fix-max_scale_nano-values.patch new file mode 100644 index 0000000000..70a3a7c139 --- /dev/null +++ b/queue-6.12/iio-light-apds9306-fix-max_scale_nano-values.patch @@ -0,0 +1,51 @@ +From a96d3e2beca0e51c8444d0a3b6b3ec484c4c5a8f Mon Sep 17 00:00:00 2001 +From: Javier Carrasco +Date: Sun, 12 Jan 2025 01:08:11 +0100 +Subject: iio: light: apds9306: fix max_scale_nano values +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Javier Carrasco + +commit a96d3e2beca0e51c8444d0a3b6b3ec484c4c5a8f upstream. + +The two provided max_scale_nano values must be multiplied by 100 and 10 +respectively to achieve nano units. According to the comments: + +Max scale for apds0306 is 16.326432 → the fractional part is 0.326432, +which is 326432000 in NANO. The current value is 3264320. + +Max scale for apds0306-065 is 14.09721 → the fractional part is 0.09712, +which is 97120000 in NANO. The current value is 9712000. + +Update max_scale_nano initialization to use the right NANO fractional +parts. + +Cc: stable@vger.kernel.org +Fixes: 620d1e6c7a3f ("iio: light: Add support for APDS9306 Light Sensor") +Signed-off-by: Javier Carrasco +Tested-by: subhajit.ghosh@tweaklogic.com +Link: https://patch.msgid.link/20250112-apds9306_nano_vals-v1-1-82fb145d0b16@gmail.com +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/light/apds9306.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/iio/light/apds9306.c ++++ b/drivers/iio/light/apds9306.c +@@ -108,11 +108,11 @@ static const struct part_id_gts_multipli + { + .part_id = 0xB1, + .max_scale_int = 16, +- .max_scale_nano = 3264320, ++ .max_scale_nano = 326432000, + }, { + .part_id = 0xB3, + .max_scale_int = 14, +- .max_scale_nano = 9712000, ++ .max_scale_nano = 97120000, + }, + }; + diff --git a/queue-6.12/intel_th-pci-add-arrow-lake-support.patch b/queue-6.12/intel_th-pci-add-arrow-lake-support.patch new file mode 100644 index 0000000000..05c2bb4c7a --- /dev/null +++ b/queue-6.12/intel_th-pci-add-arrow-lake-support.patch @@ -0,0 +1,35 @@ +From b5edccae9f447a92d475267d94c33f4926963eec Mon Sep 17 00:00:00 2001 +From: Pawel Chmielewski +Date: Tue, 11 Feb 2025 20:50:15 +0200 +Subject: intel_th: pci: Add Arrow Lake support + +From: Pawel Chmielewski + +commit b5edccae9f447a92d475267d94c33f4926963eec upstream. + +Add support for the Trace Hub in Arrow Lake. + +Signed-off-by: Pawel Chmielewski +Signed-off-by: Alexander Shishkin +Reviewed-by: Andy Shevchenko +Cc: stable@kernel.org +Link: https://lore.kernel.org/r/20250211185017.1759193-4-alexander.shishkin@linux.intel.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/hwtracing/intel_th/pci.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/drivers/hwtracing/intel_th/pci.c ++++ b/drivers/hwtracing/intel_th/pci.c +@@ -330,6 +330,11 @@ static const struct pci_device_id intel_ + .driver_data = (kernel_ulong_t)&intel_th_2x, + }, + { ++ /* Arrow Lake */ ++ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x7724), ++ .driver_data = (kernel_ulong_t)&intel_th_2x, ++ }, ++ { + /* Alder Lake CPU */ + PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x466f), + .driver_data = (kernel_ulong_t)&intel_th_2x, diff --git a/queue-6.12/intel_th-pci-add-panther-lake-h-support.patch b/queue-6.12/intel_th-pci-add-panther-lake-h-support.patch new file mode 100644 index 0000000000..748e3ae9e7 --- /dev/null +++ b/queue-6.12/intel_th-pci-add-panther-lake-h-support.patch @@ -0,0 +1,34 @@ +From a70034d6c0d5f3cdee40bb00a578e17fd2ebe426 Mon Sep 17 00:00:00 2001 +From: Alexander Shishkin +Date: Tue, 11 Feb 2025 20:50:16 +0200 +Subject: intel_th: pci: Add Panther Lake-H support + +From: Alexander Shishkin + +commit a70034d6c0d5f3cdee40bb00a578e17fd2ebe426 upstream. + +Add support for the Trace Hub in Panther Lake-H. + +Signed-off-by: Alexander Shishkin +Reviewed-by: Andy Shevchenko +Cc: stable@kernel.org +Link: https://lore.kernel.org/r/20250211185017.1759193-5-alexander.shishkin@linux.intel.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/hwtracing/intel_th/pci.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/drivers/hwtracing/intel_th/pci.c ++++ b/drivers/hwtracing/intel_th/pci.c +@@ -335,6 +335,11 @@ static const struct pci_device_id intel_ + .driver_data = (kernel_ulong_t)&intel_th_2x, + }, + { ++ /* Panther Lake-H */ ++ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0xe324), ++ .driver_data = (kernel_ulong_t)&intel_th_2x, ++ }, ++ { + /* Alder Lake CPU */ + PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x466f), + .driver_data = (kernel_ulong_t)&intel_th_2x, diff --git a/queue-6.12/intel_th-pci-add-panther-lake-p-u-support.patch b/queue-6.12/intel_th-pci-add-panther-lake-p-u-support.patch new file mode 100644 index 0000000000..98128db206 --- /dev/null +++ b/queue-6.12/intel_th-pci-add-panther-lake-p-u-support.patch @@ -0,0 +1,34 @@ +From 49114ff05770264ae233f50023fc64a719a9dcf9 Mon Sep 17 00:00:00 2001 +From: Alexander Shishkin +Date: Tue, 11 Feb 2025 20:50:17 +0200 +Subject: intel_th: pci: Add Panther Lake-P/U support + +From: Alexander Shishkin + +commit 49114ff05770264ae233f50023fc64a719a9dcf9 upstream. + +Add support for the Trace Hub in Panther Lake-P/U. + +Signed-off-by: Alexander Shishkin +Reviewed-by: Andy Shevchenko +Cc: stable@kernel.org +Link: https://lore.kernel.org/r/20250211185017.1759193-6-alexander.shishkin@linux.intel.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/hwtracing/intel_th/pci.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/drivers/hwtracing/intel_th/pci.c ++++ b/drivers/hwtracing/intel_th/pci.c +@@ -340,6 +340,11 @@ static const struct pci_device_id intel_ + .driver_data = (kernel_ulong_t)&intel_th_2x, + }, + { ++ /* Panther Lake-P/U */ ++ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0xe424), ++ .driver_data = (kernel_ulong_t)&intel_th_2x, ++ }, ++ { + /* Alder Lake CPU */ + PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x466f), + .driver_data = (kernel_ulong_t)&intel_th_2x, diff --git a/queue-6.12/kvm-svm-drop-debugctl-from-guest-s-effective-value.patch b/queue-6.12/kvm-svm-drop-debugctl-from-guest-s-effective-value.patch new file mode 100644 index 0000000000..ece2d3cfc0 --- /dev/null +++ b/queue-6.12/kvm-svm-drop-debugctl-from-guest-s-effective-value.patch @@ -0,0 +1,84 @@ +From ee89e8013383d50a27ea9bf3c8a69eed6799856f Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Thu, 27 Feb 2025 14:24:06 -0800 +Subject: KVM: SVM: Drop DEBUGCTL[5:2] from guest's effective value +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Sean Christopherson + +commit ee89e8013383d50a27ea9bf3c8a69eed6799856f upstream. + +Drop bits 5:2 from the guest's effective DEBUGCTL value, as AMD changed +the architectural behavior of the bits and broke backwards compatibility. +On CPUs without BusLockTrap (or at least, in APMs from before ~2023), +bits 5:2 controlled the behavior of external pins: + + Performance-Monitoring/Breakpoint Pin-Control (PBi)—Bits 5:2, read/write. + Software uses thesebits to control the type of information reported by + the four external performance-monitoring/breakpoint pins on the + processor. When a PBi bit is cleared to 0, the corresponding external pin + (BPi) reports performance-monitor information. When a PBi bit is set to + 1, the corresponding external pin (BPi) reports breakpoint information. + +With the introduction of BusLockTrap, presumably to be compatible with +Intel CPUs, AMD redefined bit 2 to be BLCKDB: + + Bus Lock #DB Trap (BLCKDB)—Bit 2, read/write. Software sets this bit to + enable generation of a #DB trap following successful execution of a bus + lock when CPL is > 0. + +and redefined bits 5:3 (and bit 6) as "6:3 Reserved MBZ". + +Ideally, KVM would treat bits 5:2 as reserved. Defer that change to a +feature cleanup to avoid breaking existing guest in LTS kernels. For now, +drop the bits to retain backwards compatibility (of a sort). + +Note, dropping bits 5:2 is still a guest-visible change, e.g. if the guest +is enabling LBRs *and* the legacy PBi bits, then the state of the PBi bits +is visible to the guest, whereas now the guest will always see '0'. + +Reported-by: Ravi Bangoria +Cc: stable@vger.kernel.org +Reviewed-and-tested-by: Ravi Bangoria +Link: https://lore.kernel.org/r/20250227222411.3490595-2-seanjc@google.com +Signed-off-by: Sean Christopherson +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/svm/svm.c | 12 ++++++++++++ + arch/x86/kvm/svm/svm.h | 2 +- + 2 files changed, 13 insertions(+), 1 deletion(-) + +--- a/arch/x86/kvm/svm/svm.c ++++ b/arch/x86/kvm/svm/svm.c +@@ -3167,6 +3167,18 @@ static int svm_set_msr(struct kvm_vcpu * + kvm_pr_unimpl_wrmsr(vcpu, ecx, data); + break; + } ++ ++ /* ++ * AMD changed the architectural behavior of bits 5:2. On CPUs ++ * without BusLockTrap, bits 5:2 control "external pins", but ++ * on CPUs that support BusLockDetect, bit 2 enables BusLockTrap ++ * and bits 5:3 are reserved-to-zero. Sadly, old KVM allowed ++ * the guest to set bits 5:2 despite not actually virtualizing ++ * Performance-Monitoring/Breakpoint external pins. Drop bits ++ * 5:2 for backwards compatibility. ++ */ ++ data &= ~GENMASK(5, 2); ++ + if (data & DEBUGCTL_RESERVED_BITS) + return 1; + +--- a/arch/x86/kvm/svm/svm.h ++++ b/arch/x86/kvm/svm/svm.h +@@ -591,7 +591,7 @@ static inline bool is_vnmi_enabled(struc + /* svm.c */ + #define MSR_INVALID 0xffffffffU + +-#define DEBUGCTL_RESERVED_BITS (~(0x3fULL)) ++#define DEBUGCTL_RESERVED_BITS (~(DEBUGCTLMSR_BTF | DEBUGCTLMSR_LBR)) + + extern bool dump_invalid_vmcb; + diff --git a/queue-6.12/kvm-svm-manually-context-switch-debugctl-if-lbr-virtualization-is-disabled.patch b/queue-6.12/kvm-svm-manually-context-switch-debugctl-if-lbr-virtualization-is-disabled.patch new file mode 100644 index 0000000000..053d9fee6c --- /dev/null +++ b/queue-6.12/kvm-svm-manually-context-switch-debugctl-if-lbr-virtualization-is-disabled.patch @@ -0,0 +1,88 @@ +From 433265870ab3455b418885bff48fa5fd02f7e448 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Thu, 27 Feb 2025 14:24:09 -0800 +Subject: KVM: SVM: Manually context switch DEBUGCTL if LBR virtualization is disabled + +From: Sean Christopherson + +commit 433265870ab3455b418885bff48fa5fd02f7e448 upstream. + +Manually load the guest's DEBUGCTL prior to VMRUN (and restore the host's +value on #VMEXIT) if it diverges from the host's value and LBR +virtualization is disabled, as hardware only context switches DEBUGCTL if +LBR virtualization is fully enabled. Running the guest with the host's +value has likely been mildly problematic for quite some time, e.g. it will +result in undesirable behavior if BTF diverges (with the caveat that KVM +now suppresses guest BTF due to lack of support). + +But the bug became fatal with the introduction of Bus Lock Trap ("Detect" +in kernel paralance) support for AMD (commit 408eb7417a92 +("x86/bus_lock: Add support for AMD")), as a bus lock in the guest will +trigger an unexpected #DB. + +Note, suppressing the bus lock #DB, i.e. simply resuming the guest without +injecting a #DB, is not an option. It wouldn't address the general issue +with DEBUGCTL, e.g. for things like BTF, and there are other guest-visible +side effects if BusLockTrap is left enabled. + +If BusLockTrap is disabled, then DR6.BLD is reserved-to-1; any attempts to +clear it by software are ignored. But if BusLockTrap is enabled, software +can clear DR6.BLD: + + Software enables bus lock trap by setting DebugCtl MSR[BLCKDB] (bit 2) + to 1. When bus lock trap is enabled, ... The processor indicates that + this #DB was caused by a bus lock by clearing DR6[BLD] (bit 11). DR6[11] + previously had been defined to be always 1. + +and clearing DR6.BLD is "sticky" in that it's not set (i.e. lowered) by +other #DBs: + + All other #DB exceptions leave DR6[BLD] unmodified + +E.g. leaving BusLockTrap enable can confuse a legacy guest that writes '0' +to reset DR6. + +Reported-by: rangemachine@gmail.com +Reported-by: whanos@sergal.fun +Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219787 +Closes: https://lore.kernel.org/all/bug-219787-28872@https.bugzilla.kernel.org%2F +Cc: Ravi Bangoria +Cc: stable@vger.kernel.org +Reviewed-and-tested-by: Ravi Bangoria +Link: https://lore.kernel.org/r/20250227222411.3490595-5-seanjc@google.com +Signed-off-by: Sean Christopherson +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/svm/svm.c | 14 ++++++++++++++ + 1 file changed, 14 insertions(+) + +--- a/arch/x86/kvm/svm/svm.c ++++ b/arch/x86/kvm/svm/svm.c +@@ -4275,6 +4275,16 @@ static __no_kcsan fastpath_t svm_vcpu_ru + clgi(); + kvm_load_guest_xsave_state(vcpu); + ++ /* ++ * Hardware only context switches DEBUGCTL if LBR virtualization is ++ * enabled. Manually load DEBUGCTL if necessary (and restore it after ++ * VM-Exit), as running with the host's DEBUGCTL can negatively affect ++ * guest state and can even be fatal, e.g. due to Bus Lock Detect. ++ */ ++ if (!(svm->vmcb->control.virt_ext & LBR_CTL_ENABLE_MASK) && ++ vcpu->arch.host_debugctl != svm->vmcb->save.dbgctl) ++ update_debugctlmsr(svm->vmcb->save.dbgctl); ++ + kvm_wait_lapic_expire(vcpu); + + /* +@@ -4302,6 +4312,10 @@ static __no_kcsan fastpath_t svm_vcpu_ru + if (unlikely(svm->vmcb->control.exit_code == SVM_EXIT_NMI)) + kvm_before_interrupt(vcpu, KVM_HANDLING_NMI); + ++ if (!(svm->vmcb->control.virt_ext & LBR_CTL_ENABLE_MASK) && ++ vcpu->arch.host_debugctl != svm->vmcb->save.dbgctl) ++ update_debugctlmsr(vcpu->arch.host_debugctl); ++ + kvm_load_host_xsave_state(vcpu); + stgi(); + diff --git a/queue-6.12/kvm-svm-save-host-dr-masks-on-cpus-with-debugswap.patch b/queue-6.12/kvm-svm-save-host-dr-masks-on-cpus-with-debugswap.patch new file mode 100644 index 0000000000..1c5c7177ea --- /dev/null +++ b/queue-6.12/kvm-svm-save-host-dr-masks-on-cpus-with-debugswap.patch @@ -0,0 +1,86 @@ +From b2653cd3b75f62f29b72df4070e20357acb52bc4 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Wed, 26 Feb 2025 17:25:32 -0800 +Subject: KVM: SVM: Save host DR masks on CPUs with DebugSwap + +From: Sean Christopherson + +commit b2653cd3b75f62f29b72df4070e20357acb52bc4 upstream. + +When running SEV-SNP guests on a CPU that supports DebugSwap, always save +the host's DR0..DR3 mask MSR values irrespective of whether or not +DebugSwap is enabled, to ensure the host values aren't clobbered by the +CPU. And for now, also save DR0..DR3, even though doing so isn't +necessary (see below). + +SVM_VMGEXIT_AP_CREATE is deeply flawed in that it allows the *guest* to +create a VMSA with guest-controlled SEV_FEATURES. A well behaved guest +can inform the hypervisor, i.e. KVM, of its "requested" features, but on +CPUs without ALLOWED_SEV_FEATURES support, nothing prevents the guest from +lying about which SEV features are being enabled (or not!). + +If a misbehaving guest enables DebugSwap in a secondary vCPU's VMSA, the +CPU will load the DR0..DR3 mask MSRs on #VMEXIT, i.e. will clobber the +MSRs with '0' if KVM doesn't save its desired value. + +Note, DR0..DR3 themselves are "ok", as DR7 is reset on #VMEXIT, and KVM +restores all DRs in common x86 code as needed via hw_breakpoint_restore(). +I.e. there is no risk of host DR0..DR3 being clobbered (when it matters). +However, there is a flaw in the opposite direction; because the guest can +lie about enabling DebugSwap, i.e. can *disable* DebugSwap without KVM's +knowledge, KVM must not rely on the CPU to restore DRs. Defer fixing +that wart, as it's more of a documentation issue than a bug in the code. + +Note, KVM added support for DebugSwap on commit d1f85fbe836e ("KVM: SEV: +Enable data breakpoints in SEV-ES"), but that is not an appropriate Fixes, +as the underlying flaw exists in hardware, not in KVM. I.e. all kernels +that support SEV-SNP need to be patched, not just kernels with KVM's full +support for DebugSwap (ignoring that DebugSwap support landed first). + +Opportunistically fix an incorrect statement in the comment; on CPUs +without DebugSwap, the CPU does NOT save or load debug registers, i.e. + +Fixes: e366f92ea99e ("KVM: SEV: Support SEV-SNP AP Creation NAE event") +Cc: stable@vger.kernel.org +Cc: Naveen N Rao +Cc: Kim Phillips +Cc: Tom Lendacky +Cc: Alexey Kardashevskiy +Reviewed-by: Tom Lendacky +Link: https://lore.kernel.org/r/20250227012541.3234589-2-seanjc@google.com +Signed-off-by: Sean Christopherson +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/svm/sev.c | 13 ++++++++++--- + 1 file changed, 10 insertions(+), 3 deletions(-) + +--- a/arch/x86/kvm/svm/sev.c ++++ b/arch/x86/kvm/svm/sev.c +@@ -4579,6 +4579,8 @@ void sev_es_vcpu_reset(struct vcpu_svm * + + void sev_es_prepare_switch_to_guest(struct vcpu_svm *svm, struct sev_es_save_area *hostsa) + { ++ struct kvm *kvm = svm->vcpu.kvm; ++ + /* + * All host state for SEV-ES guests is categorized into three swap types + * based on how it is handled by hardware during a world switch: +@@ -4602,10 +4604,15 @@ void sev_es_prepare_switch_to_guest(stru + + /* + * If DebugSwap is enabled, debug registers are loaded but NOT saved by +- * the CPU (Type-B). If DebugSwap is disabled/unsupported, the CPU both +- * saves and loads debug registers (Type-A). ++ * the CPU (Type-B). If DebugSwap is disabled/unsupported, the CPU does ++ * not save or load debug registers. Sadly, on CPUs without ++ * ALLOWED_SEV_FEATURES, KVM can't prevent SNP guests from enabling ++ * DebugSwap on secondary vCPUs without KVM's knowledge via "AP Create". ++ * Save all registers if DebugSwap is supported to prevent host state ++ * from being clobbered by a misbehaving guest. + */ +- if (sev_vcpu_has_debug_swap(svm)) { ++ if (sev_vcpu_has_debug_swap(svm) || ++ (sev_snp_guest(kvm) && cpu_feature_enabled(X86_FEATURE_DEBUG_SWAP))) { + hostsa->dr0 = native_get_debugreg(0); + hostsa->dr1 = native_get_debugreg(1); + hostsa->dr2 = native_get_debugreg(2); diff --git a/queue-6.12/kvm-svm-set-rflags.if-1-in-c-code-to-get-vmrun-out-of-the-sti-shadow.patch b/queue-6.12/kvm-svm-set-rflags.if-1-in-c-code-to-get-vmrun-out-of-the-sti-shadow.patch new file mode 100644 index 0000000000..f7281edf90 --- /dev/null +++ b/queue-6.12/kvm-svm-set-rflags.if-1-in-c-code-to-get-vmrun-out-of-the-sti-shadow.patch @@ -0,0 +1,114 @@ +From be45bc4eff33d9a7dae84a2150f242a91a617402 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Mon, 24 Feb 2025 08:54:41 -0800 +Subject: KVM: SVM: Set RFLAGS.IF=1 in C code, to get VMRUN out of the STI shadow + +From: Sean Christopherson + +commit be45bc4eff33d9a7dae84a2150f242a91a617402 upstream. + +Enable/disable local IRQs, i.e. set/clear RFLAGS.IF, in the common +svm_vcpu_enter_exit() just after/before guest_state_{enter,exit}_irqoff() +so that VMRUN is not executed in an STI shadow. AMD CPUs have a quirk +(some would say "bug"), where the STI shadow bleeds into the guest's +intr_state field if a #VMEXIT occurs during injection of an event, i.e. if +the VMRUN doesn't complete before the subsequent #VMEXIT. + +The spurious "interrupts masked" state is relatively benign, as it only +occurs during event injection and is transient. Because KVM is already +injecting an event, the guest can't be in HLT, and if KVM is querying IRQ +blocking for injection, then KVM would need to force an immediate exit +anyways since injecting multiple events is impossible. + +However, because KVM copies int_state verbatim from vmcb02 to vmcb12, the +spurious STI shadow is visible to L1 when running a nested VM, which can +trip sanity checks, e.g. in VMware's VMM. + +Hoist the STI+CLI all the way to C code, as the aforementioned calls to +guest_state_{enter,exit}_irqoff() already inform lockdep that IRQs are +enabled/disabled, and taking a fault on VMRUN with RFLAGS.IF=1 is already +possible. I.e. if there's kernel code that is confused by running with +RFLAGS.IF=1, then it's already a problem. In practice, since GIF=0 also +blocks NMIs, the only change in exposure to non-KVM code (relative to +surrounding VMRUN with STI+CLI) is exception handling code, and except for +the kvm_rebooting=1 case, all exception in the core VM-Enter/VM-Exit path +are fatal. + +Use the "raw" variants to enable/disable IRQs to avoid tracing in the +"no instrumentation" code; the guest state helpers also take care of +tracing IRQ state. + +Oppurtunstically document why KVM needs to do STI in the first place. + +Reported-by: Doug Covelli +Closes: https://lore.kernel.org/all/CADH9ctBs1YPmE4aCfGPNBwA10cA8RuAk2gO7542DjMZgs4uzJQ@mail.gmail.com +Fixes: f14eec0a3203 ("KVM: SVM: move more vmentry code to assembly") +Cc: stable@vger.kernel.org +Reviewed-by: Jim Mattson +Link: https://lore.kernel.org/r/20250224165442.2338294-2-seanjc@google.com +Signed-off-by: Sean Christopherson +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/svm/svm.c | 14 ++++++++++++++ + arch/x86/kvm/svm/vmenter.S | 10 +--------- + 2 files changed, 15 insertions(+), 9 deletions(-) + +--- a/arch/x86/kvm/svm/svm.c ++++ b/arch/x86/kvm/svm/svm.c +@@ -4176,6 +4176,18 @@ static noinstr void svm_vcpu_enter_exit( + + guest_state_enter_irqoff(); + ++ /* ++ * Set RFLAGS.IF prior to VMRUN, as the host's RFLAGS.IF at the time of ++ * VMRUN controls whether or not physical IRQs are masked (KVM always ++ * runs with V_INTR_MASKING_MASK). Toggle RFLAGS.IF here to avoid the ++ * temptation to do STI+VMRUN+CLI, as AMD CPUs bleed the STI shadow ++ * into guest state if delivery of an event during VMRUN triggers a ++ * #VMEXIT, and the guest_state transitions already tell lockdep that ++ * IRQs are being enabled/disabled. Note! GIF=0 for the entirety of ++ * this path, so IRQs aren't actually unmasked while running host code. ++ */ ++ raw_local_irq_enable(); ++ + amd_clear_divider(); + + if (sev_es_guest(vcpu->kvm)) +@@ -4184,6 +4196,8 @@ static noinstr void svm_vcpu_enter_exit( + else + __svm_vcpu_run(svm, spec_ctrl_intercepted); + ++ raw_local_irq_disable(); ++ + guest_state_exit_irqoff(); + } + +--- a/arch/x86/kvm/svm/vmenter.S ++++ b/arch/x86/kvm/svm/vmenter.S +@@ -170,12 +170,8 @@ SYM_FUNC_START(__svm_vcpu_run) + mov VCPU_RDI(%_ASM_DI), %_ASM_DI + + /* Enter guest mode */ +- sti +- + 3: vmrun %_ASM_AX + 4: +- cli +- + /* Pop @svm to RAX while it's the only available register. */ + pop %_ASM_AX + +@@ -340,12 +336,8 @@ SYM_FUNC_START(__svm_sev_es_vcpu_run) + mov KVM_VMCB_pa(%rax), %rax + + /* Enter guest mode */ +- sti +- + 1: vmrun %rax +- +-2: cli +- ++2: + /* IMPORTANT: Stuff the RSB immediately after VM-Exit, before RET! */ + FILL_RETURN_BUFFER %rax, RSB_CLEAR_LOOPS, X86_FEATURE_RSB_VMEXIT + diff --git a/queue-6.12/kvm-svm-suppress-debugctl.btf-on-amd.patch b/queue-6.12/kvm-svm-suppress-debugctl.btf-on-amd.patch new file mode 100644 index 0000000000..3c52280a62 --- /dev/null +++ b/queue-6.12/kvm-svm-suppress-debugctl.btf-on-amd.patch @@ -0,0 +1,64 @@ +From d0eac42f5cecce009d315655bee341304fbe075e Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Thu, 27 Feb 2025 14:24:07 -0800 +Subject: KVM: SVM: Suppress DEBUGCTL.BTF on AMD + +From: Sean Christopherson + +commit d0eac42f5cecce009d315655bee341304fbe075e upstream. + +Mark BTF as reserved in DEBUGCTL on AMD, as KVM doesn't actually support +BTF, and fully enabling BTF virtualization is non-trivial due to +interactions with the emulator, guest_debug, #DB interception, nested SVM, +etc. + +Don't inject #GP if the guest attempts to set BTF, as there's no way to +communicate lack of support to the guest, and instead suppress the flag +and treat the WRMSR as (partially) unsupported. + +In short, make KVM behave the same on AMD and Intel (VMX already squashes +BTF). + +Note, due to other bugs in KVM's handling of DEBUGCTL, the only way BTF +has "worked" in any capacity is if the guest simultaneously enables LBRs. + +Reported-by: Ravi Bangoria +Cc: stable@vger.kernel.org +Reviewed-and-tested-by: Ravi Bangoria +Link: https://lore.kernel.org/r/20250227222411.3490595-3-seanjc@google.com +Signed-off-by: Sean Christopherson +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/svm/svm.c | 9 +++++++++ + arch/x86/kvm/svm/svm.h | 2 +- + 2 files changed, 10 insertions(+), 1 deletion(-) + +--- a/arch/x86/kvm/svm/svm.c ++++ b/arch/x86/kvm/svm/svm.c +@@ -3179,6 +3179,15 @@ static int svm_set_msr(struct kvm_vcpu * + */ + data &= ~GENMASK(5, 2); + ++ /* ++ * Suppress BTF as KVM doesn't virtualize BTF, but there's no ++ * way to communicate lack of support to the guest. ++ */ ++ if (data & DEBUGCTLMSR_BTF) { ++ kvm_pr_unimpl_wrmsr(vcpu, MSR_IA32_DEBUGCTLMSR, data); ++ data &= ~DEBUGCTLMSR_BTF; ++ } ++ + if (data & DEBUGCTL_RESERVED_BITS) + return 1; + +--- a/arch/x86/kvm/svm/svm.h ++++ b/arch/x86/kvm/svm/svm.h +@@ -591,7 +591,7 @@ static inline bool is_vnmi_enabled(struc + /* svm.c */ + #define MSR_INVALID 0xffffffffU + +-#define DEBUGCTL_RESERVED_BITS (~(DEBUGCTLMSR_BTF | DEBUGCTLMSR_LBR)) ++#define DEBUGCTL_RESERVED_BITS (~DEBUGCTLMSR_LBR) + + extern bool dump_invalid_vmcb; + diff --git a/queue-6.12/kvm-x86-explicitly-zero-eax-and-ebx-when-perfmon_v2-isn-t-supported-by-kvm.patch b/queue-6.12/kvm-x86-explicitly-zero-eax-and-ebx-when-perfmon_v2-isn-t-supported-by-kvm.patch new file mode 100644 index 0000000000..398f6c2074 --- /dev/null +++ b/queue-6.12/kvm-x86-explicitly-zero-eax-and-ebx-when-perfmon_v2-isn-t-supported-by-kvm.patch @@ -0,0 +1,43 @@ +From f9dc8fb3afc968042bdaf4b6e445a9272071c9f3 Mon Sep 17 00:00:00 2001 +From: Xiaoyao Li +Date: Tue, 4 Mar 2025 03:23:14 -0500 +Subject: KVM: x86: Explicitly zero EAX and EBX when PERFMON_V2 isn't supported by KVM + +From: Xiaoyao Li + +commit f9dc8fb3afc968042bdaf4b6e445a9272071c9f3 upstream. + +Fix a goof where KVM sets CPUID.0x80000022.EAX to CPUID.0x80000022.EBX +instead of zeroing both when PERFMON_V2 isn't supported by KVM. In +practice, barring a buggy CPU (or vCPU model when running nested) only the +!enable_pmu case is affected, as KVM always supports PERFMON_V2 if it's +available in hardware, i.e. CPUID.0x80000022.EBX will be '0' if PERFMON_V2 +is unsupported. + +For the !enable_pmu case, the bug is relatively benign as KVM will refuse +to enable PMU capabilities, but a VMM that reflects KVM's supported CPUID +into the guest could inadvertently induce #GPs in the guest due to +advertising support for MSRs that KVM refuses to emulate. + +Fixes: 94cdeebd8211 ("KVM: x86/cpuid: Add AMD CPUID ExtPerfMonAndDbg leaf 0x80000022") +Signed-off-by: Xiaoyao Li +Link: https://lore.kernel.org/r/20250304082314.472202-3-xiaoyao.li@intel.com +[sean: massage shortlog and changelog, tag for stable] +Cc: stable@vger.kernel.org +Signed-off-by: Sean Christopherson +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/cpuid.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/kvm/cpuid.c ++++ b/arch/x86/kvm/cpuid.c +@@ -1387,7 +1387,7 @@ static inline int __do_cpuid_func(struct + + entry->ecx = entry->edx = 0; + if (!enable_pmu || !kvm_cpu_cap_has(X86_FEATURE_PERFMON_V2)) { +- entry->eax = entry->ebx; ++ entry->eax = entry->ebx = 0; + break; + } + diff --git a/queue-6.12/kvm-x86-snapshot-the-host-s-debugctl-after-disabling-irqs.patch b/queue-6.12/kvm-x86-snapshot-the-host-s-debugctl-after-disabling-irqs.patch new file mode 100644 index 0000000000..f88f948c90 --- /dev/null +++ b/queue-6.12/kvm-x86-snapshot-the-host-s-debugctl-after-disabling-irqs.patch @@ -0,0 +1,43 @@ +From 189ecdb3e112da703ac0699f4ec76aa78122f911 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Thu, 27 Feb 2025 14:24:10 -0800 +Subject: KVM: x86: Snapshot the host's DEBUGCTL after disabling IRQs + +From: Sean Christopherson + +commit 189ecdb3e112da703ac0699f4ec76aa78122f911 upstream. + +Snapshot the host's DEBUGCTL after disabling IRQs, as perf can toggle +debugctl bits from IRQ context, e.g. when enabling/disabling events via +smp_call_function_single(). Taking the snapshot (long) before IRQs are +disabled could result in KVM effectively clobbering DEBUGCTL due to using +a stale snapshot. + +Cc: stable@vger.kernel.org +Reviewed-and-tested-by: Ravi Bangoria +Link: https://lore.kernel.org/r/20250227222411.3490595-6-seanjc@google.com +Signed-off-by: Sean Christopherson +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/x86.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/arch/x86/kvm/x86.c ++++ b/arch/x86/kvm/x86.c +@@ -4993,7 +4993,6 @@ void kvm_arch_vcpu_load(struct kvm_vcpu + + /* Save host pkru register if supported */ + vcpu->arch.host_pkru = read_pkru(); +- vcpu->arch.host_debugctl = get_debugctlmsr(); + + /* Apply any externally detected TSC adjustments (due to suspend) */ + if (unlikely(vcpu->arch.tsc_offset_adjustment)) { +@@ -10965,6 +10964,8 @@ static int vcpu_enter_guest(struct kvm_v + set_debugreg(0, 7); + } + ++ vcpu->arch.host_debugctl = get_debugctlmsr(); ++ + guest_timing_enter_irqoff(); + + for (;;) { diff --git a/queue-6.12/kvm-x86-snapshot-the-host-s-debugctl-in-common-x86.patch b/queue-6.12/kvm-x86-snapshot-the-host-s-debugctl-in-common-x86.patch new file mode 100644 index 0000000000..32826de00a --- /dev/null +++ b/queue-6.12/kvm-x86-snapshot-the-host-s-debugctl-in-common-x86.patch @@ -0,0 +1,90 @@ +From fb71c795935652fa20eaf9517ca9547f5af99a76 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Thu, 27 Feb 2025 14:24:08 -0800 +Subject: KVM: x86: Snapshot the host's DEBUGCTL in common x86 + +From: Sean Christopherson + +commit fb71c795935652fa20eaf9517ca9547f5af99a76 upstream. + +Move KVM's snapshot of DEBUGCTL to kvm_vcpu_arch and take the snapshot in +common x86, so that SVM can also use the snapshot. + +Opportunistically change the field to a u64. While bits 63:32 are reserved +on AMD, not mentioned at all in Intel's SDM, and managed as an "unsigned +long" by the kernel, DEBUGCTL is an MSR and therefore a 64-bit value. + +Reviewed-by: Xiaoyao Li +Cc: stable@vger.kernel.org +Reviewed-and-tested-by: Ravi Bangoria +Link: https://lore.kernel.org/r/20250227222411.3490595-4-seanjc@google.com +Signed-off-by: Sean Christopherson +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/include/asm/kvm_host.h | 1 + + arch/x86/kvm/vmx/vmx.c | 8 ++------ + arch/x86/kvm/vmx/vmx.h | 2 -- + arch/x86/kvm/x86.c | 1 + + 4 files changed, 4 insertions(+), 8 deletions(-) + +--- a/arch/x86/include/asm/kvm_host.h ++++ b/arch/x86/include/asm/kvm_host.h +@@ -761,6 +761,7 @@ struct kvm_vcpu_arch { + u32 pkru; + u32 hflags; + u64 efer; ++ u64 host_debugctl; + u64 apic_base; + struct kvm_lapic *apic; /* kernel irqchip context */ + bool load_eoi_exitmap_pending; +--- a/arch/x86/kvm/vmx/vmx.c ++++ b/arch/x86/kvm/vmx/vmx.c +@@ -1515,16 +1515,12 @@ void vmx_vcpu_load_vmcs(struct kvm_vcpu + */ + void vmx_vcpu_load(struct kvm_vcpu *vcpu, int cpu) + { +- struct vcpu_vmx *vmx = to_vmx(vcpu); +- + if (vcpu->scheduled_out && !kvm_pause_in_guest(vcpu->kvm)) + shrink_ple_window(vcpu); + + vmx_vcpu_load_vmcs(vcpu, cpu, NULL); + + vmx_vcpu_pi_load(vcpu, cpu); +- +- vmx->host_debugctlmsr = get_debugctlmsr(); + } + + void vmx_vcpu_put(struct kvm_vcpu *vcpu) +@@ -7454,8 +7450,8 @@ fastpath_t vmx_vcpu_run(struct kvm_vcpu + } + + /* MSR_IA32_DEBUGCTLMSR is zeroed on vmexit. Restore it if needed */ +- if (vmx->host_debugctlmsr) +- update_debugctlmsr(vmx->host_debugctlmsr); ++ if (vcpu->arch.host_debugctl) ++ update_debugctlmsr(vcpu->arch.host_debugctl); + + #ifndef CONFIG_X86_64 + /* +--- a/arch/x86/kvm/vmx/vmx.h ++++ b/arch/x86/kvm/vmx/vmx.h +@@ -339,8 +339,6 @@ struct vcpu_vmx { + /* apic deadline value in host tsc */ + u64 hv_deadline_tsc; + +- unsigned long host_debugctlmsr; +- + /* + * Only bits masked by msr_ia32_feature_control_valid_bits can be set in + * msr_ia32_feature_control. FEAT_CTL_LOCKED is always included +--- a/arch/x86/kvm/x86.c ++++ b/arch/x86/kvm/x86.c +@@ -4993,6 +4993,7 @@ void kvm_arch_vcpu_load(struct kvm_vcpu + + /* Save host pkru register if supported */ + vcpu->arch.host_pkru = read_pkru(); ++ vcpu->arch.host_debugctl = get_debugctlmsr(); + + /* Apply any externally detected TSC adjustments (due to suspend) */ + if (unlikely(vcpu->arch.tsc_offset_adjustment)) { diff --git a/queue-6.12/mei-me-add-panther-lake-p-did.patch b/queue-6.12/mei-me-add-panther-lake-p-did.patch new file mode 100644 index 0000000000..8a98903c0d --- /dev/null +++ b/queue-6.12/mei-me-add-panther-lake-p-did.patch @@ -0,0 +1,44 @@ +From a8e8ffcc3afce2ee5fb70162aeaef3f03573ee1e Mon Sep 17 00:00:00 2001 +From: Alexander Usyskin +Date: Sun, 9 Feb 2025 13:05:50 +0200 +Subject: mei: me: add panther lake P DID + +From: Alexander Usyskin + +commit a8e8ffcc3afce2ee5fb70162aeaef3f03573ee1e upstream. + +Add Panther Lake P device id. + +Cc: stable +Co-developed-by: Tomas Winkler +Signed-off-by: Tomas Winkler +Signed-off-by: Alexander Usyskin +Link: https://lore.kernel.org/r/20250209110550.1582982-1-alexander.usyskin@intel.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/misc/mei/hw-me-regs.h | 2 ++ + drivers/misc/mei/pci-me.c | 2 ++ + 2 files changed, 4 insertions(+) + +--- a/drivers/misc/mei/hw-me-regs.h ++++ b/drivers/misc/mei/hw-me-regs.h +@@ -117,6 +117,8 @@ + + #define MEI_DEV_ID_LNL_M 0xA870 /* Lunar Lake Point M */ + ++#define MEI_DEV_ID_PTL_P 0xE470 /* Panther Lake P */ ++ + /* + * MEI HW Section + */ +--- a/drivers/misc/mei/pci-me.c ++++ b/drivers/misc/mei/pci-me.c +@@ -124,6 +124,8 @@ static const struct pci_device_id mei_me + + {MEI_PCI_DEVICE(MEI_DEV_ID_LNL_M, MEI_ME_PCH15_CFG)}, + ++ {MEI_PCI_DEVICE(MEI_DEV_ID_PTL_P, MEI_ME_PCH15_CFG)}, ++ + /* required last entry */ + {0, } + }; diff --git a/queue-6.12/mei-vsc-use-wakeuphostint-when-getting-the-host-wakeup-gpio.patch b/queue-6.12/mei-vsc-use-wakeuphostint-when-getting-the-host-wakeup-gpio.patch new file mode 100644 index 0000000000..2e7b0e3bf0 --- /dev/null +++ b/queue-6.12/mei-vsc-use-wakeuphostint-when-getting-the-host-wakeup-gpio.patch @@ -0,0 +1,76 @@ +From fdb1ada57cf8b8752cdf54f08709d76d74999544 Mon Sep 17 00:00:00 2001 +From: Hans de Goede +Date: Fri, 14 Feb 2025 22:24:25 +0100 +Subject: mei: vsc: Use "wakeuphostint" when getting the host wakeup GPIO + +From: Hans de Goede + +commit fdb1ada57cf8b8752cdf54f08709d76d74999544 upstream. + +The _CRS ACPI resources table has 2 entries for the host wakeup GPIO, +the first one being a regular GpioIo () resource while the second one +is a GpioInt () resource for the same pin. + +The acpi_gpio_mapping table used by vsc-tp.c maps the first Gpio () +resource to "wakeuphost-gpios" where as the second GpioInt () entry +is mapped to "wakeuphostint-gpios". + +Using "wakeuphost" to request the GPIO as was done until now, means +that the gpiolib-acpi code does not know that the GPIO is active-low +as that info is only available in the GpioInt () entry. + +Things were still working before due to the following happening: + +1. Since the 2 entries point to the same pin they share a struct gpio_desc +2. The SPI core creates the SPI device vsc-tp.c binds to and calls + acpi_dev_gpio_irq_get(). This does use the second entry and sets + FLAG_ACTIVE_LOW in gpio_desc.flags . +3. vsc_tp_probe() requests the "wakeuphost" GPIO and inherits the + active-low flag set by acpi_dev_gpio_irq_get() + +But there is a possible scenario where things do not work: + +1. - 3. happen as above +4. After requesting the "wakeuphost" GPIO, the "resetfw" GPIO is requested + next, but its USB GPIO controller is not available yet, so this call + returns -EPROBE_DEFER. +5. The gpio_desc for "wakeuphost" is put() and during this the active-low + flag is cleared from gpio_desc.flags . +6. Later on vsc_tp_probe() requests the "wakeuphost" GPIO again, but now it + is not marked active-low. + +The difference can also be seen in /sys/kernel/debug/gpio, which contains +the following line for this GPIO: + + gpio-535 ( |wakeuphost ) in hi IRQ ACTIVE LOW + +If the second scenario is hit the "ACTIVE LOW" at the end disappears and +things do not work. + +Fix this by requesting the GPIO through the "wakeuphostint" mapping instead +which provides active-low info without relying on acpi_dev_gpio_irq_get() +pre-populating this info in the gpio_desc. + +Link: https://bugzilla.redhat.com/show_bug.cgi?id=2316918 +Signed-off-by: Hans de Goede +Reviewed-by: Stanislaw Gruszka +Tested-by: Sakari Ailus +Fixes: 566f5ca97680 ("mei: Add transport driver for IVSC device") +Cc: stable +Link: https://lore.kernel.org/r/20250214212425.84021-1-hdegoede@redhat.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/misc/mei/vsc-tp.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/misc/mei/vsc-tp.c ++++ b/drivers/misc/mei/vsc-tp.c +@@ -504,7 +504,7 @@ static int vsc_tp_probe(struct spi_devic + if (ret) + return ret; + +- tp->wakeuphost = devm_gpiod_get(dev, "wakeuphost", GPIOD_IN); ++ tp->wakeuphost = devm_gpiod_get(dev, "wakeuphostint", GPIOD_IN); + if (IS_ERR(tp->wakeuphost)) + return PTR_ERR(tp->wakeuphost); + diff --git a/queue-6.12/series b/queue-6.12/series index ab5b246748..10b3959711 100644 --- a/queue-6.12/series +++ b/queue-6.12/series @@ -226,3 +226,28 @@ rust-finish-using-custom-ffi-integer-types.patch rust-map-long-to-isize-and-char-to-u8.patch xhci-pci-fix-indentation-in-the-pci-device-id-definitions.patch usb-xhci-enable-the-trb-overfetch-quirk-on-via-vl805.patch +kvm-svm-set-rflags.if-1-in-c-code-to-get-vmrun-out-of-the-sti-shadow.patch +kvm-svm-save-host-dr-masks-on-cpus-with-debugswap.patch +kvm-svm-drop-debugctl-from-guest-s-effective-value.patch +kvm-svm-suppress-debugctl.btf-on-amd.patch +kvm-x86-snapshot-the-host-s-debugctl-in-common-x86.patch +kvm-svm-manually-context-switch-debugctl-if-lbr-virtualization-is-disabled.patch +kvm-x86-snapshot-the-host-s-debugctl-after-disabling-irqs.patch +kvm-x86-explicitly-zero-eax-and-ebx-when-perfmon_v2-isn-t-supported-by-kvm.patch +cdx-fix-possible-uaf-error-in-driver_override_show.patch +mei-me-add-panther-lake-p-did.patch +mei-vsc-use-wakeuphostint-when-getting-the-host-wakeup-gpio.patch +intel_th-pci-add-arrow-lake-support.patch +intel_th-pci-add-panther-lake-h-support.patch +intel_th-pci-add-panther-lake-p-u-support.patch +char-misc-deallocate-static-minor-in-error-path.patch +drivers-core-fix-device-leak-in-__fw_devlink_relax_cycles.patch +slimbus-messaging-free-transaction-id-in-delayed-interrupt-scenario.patch +bus-mhi-host-pci_generic-use-pci_try_reset_function-to-avoid-deadlock.patch +eeprom-digsy_mtc-make-gpio-lookup-table-match-the-device.patch +drivers-virt-acrn-hsm-use-kzalloc-to-avoid-info-leak-in-pmcmd_ioctl.patch +iio-filter-admv8818-force-initialization-of-sdo.patch +iio-light-apds9306-fix-max_scale_nano-values.patch +iio-dac-ad3552r-clear-reset-status-flag.patch +iio-adc-ad7192-fix-channel-select.patch +iio-adc-at91-sama5d2_adc-fix-sama7g5-realbits-value.patch diff --git a/queue-6.12/slimbus-messaging-free-transaction-id-in-delayed-interrupt-scenario.patch b/queue-6.12/slimbus-messaging-free-transaction-id-in-delayed-interrupt-scenario.patch new file mode 100644 index 0000000000..4ffbbc43bc --- /dev/null +++ b/queue-6.12/slimbus-messaging-free-transaction-id-in-delayed-interrupt-scenario.patch @@ -0,0 +1,55 @@ +From dcb0d43ba8eb9517e70b1a0e4b0ae0ab657a0e5a Mon Sep 17 00:00:00 2001 +From: Visweswara Tanuku +Date: Fri, 24 Jan 2025 04:57:40 -0800 +Subject: slimbus: messaging: Free transaction ID in delayed interrupt scenario + +From: Visweswara Tanuku + +commit dcb0d43ba8eb9517e70b1a0e4b0ae0ab657a0e5a upstream. + +In case of interrupt delay for any reason, slim_do_transfer() +returns timeout error but the transaction ID (TID) is not freed. +This results into invalid memory access inside +qcom_slim_ngd_rx_msgq_cb() due to invalid TID. + +Fix the issue by freeing the TID in slim_do_transfer() before +returning timeout error to avoid invalid memory access. + +Call trace: +__memcpy_fromio+0x20/0x190 +qcom_slim_ngd_rx_msgq_cb+0x130/0x290 [slim_qcom_ngd_ctrl] +vchan_complete+0x2a0/0x4a0 +tasklet_action_common+0x274/0x700 +tasklet_action+0x28/0x3c +_stext+0x188/0x620 +run_ksoftirqd+0x34/0x74 +smpboot_thread_fn+0x1d8/0x464 +kthread+0x178/0x238 +ret_from_fork+0x10/0x20 +Code: aa0003e8 91000429 f100044a 3940002b (3800150b) +---[ end trace 0fe00bec2b975c99 ]--- +Kernel panic - not syncing: Oops: Fatal exception in interrupt. + +Fixes: afbdcc7c384b ("slimbus: Add messaging APIs to slimbus framework") +Cc: stable +Signed-off-by: Visweswara Tanuku +Link: https://lore.kernel.org/r/20250124125740.16897-1-quic_vtanuku@quicinc.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/slimbus/messaging.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/drivers/slimbus/messaging.c ++++ b/drivers/slimbus/messaging.c +@@ -148,8 +148,9 @@ int slim_do_transfer(struct slim_control + } + + ret = ctrl->xfer_msg(ctrl, txn); +- +- if (!ret && need_tid && !txn->msg->comp) { ++ if (ret == -ETIMEDOUT) { ++ slim_free_txn_tid(ctrl, txn); ++ } else if (!ret && need_tid && !txn->msg->comp) { + unsigned long ms = txn->rl + HZ; + + time_left = wait_for_completion_timeout(txn->comp,