These casts need to happen before the shift. The only time it would
matter would be if "rev.core" is >= 128. In that case the sign bit
would be extended and we do not want that.
Fixes: afab9d91d8 ("drm/msm/adreno: Expose speedbin to userspace")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Akhil P Oommen <quic_akhilpo@quicinc.com>
Link: https://lore.kernel.org/r/20220307133105.GA17534@kili
Signed-off-by: Rob Clark <robdclark@chromium.org>
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQSQHSd0lITzzeNWNm3h3BK/laaZPAUCYidm9QAKCRDh3BK/laaZ
PAWVAQCMbTjDZzjk3jPVaCR9xS4mhDfjnQGH6FJmykpheGy59gD6AvdDAtwYsiRq
alvwpDyeI6YVueBKst1joFFcnzKEPAU=
=sxAr
-----END PGP SIGNATURE-----
Merge tag 'fuse-fixes-5.17-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse
Pull fuse fixes from Miklos Szeredi:
- Fix an issue with splice on the fuse device
- Fix a regression in the fileattr API conversion
- Add a small userspace API improvement
* tag 'fuse-fixes-5.17-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse:
fuse: fix pipe buffer lifetime for direct_io
fuse: move FUSE_SUPER_MAGIC definition to magic.h
fuse: fix fileattr op failure
- Make EL1 vectors per-cpu
- Add mitigation sequences to the EL1 and EL2 vectors on vulnerble CPUs
- Implement ARCH_WORKAROUND_3 for KVM guests
- Report Vulnerable when unprivileged eBPF is enabled
-----BEGIN PGP SIGNATURE-----
iQJIBAABCgAyFiEEmVzZdC2f8yLvolS4hFk2x3H8xgYFAmImQMAUHGphbWVzLm1v
cnNlQGFybS5jb20ACgkQhFk2x3H8xgZPtw//atLbMQvEiUdOUfuwZFA2iwRKQ2xn
DHDRwN2BBQRT4EPowGGYU/IyGJ/1Mm3JbxRa8uxVsUtd+BTxg9IaUIikHewDP0Pb
JuiSs5QneA6TErzH0qiFAPCgpzeO2P8I3vm18IsOmHYi5P8+ZvR7FKC5x/nXfcdO
zZE/vag69hnZzyw1fpG95/MDUR5uN3eM1Y1pexltmQZjhnOyfghBbCpp4itJ5u2n
FtTXT0A1pTJqjGFujEqBZa7B57ymf+cpZxatsSywK7Lr97iKR7L6As5FBRN0ECEs
NTZRsWjgRdoOnk1pk5TqJWnctjCvrkLafvu82aiRb9S4uTDI+U85K8yqPna9Wjq+
63ChQu8s/RTfP395ao55HIySynWYo5FTf2WJ8RXQKEJ6wAI0SLgcO1VfAGq/veIy
sv+OzG1gh9VZ51fzkaG5vAsk1brjX3YD112xcN718sxaHgTT1y1dAGeG9NbjAU3B
wzrZEaNtDM2ZFtsGqBN5xOmKdeKOMp/jxiSmOu1nooEbMwHx0YKzpm/L5CbT7MvL
1b1jcK9uPRob6ZrtQIGEcP5Tkd4w0cNB6r/Ynh29z0nFhaxpsGLnqRIeuPjxJGxm
Kl4nAu2cb5fdfUzZckelaGEkVqBV3+9785fo4bFpRo96A/H+h4IB/OkEmwtAJvjY
hqJh/TliXoZwrZ8=
=bXPh
-----END PGP SIGNATURE-----
Merge tag 'arm64-spectre-bhb-for-v5.17-2' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull arm64 spectre fixes from James Morse:
"ARM64 Spectre-BHB mitigations:
- Make EL1 vectors per-cpu
- Add mitigation sequences to the EL1 and EL2 vectors on vulnerble
CPUs
- Implement ARCH_WORKAROUND_3 for KVM guests
- Report Vulnerable when unprivileged eBPF is enabled"
* tag 'arm64-spectre-bhb-for-v5.17-2' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
arm64: proton-pack: Include unprivileged eBPF status in Spectre v2 mitigation reporting
arm64: Use the clearbhb instruction in mitigations
KVM: arm64: Allow SMCCC_ARCH_WORKAROUND_3 to be discovered and migrated
arm64: Mitigate spectre style branch history side channels
arm64: proton-pack: Report Spectre-BHB vulnerabilities as part of Spectre-v2
arm64: Add percpu vectors for EL1
arm64: entry: Add macro for reading symbol addresses from the trampoline
arm64: entry: Add vectors that have the bhb mitigation sequences
arm64: entry: Add non-kpti __bp_harden_el1_vectors for mitigations
arm64: entry: Allow the trampoline text to occupy multiple pages
arm64: entry: Make the kpti trampoline's kpti sequence optional
arm64: entry: Move trampoline macros out of ifdef'd section
arm64: entry: Don't assume tramp_vectors is the start of the vectors
arm64: entry: Allow tramp_alias to access symbols after the 4K boundary
arm64: entry: Move the trampoline data page before the text page
arm64: entry: Free up another register on kpti's tramp_exit path
arm64: entry: Make the trampoline cleanup optional
KVM: arm64: Allow indirect vectors to be used without SPECTRE_V3A
arm64: spectre: Rename spectre_v4_patch_fw_mitigation_conduit
arm64: entry.S: Add ventry overflow sanity checks
Add compatible and port configuration for spi controller
for Tesla Full Self-Driving SoC.
Cc: linux-fsd@tesla.com
Signed-off-by: Aswani Reddy <aswani.reddy@samsung.com>
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Reviewed-by: Andi Shyti <andi@etezian.org>
Link: https://lore.kernel.org/r/20220308121640.27344-2-alim.akhtar@samsung.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Adds spi controller dt-binding compatible information for
Tesla Full Self-Driving (FSD) SoC.
Cc: linux-fsd@tesla.com
Signed-off-by: Adithya K V <adithya.kv@samsung.com>
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Reviewed-by: Andi Shyti <andi@etezian.org>
Link: https://lore.kernel.org/r/20220308121640.27344-1-alim.akhtar@samsung.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Convert the TPS62360 regulator binding to DT schema format
using json-schema.
This also removes redundant "ti,enable-force-pwm" property
from the example. The property description was removed from the
original text binding file by commit 9a00630c3d ("regulator:
tps62360: support force PWM mode via regulator mode"), but a
reference to it remained in the example.
Signed-off-by: Georgi Vlaev <g-vlaev@ti.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
Link: https://lore.kernel.org/r/20220308134454.14504-1-g-vlaev@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Krishna Yarlagadda <kyarlagadda@nvidia.com>:
Add ACPI support for Tegra210 QUAD SPI driver Support new Tegra194
feature, combined sequence mode.
Merge series from Ranjani Sridharan <ranjani.sridharan@linux.intel.com>:
In preparation for adding support for the new IPC version that has been
introduced in the SOF firmware, this patch set includes some clean ups
and necessary modifications to commonly used functions that will be
re-used across different IPC-specific code.
Merge series from Codrin Ciubotariu <codrin.ciubotariu@microchip.com>:
This patch series adds support for Pulse Density Microphone Controller
(PDMC), present on Microchip's SAMA7G5.
The PDMC interfaces up to 4 digital microphones having Pulse Density
Modulated (PDM) outputs. It generates a single clock line and samples 1 or
2 data lines. The signal path includes an audio grade programmable
decimation filter and outputs 24-bit audio words.
The source of each channel can be independently defined as PDMC_DS0 or
PDMC_DS1, sampled at the rising or falling edge of PDMC_CLK.
The patch series starts with a fix on the ASoC DMA engine support. Then
continues with the bindings and the driver of PDMC. It is followed by the
DT nodes for SAMA7G5 and SAMA7G5-EK. In the end, the drivers for PDMC
and PDM microphones are enabled in sama7_defconfig.
These patches add Spectre BHB migitations for the following Arm CPUs to
the 32-bit ARM kernels:
Cortex-A15
Cortex-A57
Cortex-A72
Cortex-A73
Cortex A75
Brahma B15
for CVE-2022-23960.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEuNNh8scc2k/wOAE+9OeQG+StrGQFAmInch4ACgkQ9OeQG+St
rGT62Q//Xve9O5C6d3I+7hwzVUGgRmYszrLRqLDG2qFP3Vw7hx1VygFRovKiFPD5
jvVHWMIC6Yev4D7N2DjXpmfULOrL7277EX31QFpdtkvNR5WrSAV7ku0mJm4UmE6+
WWo3l7d7WfxnbN7ZhRpISYc6aPm0/oYhH6Oux0FXe9eKWVr+hnNjVqBVaoSbnomy
AcYhh1yy3p680zKvarUndLkYPgCPiCci7+IozxD4MfBV/M5IlIDawW9P0lxMgMZR
ZbUe6t2k1Tis2EH2gKtj7KB0sDxAUnMD8tWYQylYsBM8wIINLDifuMSBrgU4ZcML
3stf7IBynn7oA8U+4jrIwc1OEBj64UYqQEPTqg8jaogAB+JfPINNxp7Byq1LnuJm
iwnmgeapQLRR3sh2jx8C4Boexv9KyIYAhIc2MkciyUlLbBWABLPNxp5cycz5znUr
mSBPeSj2F0A10LdPT8NauHJj8m2j1U67tyBcRFO6z+T6+krR6zk+Aiqb/XyWOQbN
Fe3D0SqOw5bd8hDenO5wGqQAuPpKhQhIo+XsbxckQ3jMtFKAABGkCW08gTTmfeDg
kg56GCvedrzGdZs7xkAzJ/o/AtNxYNdYjWnfc+zJmkLMPbt2qunL7yUkwOuiru29
biCMyw6j0afPpt7ScJAASTKyuaUgE3HxxWTnk1rgCsl3Ho8MeLU=
=VHyX
-----END PGP SIGNATURE-----
Merge tag 'for-linus-bhb' of git://git.armlinux.org.uk/~rmk/linux-arm
Pull ARM spectre fixes from Russell King:
"ARM Spectre BHB mitigations.
These patches add Spectre BHB migitations for the following Arm CPUs
to the 32-bit ARM kernels:
- Cortex A15
- Cortex A57
- Cortex A72
- Cortex A73
- Cortex A75
- Brahma B15
for CVE-2022-23960"
* tag 'for-linus-bhb' of git://git.armlinux.org.uk/~rmk/linux-arm:
ARM: include unprivileged BPF status in Spectre V2 reporting
ARM: Spectre-BHB workaround
ARM: use LOADADDR() to get load address of sections
ARM: early traps initialisation
ARM: report Spectre v2 status through sysfs
Convert the Qualcomm Universal Flash Storage (UFS) Controller to DT
schema format.
Except the conversion, add also properties already present in DTS:
iommus, interconnects and power-domains.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20220306111125.116455-6-krzysztof.kozlowski@canonical.com
The Qualcomm UFS PHY bindings are documented in
bindings/phy/qcom,qmp-phy.yaml and the compatibles from separate file
bindings/ufs/ufs-qcom.txt are not used at all.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20220306111125.116455-5-krzysztof.kozlowski@canonical.com
Use common UFS bindings in Samsung Exynos UFS to cover generic/common
properties in DTS.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20220306111125.116455-3-krzysztof.kozlowski@canonical.com
Add bindings for common parts (platform) of Universal Flash Storage
(UFS) Host Controllers in dtschema format.
Include also the bindings directory in the UFS maintainers entry.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20220306111125.116455-2-krzysztof.kozlowski@canonical.com
On some boards, for routing CAN signals from controller to transceivers,
muxes might need to be set. This can be implemented using mux-states
property. Therefore, document the same in the respective bindings.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20211216041012.16892-2-a-govindraju@ti.com
The recent addition pinctrl.yaml in commit c09acbc499 ("dt-bindings:
pinctrl: use pinctrl.yaml") resulted in some node name warnings:
Documentation/devicetree/bindings/mfd/cirrus,lochnagar.example.dt.yaml: \
lochnagar-pinctrl: $nodename:0: 'lochnagar-pinctrl' does not match '^(pinctrl|pinmux)(@[0-9a-f]+)?$'
Documentation/devicetree/bindings/mfd/cirrus,madera.example.dt.yaml: \
codec@1a: $nodename:0: 'codec@1a' does not match '^(pinctrl|pinmux)(@[0-9a-f]+)?$'
Documentation/devicetree/bindings/mfd/brcm,cru.example.dt.yaml: \
pin-controller@1c0: $nodename:0: 'pin-controller@1c0' does not match '^(pinctrl|pinmux)(@[0-9a-f]+)?$'
Fix the node names to the preferred 'pinctrl'. For cirrus,madera,
nothing from pinctrl.yaml schema is used, so just drop the reference.
Fixes: c09acbc499 ("dt-bindings: pinctrl: use pinctrl.yaml")
Cc: Rafał Miłecki <rafal@milecki.pl>
Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20220303232350.2591143-1-robh@kernel.org
I'm leaving synaptics. Update my email address to my korg mail
address and add entries to .mailmap as well to map my work
addresses to korg mail address.
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/ce7213bd-28ac-6580-466e-875e755fe0ae@synaptics.com'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
This was a prerequisite for the ill-fated
"netfilter: nat: force port remap to prevent shadowing well-known ports".
As this has been reverted, this change can be backed out too.
Signed-off-by: Florian Westphal <fw@strlen.de>
pull the following for 5.18:
- Kuldeep updates the Broadcom iProc entry to use the same up to date
Linux tree as the other Broadcom SoCs.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEm+Rq3+YGJdiR9yuFh9CWnEQHBwQFAmImYUUACgkQh9CWnEQH
BwSmzRAAgluapoDgyGV15Lp10XZHQWvz45RTEEcGouaZalS8nZy7UmdN6gWgv/N7
7ekRiZJr1x6ihLIa5jrYsRWJIFNjb2Ekx8J2H0dggMSS3NX73Vlnv+rEgoKbUjj2
wh3JoKTdZSyFdpnSPgis1ON9m/MCJiAQ9cTi0lnzKLMjbMi1qzIAkO/GFzIvzzSj
dcFQtBZEwcQ1J751XXekhSHRxQqTLLS3ijXTpcgPNMBriJD0cTpBhtdwGWFq5LRg
idy01bd9WZY4D62XqmWFzFGd1/Ke+wPUJh55yyCmfx8Ay2xFNVbX1bhmj2yvYMlV
NT5Wuo0UDirMaj007e0xaSl0aBBPNSIpuQNPhpB7IBUknqJ2GJG5CYk+4YBwfXAY
CvMimtuDMmTg1c2qfB13VN1eRt36B2EXVbEa4ejb6C8+Jjj1cvrOtAwpTfhtzi+3
TXA+OU+3UaVhj2iDnWKoC65h4+1EqUMW4l0Jc/K8/349iZU3cGmK1lRNG5WjSuhT
oNZQzBjGwfQ4tErQUGX3ufK4ZIFjSpqgDSp30AzQGk7ehBMr8sUBBUamgqpS1mMx
+dGVmQH2xK5B0st2uA4WK0w/McL9oVPdKhCh9Ov9JxW9Q8f4U321wUhhhOg4c0m1
gRol3D2svUQ4+rQ9t2ceVWq6eR23E+hwiJg0X7NyHQEM1mrzmpY=
=6Bpd
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmIng3QACgkQmmx57+YA
GNlIOQ/9HVXUlBbPOemm4Tlz77zXE4HqTS+hBX+Vxyd/+UbmEmLG+8sXPXkWH3nb
HbC8jTFb9sP8PL2Fy/NJexY8NhhvzkaFDm+Gcccj1K7uHFFCIACXH2HNORo8EDIW
kTjuznKF5ZWOOskv9Zwmkfwe5amEeZ5WvnMkg4qUUXA7hh2G4UCsk88kGM8WetxS
06wWrTIwajlP1PbpA6YgOwO0/EoFU5djLJG0RcJ3z1CE6AC4WPFNhiyI1AuVNBvD
MzjTcLtyzzF3ondEisCcwgKoHSpXNZNPXfstWVhuv7xoAcNqUbBsO2Pjm4Y/ZBTq
3xtDsSyGYwULEf7+AC5tUZ9AfcVahZZuZOft1bxpeIvq/kKdxd5CzAXY0HZTAn5M
VsH4+PYSx75bXG9mHUiWQU3jqmvo1zgwmCn9U3KJLV/X+Mfbj/SK37ScwOQeWtDs
oa3JT9qTMb6hiCnU6jKGq09pADSwZSuOvU/3rKXCZEzdLG4XS0VKeIdmrALVJNNA
02vJZYX9c6HBdxldCnYTsjR5qcsVmjmhKrH/ST+auyRBzwwizyBW7oBUTDdzrQxe
C/xyul6VloaJ5A22n4bnnpOf4DMeUSyZ3Y4l9T3Tyqpqw3by2ii+d7XYfDnu/VdO
X/0teNoKKKhSY+LD1VJQYfOkZdk61KNMcE8Na4BRrSPRxzXc4ec=
=jhBt
-----END PGP SIGNATURE-----
Merge tag 'arm-soc/for-5.18/maintainers' of https://github.com/Broadcom/stblinux into arm/fixes
This pull request updates the MAINTAINERS file for Broadcom SoCs, please
pull the following for 5.18:
- Kuldeep updates the Broadcom iProc entry to use the same up to date
Linux tree as the other Broadcom SoCs.
* tag 'arm-soc/for-5.18/maintainers' of https://github.com/Broadcom/stblinux:
MAINTAINERS: Update git tree for Broadcom iProc SoCs
Link: https://lore.kernel.org/r/20220307194817.3754107-4-f.fainelli@gmail.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Expand KVM's mask for the AVIC host physical ID to the full 12 bits defined
by the architecture. The number of bits consumed by hardware is model
specific, e.g. early CPUs ignored bits 11:8, but there is no way for KVM
to enumerate the "true" size. So, KVM must allow using all bits, else it
risks rejecting completely legal x2APIC IDs on newer CPUs.
This means KVM relies on hardware to not assign x2APIC IDs that exceed the
"true" width of the field, but presumably hardware is smart enough to tie
the width to the max x2APIC ID. KVM also relies on hardware to support at
least 8 bits, as the legacy xAPIC ID is writable by software. But, those
assumptions are unavoidable due to the lack of any way to enumerate the
"true" width.
Cc: stable@vger.kernel.org
Cc: Maxim Levitsky <mlevitsk@redhat.com>
Suggested-by: Sean Christopherson <seanjc@google.com>
Reviewed-by: Sean Christopherson <seanjc@google.com>
Fixes: 44a95dae1d ("KVM: x86: Detect and Initialize AVIC support")
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Message-Id: <20220211000851.185799-1-suravee.suthikulpanit@amd.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Add a selftest that enables populating a VM with the maximum amount of
guest memory allowed by the underlying architecture. Abuse KVM's
memslots by mapping a single host memory region into multiple memslots so
that the selftest doesn't require a system with terabytes of RAM.
Default to 512gb of guest memory, which isn't all that interesting, but
should work on all MMUs and doesn't take an exorbitant amount of memory
or time. E.g. testing with ~64tb of guest memory takes the better part
of an hour, and requires 200gb of memory for KVM's page tables when using
4kb pages.
To inflicit maximum abuse on KVM' MMU, default to 4kb pages (or whatever
the not-hugepage size is) in the backing store (memfd). Use memfd for
the host backing store to ensure that hugepages are guaranteed when
requested, and to give the user explicit control of the size of hugepage
being tested.
By default, spin up as many vCPUs as there are available to the selftest,
and distribute the work of dirtying each 4kb chunk of memory across all
vCPUs. Dirtying guest memory forces KVM to populate its page tables, and
also forces KVM to write back accessed/dirty information to struct page
when the guest memory is freed.
On x86, perform two passes with a MMU context reset between each pass to
coerce KVM into dropping all references to the MMU root, e.g. to emulate
a vCPU dropping the last reference. Perform both passes and all
rendezvous on all architectures in the hope that arm64 and s390x can gain
similar shenanigans in the future.
Measure and report the duration of each operation, which is helpful not
only to verify the test is working as intended, but also to easily
evaluate the performance differences different page sizes.
Provide command line options to limit the amount of guest memory, set the
size of each slot (i.e. of the host memory region), set the number of
vCPUs, and to enable usage of hugepages.
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20220226001546.360188-29-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Add cpu_relax() for s390 and x86 for use in arch-agnostic tests. arm64
already defines its own version.
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20220226001546.360188-28-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Extract the code for allocating guest memory via memfd out of
vm_userspace_mem_region_add() and into a new helper, kvm_memfd_alloc().
A future selftest to populate a guest with the maximum amount of guest
memory will abuse KVM's memslots to alias guest memory regions to a
single memfd-backed host region, i.e. needs to back a guest with memfd
memory without a 1:1 association between a memslot and a memfd instance.
No functional change intended.
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20220226001546.360188-27-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
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>
Disallow calling tdp_mmu_set_spte_atomic() with a REMOVED "old" SPTE.
This solves a conundrum introduced by commit 3255530ab1 ("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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
The "size" variable can be uninitialized if amd_pmc_send_cmd() fails.
Fixes: 3d7d407dfb ("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>
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: dbce412a77 ("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>
