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>
The function device_create_file() in huawei_wmi_battery_add() can fail,
so its return value should be checked.
Fixes: 355a070b09 ("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>
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
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEm+Rq3+YGJdiR9yuFh9CWnEQHBwQFAmImX64ACgkQh9CWnEQH
BwRKhQ//RUIUtJqWOZNMkvspu2VaIOa4DeDFXHQ2F8X7hoRsRw93mksxk90xBuIG
Oz4UdzF5D0cKwXdlNWeJ3V8er6qSkl5V37Z0iBUft6n1vYiqPzQHAG7lvI3r0ZNX
Ial9H1TLuT36CeubcUlb88ztPvMZYDPoUDFQv8GKoavGldwMithoHe6SZ3SFGFVh
/lzRyqJImJR3wITZJboLdyqkUvksj1lofR0kRM25bNZ1QeDxzEdA48svZYnexnGh
PNPGvuhNlT63CBSdteXs5lU2pmt6OhaxUH6Vl9dWE5LznqCrEPAlSy6jiNsymgHp
GqijueWGQyVQYqCE2T0VNowCTLY1a3bl7rFQUigZLCurbqYr932GwZP+r/1/xfqI
pP96QjA/Fz4fjuH9yZ30dTCB3xe69GurM80V3udNi1nr8ExDjOY/3rmrEmKVLKDR
Y94wgzjgzy1Wopvnzu9CtlabixQ7sv0NLJB6YjSSqc+ziBZsnJOl0+b7hWaBTuno
UxBY3pIsekBg4MP6evPHs8muUHO9STXijDwnny6tNj5o/usGrfWIBtilNYnAYg/1
/3UWnDArcV+/zpRhIwsAwYb19pUBOQCpKFLdZYw4yNss12KLqxvmA3fe6JXAu9HF
bmCUEjAwuf3mtEN41V8Tjyp3ftuh7rO3VVjDuT72VfYiEh2QtKU=
=nJaL
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmIndl0ACgkQmmx57+YA
GNk5PhAAxL+CTTI8nidIhzO5kO/KZ4NIb7LO/QnMWknn+HeUdXPl0GDRyIpsXml9
X5qcIzL4Npj0U8+UAHYarT6ngDcj8EZDWv+H5zRmt5qXSNhpfnlm+1OEgicy8Y1u
XwgIfLtGbdE9w05i9fPPtSIjoAjMQpJEplOkKKzex3k8GN653dT8bLm/manevoL7
7Sn27jxfQUcRM10QOJcWmF1fqgdl542J31bE4xl1axXww1Fa6aoZAXeeh+XlO8KB
oXJhcw4HLW7LKpZUESCwTiXS7fymSgp73U2bRhr41g40BPzt8wJbmS5MMsY7eiLP
9+kgfswtDrNt5NBDHFye71bU1YXvIAdcWkexlJfio8bsv8HweS+hU61+jpULpbtp
EzttCHoljyyAIpnjOMe7mrQKsm4hTnTcB0vKBgZqpxAlLZaoKcrkknfZz57nwcHL
xLtkug5lEp6jIXtAAQAYZ5ZwkQCUo4oaHlN16DypGvAsvSUd3UjQbLJBtfb7joac
wQ8stJQGhMcSzjyiOAEwSHqJeau9uJ03xWHrKNYPAx8aj5eVtNLMXxNcq69mzMvb
BbDUt8SMedxxficxteZfC3tkoH6CQ+zOHSEAzm/A+Q0GvJkxOkyDt6IW+BE30bGE
vDzfJmwBrf2N8FhnkbJsob+vlWZuAz4ezM5q8i4zHx6U2MoSc3I=
=B+QM
-----END PGP SIGNATURE-----
Merge tag 'arm-soc/for-5.18/devicetree-arm64' of https://github.com/Broadcom/stblinux into arm/dt
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>
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
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEm+Rq3+YGJdiR9yuFh9CWnEQHBwQFAmImXvIACgkQh9CWnEQH
BwTVXxAAoyyP5yDDRysvcEoK0bgNnInp2RyVbYPgI/lMCkn5Ngs/9jTPEveVO3hq
UOljI3uqmi4h+K+bLp7NpqybiueFH/92t26J2V+mqRQ7G1ivKnHXh08B3LBv5OU0
IeOQgUwe+lQLlb6boH4O7dvju/3cnBpJUGW4KZpAzjxtmyRjekutmd+dIlkJr7zM
jvNT+MLvpapCECWgXYo0km7TP1SnIB9TG1EWFPvf7YjYfBhroLEeKQS7K1VANtjG
sVP0FVAuiXRx4cs751EnGoIR2Nla+XrbYrJxZBya81xAZ3rCzwjxbGztdCFDqm5j
gf4D3Ww4NZHVIONOJOWGy7c6KIU1aiSGPzNaqK8rNGyxRH6cmavh5QEIEb6fSQOH
9Gyg0aEbxxaH/j75pa4e60pbivise7+TI1yN23aJDTaIKTEYtkSADVZw3PW++il6
kIOaCGmOaYHMQRCByjTxg6soqbaaSuUZ/A1Frh1Ox/EpfU+6N04+RC+D2OPuSPT/
yuN0P3gYo8/Le1Zv1RB2+0CmNsgrAiRFy9kbD//6WEOaa7r7t3z4RTfFduGrZF2R
XtxDatKKqIkNpWmHp0s2g28QXcDow1mnM/x6g6aA2UR8rCj7mg/odULZyxqStGxj
ehh0M7gZo1P92HVf+HT5A6t/jXk+HEw0xddRh+xdzzrd+JHwTUo=
=ZPvV
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmIndXEACgkQmmx57+YA
GNm+zA//RCHiiWwfAgJXPquuZcdcioZw2R451MmvgfVA1ST2hTZexL2jkHym6X/b
UE01YttV0A82JNWy+4zxMVkTefjhbp+rSNSSlMHN+Z3SXIXOZSIEW3eWc+D6UCqw
/XQx8wthJUDCPdGw+e1sW8GqcagY6uwa2xyrBGlhQu9uv7Waor+Q6rbUOKRCr9oD
j4o3wFdBFrMRCg6AzGhchDJ7454C87Nc6hC5xpst9za2O+4uU6LE3GOMuWEHQmTz
hsqkuOPvMNW+6dXicC6nihRUdRS6Km781VFtc5+7xRvPRqpzdAhi83dJz0KmL/Aq
mucnIn+hfPvL6DMGUzSLh+fGR3e2m7586RA7IeRA2Bd/xyJsEBZr59iXg+qhde3V
0odwGqRNWPR5XKOhkSTBW5+JJZveCk7QcLvIYdfPMiNMSEBCSt8M46golgWTmbgA
RB7cOzp5OPUjNmKKN2io4VO6pmnsFUT5ygR652x7LgpX/5t5nanjrOAOQJbObEid
kgO8lFd2arOBW530x6xAyW/RGNZ7rbrCQVoa1jXD5lP1V3isGl32weNp5+dC1OeF
IvEeU7chZli0dXpmKuD8tKU4M0XStBmMYQJHu44UArjYeB4gSR/aYztkaUhX01Aj
jWILMQPMgfvEXb6NYqqxgJhmNpbscwLfhUHDu0gUJ2IhBwRKwTw=
=8qCg
-----END PGP SIGNATURE-----
Merge tag 'arm-soc/for-5.18/devicetree' of https://github.com/Broadcom/stblinux into arm/dt
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>
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
e496132ebe ("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: e496132ebe ("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
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
