kernel/linux.git/arch, branch v6.6.27

x86/xen: attempt to inflate the memory balloon on PVH

2024-04-13T11:07:39+00:00

[ Upstream commit 38620fc4e8934f1801c7811ef39a041914ac4c1d ] When running as PVH or HVM Linux will use holes in the memory map as scratch space to map grants, foreign domain pages and possibly miscellaneous other stuff. However the usage of such memory map holes for Xen purposes can be problematic. The request of holesby Xen happen quite early in the kernel boot process (grant table setup already uses scratch map space), and it's possible that by then not all devices have reclaimed their MMIO space. It's not unlikely for chunks of Xen scratch map space to end up using PCI bridge MMIO window memory, which (as expected) causes quite a lot of issues in the system. At least for PVH dom0 we have the possibility of using regions marked as UNUSABLE in the e820 memory map. Either if the region is UNUSABLE in the native memory map, or it has been converted into UNUSABLE in order to hide RAM regions from dom0, the second stage translation page-tables can populate those areas without issues. PV already has this kind of logic, where the balloon driver is inflated at boot. Re-use the current logic in order to also inflate it when running as PVH. onvert UNUSABLE regions up to the ratio specified in EXTRA_MEM_RATIO to RAM, while reserving them using xen_add_extra_mem() (which is also moved so it's no longer tied to CONFIG_PV). [jgross: fixed build for CONFIG_PVH without CONFIG_XEN_PVH] Signed-off-by: Roger Pau Monné Reviewed-by: Juergen Gross Link: https://lore.kernel.org/r/20240220174341.56131-1-roger.pau@citrix.com Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin

perf/x86/amd/lbr: Discard erroneous branch entries

2024-04-13T11:07:37+00:00

[ Upstream commit 29297ffffb0bf388778bd4b581a43cee6929ae65 ] The Revision Guide for AMD Family 19h Model 10-1Fh processors declares Erratum 1452 which states that non-branch entries may erroneously be recorded in the Last Branch Record (LBR) stack with the valid and spec bits set. Such entries can be recognized by inspecting bit 61 of the corresponding LastBranchStackToIp register. This bit is currently reserved but if found to be set, the associated branch entry should be discarded. Signed-off-by: Sandipan Das Signed-off-by: Ingo Molnar Cc: Peter Zijlstra Link: https://bugzilla.kernel.org/attachment.cgi?id=305518 Link: https://lore.kernel.org/r/3ad2aa305f7396d41a40e3f054f740d464b16b7f.1706526029.git.sandipan.das@amd.com Signed-off-by: Sasha Levin

PCI: Disable D3cold on Asus B1400 PCI-NVMe bridge

2024-04-13T11:07:36+00:00

[ Upstream commit cdea98bf1faef23166262825ce44648be6ebff42 ] The Asus B1400 with original shipped firmware versions and VMD disabled cannot resume from suspend: the NVMe device becomes unresponsive and inaccessible. This appears to be an untested D3cold transition by the vendor; Intel socwatch shows that Windows leaves the NVMe device and parent bridge in D0 during suspend, even though these firmware versions have StorageD3Enable=1. The NVMe device and parent PCI bridge both share the same "PXP" ACPI power resource, which gets turned off as both devices are put into D3cold during suspend. The _OFF() method calls DL23() which sets a L23E bit at offset 0xe2 into the PCI configuration space for this root port. This is the specific write that the _ON() routine is unable to recover from. This register is not documented in the public chipset datasheet. Disallow D3cold on the PCI bridge to enable successful suspend/resume. Link: https://bugzilla.kernel.org/show_bug.cgi?id=215742 Link: https://lore.kernel.org/r/20240228075316.7404-1-drake@endlessos.org Signed-off-by: Daniel Drake Signed-off-by: Bjorn Helgaas Acked-by: Jian-Hong Pan Acked-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

arm64: dts: rockchip: fix rk3399 hdmi ports node

2024-04-13T11:07:30+00:00

[ Upstream commit f051b6ace7ffcc48d6d1017191f167c0a85799f6 ] Fix rk3399 hdmi ports node so that it matches the rockchip,dw-hdmi.yaml binding. Signed-off-by: Johan Jonker Link: https://lore.kernel.org/r/a6ab6f75-3b80-40b1-bd30-3113e14becdd@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin

arm64: dts: rockchip: fix rk3328 hdmi ports node

2024-04-13T11:07:30+00:00

[ Upstream commit 1d00ba4700d1e0f88ae70d028d2e17e39078fa1c ] Fix rk3328 hdmi ports node so that it matches the rockchip,dw-hdmi.yaml binding. Signed-off-by: Johan Jonker Link: https://lore.kernel.org/r/e5dea3b7-bf84-4474-9530-cc2da3c41104@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin

ARM: dts: rockchip: fix rk322x hdmi ports node

2024-04-13T11:07:30+00:00

[ Upstream commit 15a5ed03000cf61daf87d14628085cb1bc8ae72c ] Fix rk322x hdmi ports node so that it matches the rockchip,dw-hdmi.yaml binding. Signed-off-by: Johan Jonker Link: https://lore.kernel.org/r/9b84adf0-9312-47fd-becc-cadd06941f70@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin

ARM: dts: rockchip: fix rk3288 hdmi ports node

2024-04-13T11:07:29+00:00

[ Upstream commit 585e4dc07100a6465b3da8d24e46188064c1c925 ] Fix rk3288 hdmi ports node so that it matches the rockchip,dw-hdmi.yaml binding with some reordering to align with the (new) documentation about property ordering. Signed-off-by: Johan Jonker Link: https://lore.kernel.org/r/cc3a9b4f-076d-4660-b464-615003b6a066@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin

x86: set SPECTRE_BHI_ON as default

2024-04-10T14:36:08+00:00

commit 2bb69f5fc72183e1c62547d900f560d0e9334925 upstream. Part of a merge commit from Linus that adjusted the default setting of SPECTRE_BHI_ON. Cc: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

KVM: x86: Add BHI_NO

2024-04-10T14:36:08+00:00

commit ed2e8d49b54d677f3123668a21a57822d679651f upstream. Intel processors that aren't vulnerable to BHI will set MSR_IA32_ARCH_CAPABILITIES[BHI_NO] = 1;. Guests may use this BHI_NO bit to determine if they need to implement BHI mitigations or not. Allow this bit to be passed to the guests. Signed-off-by: Daniel Sneddon Signed-off-by: Pawan Gupta Signed-off-by: Daniel Sneddon Signed-off-by: Thomas Gleixner Reviewed-by: Alexandre Chartre Reviewed-by: Josh Poimboeuf Signed-off-by: Daniel Sneddon Signed-off-by: Greg Kroah-Hartman

x86/bhi: Mitigate KVM by default

2024-04-10T14:36:08+00:00

commit 95a6ccbdc7199a14b71ad8901cb788ba7fb5167b upstream. BHI mitigation mode spectre_bhi=auto does not deploy the software mitigation by default. In a cloud environment, it is a likely scenario where userspace is trusted but the guests are not trusted. Deploying system wide mitigation in such cases is not desirable. Update the auto mode to unconditionally mitigate against malicious guests. Deploy the software sequence at VMexit in auto mode also, when hardware mitigation is not available. Unlike the force =on mode, software sequence is not deployed at syscalls in auto mode. Suggested-by: Alexandre Chartre Signed-off-by: Pawan Gupta Signed-off-by: Daniel Sneddon Signed-off-by: Thomas Gleixner Reviewed-by: Alexandre Chartre Reviewed-by: Josh Poimboeuf Signed-off-by: Daniel Sneddon Signed-off-by: Greg Kroah-Hartman