Pick up two kvm upstream patch to fix build kselftest KVM test errros #15

Signed-off-by: Ian May <[email protected]>

…dversion" This reverts commit 47d27f2. We need to revert this to avoid regressing any modules used in Jammy. Signed-off-by: Ian May <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/1786013 Signed-off-by: Ian May <[email protected]>

Ignore: yes Signed-off-by: Ian May <[email protected]>

Signed-off-by: Ian May <[email protected]>

Ignore: yes Signed-off-by: Ian May <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/2038972 Properties: no-test-build Signed-off-by: Ian May <[email protected]>

Ignore: yes Signed-off-by: Ian May <[email protected]>

Signed-off-by: Ian May <[email protected]>

… a pasid support BugLink: https://bugs.launchpad.net/bugs/2031320 When an iommu_domain is set to IOMMU_DOMAIN_IDENTITY, the driver would skip the allocation of a CD table and set the CONFIG field of the STE to STRTAB_STE_0_CFG_BYPASS. This works well for devices that only have one substream, i.e. PASID disabled. However, there could be a use case, for a pasid capable device, that allows bypassing the translation at the default substream while still enabling the pasid feature, which means the driver should not skip the allocation of a CD table nor simply bypass the CONFIG field. Instead, the S1DSS field should be set to STRTAB_STE_1_S1DSS_BYPASS and the SHCFG field should be set to STRTAB_STE_1_SHCFG_INCOMING. Add s1dss in struct arm_smmu_s1_cfg, to allow a configuration in the finalise() to support this use case. Also, according to "13.5 Summary of attribute/permission configuration fields" in the reference manual, the SHCFG field value is irrelevant. So, set the SHCFG field of the STE always to STRTAB_STE_1_SHCFG_INCOMING for simplification. Signed-off-by: Nicolin Chen <[email protected]> Reviewed-by: Pritesh Raithatha <[email protected]> Acked-by: Jamie Nguyen <[email protected]> Acked-by: Nicolin Chen <[email protected]> Acked-by: Brad Figg <[email protected]> Acked-by: Ian May <[email protected]> Acked-by: Jacob Martin <[email protected]> Signed-off-by: Brad Figg <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/1786013 Signed-off-by: Ian May <[email protected]>

Ignore: yes Signed-off-by: Ian May <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/2045591 Properties: no-test-build Signed-off-by: Ian May <[email protected]>

Signed-off-by: Ian May <[email protected]>

…rnel BugLink: https://bugs.launchpad.net/bugs/2043132 With this change, the NVMe and NVMeOF driver would be enabled to support GPUDirectStorage(GDS). The change is around nvme/nvme rdma map_data() and unmap_data(), where the IO request is first intercepted to check for GDS pages and if it is a GDS page then the request is served by GDS driver component called nvidia-fs, else the request would be served by the standard NVMe driver code Signed-off-by: Sourab Gupta <[email protected]> Acked-by: Brad Figg <[email protected]> Acked-by: Jacob Martin <[email protected]> Acked-by: Ian May <[email protected]> Signed-off-by: Brad Figg <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/2043132 With this change, the NFS driver would be enabled to support GPUDirectStorage(GDS). The change is around frwr_map and frwr_unmap in the NFS driver, where the IO request is first intercepted to check for GDS pages and if it is a GDS page then the request is served by GDS driver component called nvidia-fs, else the request would be served by the standard NFS driver code. Signed-off-by: Sourab Gupta <[email protected]> Acked-by: Brad Figg <[email protected]> Acked-by: Jacob Martin <[email protected]> Acked-by: Ian May <[email protected]> Signed-off-by: Brad Figg <[email protected]>

This reverts commit b2638e9. This feature is not targeted for Jammy. Signed-off-by: Brad Figg <[email protected]> Signed-off-by: Ian May <[email protected]>

Signed-off-by: Brad Figg <[email protected]> Signed-off-by: Ian May <[email protected]>

Add support for exposing rprovides data for standalone modules too. Switch to exposing provides as a shared debian/substvar file and use that in the templates. Signed-off-by: Brad Figg <[email protected]> Signed-off-by: Ian May <[email protected]>

Signed-off-by: Brad Figg <[email protected]> Signed-off-by: Ian May <[email protected]>

…e_range BugLink: https://bugs.launchpad.net/bugs/2048966 When running an SVA case, the following soft lockup is triggered: -------------------------------------------------------------------- watchdog: BUG: soft lockup - CPU#244 stuck for 26s! pstate: 83400009 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : arm_smmu_cmdq_issue_cmdlist+0x178/0xa50 lr : arm_smmu_cmdq_issue_cmdlist+0x150/0xa50 sp : ffff8000d83ef290 x29: ffff8000d83ef290 x28: 000000003b9aca00 x27: 0000000000000000 x26: ffff8000d83ef3c0 x25: da86c0812194a0e8 x24: 0000000000000000 x23: 0000000000000040 x22: ffff8000d83ef340 x21: ffff0000c63980c0 x20: 0000000000000001 x19: ffff0000c6398080 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: ffff3000b4a3bbb0 x14: ffff3000b4a30888 x13: ffff3000b4a3cf60 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc08120e4d6bc x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000048cfa x5 : 0000000000000000 x4 : 0000000000000001 x3 : 000000000000000a x2 : 0000000080000000 x1 : 0000000000000000 x0 : 0000000000000001 Call trace: arm_smmu_cmdq_issue_cmdlist+0x178/0xa50 __arm_smmu_tlb_inv_range+0x118/0x254 arm_smmu_tlb_inv_range_asid+0x6c/0x130 arm_smmu_mm_invalidate_range+0xa0/0xa4 __mmu_notifier_invalidate_range_end+0x88/0x120 unmap_vmas+0x194/0x1e0 unmap_region+0xb4/0x144 do_mas_align_munmap+0x290/0x490 do_mas_munmap+0xbc/0x124 __vm_munmap+0xa8/0x19c __arm64_sys_munmap+0x28/0x50 invoke_syscall+0x78/0x11c el0_svc_common.constprop.0+0x58/0x1c0 do_el0_svc+0x34/0x60 el0_svc+0x2c/0xd4 el0t_64_sync_handler+0x114/0x140 el0t_64_sync+0x1a4/0x1a8 -------------------------------------------------------------------- Note that since 6.6-rc1 the arm_smmu_mm_invalidate_range above is renamed to "arm_smmu_mm_arch_invalidate_secondary_tlbs", yet the problem remains. The commit 06ff87b ("arm64: mm: remove unused functions and variable protoypes") fixed a similar lockup on the CPU MMU side. Yet, it can occur to SMMU too, since arm_smmu_mm_arch_invalidate_secondary_tlbs() is called typically next to MMU tlb flush function, e.g. tlb_flush_mmu_tlbonly { tlb_flush { __flush_tlb_range { // check MAX_TLBI_OPS } } mmu_notifier_arch_invalidate_secondary_tlbs { arm_smmu_mm_arch_invalidate_secondary_tlbs { // does not check MAX_TLBI_OPS } } } Clone a CMDQ_MAX_TLBI_OPS from the MAX_TLBI_OPS in tlbflush.h, since in an SVA case SMMU uses the CPU page table, so it makes sense to align with the tlbflush code. Then, replace per-page TLBI commands with a single per-asid TLBI command, if the request size hits this threshold. Signed-off-by: Nicolin Chen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> [backported from commit d5afb4b] [ian-may: change made to function arm_smmu_mm_invalidate_range] Acked-by: Noah Wager <[email protected]> Acked-by: Jacob Martin <[email protected]> Signed-off-by: Ian May <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/2048815 TPM devices may insert wait state on last clock cycle of ADDR phase. For SPI controllers that support full-duplex transfers, this can be detected using software by reading the MISO line. For SPI controllers that only support half-duplex transfers, such as the Tegra QSPI, it is not possible to detect the wait signal from software. The QSPI controller in Tegra234 and Tegra241 implement hardware detection of the wait signal which can be enabled in the controller for TPM devices. The current TPM TIS driver only supports software detection of the wait signal. To support SPI controllers that use hardware to detect the wait signal, add the function tpm_tis_spi_transfer_half() and move the existing code for software based detection into a function called tpm_tis_spi_transfer_full(). SPI controllers that only support half-duplex transfers will always call tpm_tis_spi_transfer_half() because they cannot support software based detection. The bit SPI_TPM_HW_FLOW is set to indicate to the SPI controller that hardware detection is required and it is the responsibility of the SPI controller driver to determine if this is supported or not. For hardware flow control, CMD-ADDR-DATA messages are combined into a single message where as for software flow control exiting method of CMD-ADDR in a message and DATA in another is followed. [jarkko: Fixed the function names to match the code change, and the tag in the short summary.] Signed-off-by: Krishna Yarlagadda <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]> (cherry picked from commit a86a42a) Acked-by: Jamie Nguyen <[email protected]> Acked-by: Brad Figg <[email protected]> Acked-by: Jacob Martin <[email protected]> Acked-by: Ian May <[email protected]> Signed-off-by: Ian May <[email protected]>

Ignore: yes Signed-off-by: Ian May <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/2047983 Properties: no-test-build Signed-off-by: Ian May <[email protected]>

Signed-off-by: Ian May <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/2049537 Add support of "Thermal fast Sampling Period (_TFP)" for passive cooling. As per the ACPI specification (ACPI 6.5, Section 11.4.17 "_TFP (Thermal fast Sampling Period)", _TFP overrides _TSP ("Thermal Sampling Period" if both are present in a Thermal zone. Signed-off-by: Jeff Brasen <[email protected]> Co-developed-by: Sumit Gupta <[email protected]> Signed-off-by: Sumit Gupta <[email protected]> [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]> Acked-by: Jamie Nguyen <[email protected]> Acked-by: Sumit Gupta <[email protected]> (backported from commit a2ee758 linux-next) Acked-by: Brad Figg <[email protected]> Acked-by: Jacob Martin <[email protected]> Acked-by: Ian May <[email protected]> Signed-off-by: Brad Figg <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/2049537 Current implementation of processor_thermal performs software throttling in fixed steps of "20%" which can be too coarse for some platforms. We observed some performance gain after reducing the throttle percentage. Change the CPUFREQ thermal reduction percentage and maximum thermal steps to be configurable. Also, update the default values of both for Nvidia Tegra241 (Grace) SoC. The thermal reduction percentage is reduced to "5%" and accordingly the maximum number of thermal steps are increased as they are derived from the reduction percentage. Signed-off-by: Srikar Srimath Tirumala <[email protected]> Co-developed-by: Sumit Gupta <[email protected]> Signed-off-by: Sumit Gupta <[email protected]> Acked-by: Sudeep Holla <[email protected]> Acked-by: Hanjun Guo <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Acked-by: Jamie Nguyen <[email protected]> Acked-by: Sumit Gupta <[email protected]> (cherry picked from commit 310293a linux-next) Acked-by: Brad Figg <[email protected]> Acked-by: Jacob Martin <[email protected]> Acked-by: Ian May <[email protected]> Signed-off-by: Brad Figg <[email protected]>

…arlier BugLink: https://bugs.launchpad.net/bugs/2049537 Allocate and device assign 'struct etmv4_drvdata' earlier during the driver probe, ensuring that it can be retrieved in power management based runtime callbacks if required. This will also help in dropping iomem base address argument from the function etm4_probe() later. Cc: Mathieu Poirier <[email protected]> Cc: Suzuki K Poulose <[email protected]> Cc: Mike Leach <[email protected]> Cc: Leo Yan <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Signed-off-by: Anshuman Khandual <[email protected]> Signed-off-by: Suzuki K Poulose <[email protected]> Link: https://lore.kernel.org/r/[email protected] (cherry picked from commit 3095e90 linux) Signed-off-by: Tushar Dave <[email protected]> Acked-by: Brad Figg <[email protected]> Acked-by: Jacob Martin <[email protected]> Acked-by: Ian May <[email protected]> Signed-off-by: Brad Figg <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/2049537 'struct etm4_drvdata' itself can carry the base address before etm4_probe() gets called. Just drop that redundant argument from etm4_probe(). Cc: Mathieu Poirier <[email protected]> Cc: Suzuki K Poulose <[email protected]> Cc: Mike Leach <[email protected]> Cc: Leo Yan <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Reviewed-by: James Clark <[email protected]> Signed-off-by: Anshuman Khandual <[email protected]> Signed-off-by: Suzuki K Poulose <[email protected]> Link: https://lore.kernel.org/r/[email protected] (cherry picked from commit 4e3b9a6 linux) Signed-off-by: Tushar Dave <[email protected]> Acked-by: Brad Figg <[email protected]> Acked-by: Jacob Martin <[email protected]> Acked-by: Ian May <[email protected]> Signed-off-by: Brad Figg <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/2049537 Coresight device pid can be retrieved from its iomem base address, which is stored in 'struct etm4x_drvdata'. This drops pid argument from etm4_probe() and 'struct etm4_init_arg'. Instead etm4_check_arch_features() derives the coresight device pid with a new helper coresight_get_pid(), right before it is consumed in etm4_hisi_match_pid(). Cc: Mathieu Poirier <[email protected]> Cc: Suzuki K Poulose <[email protected]> Cc: Mike Leach <[email protected]> Cc: Leo Yan <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Signed-off-by: Anshuman Khandual <[email protected]> Signed-off-by: Suzuki K Poulose <[email protected]> Link: https://lore.kernel.org/r/[email protected] (cherry picked from commit 5a1c709 linux) Signed-off-by: Tushar Dave <[email protected]> Acked-by: Brad Figg <[email protected]> Acked-by: Jacob Martin <[email protected]> Acked-by: Ian May <[email protected]> Signed-off-by: Brad Figg <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/2049537 Add support for handling MMIO based devices via platform driver. We need to make sure that : 1) The APB clock, if present is enabled at probe and via runtime_pm ops 2) Use the ETM4x architecture or CoreSight architecture registers to identify a device as CoreSight ETM4x, instead of relying a white list of "Peripheral IDs" The driver doesn't get to handle the devices yet, until we wire the ACPI changes to move the devices to be handled via platform driver than the etm4_amba driver. Cc: Mathieu Poirier <[email protected]> Cc: Suzuki K Poulose <[email protected]> Cc: Mike Leach <[email protected]> Cc: Leo Yan <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Acked-by: Sudeep Holla <[email protected]> Signed-off-by: Anshuman Khandual <[email protected]> Signed-off-by: Suzuki K Poulose <[email protected]> Link: https://lore.kernel.org/r/[email protected] (cherry picked from commit 73d779a linux) Signed-off-by: Tushar Dave <[email protected]> Acked-by: Brad Figg <[email protected]> Acked-by: Jacob Martin <[email protected]> Acked-by: Ian May <[email protected]> Signed-off-by: Brad Figg <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/2049537 Drop ETM4X ACPI ID from the AMBA ACPI device list, and instead just move it inside the new ACPI devices list detected and used via platform driver. Cc: "Rafael J. Wysocki" <[email protected]> Cc: Len Brown <[email protected]> Cc: Mathieu Poirier <[email protected]> Cc: Suzuki K Poulose <[email protected]> Cc: Mike Leach <[email protected]> Cc: Leo Yan <[email protected]> Cc: Sudeep Holla <[email protected]> Cc: Lorenzo Pieralisi <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Reviewed-by: Sudeep Holla <[email protected]> (for ACPI specific changes) Acked-by: "Rafael J. Wysocki" <[email protected]> Signed-off-by: Suzuki K Poulose <[email protected]> Signed-off-by: Anshuman Khandual <[email protected]> Tested-by: Tanmay Jagdale <[email protected]> Link: https://lore.kernel.org/r/[email protected] (cherry picked from commit 134124a linux) Signed-off-by: Tushar Dave <[email protected]> Acked-by: Brad Figg <[email protected]> Acked-by: Jacob Martin <[email protected]> Acked-by: Ian May <[email protected]> Signed-off-by: Brad Figg <[email protected]>

Ignore: yes Signed-off-by: Ian May <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/2049653 Properties: no-test-build Signed-off-by: Ian May <[email protected]>

Signed-off-by: Ian May <[email protected]>

…re access." BugLink: https://bugs.launchpad.net/bugs/2053148 This reverts commit b2b56a1. This commit causes a regression in the GPIO initialization routine on T241 (or Grace) systems. The tegra186_gpio_is_accessible() function incorrectly declares GPIO lines that have only one of TEGRA186_GPIO_SCR_SEC_REN _or_ TEGRA186_GPIO_SCR_SEC_WEN set as being inaccessible. Signed-off-by: Jamie Nguyen <[email protected]> Acked-by: Brad Figg <[email protected]> Acked-by: Jacob Martin <[email protected]> Signed-off-by: Ian May <[email protected]>

…nvalidate_range" BugLink: https://bugs.launchpad.net/bugs/2048966 This reverts commit 9a5dc20. There are two versions of this patch, one for 6.5 and 6.6. This is the 6.6 version. Revert and will apply 6.5 version. Acked-by: Brad Figg <[email protected]> Acked-by: Ian May <[email protected]> Signed-off-by: Ian May <[email protected]>

…e_range BugLink: https://bugs.launchpad.net/bugs/2048966 commit d5afb4b upstream. When running an SVA case, the following soft lockup is triggered: -------------------------------------------------------------------- watchdog: BUG: soft lockup - CPU#244 stuck for 26s! pstate: 83400009 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : arm_smmu_cmdq_issue_cmdlist+0x178/0xa50 lr : arm_smmu_cmdq_issue_cmdlist+0x150/0xa50 sp : ffff8000d83ef290 x29: ffff8000d83ef290 x28: 000000003b9aca00 x27: 0000000000000000 x26: ffff8000d83ef3c0 x25: da86c0812194a0e8 x24: 0000000000000000 x23: 0000000000000040 x22: ffff8000d83ef340 x21: ffff0000c63980c0 x20: 0000000000000001 x19: ffff0000c6398080 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: ffff3000b4a3bbb0 x14: ffff3000b4a30888 x13: ffff3000b4a3cf60 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc08120e4d6bc x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000048cfa x5 : 0000000000000000 x4 : 0000000000000001 x3 : 000000000000000a x2 : 0000000080000000 x1 : 0000000000000000 x0 : 0000000000000001 Call trace: arm_smmu_cmdq_issue_cmdlist+0x178/0xa50 __arm_smmu_tlb_inv_range+0x118/0x254 arm_smmu_tlb_inv_range_asid+0x6c/0x130 arm_smmu_mm_invalidate_range+0xa0/0xa4 __mmu_notifier_invalidate_range_end+0x88/0x120 unmap_vmas+0x194/0x1e0 unmap_region+0xb4/0x144 do_mas_align_munmap+0x290/0x490 do_mas_munmap+0xbc/0x124 __vm_munmap+0xa8/0x19c __arm64_sys_munmap+0x28/0x50 invoke_syscall+0x78/0x11c el0_svc_common.constprop.0+0x58/0x1c0 do_el0_svc+0x34/0x60 el0_svc+0x2c/0xd4 el0t_64_sync_handler+0x114/0x140 el0t_64_sync+0x1a4/0x1a8 -------------------------------------------------------------------- The commit 06ff87b ("arm64: mm: remove unused functions and variable protoypes") fixed a similar lockup on the CPU MMU side. Yet, it can occur to SMMU too since arm_smmu_mm_invalidate_range() is typically called next to MMU tlb flush function, e.g. tlb_flush_mmu_tlbonly { tlb_flush { __flush_tlb_range { // check MAX_TLBI_OPS } } mmu_notifier_invalidate_range { arm_smmu_mm_invalidate_range { // does not check MAX_TLBI_OPS } } } Clone a CMDQ_MAX_TLBI_OPS from the MAX_TLBI_OPS in tlbflush.h, since in an SVA case SMMU uses the CPU page table, so it makes sense to align with the tlbflush code. Then, replace per-page TLBI commands with a single per-asid TLBI command, if the request size hits this threshold. Signed-off-by: Nicolin Chen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry-picked from 3283a1bce9bbc978059f790b84f3c10c32492429) Acked-by: Brad Figg <[email protected]> Acked-by: Ian May <[email protected]> Signed-off-by: Ian May <[email protected]>

Ignore: yes Signed-off-by: Ian May <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/2053169 Properties: no-test-build Signed-off-by: Ian May <[email protected]>

Signed-off-by: Ian May <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/2054984 Signed-off-by: Brad Figg <[email protected]> Acked-by: Brad Figg <[email protected]> Acked-by: Jacob Martin <[email protected]> Acked-by: Ian May <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/2054984 TRBE coresight devices do not need regular connections information, as the paths get built between all percpu source and their respective percpu sink devices. Please refer 'commit 2cd87a7 ("coresight: core: Add support for dedicated percpu sinks")' which added support for percpu sink devices. coresight_register() expect device connections via the platform_data. TRBE devices do not have any graph connections and thus is empty. With upcoming ACPI support for TRBE, we do not get a real acpi_device and thus coresight_get_platform_dat() will end up in failures. Hence this allocates a zeroed coresight_platform_data structure and assigns that back into the device. Cc: Suzuki K Poulose <[email protected]> Cc: Mike Leach <[email protected]> Cc: Leo Yan <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Signed-off-by: Anshuman Khandual <[email protected]> (cherry picked from commit 4277f03) Signed-off-by: Besar Wicaksono <[email protected]> Acked-by: Brad Figg <[email protected]> Acked-by: Jacob Martin <[email protected]> Acked-by: Ian May <[email protected]> Signed-off-by: Brad Figg <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/2054984 This detects and enables ACPI based TRBE devices via the dummy platform device created earlier for this purpose. Cc: Suzuki K Poulose <[email protected]> Cc: Mike Leach <[email protected]> Cc: Leo Yan <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Signed-off-by: Anshuman Khandual <[email protected]> (cherry picked from commit 17f8b21) Signed-off-by: Besar Wicaksono <[email protected]> Acked-by: Brad Figg <[email protected]> Acked-by: Jacob Martin <[email protected]> Acked-by: Ian May <[email protected]> Signed-off-by: Brad Figg <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/2054984 Sanity checking all the GICC tables for same interrupt number, and ensuring a homogeneous ACPI based machine, could be used for other platform devices as well. Hence this refactors arm_spe_acpi_register_device() into a common helper arm_acpi_register_pmu_device(). Cc: Catalin Marinas <[email protected]> Cc: Will Deacon <[email protected]> Cc: Mark Rutland <[email protected]> Cc: [email protected] Cc: [email protected] Co-developed-by: Will Deacon <[email protected]> Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Anshuman Khandual <[email protected]> (cherry picked from commit 81e5ee4) Signed-off-by: Besar Wicaksono <[email protected]> Acked-by: Brad Figg <[email protected]> Acked-by: Jacob Martin <[email protected]> Acked-by: Ian May <[email protected]> Signed-off-by: Brad Figg <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/2054984 ACPI TRBE does not have a HID for identification which could create and add a platform device into the platform bus. Also without a platform device, it cannot be probed and bound to a platform driver. This creates a dummy platform device for TRBE after ascertaining that ACPI provides required interrupts uniformly across all cpus on the system. This device gets created inside drivers/perf/arm_pmu_acpi.c to accommodate TRBE being built as a module. Cc: Catalin Marinas <[email protected]> Cc: Will Deacon <[email protected]> Cc: Mark Rutland <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Anshuman Khandual <[email protected]> (cherry picked from commit 1aa3d02) Signed-off-by: Besar Wicaksono <[email protected]> Acked-by: Brad Figg <[email protected]> Acked-by: Jacob Martin <[email protected]> Acked-by: Ian May <[email protected]> Signed-off-by: Brad Figg <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/2054984 The decoder creation for raw trace uses metadata from the first CPU. On per-cpu mode, this metadata is incorrectly used for every decoder. On per-process/per-thread traces, the first CPU is CPU0. If CPU0 trace is not enabled, its metadata will be marked unused and the decoder is not created. Perf report dump skips the decoding part because the decoder is missing. To fix this, use metadata of the CPU associated with sample object. Signed-off-by: Besar Wicaksono <[email protected]> Reviewed-by: James Clark <[email protected]> (backported from commit a16afcc upstream) Signed-off-by: Besar Wicaksono <[email protected]> Acked-by: Brad Figg <[email protected]> Acked-by: Jacob Martin <[email protected]> Acked-by: Ian May <[email protected]> Signed-off-by: Brad Figg <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/2055060 commit 5095a2b upstream. The initial MGLRU patchset didn't include the memcg LRU support, and it relied on should_abort_scan(), added by commit f76c833 ("mm: multi-gen LRU: optimize multiple memcgs"), to "backoff to avoid overshooting their aggregate reclaim target by too much". Later on when the memcg LRU was added, should_abort_scan() was deemed unnecessary, and the test results [1] showed no side effects after it was removed by commit a579086 ("mm: multi-gen LRU: remove eviction fairness safeguard"). However, that test used memory.reclaim, which sets nr_to_reclaim to SWAP_CLUSTER_MAX. So it can overshoot only by SWAP_CLUSTER_MAX-1 pages, i.e., from nr_reclaimed=nr_to_reclaim-1 to nr_reclaimed=nr_to_reclaim+SWAP_CLUSTER_MAX-1. Compared with the batch size kswapd sets to nr_to_reclaim, SWAP_CLUSTER_MAX is tiny. Therefore that test isn't able to reproduce the worst case scenario, i.e., kswapd overshooting GBs on large systems and "consuming 100% CPU" (see the Closes tag). Bring back a simplified version of should_abort_scan() on top of the memcg LRU, so that kswapd stops when all eligible zones are above their respective high watermarks plus a small delta to lower the chance of KSWAPD_HIGH_WMARK_HIT_QUICKLY. Note that this only applies to order-0 reclaim, meaning compaction-induced reclaim can still run wild (which is a different problem). On Android, launching 55 apps sequentially: Before After Change pgpgin 838377172 802955040 -4% pgpgout 38037080 34336300 -10% [1] https://lore.kernel.org/[email protected]/ Link: https://lkml.kernel.org/r/[email protected] Fixes: a579086 ("mm: multi-gen LRU: remove eviction fairness safeguard") Signed-off-by: Yu Zhao <[email protected]> Reported-by: Charan Teja Kalla <[email protected]> Reported-by: Jaroslav Pulchart <[email protected]> Closes: https://lore.kernel.org/CAK8fFZ4DY+GtBA40Pm7Nn5xCHy+51w3sfxPqkqpqakSXYyX+Wg@mail.gmail.com/ Tested-by: Jaroslav Pulchart <[email protected]> Tested-by: Kalesh Singh <[email protected]> Cc: Hillf Danton <[email protected]> Cc: Kairui Song <[email protected]> Cc: T.J. Mercier <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Acked-by: Jamie Nguyen <[email protected]> (cherry picked from commit c5f67b7e847490d41219f1dfe1b1610e88a997e4 linux-6.6.8) Acked-by: Brad Figg <[email protected]> Acked-by: Jacob Martin <[email protected]> Acked-by: Ian May <[email protected]> Signed-off-by: Brad Figg <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/2055060 commit 8aa4206 upstream. While investigating kswapd "consuming 100% CPU" [1] (also see "mm/mglru: try to stop at high watermarks"), it was discovered that the memcg LRU can breach the thrashing protection imposed by min_ttl_ms. Before the memcg LRU: kswapd() shrink_node_memcgs() mem_cgroup_iter() inc_max_seq() // always hit a different memcg lru_gen_age_node() mem_cgroup_iter() check the timestamp of the oldest generation After the memcg LRU: kswapd() shrink_many() restart: iterate the memcg LRU: inc_max_seq() // occasionally hit the same memcg if raced with lru_gen_rotate_memcg(): goto restart lru_gen_age_node() mem_cgroup_iter() check the timestamp of the oldest generation Specifically, when the restart happens in shrink_many(), it needs to stick with the (memcg LRU) generation it began with. In other words, it should neither re-read memcg_lru->seq nor age an lruvec of a different generation. Otherwise it can hit the same memcg multiple times without giving lru_gen_age_node() a chance to check the timestamp of that memcg's oldest generation (against min_ttl_ms). [1] https://lore.kernel.org/CAK8fFZ4DY+GtBA40Pm7Nn5xCHy+51w3sfxPqkqpqakSXYyX+Wg@mail.gmail.com/ Link: https://lkml.kernel.org/r/[email protected] Fixes: e4dde56 ("mm: multi-gen LRU: per-node lru_gen_folio lists") Signed-off-by: Yu Zhao <[email protected]> Tested-by: T.J. Mercier <[email protected]> Cc: Charan Teja Kalla <[email protected]> Cc: Hillf Danton <[email protected]> Cc: Jaroslav Pulchart <[email protected]> Cc: Kairui Song <[email protected]> Cc: Kalesh Singh <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Acked-by: Jamie Nguyen <[email protected]> (cherry picked from commit 6b131c2a2875682bc5ea0d4b15ba76775aa3ea80 linux-6.6.8) Acked-by: Brad Figg <[email protected]> Acked-by: Jacob Martin <[email protected]> Acked-by: Ian May <[email protected]> Signed-off-by: Brad Figg <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/2055712 The current calculation of min_free_kbytes only uses ZONE_DMA and ZONE_NORMAL pages,but the ZONE_MOVABLE zone->_watermark[WMARK_MIN] will also divide part of min_free_kbytes.This will cause the min watermark of ZONE_NORMAL to be too small in the presence of ZONE_MOVEABLE. __GFP_HIGH and PF_MEMALLOC allocations usually don't need movable zone pages, so just like ZONE_HIGHMEM, cap pages_min to a small value in __setup_per_zone_wmarks(). On my testing machine with 16GB of memory (transparent hugepage is turned off by default, and movablecore=12G is configured) The following is a comparative test data of watermark_min no patch add patch ZONE_DMA 1 8 ZONE_DMA32 151 709 ZONE_NORMAL 233 1113 ZONE_MOVABLE 1434 128 min_free_kbytes 7288 7326 Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: liuq <[email protected]> Reviewed-by: "Huang, Ying" <[email protected]> Signed-off-by: Andrew Morton <[email protected]> (cherry picked from commit 416ef04 linux) Signed-off-by: Jamie Nguyen <[email protected]> Signed-off-by: Jan Vesely <[email protected]> Acked-by: Brad Figg <[email protected]> Acked-by: Ian May <[email protected]> Acked-by: Jacob Martin <[email protected]> Signed-off-by: Brad Figg <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/1786013 Signed-off-by: Ian May <[email protected]>

Ignore: yes Signed-off-by: Ian May <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/2055581 Properties: no-test-build Signed-off-by: Ian May <[email protected]>

…s (main/2024.03.04) BugLink: https://bugs.launchpad.net/bugs/1786013 Signed-off-by: Ian May <[email protected]>

Ignore: yes Signed-off-by: Ian May <[email protected]>

…ovides When nvidia-fs-dkms is available as a dkms package, we want to default to using the signed modules if possible. Adding a version number for the nvidia-fs modules package enables the inbox modules to be selected over an equivalent dkms version. Ignore: yes Signed-off-by: Ian May <[email protected]>

Signed-off-by: Ian May <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/1786013 Signed-off-by: Ian May <[email protected]>

Ignore: yes Signed-off-by: Ian May <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/2059703 Properties: no-test-build Signed-off-by: Ian May <[email protected]>

Signed-off-by: Ian May <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/2061930 There are systems in production that don't have firmware that supports coresight_etm4x. Instead of removing completely, blacklist coresight_etm4x so systems with the correct firmware can use the module. Signed-off-by: Ian May <[email protected]>

Ignore: yes Signed-off-by: Ian May <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/2063373 Properties: no-test-build Signed-off-by: Ian May <[email protected]>

…rnel-versions (main/s2024.03.04) BugLink: https://bugs.launchpad.net/bugs/1786013 Signed-off-by: Ian May <[email protected]>

Signed-off-by: Ian May <[email protected]>

Ignore: yes Signed-off-by: Jacob Martin <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/2063578 Properties: no-test-build Signed-off-by: Jacob Martin <[email protected]>

Signed-off-by: Jacob Martin <[email protected]>

Ignore: yes Signed-off-by: Stefan Bader <[email protected]>

Signed-off-by: Stefan Bader <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/2063461 N2 r0p3 doesn't require the workaround [1], so gating on (#slots - 5) no longer works because all N2s have 5 slots. Use the new expression builtin that allows calling strcmp_cpuid_str() and comparing CPUIDs in metric formulas. In this case, the commented formula looks like this: strcmp_cpuid_str(0x410fd493) # greater than or equal to N2 r0p3 | strcmp_cpuid_str(0x410fd490) ^ 1 # OR NOT any version of N2 [1]: https://gitlab.arm.com/telemetry-solution/telemetry-solution/-/blob/main/data/pmu/cpu/neoverse/neoverse-n2-r0p3.json Signed-off-by: James Clark <[email protected]> Reviewed-by: John Garry <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Eduard Zingerman <[email protected]> Cc: Haixin Yu <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jing Zhang <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Kajol Jain <[email protected]> Cc: Kan Liang <[email protected]> Cc: Leo Yan <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Mike Leach <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Nick Forrington <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Rob Herring <[email protected]> Cc: Sohom Datta <[email protected]> Cc: Will Deacon <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> (cherry picked from commit d43f549) Signed-off-by: Brad Figg <[email protected]> Acked-by: Jacob Martin <[email protected]> Acked-by: Noah Wager <[email protected]>

…rm telemetry repo BugLink: https://bugs.launchpad.net/bugs/2063461 Apart from some slight naming and grouping differences, the new metrics are functionally the same as the existing ones. Any missing metrics were manually appended to the end of the auto generated file. For the events, the new data includes descriptions that may have product specific details and new groupings that will be consistent with other products. After generating the metrics from the telemetry repo [1], the following manual steps were performed: * Change the topdown expressions to compare on CPUID and use #slots so that the same data can be shared between N2 and V2. Apart from these modifications, the expressions now match more closely with the Arm telemetry data which will hopefully make future updates easier. * Append some metrics from the old N2/V2 data that aren't present in the telemetry data. These will possibly be added to the telemetry-solution repo at a later time: l3d_cache_mpki, l3d_cache_miss_rate, branch_pki, ipc_rate, spec_ipc, retired_rate, wasted_rate, branch_immed_spec_rate, branch_return_spec_rate, branch_indirect_spec_rate [1]: https://gitlab.arm.com/telemetry-solution/telemetry-solution/-/blob/main/data/pmu/cpu/neoverse/neoverse-n2.json Signed-off-by: James Clark <[email protected]> Reviewed-by: John Garry <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Andrii Nakryiko <[email protected]> Cc: Eduard Zingerman <[email protected]> Cc: Haixin Yu <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jing Zhang <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Kajol Jain <[email protected]> Cc: Kan Liang <[email protected]> Cc: Leo Yan <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Mike Leach <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Nick Forrington <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Rob Herring <[email protected]> Cc: Sohom Datta <[email protected]> Cc: Will Deacon <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> (cherry picked from commit 4473949) Signed-off-by: Brad Figg <[email protected]> Acked-by: Jacob Martin <[email protected]> Acked-by: Noah Wager <[email protected]>

…ion before access."" BugLink: https://bugs.launchpad.net/bugs/2064549 This reverts commit 9cfa409. This effectively restores the functionality added by: b2b56a1 ("gpio: tegra186: Check GPIO pin permission before access." We restore this and, now that the patch has been upstreamed, will apply the proper fix atop. Signed-off-by: Jamie Nguyen <[email protected]> Acked-by: Brad Figg <[email protected]> Acked-by: Noah Wager <[email protected]> Acked-by: Jacob Martin <[email protected]> Signed-off-by: Brad Figg <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/2064549 The controller has several register bits describing access control information for a given GPIO pin. When SCR_SEC_[R|W]EN is unset, it means we have full read/write access to all the registers for given GPIO pin. When SCR_SEC[R|W]EN is set, it means we need to further check the accompanying SCR_SEC_G1[R|W] bit to determine read/write access to all the registers for given GPIO pin. This check was previously declaring that a GPIO pin was accessible only if either of the following conditions were met: - SCR_SEC_REN + SCR_SEC_WEN both set or - SCR_SEC_REN + SCR_SEC_WEN both set and SCR_SEC_G1R + SCR_SEC_G1W both set Update the check to properly handle cases where only one of SCR_SEC_REN or SCR_SEC_WEN is set. Fixes: b2b56a1 ("gpio: tegra186: Check GPIO pin permission before access.") Signed-off-by: Prathamesh Shete <[email protected]> Acked-by: Thierry Reding <[email protected]> (cherry-picked from commit d806f474a9a7993648a2c70642ee129316d8deff linux-next) Signed-off-by: Jamie Nguyen <[email protected]> Acked-by: Brad Figg <[email protected]> Acked-by: Noah Wager <[email protected]> Acked-by: Jacob Martin <[email protected]> Signed-off-by: Brad Figg <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/2067111 Nvidia provide a way to flash the UEFI via capsule loader in arm64. CAPSULE_LOADER is also built-in in L4T kernel so for the easy use, need to make CAPSULE_LOADER as built-in in arm64. Nvidia-BugLink: https://nvbugspro.nvidia.com/bug/4601764 Signed-off-by: kobak <[email protected]> Acked-by: Brad Figg <[email protected]> Acked-by: Jacob Martin <[email protected]> Acked-by: Noah Wager <[email protected]> Signed-off-by: Brad Figg <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/2065721 While calculating the hardware interrupt number for a MSI interrupt, the higher bits (i.e. from bit-5 onwards a.k.a domain_nr >= 32) of the PCI domain number gets truncated because of the shifted value casting to return type of pci_domain_nr() which is 'int'. This for example is resulting in same hardware interrupt number for devices 0019:00:00.0 and 0039:00:00.0. To address this cast the PCI domain number to 'irq_hw_number_t' before left shifting it to calculate the hardware interrupt number. Please note that this fixes the issue only on 64-bit systems and doesn't change the behavior for 32-bit systems i.e. the 32-bit systems continue to have the issue. Since the issue surfaces only if there are too many PCIe controllers in the system which usually is the case in modern server systems and they don't tend to run 32-bit kernels. Fixes: 3878eae ("PCI/MSI: Enhance core to support hierarchy irqdomain") Signed-off-by: Vidya Sagar <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Shanker Donthineni <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] (cherry-picked from commit db744dd) Signed-off-by: Jamie Nguyen <[email protected]> Acked-by: Brad Figg <[email protected]> Acked-by: Jacob Martin <[email protected]> Acked-by: Noah Wager <[email protected]> Signed-off-by: Brad Figg <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/2063461 This will allow writing formulas that are conditional on a specific CPU type or CPU version. It calls through to the existing strcmp_cpuid_str() function in Perf which has a default weak version, and an arch specific version for x86 and arm64. The function takes an 'ID' type value, which is a string. But in this case Arm CPU IDs are hex numbers prefixed with '0x'. metric.py assumes strings are only used by event names, and that they can't start with a number ('0'), so an additional change has to be made to the regex to convert hex numbers back to 'ID' types. Signed-off-by: James Clark <[email protected]> Reviewed-by: John Garry <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Eduard Zingerman <[email protected]> Cc: Haixin Yu <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jing Zhang <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Kajol Jain <[email protected]> Cc: Kan Liang <[email protected]> Cc: Leo Yan <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Mike Leach <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Nick Forrington <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Rob Herring <[email protected]> Cc: Sohom Datta <[email protected]> Cc: Will Deacon <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> (cherry picked from commit 9d5da30) Acked-by: Brad Figg <[email protected]> Acked-by: Jacob Martin <[email protected]> Acked-by: Noah Wager <[email protected]> Signed-off-by: Jacob Martin <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/2063461 The parser wraps all strings as Events, so the input is an Event. Using a string would be bad as functions like Simplify are called on the arguments, which wouldn't be present on a string. Fixes: 9d5da30 ("perf jevents: Add a new expression builtin strcmp_cpuid_str()") Signed-off-by: Ian Rogers <[email protected]> Cc: James Clark <[email protected]> Cc: Kajol Jain <[email protected]> Cc: John Garry <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Namhyung Kim <[email protected]> (cherry picked from commit d1bac78) Acked-by: Brad Figg <[email protected]> Acked-by: Jacob Martin <[email protected]> Acked-by: Noah Wager <[email protected]> Signed-off-by: Jacob Martin <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/2067429 The TPM SPI transfer mechanism uses MAX_SPI_FRAMESIZE for computing the maximum transfer length and the size of the transfer buffer. As such, it does not account for the 4 bytes of header that prepends the SPI data frame. This can result in out-of-bounds accesses and was confirmed with KASAN. Introduce SPI_HDRSIZE to account for the header and use to allocate the transfer buffer. Fixes: a86a42a ("tpm_tis_spi: Add hardware wait polling") Signed-off-by: Matthew R. Ochs <[email protected]> Tested-by: Carol Soto <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]> (cherry picked from commit 195aba96b854dd664768f382cd1db375d8181f88) Acked-by: Brad Figg <[email protected]> Acked-by: Noah Wager <[email protected]> Acked-by: Jacob Martin <[email protected]> Signed-off-by: Brad Figg <[email protected]>

Ignore: yes Signed-off-by: Jacob Martin <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/2065892 Properties: no-test-build Signed-off-by: Jacob Martin <[email protected]>

…rnel-versions (main/2024.04.29) BugLink: https://bugs.launchpad.net/bugs/1786013 Signed-off-by: Jacob Martin <[email protected]>

Signed-off-by: Jacob Martin <[email protected]>

Ignore: yes Signed-off-by: Jacob Martin <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/2068185 Properties: no-test-build Signed-off-by: Jacob Martin <[email protected]>

Signed-off-by: Jacob Martin <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/1786013 Signed-off-by: Jacob Martin <[email protected]>

Ignore: yes Signed-off-by: Jacob Martin <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/2042546 Signed-off-by: Roxana Nicolescu <[email protected]> Acked-by: Tim Gardner <[email protected]> Acked-by: Manuel Diewald <[email protected]> Signed-off-by: Jacob Martin <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/2068338 Properties: no-test-build Signed-off-by: Jacob Martin <[email protected]>

…rnel-versions (main/2024.06.10) BugLink: https://bugs.launchpad.net/bugs/1786013 Signed-off-by: Jacob Martin <[email protected]>

Signed-off-by: Jacob Martin <[email protected]>

Attempt to modify vcpu->run->s.regs _after_ the sanity checks performed by KVM_CAP_SYNC_REGS's arch/x86/kvm/x86.c:sync_regs(). This can lead to some nonsensical vCPU states accompanied by kernel splats, e.g. disabling PAE while long mode is enabled makes KVM all kinds of confused: WARNING: CPU: 0 PID: 1142 at arch/x86/kvm/mmu/paging_tmpl.h:358 paging32_walk_addr_generic+0x431/0x8f0 [kvm] arch/x86/kvm/mmu/paging_tmpl.h: KVM_BUG_ON(is_long_mode(vcpu) && !is_pae(vcpu), vcpu->kvm) Signed-off-by: Michal Luczaj <[email protected]> Link: https://lore.kernel.org/r/[email protected] [sean: see link] Signed-off-by: Sean Christopherson <[email protected]>

There is already an ASSERT_EQ macro in the file tools/testing/selftests/kselftest_harness.h, so currently KVM selftests can't include test_util.h from the KVM selftests together with that file. Rename the macro in the KVM selftests to TEST_ASSERT_EQ to avoid the problem - it is also more similar to the other macros in test_util.h that way. Suggested-by: Sean Christopherson <[email protected]> Signed-off-by: Thomas Huth <[email protected]> Reviewed-by: Philippe Mathieu-Daud <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sean Christopherson <[email protected]>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Pick up two kvm upstream patch to fix build kselftest KVM test errros #15

Pick up two kvm upstream patch to fix build kselftest KVM test errros #15

Commits on Jun 24, 2024

Commits on Jun 28, 2024

Pick up two kvm upstream patch to fix build kselftest KVM test errros #15

Are you sure you want to change the base?

Pick up two kvm upstream patch to fix build kselftest KVM test errros #15

Commits on Jun 24, 2024

Commits on Jun 28, 2024