aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2022-03-08KVM: selftests: Move raw KVM_SET_USER_MEMORY_REGION helper to utilsSean Christopherson3-27/+36
Move set_memory_region_test's KVM_SET_USER_MEMORY_REGION helper to KVM's utils so that it can be used by other tests. Provide a raw version as well as an assert-success version to reduce the amount of boilerplate code need for basic usage. No functional change intended. Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20220226001546.360188-26-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-08KVM: x86/mmu: WARN on any attempt to atomically update REMOVED SPTESean Christopherson1-8/+7
Disallow calling tdp_mmu_set_spte_atomic() with a REMOVED "old" SPTE. This solves a conundrum introduced by commit 3255530ab191 ("KVM: x86/mmu: Automatically update iter->old_spte if cmpxchg fails"); if the helper doesn't update old_spte in the REMOVED case, then theoretically the caller could get stuck in an infinite loop as it will fail indefinitely on the REMOVED SPTE. E.g. until recently, clear_dirty_gfn_range() didn't check for a present SPTE and would have spun until getting rescheduled. In practice, only the page fault path should "create" a new SPTE, all other paths should only operate on existing, a.k.a. shadow present, SPTEs. Now that the page fault path pre-checks for a REMOVED SPTE in all cases, require all other paths to indirectly pre-check by verifying the target SPTE is a shadow-present SPTE. Note, this does not guarantee the actual SPTE isn't REMOVED, nor is that scenario disallowed. The invariant is only that the caller mustn't invoke tdp_mmu_set_spte_atomic() if the SPTE was REMOVED when last observed by the caller. Cc: David Matlack <dmatlack@google.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20220226001546.360188-25-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-08KVM: x86/mmu: Check for a REMOVED leaf SPTE before making the SPTESean Christopherson1-1/+5
Explicitly check for a REMOVED leaf SPTE prior to attempting to map the final SPTE when handling a TDP MMU fault. Functionally, this is a nop as tdp_mmu_set_spte_atomic() will eventually detect the frozen SPTE. Pre-checking for a REMOVED SPTE is a minor optmization, but the real goal is to allow tdp_mmu_set_spte_atomic() to have an invariant that the "old" SPTE is never a REMOVED SPTE. Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Ben Gardon <bgardon@google.com> Message-Id: <20220226001546.360188-24-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-08KVM: x86/mmu: Zap defunct roots via asynchronous workerPaolo Bonzini1-9/+11
Zap defunct roots, a.k.a. roots that have been invalidated after their last reference was initially dropped, asynchronously via the existing work queue instead of forcing the work upon the unfortunate task that happened to drop the last reference. If a vCPU task drops the last reference, the vCPU is effectively blocked by the host for the entire duration of the zap. If the root being zapped happens be fully populated with 4kb leaf SPTEs, e.g. due to dirty logging being active, the zap can take several hundred seconds. Unsurprisingly, most guests are unhappy if a vCPU disappears for hundreds of seconds. E.g. running a synthetic selftest that triggers a vCPU root zap with ~64tb of guest memory and 4kb SPTEs blocks the vCPU for 900+ seconds. Offloading the zap to a worker drops the block time to <100ms. There is an important nuance to this change. If the same work item was queued twice before the work function has run, it would only execute once and one reference would be leaked. Therefore, now that queueing and flushing items is not anymore protected by kvm->slots_lock, kvm_tdp_mmu_invalidate_all_roots() has to check root->role.invalid and skip already invalid roots. On the other hand, kvm_mmu_zap_all_fast() must return only after those skipped roots have been zapped as well. These two requirements can be satisfied only if _all_ places that change invalid to true now schedule the worker before releasing the mmu_lock. There are just two, kvm_tdp_mmu_put_root() and kvm_tdp_mmu_invalidate_all_roots(). Co-developed-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Ben Gardon <bgardon@google.com> Message-Id: <20220226001546.360188-23-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-08KVM: x86/mmu: Zap roots in two passes to avoid inducing RCU stallsSean Christopherson1-17/+34
When zapping a TDP MMU root, perform the zap in two passes to avoid zapping an entire top-level SPTE while holding RCU, which can induce RCU stalls. In the first pass, zap SPTEs at PG_LEVEL_1G, and then zap top-level entries in the second pass. With 4-level paging, zapping a PGD that is fully populated with 4kb leaf SPTEs take up to ~7 or so seconds (time varies based on kernel config, number of (v)CPUs, etc...). With 5-level paging, that time can balloon well into hundreds of seconds. Before remote TLB flushes were omitted, the problem was even worse as waiting for all active vCPUs to respond to the IPI introduced significant overhead for VMs with large numbers of vCPUs. By zapping 1gb SPTEs (both shadow pages and hugepages) in the first pass, the amount of work that is done without dropping RCU protection is strictly bounded, with the worst case latency for a single operation being less than 100ms. Zapping at 1gb in the first pass is not arbitrary. First and foremost, KVM relies on being able to zap 1gb shadow pages in a single shot when when repacing a shadow page with a hugepage. Zapping a 1gb shadow page that is fully populated with 4kb dirty SPTEs also triggers the worst case latency due writing back the struct page accessed/dirty bits for each 4kb page, i.e. the two-pass approach is guaranteed to work so long as KVM can cleany zap a 1gb shadow page. rcu: INFO: rcu_sched self-detected stall on CPU rcu: 52-....: (20999 ticks this GP) idle=7be/1/0x4000000000000000 softirq=15759/15759 fqs=5058 (t=21016 jiffies g=66453 q=238577) NMI backtrace for cpu 52 Call Trace: ... mark_page_accessed+0x266/0x2f0 kvm_set_pfn_accessed+0x31/0x40 handle_removed_tdp_mmu_page+0x259/0x2e0 __handle_changed_spte+0x223/0x2c0 handle_removed_tdp_mmu_page+0x1c1/0x2e0 __handle_changed_spte+0x223/0x2c0 handle_removed_tdp_mmu_page+0x1c1/0x2e0 __handle_changed_spte+0x223/0x2c0 zap_gfn_range+0x141/0x3b0 kvm_tdp_mmu_zap_invalidated_roots+0xc8/0x130 kvm_mmu_zap_all_fast+0x121/0x190 kvm_mmu_invalidate_zap_pages_in_memslot+0xe/0x10 kvm_page_track_flush_slot+0x5c/0x80 kvm_arch_flush_shadow_memslot+0xe/0x10 kvm_set_memslot+0x172/0x4e0 __kvm_set_memory_region+0x337/0x590 kvm_vm_ioctl+0x49c/0xf80 Reported-by: David Matlack <dmatlack@google.com> Cc: Ben Gardon <bgardon@google.com> Cc: Mingwei Zhang <mizhang@google.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Ben Gardon <bgardon@google.com> Message-Id: <20220226001546.360188-22-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-08KVM: x86/mmu: Allow yielding when zapping GFNs for defunct TDP MMU rootPaolo Bonzini1-41/+62
Allow yielding when zapping SPTEs after the last reference to a valid root is put. Because KVM must drop all SPTEs in response to relevant mmu_notifier events, mark defunct roots invalid and reset their refcount prior to zapping the root. Keeping the refcount elevated while the zap is in-progress ensures the root is reachable via mmu_notifier until the zap completes and the last reference to the invalid, defunct root is put. Allowing kvm_tdp_mmu_put_root() to yield fixes soft lockup issues if the root in being put has a massive paging structure, e.g. zapping a root that is backed entirely by 4kb pages for a guest with 32tb of memory can take hundreds of seconds to complete. watchdog: BUG: soft lockup - CPU#49 stuck for 485s! [max_guest_memor:52368] RIP: 0010:kvm_set_pfn_dirty+0x30/0x50 [kvm] __handle_changed_spte+0x1b2/0x2f0 [kvm] handle_removed_tdp_mmu_page+0x1a7/0x2b8 [kvm] __handle_changed_spte+0x1f4/0x2f0 [kvm] handle_removed_tdp_mmu_page+0x1a7/0x2b8 [kvm] __handle_changed_spte+0x1f4/0x2f0 [kvm] tdp_mmu_zap_root+0x307/0x4d0 [kvm] kvm_tdp_mmu_put_root+0x7c/0xc0 [kvm] kvm_mmu_free_roots+0x22d/0x350 [kvm] kvm_mmu_reset_context+0x20/0x60 [kvm] kvm_arch_vcpu_ioctl_set_sregs+0x5a/0xc0 [kvm] kvm_vcpu_ioctl+0x5bd/0x710 [kvm] __se_sys_ioctl+0x77/0xc0 __x64_sys_ioctl+0x1d/0x20 do_syscall_64+0x44/0xa0 entry_SYSCALL_64_after_hwframe+0x44/0xae KVM currently doesn't put a root from a non-preemptible context, so other than the mmu_notifier wrinkle, yielding when putting a root is safe. Yield-unfriendly iteration uses for_each_tdp_mmu_root(), which doesn't take a reference to each root (it requires mmu_lock be held for the entire duration of the walk). tdp_mmu_next_root() is used only by the yield-friendly iterator. tdp_mmu_zap_root_work() is explicitly yield friendly. kvm_mmu_free_roots() => mmu_free_root_page() is a much bigger fan-out, but is still yield-friendly in all call sites, as all callers can be traced back to some combination of vcpu_run(), kvm_destroy_vm(), and/or kvm_create_vm(). Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20220226001546.360188-21-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-08KVM: x86/mmu: Zap invalidated roots via asynchronous workerPaolo Bonzini4-87/+76
Use the system worker threads to zap the roots invalidated by the TDP MMU's "fast zap" mechanism, implemented by kvm_tdp_mmu_invalidate_all_roots(). At this point, apart from allowing some parallelism in the zapping of roots, the workqueue is a glorified linked list: work items are added and flushed entirely within a single kvm->slots_lock critical section. However, the workqueue fixes a latent issue where kvm_mmu_zap_all_invalidated_roots() assumes that it owns a reference to all invalid roots; therefore, no one can set the invalid bit outside kvm_mmu_zap_all_fast(). Putting the invalidated roots on a linked list... erm, on a workqueue ensures that tdp_mmu_zap_root_work() only puts back those extra references that kvm_mmu_zap_all_invalidated_roots() had gifted to it. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-08dt-bindings: rtc: at91: Add SAMA7G5 compatible strings listSergiu Moga1-0/+4
Add compatible strings list for SAMA7G5. Signed-off-by: Sergiu Moga <sergiu.moga@microchip.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20220304161159.147784-5-sergiu.moga@microchip.com
2022-03-08dt-bindings: rtc: convert at91sam9 bindings to json-schemaSergiu Moga2-25/+65
Convert RTC binding for Atmel/Microchip SoCs to Device Tree Schema format. Signed-off-by: Sergiu Moga <sergiu.moga@microchip.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20220304161159.147784-4-sergiu.moga@microchip.com
2022-03-08Merge tag 'memory-controller-drv-5.18-2' of git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl into arm/driversArnd Bergmann2-4/+7
Memory controller drivers for v5.18, part two 1. TI: Two fixes for TI EMIF driver for quite old error path issues (so for unlikely scenarios). 2. Renesas: Document RZ/V2L SoC in bindings. * tag 'memory-controller-drv-5.18-2' of git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl: dt-bindings: memory: renesas,rpc-if: Document RZ/V2L SoC memory: emif: check the pointer temp in get_device_details() memory: emif: Add check for setup_interrupts Link: https://lore.kernel.org/r/20220307082552.55719-1-krzysztof.kozlowski@canonical.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-03-08Merge tag 'at91-soc-5.18-2' of git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux into arm/driversArnd Bergmann13-14/+252
AT91 SoC #2 for 5.18: - SAMA5D29 variant to the SAMA5D2 family in SoC driver. * tag 'at91-soc-5.18-2' of git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux: ARM: at91: add support in soc driver for new SAMA5D29 soc: add microchip polarfire soc system controller ARM: at91: Kconfig: select PM_OPP ARM: at91: PM: add cpu idle support for sama7g5 ARM: at91: ddr: fix typo to align with datasheet naming ARM: at91: ddr: align macro definitions ARM: at91: ddr: remove CONFIG_SOC_SAMA7 dependency Link: https://lore.kernel.org/r/20220304144216.23340-1-nicolas.ferre@microchip.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-03-08arm: multi_v5: enable configs for versatileAnders Roxell1-0/+7
Make it possible to boot a versatile machine in qemu. Boot command: /usr/bin/qemu-system-arm -cpu arm926 -machine versatilepb \ -nographic -nic none -m 256M -monitor none -no-reboot \ -kernel zImage -dtb versatile-pb.dtb \ -append "console=ttyAMA0,115200 rootwait root=/dev/vda" \ -drive armv5_rootfs.ext4,if=none,format=raw,id=hd0 \ -device virtio-blk-pci,drive=hd0 When doing build and boot testing, it makes more sense to enable arch vesatile, serial amba_pl011 and virtio (mmio|blk|pci) to multi_v5_defconfig to make that boot out of the box, with a modern virtio (mmio|blk|pci) driver. Using the above commandline. Another way to build and boot would be to use tuxmake/tuxrun. Tuxmake [1] builds the kernel, and Tuxrun [2] boots the kernel in qemu. Both projects uses podman to do the build/tests inside. This makes both project a good tool to use when finding a regression that you would like someone else to reproduce with the exact same setup. tuxmake --runtime podman --target-arch arm \ --toolchain gcc-11 --kconfig multi_v5_defconfig tuxrun --tuxmake ~/.cache/tuxmake/builds/3072 --device qemu-armv5 [1] https://tuxmake.org/ [2] https://tuxrun.org/ Signed-off-by: Anders Roxell <anders.roxell@linaro.org> Link: https://lore.kernel.org/r/20220308121933.3967868-1-anders.roxell@linaro.org' Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-03-08Merge tag 'arm-soc/for-5.18/defconfig-arm64' of https://github.com/Broadcom/stblinux into arm/defconfigArnd Bergmann1-0/+7
This pull request contains Broadcom ARM64-based defconfig updates for 5.18, please pull the following: - Florian enables Broadcom STB drivers for NAND, SATA, Ethernet switch, USB PHY and host controllers, watchdog, PWM and Ethernet controller * tag 'arm-soc/for-5.18/defconfig-arm64' of https://github.com/Broadcom/stblinux: arm64: defconfig: Enable additional Broadcom STB drivers Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-03-08arm64: defconfig: enable Layerscape SFP driverMichael Walle1-0/+1
Enable the driver for the Layerscape SFP (Security Fuse Processor) found on most Layerscape SoCs. For example, a per-device unique serial number is stored in the fuses. Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-03-08Merge tag 'at91-defconfig-5.18-2' of git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux into arm/defconfigArnd Bergmann1-1/+1
AT91: defconfig #2 for 5.18: - Add EIC, remove DMATEST to sama7_defconfig * tag 'at91-defconfig-5.18-2' of git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux: ARM: configs: at91: sama7: Unselect CONFIG_DMATEST ARM: configs: at91: add eic Link: https://lore.kernel.org/r/20220304144746.23779-1-nicolas.ferre@microchip.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-03-08ixgbevf: add disable link stateSlawomir Mrozowicz5-1/+57
Add possibility to disable link state if it is administratively disabled in PF. It is part of the general functionality that allows the PF driver to control the state of the virtual link VF devices. Signed-off-by: Slawomir Mrozowicz <slawomirx.mrozowicz@intel.com> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-03-08ixgbe: add improvement for MDD response functionalitySlawomir Mrozowicz3-1/+52
The 82599 PF driver disable VF driver after a special MDD event occurs. Adds the option for administrators to control whether VFs are automatically disabled after several MDD events. The automatically disabling is now the default mode for 82599 PF driver, as it is more reliable. This addresses CVE-2021-33061. Signed-off-by: Slawomir Mrozowicz <slawomirx.mrozowicz@intel.com> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-03-08ixgbe: add the ability for the PF to disable VF link stateSlawomir Mrozowicz5-44/+182
Add support for ndo_set_vf_link_state the Network Device Option that allows the PF driver to control the virtual link state of the VF devices. Without this change a VF cannot be disabled/enabled by the administrator. In the implementation the auto state takes over PF link state to VF link setting, the enable state is not supported, the disable state shut off the VF link regardless of the PF setting. Signed-off-by: Slawomir Mrozowicz <slawomirx.mrozowicz@intel.com> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-03-08platform/x86: amd-pmc: uninitialized variable in amd_pmc_s2d_init()Dan Carpenter1-1/+2
The "size" variable can be uninitialized if amd_pmc_send_cmd() fails. Fixes: 3d7d407dfb05 ("platform/x86: amd-pmc: Add support for AMD Spill to DRAM STB feature") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20220307141832.GA19660@kili Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-03-08platform/x86: intel-uncore-freq: fix uncore_freq_common_init() error codesDan Carpenter2-2/+2
Currently the uncore_freq_common_init() return one on success and zero on failure. There is only one caller and it has a "forgot to set the error code" bug. Change uncore_freq_common_init() to return negative error codes which makes the code simpler and avoids this kind of bug in the future. Fixes: dbce412a7733 ("platform/x86/intel-uncore-freq: Split common and enumeration part") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://lore.kernel.org/r/20220304131925.GG28739@kili Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-03-08platform/x86: huawei-wmi: check the return value of device_create_file()Jia-Ju Bai1-3/+10
The function device_create_file() in huawei_wmi_battery_add() can fail, so its return value should be checked. Fixes: 355a070b09ab ("platform/x86: huawei-wmi: Add battery charging thresholds") Reported-by: TOTE Robot <oslab@tsinghua.edu.cn> Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com> Link: https://lore.kernel.org/r/20220303022421.313-1-baijiaju1990@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-03-08Merge tag 'arm-soc/for-5.18/devicetree-arm64' of https://github.com/Broadcom/stblinux into arm/dtArnd Bergmann4-15/+168
This pull request contains Broadcom ARM64-based SoCs Device Tree updates for 5.18, please pull the following: - Krzysztof aligns the PL330 DMA controller node name to the schema - Rafal corrects the TWD (Timer/Watchdog) block, adds the watchdog node, I2C controller node and the pinctrl node for the 4908 SoC - Kuldeep fixes the Northstar 2 SPI properties as well as the PL022 SPI controller clock names - Frank fixes the SATA node names to conform to the AHCI controller schema * tag 'arm-soc/for-5.18/devicetree-arm64' of https://github.com/Broadcom/stblinux: arm64: dts: stingray: Fix spi clock name arm64: dts: ns2: Fix spi clock name arm64: dts: broadcom: Fix sata nodename arm64: dts: ns2: Fix spi-cpol and spi-cpha property arm64: dts: broadcom: bcm4908: add I2C block arm64: dts: broadcom: bcm4908: add watchdog block arm64: dts: broadcom: bcm4908: add pinctrl binding arm64: dts: broadcom: bcm4908: use proper TWD binding arm64: dts: broadcom: align pl330 node name with dtschema Link: https://lore.kernel.org/r/20220307194817.3754107-3-f.fainelli@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-03-08Merge tag 'arm-soc/for-5.18/devicetree' of https://github.com/Broadcom/stblinux into arm/dtArnd Bergmann14-6/+403
This pull request contains Broadcom ARM-based SoCs Device Tree changes for 5.18, please pull the following: - Arinc defines the switch ports of the RTL8365MB switch on the Asus RT-AC88U - Richard provides cache information for the BCM2835/36/37 and BCM2711 SoCs such that tools like "lscpu -C" can report it when supported - Stefan adds support for the Raspberry Pi Zero 2 W (wireless) - Matthew defines the MAC address NVMEM cells for the Cisco Meraki MX64/MX65 devices, he also fixes the LED for these platforms. - Rafal adds the MAC addres NVMEM cell for the Luxul XWR-3150 * tag 'arm-soc/for-5.18/devicetree' of https://github.com/Broadcom/stblinux: ARM: dts: BCM5301X: Add Ethernet MAC address to Luxul XWR-3150 ARM: dts: NSP: MX6X: correct LED function types ARM: dts: NSP: MX6X: get mac-address from eeprom arm64: dts: broadcom: Add reference to RPi Zero 2 W ARM: dts: Add Raspberry Pi Zero 2 W dt-bindings: arm: bcm2835: Add Raspberry Pi Zero 2 W ARM: dts: bcm2835/6: Add the missing L1/L2 cache information ARM: dts: bcm2711: Add the missing L1/L2 cache information ARM: dts: bcm2837: Add the missing L1/L2 cache information ARM: dts: BCM5301X: define RTL8365MB switch on Asus RT-AC88U Link: https://lore.kernel.org/r/20220307194817.3754107-2-f.fainelli@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-03-08Merge tag 'dt64-cleanup-5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into arm/dtArnd Bergmann3-3/+5
Minor cleanup of ARM64 DTS for v5.18 The DT schema expects DMA controller nodes to follow certain node naming and having dma-cells property. Adjust the DTS files to pass DT schema checks. * tag 'dt64-cleanup-5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux: arm64: dts: lg: align pl330 node name with dtschema arm64: dts: lg: add dma-cells to pl330 node arm64: dts: juno: align pl330 node name with dtschema Link: https://lore.kernel.org/r/20220307173614.157884-1-krzysztof.kozlowski@canonical.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-03-08Merge tag 'at91-dt-5.18-2' of git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux into arm/dtArnd Bergmann3-10/+73
AT91 DT #2 for 5.18: - Align one sam9x60ek regulator with reality at vdd_1v15 - Clean sama7g5 i2c nodes - Add EIC and NAND nodes to sama7g5 * tag 'at91-dt-5.18-2' of git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux: ARM: dts: at91: sama7g5: Add NAND support ARM: dts: at91: sama7g5: add eic node ARM: dts: at91: sama7g5: Remove unused properties in i2c nodes ARM: dts: at91: sam9x60ek: modify vdd_1v5 regulator to vdd_1v15 Link: https://lore.kernel.org/r/20220304160036.27392-1-nicolas.ferre@microchip.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-03-08sched/topology: Remove redundant variable and fix incorrect type in build_sched_domainsK Prateek Nayak1-5/+3
While investigating the sparse warning reported by the LKP bot [1], observed that we have a redundant variable "top" in the function build_sched_domains that was introduced in the recent commit e496132ebedd ("sched/fair: Adjust the allowed NUMA imbalance when SD_NUMA spans multiple LLCs") The existing variable "sd" suffices which allows us to remove the redundant variable "top" while annotating the other variable "top_p" with the "__rcu" annotation to silence the sparse warning. [1] https://lore.kernel.org/lkml/202202170853.9vofgC3O-lkp@intel.com/ Fixes: e496132ebedd ("sched/fair: Adjust the allowed NUMA imbalance when SD_NUMA spans multiple LLCs") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Valentin Schneider <valentin.schneider@arm.com> Link: https://lore.kernel.org/r/20220218162743.1134-1-kprateek.nayak@amd.com
2022-03-08sched/deadline,rt: Remove unused parameter from pick_next_[rt|dl]_entity()Dietmar Eggemann2-6/+4
The `struct rq *rq` parameter isn't used. Remove it. Signed-off-by: Dietmar Eggemann <dietmar.eggemann@arm.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Juri Lelli <juri.lelli@redhat.com> Link: https://lore.kernel.org/r/20220302183433.333029-7-dietmar.eggemann@arm.com
2022-03-08sched/deadline,rt: Remove unused functions for !CONFIG_SMPDietmar Eggemann2-20/+0
The need_pull_[rt|dl]_task() and pull_[rt|dl]_task() functions are not used on a !CONFIG_SMP system. Remove them. Signed-off-by: Dietmar Eggemann <dietmar.eggemann@arm.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Juri Lelli <juri.lelli@redhat.com> Link: https://lore.kernel.org/r/20220302183433.333029-6-dietmar.eggemann@arm.com
2022-03-08sched/deadline: Use __node_2_[pdl|dle]() and rb_first_cached() consistentlyDietmar Eggemann1-12/+12
Deploy __node_2_pdl(node), __node_2_dle(node) and rb_first_cached() consistently throughout the sched class source file which makes the code at least easier to read. Signed-off-by: Dietmar Eggemann <dietmar.eggemann@arm.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Juri Lelli <juri.lelli@redhat.com> Link: https://lore.kernel.org/r/20220302183433.333029-5-dietmar.eggemann@arm.com
2022-03-08sched/deadline: Merge dl_task_can_attach() and dl_cpu_busy()Dietmar Eggemann3-44/+24
Both functions are doing almost the same, that is checking if admission control is still respected. With exclusive cpusets, dl_task_can_attach() checks if the destination cpuset (i.e. its root domain) has enough CPU capacity to accommodate the task. dl_cpu_busy() checks if there is enough CPU capacity in the cpuset in case the CPU is hot-plugged out. dl_task_can_attach() is used to check if a task can be admitted while dl_cpu_busy() is used to check if a CPU can be hotplugged out. Make dl_cpu_busy() able to deal with a task and use it instead of dl_task_can_attach() in task_can_attach(). Signed-off-by: Dietmar Eggemann <dietmar.eggemann@arm.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Juri Lelli <juri.lelli@redhat.com> Link: https://lore.kernel.org/r/20220302183433.333029-4-dietmar.eggemann@arm.com
2022-03-08sched/deadline: Move bandwidth mgmt and reclaim functions into sched class source fileDietmar Eggemann2-49/+44
Move the deadline bandwidth management (admission control) functions __dl_add(), __dl_sub() and __dl_overflow() as well as the bandwidth reclaim function __dl_update() from private task scheduler header file to the deadline sched class source file. The functions are only used internally so they don't have to be exported. Signed-off-by: Dietmar Eggemann <dietmar.eggemann@arm.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Juri Lelli <juri.lelli@redhat.com> Link: https://lore.kernel.org/r/20220302183433.333029-3-dietmar.eggemann@arm.com
2022-03-08sched/deadline: Remove unused def_dl_bandwidthDietmar Eggemann3-9/+0
Since commit 1724813d9f2c ("sched/deadline: Remove the sysctl_sched_dl knobs") the default deadline bandwidth control structure has no purpose. Remove it. Signed-off-by: Dietmar Eggemann <dietmar.eggemann@arm.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Juri Lelli <juri.lelli@redhat.com> Link: https://lore.kernel.org/r/20220302183433.333029-2-dietmar.eggemann@arm.com
2022-03-08Merge tag 'zynqmp-dt-for-v5.18' of https://github.com/Xilinx/linux-xlnx into arm/dtArnd Bergmann1-44/+32
arm64: dts: ZynqMP DT changes for v5.18 - Dropping #stream-id-cells - Add missing dma-cells and change dma node names * tag 'zynqmp-dt-for-v5.18' of https://github.com/Xilinx/linux-xlnx: arm64: zynqmp: Rename dma to dma-controller arm64: zynqmp: Add missing #dma-cells property arm64: xilinx: dts: drop legacy property #stream-id-cells Link: https://lore.kernel.org/r/19464dc6-eca9-f9a7-8aba-43af094d7c37@xilinx.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-03-08selftests/bpf: Make test_lwt_ip_encap more stable and fasterFelix Maurer1-1/+9
In test_lwt_ip_encap, the ingress IPv6 encap test failed from time to time. The failure occured when an IPv4 ping through the IPv6 GRE encapsulation did not receive a reply within the timeout. The IPv4 ping and the IPv6 ping in the test used different timeouts (1 sec for IPv4 and 6 sec for IPv6), probably taking into account that IPv6 might need longer to successfully complete. However, when IPv4 pings (with the short timeout) are encapsulated into the IPv6 tunnel, the delays of IPv6 apply. The actual reason for the long delays with IPv6 was that the IPv6 neighbor discovery sometimes did not complete in time. This was caused by the outgoing interface only having a tentative link local address, i.e., not having completed DAD for that lladdr. The ND was successfully retried after 1 sec but that was too late for the ping timeout. The IPv6 addresses for the test were already added with nodad. However, for the lladdrs, DAD was still performed. We now disable DAD in the test netns completely and just assume that the two lladdrs on each veth pair do not collide. This removes all the delays for IPv6 traffic in the test. Without the delays, we can now also reduce the delay of the IPv6 ping to 1 sec. This makes the whole test complete faster because we don't need to wait for the excessive timeout for each IPv6 ping that is supposed to fail. Fixes: 0fde56e4385b0 ("selftests: bpf: add test_lwt_ip_encap selftest") Signed-off-by: Felix Maurer <fmaurer@redhat.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/4987d549d48b4e316cd5b3936de69c8d4bc75a4f.1646305899.git.fmaurer@redhat.com
2022-03-08ARM: include unprivileged BPF status in Spectre V2 reportingRussell King (Oracle)1-0/+13
The mitigations for Spectre-BHB are only applied when an exception is taken, but when unprivileged BPF is enabled, userspace can load BPF programs that can be used to exploit the problem. When unprivileged BPF is enabled, report the vulnerable status via the spectre_v2 sysfs file. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2022-03-08ACPI / x86: Add skip i2c clients quirk for Lenovo Yoga Tablet 1050F/LHans de Goede1-0/+12
The Yoga Tablet 1050F/L is a x86 ACPI tablet which ships with Android x86 as factory OS. Its DSDT contains a bunch of I2C devices which are not actually there, causing various resource conflicts (the Android x86 kernel fork ignores I2C devices described in the DSDT). Add a ACPI_QUIRK_SKIP_I2C_CLIENTS for the Nextbook Ares 8 to the acpi_quirk_skip_dmi_ids table to woraround this. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-03-08ACPI / x86: Add skip i2c clients quirk for Nextbook Ares 8Hans de Goede1-0/+9
The Nextbook Ares 8 is a x86 ACPI tablet which ships with Android x86 as factory OS. Its DSDT contains a bunch of I2C devices which are not actually there, causing various resource conflicts (the Android x86 kernel fork ignores I2C devices described in the DSDT). Add a ACPI_QUIRK_SKIP_I2C_CLIENTS for the Nextbook Ares 8 to the acpi_quirk_skip_dmi_ids table to woraround this. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-03-08clk: at91: clk-master: remove dead codeClaudiu Beznea13-134/+18
Commit facb87ad7560 ("clk: at91: sama7g5: remove prescaler part of master clock") removed the master clock's prescaler from clock tree of SAMA7G5 as it has been discovered that there is a hardware bug when trying to change it at run-time (bug is described in description of commit facb87ad7560 ("clk: at91: sama7g5: remove prescaler part of master clock")). This was previously changed at CPUFreq driver request. Thus, with commit facb87ad7560 ("clk: at91: sama7g5: remove prescaler part of master clock") there is no need of code that handles run-time changes of master clock's prescaler, thus remove this code. Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20220203110202.18329-1-claudiu.beznea@microchip.com
2022-03-08bpf: Determine buf_info inside check_buffer_access()Shung-Hsi Yu1-9/+3
Instead of determining buf_info string in the caller of check_buffer_access(), we can determine whether the register type is read-only through type_is_rdonly_mem() helper inside check_buffer_access() and construct buf_info, making the code slightly cleaner. Signed-off-by: Shung-Hsi Yu <shung-hsi.yu@suse.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Yonghong Song <yhs@fb.com> Link: https://lore.kernel.org/bpf/YiWYLnAkEZXBP/gH@syu-laptop
2022-03-08clk: at91: sama7g5: fix parents of PDMCs' GCLKCodrin Ciubotariu1-4/+4
Audio PLL can be used as parent by the GCLKs of PDMCs. Fixes: cb783bbbcf54 ("clk: at91: sama7g5: add clock support for sama7g5") Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com> Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20220304182616.1920392-1-codrin.ciubotariu@microchip.com
2022-03-08KVM: x86/mmu: Defer TLB flush to caller when freeing TDP MMU shadow pagesSean Christopherson3-14/+26
Defer TLB flushes to the caller when freeing TDP MMU shadow pages instead of immediately flushing. Because the shadow pages are freed in an RCU callback, so long as at least one CPU holds RCU, all CPUs are protected. For vCPUs running in the guest, i.e. consuming TLB entries, KVM only needs to ensure the caller services the pending TLB flush before dropping its RCU protections. I.e. use the caller's RCU as a proxy for all vCPUs running in the guest. Deferring the flushes allows batching flushes, e.g. when installing a 1gb hugepage and zapping a pile of SPs. And when zapping an entire root, deferring flushes allows skipping the flush entirely (because flushes are not needed in that case). Avoiding flushes when zapping an entire root is especially important as synchronizing with other CPUs via IPI after zapping every shadow page can cause significant performance issues for large VMs. The issue is exacerbated by KVM zapping entire top-level entries without dropping RCU protection, which can lead to RCU stalls even when zapping roots backing relatively "small" amounts of guest memory, e.g. 2tb. Removing the IPI bottleneck largely mitigates the RCU issues, though it's likely still a problem for 5-level paging. A future patch will further address the problem by zapping roots in multiple passes to avoid holding RCU for an extended duration. Reviewed-by: Ben Gardon <bgardon@google.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20220226001546.360188-20-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-08KVM: x86/mmu: Do remote TLB flush before dropping RCU in TDP MMU reschedSean Christopherson1-2/+2
When yielding in the TDP MMU iterator, service any pending TLB flush before dropping RCU protections in anticipation of using the caller's RCU "lock" as a proxy for vCPUs in the guest. Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Ben Gardon <bgardon@google.com> Message-Id: <20220226001546.360188-19-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-08KVM: x86/mmu: Zap only TDP MMU leafs in kvm_zap_gfn_range()Sean Christopherson3-39/+14
Zap only leaf SPTEs in the TDP MMU's zap_gfn_range(), and rename various functions accordingly. When removing mappings for functional correctness (except for the stupid VFIO GPU passthrough memslots bug), zapping the leaf SPTEs is sufficient as the paging structures themselves do not point at guest memory and do not directly impact the final translation (in the TDP MMU). Note, this aligns the TDP MMU with the legacy/full MMU, which zaps only the rmaps, a.k.a. leaf SPTEs, in kvm_zap_gfn_range() and kvm_unmap_gfn_range(). Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Ben Gardon <bgardon@google.com> Message-Id: <20220226001546.360188-18-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-08KVM: x86/mmu: Require mmu_lock be held for write to zap TDP MMU rangeSean Christopherson1-18/+6
Now that all callers of zap_gfn_range() hold mmu_lock for write, drop support for zapping with mmu_lock held for read. That all callers hold mmu_lock for write isn't a random coincidence; now that the paths that need to zap _everything_ have their own path, the only callers left are those that need to zap for functional correctness. And when zapping is required for functional correctness, mmu_lock must be held for write, otherwise the caller has no guarantees about the state of the TDP MMU page tables after it has run, e.g. the SPTE(s) it zapped can be immediately replaced by a vCPU faulting in a page. Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Ben Gardon <bgardon@google.com> Message-Id: <20220226001546.360188-17-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-08KVM: x86/mmu: Add dedicated helper to zap TDP MMU root shadow pageSean Christopherson1-16/+82
Add a dedicated helper for zapping a TDP MMU root, and use it in the three flows that do "zap_all" and intentionally do not do a TLB flush if SPTEs are zapped (zapping an entire root is safe if and only if it cannot be in use by any vCPU). Because a TLB flush is never required, unconditionally pass "false" to tdp_mmu_iter_cond_resched() when potentially yielding. Opportunistically document why KVM must not yield when zapping roots that are being zapped by kvm_tdp_mmu_put_root(), i.e. roots whose refcount has reached zero, and further harden the flow to detect improper KVM behavior with respect to roots that are supposed to be unreachable. In addition to hardening zapping of roots, isolating zapping of roots will allow future simplification of zap_gfn_range() by having it zap only leaf SPTEs, and by removing its tricky "zap all" heuristic. By having all paths that truly need to free _all_ SPs flow through the dedicated root zapper, the generic zapper can be freed of those concerns. Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Ben Gardon <bgardon@google.com> Message-Id: <20220226001546.360188-16-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-08KVM: x86/mmu: Skip remote TLB flush when zapping all of TDP MMUSean Christopherson1-5/+6
Don't flush the TLBs when zapping all TDP MMU pages, as the only time KVM uses the slow version of "zap everything" is when the VM is being destroyed or the owning mm has exited. In either case, KVM_RUN is unreachable for the VM, i.e. the guest TLB entries cannot be consumed. Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Ben Gardon <bgardon@google.com> Message-Id: <20220226001546.360188-15-seanjc@google.com> Reviewed-by: Mingwei Zhang <mizhang@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-08KVM: x86/mmu: Zap only the target TDP MMU shadow page in NX recoverySean Christopherson4-24/+39
When recovering a potential hugepage that was shattered for the iTLB multihit workaround, precisely zap only the target page instead of iterating over the TDP MMU to find the SP that was passed in. This will allow future simplification of zap_gfn_range() by having it zap only leaf SPTEs. Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20220226001546.360188-14-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-08KVM: x86/mmu: Refactor low-level TDP MMU set SPTE helper to take raw valuesSean Christopherson1-20/+31
Refactor __tdp_mmu_set_spte() to work with raw values instead of a tdp_iter objects so that a future patch can modify SPTEs without doing a walk, and without having to synthesize a tdp_iter. No functional change intended. Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Ben Gardon <bgardon@google.com> Message-Id: <20220226001546.360188-13-seanjc@google.com> Reviewed-by: Mingwei Zhang <mizhang@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-08KVM: x86/mmu: WARN if old _or_ new SPTE is REMOVED in non-atomic pathSean Christopherson1-2/+2
WARN if the new_spte being set by __tdp_mmu_set_spte() is a REMOVED_SPTE, which is called out by the comment as being disallowed but not actually checked. Keep the WARN on the old_spte as well, because overwriting a REMOVED_SPTE in the non-atomic path is also disallowed (as evidence by lack of splats with the existing WARN). Fixes: 08f07c800e9d ("KVM: x86/mmu: Flush TLBs after zap in TDP MMU PF handler") Cc: Ben Gardon <bgardon@google.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Ben Gardon <bgardon@google.com> Message-Id: <20220226001546.360188-12-seanjc@google.com> Reviewed-by: Mingwei Zhang <mizhang@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-08KVM: x86/mmu: Add helpers to read/write TDP MMU SPTEs and document RCUSean Christopherson3-6/+22
Add helpers to read and write TDP MMU SPTEs instead of open coding rcu_dereference() all over the place, and to provide a convenient location to document why KVM doesn't exempt holding mmu_lock for write from having to hold RCU (and any future changes to the rules). No functional change intended. Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Ben Gardon <bgardon@google.com> Message-Id: <20220226001546.360188-11-seanjc@google.com> Reviewed-by: Mingwei Zhang <mizhang@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>