| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
To follow the existing per-arch conventions replace open-coded uses
of asm "sp" as "current_stack_pointer". This will let it be used in
non-arch places (like HARDENED_USERCOPY).
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Yanteng Si <siyanteng01@gmail.com>
Cc: linux-mips@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
|
|
The N5X platform has the Synopsys DDR controller the includes an EDAC
controller. Add the entry for the controller in the DTS file instead of
the base Agilex DTSI because the base Agilex does not have the
controller.
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
|
|
USB DWC2 requires clock-names:
arm64/boot/dts/altera/socfpga_stratix10_socdk_nand.dt.yaml:
usb@ffb00000: 'clock-names' is a required property
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
|
|
This expands generic branch type classification by adding two more entries
there in i.e irq and exception return. Also updates the x86 implementation
to process X86_BR_IRET and X86_BR_IRQ records as appropriate. This changes
branch types reported to user space on x86 platform but it should not be a
problem. The possible scenarios and impacts are enumerated here.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/1645681014-3346-1-git-send-email-anshuman.khandual@arm.com
|
|
Support 64-bit BAR size for discovery, and do not truncate return from
generic_uncore_mmio_box_ctl() to 32 bits.
Signed-off-by: Steve Wahl <steve.wahl@hpe.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Kan Liang <kan.liang@linux.intel.com>
Link: https://lore.kernel.org/r/20220218175418.421268-1-steve.wahl@hpe.com
|
|
Exit to userspace if setup_vmgexit_scratch() fails due to OOM or because
copying data from guest (userspace) memory failed/faulted. The OOM
scenario is clearcut, it's userspace's decision as to whether it should
terminate the guest, free memory, etc...
As for -EFAULT, arguably, any guest issue is a violation of the guest's
contract with userspace, and thus userspace needs to decide how to
proceed. E.g. userspace defines what is RAM vs. MMIO and communicates
that directly to the guest, KVM is not involved in deciding what is/isn't
RAM nor in communicating that information to the guest. If the scratch
GPA doesn't resolve to a memslot, then the guest is not honoring the
memory configuration as defined by userspace.
And if userspace unmaps an hva for whatever reason, then exiting to
userspace with -EFAULT is absolutely the right thing to do. KVM's ABI
currently sucks and doesn't provide enough information to act on the
-EFAULT, but that will hopefully be remedied in the future as there are
multiple use cases, e.g. uffd and virtiofs truncation, that shouldn't
require any work in KVM beyond returning -EFAULT with a small amount of
metadata.
KVM could define its ABI such that failure to access the scratch area is
reflected into the guest, i.e. establish a contract with userspace, but
that's undesirable as it limits KVM's options in the future, e.g. in the
potential uffd case any failure on a uaccess needs to kick out to
userspace. KVM does have several cases where it reflects these errors
into the guest, e.g. kvm_pv_clock_pairing() and Hyper-V emulation, but
KVM would preferably "fix" those instead of propagating the falsehood
that any memory failure is the guest's fault.
Lastly, returning a boolean as an "error" for that a helper that isn't
named accordingly never works out well.
Fixes: ad5b353240c8 ("KVM: SVM: Do not terminate SEV-ES guests on GHCB validation failure")
Cc: Alper Gun <alpergun@google.com>
Cc: Peter Gonda <pgonda@google.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20220225205209.3881130-1-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
mvebu arm for 5.18 (part 1)
gpio clean-up for Orion
* tag 'mvebu-arm-5.18-1' of git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu:
ARM: orion/gpio: Get rid of unused first parameter in orion_gpio_init()
Link: https://lore.kernel.org/r/87sfs1zrfn.fsf@BL-laptop
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
mvebu dt for 5.18 (part 1)
Add new 2 bays NAS:
- Ctera C200 V1 (kirkwood based)
- Ctera C200 V2 (armada-370 based)
Add support for PCIe legacy INTx interrupts on Armada 385
Add PCIe proprty to limit the power on miniPCIe slots in Turris Omnia
* tag 'mvebu-dt-5.18-1' of git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu:
ARM: dts: turris-omnia: Set PCIe slot-power-limit-milliwatt properties
ARM: dts: mvebu: Add Ctera C-200 V2 board
ARM: dts: kirkwood: Add Ctera C-200 V1 board
dt-bindings: vendor-prefixes: Add Ctera Networks
ARM: dts: armada-385.dtsi: Add definitions for PCIe legacy INTx interrupts
Link: https://lore.kernel.org/r/87pmn5zrd0.fsf@BL-laptop
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
mvebu dt64 for 5.18 (part 1)
Add PCIe clock resource for Armada 37xx
* tag 'mvebu-dt64-5.18-1' of git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu:
arm64: dts: marvell: armada-37xx: Add clock to PCIe node
Link: https://lore.kernel.org/r/87v8wxzrlo.fsf@BL-laptop
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
- add initial support for mt6582 and Prestigio PMT5008 3G tablet
- add basic support for Airoha EN7523
* tag 'v5.17-next-dts32' of git://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux:
ARM: dts: add GPIO support for Airoha EN7523
ARM: Add basic support for Airoha EN7523 SoC
dt-bindings: arm: airoha: Add binding for EN7523 SoC and EVB
dt-bindings: Add vendor prefix for Airoha
dt-bindings: mediatek: Adds a DT binding documentation for the MT6582 SoC
ARM: dts: Add initial support for Prestigio PMT5008 3G tablet
ARM: dts: Add initial support for Mediatek mt6582
Link: https://lore.kernel.org/r/3974dc7e-4185-4d88-ab5b-031a7d24214d@gmail.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
mt8192
- add clocks to the devices
- add watchdog node
- add power domain controller node
mt8183:
- add pmic (mt6358) key board node
- add JPEG enconder node
mt7986:
- update memory node
- add clock controller for mt7986a version
* tag 'v5.17-next-dts64' of git://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux:
arm64: dts: mediatek: update mt7986b memory node
arm64: dts: mediatek: update mt7986a memory node
arm64: dts: mediatek: add clock support for mt7986a
arm64: dts: mediatek: Add mt8192 power domains controller
arm64: dts: mt6358: add mt6358-keys node
arm64: dts: mt8183: add jpeg enc node for mt8183
arm64: dts: mt8192: Add watchdog node
arm64: dts: mediatek: Correct system timer clock of MT8192
arm64: dts: mediatek: Correct I2C clock of MT8192
arm64: dts: mediatek: Correct Nor Flash clock of MT8192
arm64: dts: mediatek: Correct SPI clock of MT8192
arm64: dts: mediatek: Correct uart clock of MT8192
Link: https://lore.kernel.org/r/c2064dcc-acdc-c86b-5ef7-cb8e7ae3122f@gmail.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
WARN and bail if is_unsync_root() is passed a root for which there is no
shadow page, i.e. is passed the physical address of one of the special
roots, which do not have an associated shadow page. The current usage
squeaks by without bug reports because neither kvm_mmu_sync_roots() nor
kvm_mmu_sync_prev_roots() calls the helper with pae_root or pml4_root,
and 5-level AMD CPUs are not generally available, i.e. no one can coerce
KVM into calling is_unsync_root() on pml5_root.
Note, this doesn't fix the mess with 5-level nNPT, it just (hopefully)
prevents KVM from crashing.
Cc: Lai Jiangshan <jiangshanlai@gmail.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20220225182248.3812651-8-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Add an arch request, KVM_REQ_REFRESH_GUEST_PREFIX, to deal with guest
prefix changes instead of piggybacking KVM_REQ_MMU_RELOAD. This will
allow for the removal of the generic KVM_REQ_MMU_RELOAD, which isn't
actually used by generic KVM.
No functional change intended.
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Reviewed-by: Janosch Frank <frankja@linux.ibm.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20220225182248.3812651-6-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Zap only obsolete roots when responding to zapping a single root shadow
page. Because KVM keeps root_count elevated when stuffing a previous
root into its PGD cache, shadowing a 64-bit guest means that zapping any
root causes all vCPUs to reload all roots, even if their current root is
not affected by the zap.
For many kernels, zapping a single root is a frequent operation, e.g. in
Linux it happens whenever an mm is dropped, e.g. process exits, etc...
Signed-off-by: Sean Christopherson <seanjc@google.com>
Reviewed-by: Ben Gardon <bgardon@google.com>
Message-Id: <20220225182248.3812651-5-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Remove the generic kvm_reload_remote_mmus() and open code its
functionality into the two x86 callers. x86 is (obviously) the only
architecture that uses the hook, and is also the only architecture that
uses KVM_REQ_MMU_RELOAD in a way that's consistent with the name. That
will change in a future patch, as x86's usage when zapping a single
shadow page x86 doesn't actually _need_ to reload all vCPUs' MMUs, only
MMUs whose root is being zapped actually need to be reloaded.
s390 also uses KVM_REQ_MMU_RELOAD, but for a slightly different purpose.
Drop the generic code in anticipation of implementing s390 and x86 arch
specific requests, which will allow dropping KVM_REQ_MMU_RELOAD entirely.
Opportunistically reword the x86 TDP MMU comment to avoid making
references to functions (and requests!) when possible, and to remove the
rather ambiguous "this".
No functional change intended.
Cc: Ben Gardon <bgardon@google.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Reviewed-by: Ben Gardon <bgardon@google.com>
Message-Id: <20220225182248.3812651-4-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Replace a KVM_REQ_MMU_RELOAD request with a direct kvm_mmu_unload() call
when the guest's CR4.PCIDE changes. This will allow tweaking the logic
of KVM_REQ_MMU_RELOAD to free only obsolete/invalid roots, which is the
historical intent of KVM_REQ_MMU_RELOAD. The recent PCIDE behavior is
the only user of KVM_REQ_MMU_RELOAD that doesn't mark affected roots as
obsolete, needs to unconditionally unload the entire MMU, _and_ affects
only the current vCPU.
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20220225182248.3812651-3-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Outer-privilege level return is not implemented in emulator,
move the unhandled logic into __load_segment_descriptor to
make it easier to understand why the checks for RET are
incomplete.
Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Hou Wenlong <houwenlong.hwl@antgroup.com>
Message-Id: <5b7188e6388ac9f4567d14eab32db9adf3e00119.1644292363.git.houwenlong.hwl@antgroup.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Code segment descriptor can be loaded by jmp/call/ret, iret
and int. The privilege checks are different between those
instructions above realmode. Although, the emulator has
use x86_transfer_type enumerate to differentiate them, but
it is not really used in __load_segment_descriptor(). Note,
far jump/call to call gate, task gate or task state segment
are not implemented in emulator.
As for far jump/call to code segment, if DPL > CPL for conforming
code or (RPL > CPL or DPL != CPL) for non-conforming code, it
should trigger #GP. The current checks are ok.
As for far return, if RPL < CPL or DPL > RPL for conforming
code or DPL != RPL for non-conforming code, it should trigger #GP.
Outer level return is not implemented above virtual-8086 mode in
emulator. So it implies that RPL <= CPL, but the current checks
wouldn't trigger #GP if RPL < CPL.
As for code segment loading in task switch, if DPL > RPL for conforming
code or DPL != RPL for non-conforming code, it should trigger #TS. Since
segment selector is loaded before segment descriptor when load state from
tss, it implies that RPL = CPL, so the current checks are ok.
The only problem in current implementation is missing RPL < CPL check for
far return. However, change code to follow the manual is better.
Reviewed-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Hou Wenlong <houwenlong.hwl@antgroup.com>
Message-Id: <e01f5ea70fc1f18f23da1182acdbc5c97c0e5886.1644292363.git.houwenlong.hwl@antgroup.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Per Intel's SDM on the "Instruction Set Reference", when
loading segment descriptor, not-present segment check should
be after all type and privilege checks. But the emulator checks
it first, then #NP is triggered instead of #GP if privilege fails
and segment is not present. Put not-present segment check after
type and privilege checks in __load_segment_descriptor().
Fixes: 38ba30ba51a00 (KVM: x86 emulator: Emulate task switch in emulator.c)
Reviewed-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Hou Wenlong <houwenlong.hwl@antgroup.com>
Message-Id: <52573c01d369f506cadcf7233812427cf7db81a7.1644292363.git.houwenlong.hwl@antgroup.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Hide the lapic's "raw" write helper inside lapic.c to force non-APIC code
to go through proper helpers when modification the vAPIC state. Keep the
read helper visible to outsiders for now, refactoring KVM to hide it too
is possible, it will just take more work to do so.
No functional change intended.
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20220204214205.3306634-11-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Emulate the x2APIC ICR as a single 64-bit register, as opposed to forking
it across ICR and ICR2 as two 32-bit registers. This mirrors hardware
behavior for Intel's upcoming IPI virtualization support, which does not
split the access.
Previous versions of Intel's SDM and AMD's APM don't explicitly state
exactly how ICR is reflected in the vAPIC page for x2APIC, KVM just
happened to speculate incorrectly.
Handling the upcoming behavior is necessary in order to maintain
backwards compatibility with KVM_{G,S}ET_LAPIC, e.g. failure to shuffle
the 64-bit ICR to ICR+ICR2 and vice versa would break live migration if
IPI virtualization support isn't symmetrical across the source and dest.
Cc: Zeng Guang <guang.zeng@intel.com>
Cc: Chao Gao <chao.gao@intel.com>
Cc: Maxim Levitsky <mlevitsk@redhat.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20220204214205.3306634-10-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Add helpers to handle 64-bit APIC read/writes via MSRs to deduplicate the
x2APIC and Hyper-V code needed to service reads/writes to ICR. Future
support for IPI virtualization will add yet another path where KVM must
handle 64-bit APIC MSR reads/write (to ICR).
Opportunistically fix the comment in the write path; ICR2 holds the
destination (if there's no shorthand), not the vector.
No functional change intended.
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20220204214205.3306634-9-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Make the low level read/write lapic helpers static, any accesses to the
local APIC from vendor code or non-APIC code should be routed through
proper helpers.
No functional change intended.
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20220204214205.3306634-8-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
WARN if KVM emulates an IPI without clearing the BUSY flag, failure to do
so could hang the guest if it waits for the IPI be sent.
Opportunistically use APIC_ICR_BUSY macro instead of open coding the
magic number, and add a comment to clarify why kvm_recalculate_apic_map()
is unconditionally invoked (it's really, really confusing for IPIs due to
the existence of fast paths that don't trigger a potential recalc).
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20220204214205.3306634-7-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Don't bother rewriting the ICR value into the vAPIC page on an AVIC IPI
virtualization failure, the access is a trap, i.e. the value has already
been written to the vAPIC page. The one caveat is if hardware left the
BUSY flag set (which appears to happen somewhat arbitrarily), in which
case go through the "nodecode" APIC-write path in order to clear the BUSY
flag.
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20220204214205.3306634-6-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Use the common kvm_apic_write_nodecode() to handle AVIC/APIC-write traps
instead of open coding the same exact code. This will allow making the
low level lapic helpers inaccessible outside of lapic.c code.
Opportunistically clean up the params to eliminate a bunch of svm=>vcpu
reflection.
No functional change intended.
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20220204214205.3306634-5-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Use the "raw" helper to read the vAPIC register after an APIC-write trap
VM-Exit. Hardware is responsible for vetting the write, and the caller
is responsible for sanitizing the offset. This is a functional change,
as it means KVM will consume whatever happens to be in the vAPIC page if
the write was dropped by hardware. But, unless userspace deliberately
wrote garbage into the vAPIC page via KVM_SET_LAPIC, the value should be
zero since it's not writable by the guest.
This aligns common x86 with SVM's AVIC logic, i.e. paves the way for
using the nodecode path to handle APIC-write traps when AVIC is enabled.
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20220204214205.3306634-4-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Move the vAPIC offset adjustments done in the APIC-write trap path from
common x86 to VMX in anticipation of using the nodecode path for SVM's
AVIC. The adjustment reflects hardware behavior, i.e. it's technically a
property of VMX, no common x86. SVM's AVIC behavior is identical, so
it's a bit of a moot point, the goal is purely to make it easier to
understand why the adjustment is ok.
No functional change intended.
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20220204214205.3306634-3-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Emulating writes to SELF_IPI with a write to ICR has an unwanted side effect:
the value of ICR in vAPIC page gets changed. The lists SELF_IPI as write-only,
with no associated MMIO offset, so any write should have no visible side
effect in the vAPIC page.
Reported-by: Chao Gao <chao.gao@intel.com>
Reviewed-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
In emulation of writing to cr8, one of the lowest four bits in TPR[3:0]
is kept.
According to Intel SDM 10.8.6.1(baremetal scenario):
"APIC.TPR[bits 7:4] = CR8[bits 3:0], APIC.TPR[bits 3:0] = 0";
and SDM 28.3(use TPR shadow):
"MOV to CR8. The instruction stores bits 3:0 of its source operand into
bits 7:4 of VTPR; the remainder of VTPR (bits 3:0 and bits 31:8) are
cleared.";
and AMD's APM 16.6.4:
"Task Priority Sub-class (TPS)-Bits 3 : 0. The TPS field indicates the
current sub-priority to be used when arbitrating lowest-priority messages.
This field is written with zero when TPR is written using the architectural
CR8 register.";
so in KVM emulated scenario, clear TPR[3:0] to make a consistent behavior
as in other scenarios.
This doesn't impact evaluation and delivery of pending virtual interrupts
because processor does not use the processor-priority sub-class to
determine which interrupts to delivery and which to inhibit.
Sub-class is used by hardware to arbitrate lowest priority interrupts,
but KVM just does a round-robin style delivery.
Fixes: b93463aa59d6 ("KVM: Accelerated apic support")
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
Reviewed-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20220210094506.20181-1-zhenzhong.duan@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
For both CR0 and CR4, disassociate the TLB flush logic from the
MMU role logic. Instead of relying on kvm_mmu_reset_context() being
a superset of various TLB flushes (which is not necessarily going to
be the case in the future), always call it if the role changes
but also set the various TLB flush requests according to what is
in the manual.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Building tinyconfig with gcc (Debian 11.2.0-16) and assembler (Debian
2.37.90.20220207) the following build error shows up:
{standard input}: Assembler messages:
{standard input}:10576: Error: unrecognized opcode: `stbcx.'
{standard input}:10680: Error: unrecognized opcode: `lharx'
{standard input}:10694: Error: unrecognized opcode: `lbarx'
Rework to add assembler directives [1] around the instruction. The
problem with this might be that we can trick a power6 into
single-stepping through an stbcx. for instance, and it will execute that
in kernel mode.
[1] https://sourceware.org/binutils/docs/as/PowerPC_002dPseudo.html#PowerPC_002dPseudo
Fixes: 350779a29f11 ("powerpc: Handle most loads and stores in instruction emulation code")
Cc: stable@vger.kernel.org # v4.14+
Co-developed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20220224162215.3406642-3-anders.roxell@linaro.org
|
|
Building tinyconfig with gcc (Debian 11.2.0-16) and assembler (Debian
2.37.90.20220207) the following build error shows up:
{standard input}: Assembler messages:
{standard input}:1190: Error: unrecognized opcode: `stbcix'
{standard input}:1433: Error: unrecognized opcode: `lwzcix'
{standard input}:1453: Error: unrecognized opcode: `stbcix'
{standard input}:1460: Error: unrecognized opcode: `stwcix'
{standard input}:1596: Error: unrecognized opcode: `stbcix'
...
Rework to add assembler directives [1] around the instruction. Going
through them one by one shows that the changes should be safe. Like
__get_user_atomic_128_aligned() is only called in p9_hmi_special_emu(),
which according to the name is specific to power9. And __raw_rm_read*()
are only called in things that are powernv or book3s_hv specific.
[1] https://sourceware.org/binutils/docs/as/PowerPC_002dPseudo.html#PowerPC_002dPseudo
Cc: stable@vger.kernel.org
Co-developed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
[mpe: Make commit subject more descriptive]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20220224162215.3406642-2-anders.roxell@linaro.org
|
|
Looks like there been a copy paste mistake when added the instruction
'stbcx' twice and one was probably meant to be 'sthcx'. Changing to
'sthcx' from 'stbcx'.
Fixes: 350779a29f11 ("powerpc: Handle most loads and stores in instruction emulation code")
Cc: stable@vger.kernel.org # v4.14+
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20220224162215.3406642-1-anders.roxell@linaro.org
|
|
When CONFIG_GENERIC_CPU=y (true for all our defconfigs) we pass
-mcpu=powerpc64 to the compiler, even when we're building a 32-bit
kernel.
This happens because we have an ifdef CONFIG_PPC_BOOK3S_64/else block in
the Makefile that was written before 32-bit supported GENERIC_CPU. Prior
to that the else block only applied to 64-bit Book3E.
The GCC man page says -mcpu=powerpc64 "[specifies] a pure ... 64-bit big
endian PowerPC ... architecture machine [type], with an appropriate,
generic processor model assumed for scheduling purposes."
It's unclear how that interacts with -m32, which we are also passing,
although obviously -m32 is taking precedence in some sense, as the
32-bit kernel only contains 32-bit instructions.
This was noticed by inspection, not via any bug reports, but it does
affect code generation. Comparing before/after code generation, there
are some changes to instruction scheduling, and the after case (with
-mcpu=powerpc64 removed) the compiler seems more keen to use r8.
Fix it by making the else case only apply to Book3E 64, which excludes
32-bit.
Fixes: 0e00a8c9fd92 ("powerpc: Allow CPU selection also on PPC32")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20220215112858.304779-1-mpe@ellerman.id.au
|
|
Executing node_set_online() when nid = NUMA_NO_NODE results in an
undefined behavior. node_set_online() will call node_set_state(), into
__node_set(), into set_bit(), and since NUMA_NO_NODE is -1 we'll end up
doing a negative shift operation inside
arch/powerpc/include/asm/bitops.h. This potential UB was detected
running a kernel with CONFIG_UBSAN.
The behavior was introduced by commit 10f78fd0dabb ("powerpc/numa: Fix a
regression on memoryless node 0"), where the check for nid > 0 was
removed to fix a problem that was happening with nid = 0, but the result
is that now we're trying to online NUMA_NO_NODE nids as well.
Checking for nid >= 0 will allow node 0 to be onlined while avoiding
this UB with NUMA_NO_NODE.
Fixes: 10f78fd0dabb ("powerpc/numa: Fix a regression on memoryless node 0")
Reported-by: Ping Fang <pifang@redhat.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20220224182312.1012527-1-danielhb413@gmail.com
|
|
Since commit ceff77efa4f8 ("powerpc/64e/interrupt: Use new interrupt
context tracking scheme") struct interrupt_state has been empty and
unused.
Remove it.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1d862ce3eab3da6ca7ac47d4a78a18f154462511.1645806970.git.christophe.leroy@csgroup.eu
|
|
Crash recovery (fadump) is setup in the userspace by some service. This
service rebuilds initrd with dump capture capability, if it is not
already dump capture capable before proceeding to register for firmware
assisted dump (echo 1 > /sys/kernel/fadump/registered). But arming the
kernel with crash recovery support does not have to wait for userspace
configuration. So, register for fadump while setting it up itself. This
can at worst lead to a scenario, where /proc/vmcore is ready afer crash
but the initrd does not know how/where to offload it, which is always
better than not having a /proc/vmcore at all due to incomplete
configuration in the userspace at the time of crash.
Commit 0823c68b054b ("powerpc/fadump: re-register firmware-assisted dump
if already registered") ensures this change does not break userspace.
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
[mpe: Reword comment]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20220201105305.155511-1-hbathini@linux.ibm.com
|
|
The mstar SoCs have an arch timer but HAVE_ARM_ARCH_TIMER wasn't
selected. If MSC313E_TIMER isn't selected then the kernel gets
stuck at boot because there are no timers available.
Signed-off-by: Daniel Palmer <daniel@0x0f.com>
Link: https://lore.kernel.org/r/20220301104349.3040422-1-daniel@0x0f.com'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
All 3 miniPCIe slots in Turris Omnia are designed for 10 W.
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
|
|
- Enable Airoha SoC on armv7 config.
- Enable CPU freq for arm64 based SoCs.
- Enable PMIC based (mt6397) RTC for mt8173
* tag 'v5.17-next-defconfig' of git://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux:
ARM: multi_v7_defconfig: Add support for Airoha EN7523 SoC
arm64: defconfig: Enable cpufreq for MediaTek
arm64: defconfig: Enable MT6397 RTC
Link: https://lore.kernel.org/r/9b90b407-025b-ec78-a626-faccdbc7ab39@gmail.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Qualcomm defconfig updates for v5.18
The Qualcomm Snapdragon 8916 devices come in both 32- or 64-bit form,
and even though the typical case so far has been to 64-bit, it's
possible to run the Dragonboard 410c in either mode.
Enable the relevant drivers in multi_v7_defconfig to enable this, and
other Snapdragon 8916 devices to run the 32-bit kernel.
* tag 'qcom-defconfig-for-5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
ARM: multi_v7_defconfig: Enable drivers for DragonBoard 410c
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
The earlier removal of two boards caused a build regression,
fix it by removing the extraneous '||'.
Reported-by: kernel test robot <lkp@intel.com>
Fixes: 28f74201e37c ("ARM: pxa: remove Intel Imote2 and Stargate 2 boards")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Qualcomm ARM64 DeviceTree updates for v5.18
New platforms: Snapdragon 625 and Snapdragon 632
New boards: Google Herobrine R1, Fairphone FP3, SHIFT6mq, Samsung Galaxy
Book2 and Snapdragon 8 Gen 1 Hardware Development Kit (HDK)
On IPQ6018 the USB reference period is corrected, GICv2m support is
enabled and the max-link-speed for PCIe is specified.
IPQ8074 adds description of GIVv2m and SMEM, and ensures that TrustZone
related memory is reserved from Linux.
On the Snapdragon 7c Gen 3 (SC7280) description of display, displayport,
L3 interconnect, bluetooth, CPU opp-tables are added. Another revision
of the Google Herobrine is introduced and a bunch of cleanups are
introduced.
On Snapdragon 845 new support for the SHIFT6mq device is introduced, the
OnePlus devices gains fuel gauge and the platform gains GSI DMA support,
which is enabled for SPI (for now).
On the Snapdragon 850 based WindowsOnSnapdragon laptops, initial support
for Samsugn Galaxy Book2 is introduced and the Lenovo Yoga C630 gains
description of its backlight controls.
The Snapdragon 625 platform (MSM8953) the thereof derrived Snapdragon
632 platform is introduced, with initial description of the Fairphone 3.
Fairphone 4 on the SM7225 platform gains proper WLED configuration.
On Snapdragon 855 (SM8150) description of the limits hardware (LMh) is
introduced and the SPI and I2C devices are wired to the GSI DMA controller.
On Snapdragon 865 (SM8250) the CPU and cluster idle states are
introduced, the MSI interrupts for PCIe 1 and 2 are corrected and the
CPUfreq driver gains knowledge about thermal pressure interrupts.
On Snapdragon 8 Gen 1 (SM8450) LLCC, interconnect and remoteproc
descriptions are added. The SM8450 Hardware Development Kit is
introduced and the QRD has its remoteproc instances enabled.
Cluster idle and RPMh parameters are corrected on SM8150, SM8350 and
SM8540.
The IPA device on SC7180, SC7280 and SM8350 gains knowledge of the AOSS
QMP mailbox, allowing it to enable retention of IPA registers during
power collapse.
DeviceTree validation issues related to thermal zone naming, missing
CPU, device and platform compatibles, APR, Google EC PWM, DB410c sound,
QCS404 opp-tables and SM8250 PCIe nodes are corrected.
A bunch of cleanups and style fixes for MSM8992, MSM8994, MSM8996 and
MSM8916 are introduced as well.
* tag 'qcom-arm64-for-5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: (96 commits)
arm64: dts: qcom: sdm632: Add device tree for Fairphone 3
dt-bindings: arm: qcom: Document sdm632 and fairphone,fp3 board
arm64: dts: qcom: Add SDM632 device tree
arm64: dts: qcom: Add PM8953 PMIC
arm64: dts: qcom: Add MSM8953 device tree
dt-bindings: arm: cpus: Add Kryo 250 CPUs
arm64: dts: qcom: msm8916-longcheer-l8150: Add light and proximity sensor
arm64: dts: qcom: align Google CROS EC PWM node name with dtschema
arm64: dts: qcom: Add support for Samsung Galaxy Book2
arm64: dts: qcom: msm8996: convert xo_board to RPM_SMD_BB_CLK1
arm64: dts: qcom: msm8996: add cxo and sleep-clk to gcc node
arm64: dts: qcom: sdm845: add bi_tcxo to camcc
arm64: dts: qcom: sdm845: enable dma for spi
arm64: dts: qcom: sdm845: Add gsi dma node
arm64: dts: qcom: sc7280: Add cpu OPP tables
arm64: dts: qcom: sc7280: Add EPSS L3 interconnect provider
arm64: dts: qcom: sm8450: Add LLCC/system-cache-controller node
arm64: dts: qcom: ipq6018: drop the clock-frequency property
arm64: dts: qcom: ipq8074: drop the clock-frequency property
arm64: dts: qcom: sm8450: add interconnect nodes
...
Link: https://lore.kernel.org/r/20220301053929.1809684-1-bjorn.andersson@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Qualcomm dts updates for v5.18
The MSM8226 platform gains description of USB, SoC power-domains,
PMIC multi-purpose pins, SPMI regulators, the smbb battery charger and
the LG G Watch R, on this platform, gains description of Bluetooth,
WiFI, fuel gauge, SMBB battery charger and USB.
DeviceTree validation issues in APQ8060, APQ8064, MDM9615, MSM8960,
IPQ4019 and SDX55 are corrected.
* tag 'qcom-dts-for-5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: (27 commits)
ARM: dts: qcom: msm8226: add power domains
ARM: dts: qcom: apq8026-lg-lenok: Add Bluetooth
ARM: dts: qcom: apq8026-lg-lenok: Add Wifi
ARM: dts: qcom: msm8226: Add pinctrl for sdhci nodes
ARM: dts: qcom: sdx55: Fix the address used for PCIe EP local addr space
ARM: dts: qcom: apq8060-dragonboard: fix typo in eMMC
ARM: dts: qcom: pm8226: Add node for the MPP
ARM: dts: qcom: fill missing power-domain-cells for gcc controllers
ARM: dts: qcom: msm8960: move vsdcc regulator out of simple-bus
ARM: dts: qcom: add KPSS GCC compatible to clock nodes
ARM: dts: qcom: fix gic_irq_domain_translate warnings for msm8960
ARM: dts: qcom: rename eth node to ethernet
ARM: dts: qcom: apq8060: correct mvs switch name
ARM: dts: qcom: nexus7: remove vcss supply which never existed
ARM: dts: qcom: apq8064: adjust dsi node name to match dt-schema
ARM: dts: qcom: apq8064: make pci regs property dt-schema compliant
ARM: dts: qcom: apq8064: correct ranges values
ARM: dts: qcom: ipq4019: fix sleep clock
ARM: dts: qcom: pm8226: Support SPMI regulators on PMIC sid 1
ARM: dts: qcom: pm8226: Add vibration motor node
...
Link: https://lore.kernel.org/r/20220301042828.1805481-1-bjorn.andersson@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
- Set display pipeline to DSI on mt8183 kukui jacuzzi
- Fix display for mt8192 based boards by fixing the routing table
* tag 'v5.17-fixes-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux:
soc: mediatek: mt8192-mmsys: Fix dither to dsi0 path's input sel
arm64: dts: mt8183: jacuzzi: Fix bus properties in anx's DSI endpoint
Link: https://lore.kernel.org/r/8eb8510d-c597-4fee-e4b3-924b6d4bb3be@gmail.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Qualcomm ARM64 DeviceTree fixes for 5.17
This starts off by fixing an issue introduced in a bug fix in the
global clock controller, where the symbol clocks for UFS would
end up picking the wrong parent clock which breaks UFS.
It then makes sure that the reference clock for the USB blocks are
enabled, even with booting without clk_ignore_unused.
It corrects the apps SMMU interrupts defintion by adding a missing
interrupt in the list.
Lastly it disables the Qualcomm crypto hardware (for now) on the Lenovo
Yoga C630, to prevent the cryptomanager tests during boot from crashing
the device.
* tag 'qcom-arm64-fixes-for-5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
arm64: dts: qcom: c630: disable crypto due to serror
arm64: dts: qcom: sm8450: fix apps_smmu interrupts
arm64: dts: qcom: sm8450: enable GCC_USB3_0_CLKREF_EN for usb
arm64: dts: qcom: sm8350: Correct UFS symbol clocks
Link: https://lore.kernel.org/r/20220301033526.1801295-1-bjorn.andersson@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
This pull request contains Broadcom ARM-based SoCs Device Tree fixes for
5.17, please pull the following:
- Maxime fixes the HVS (display) register range for the BCM2711
(Raspberry Pi 4) SoC
* tag 'arm-soc/for-5.17/devicetree-fixes' of https://github.com/Broadcom/stblinux:
ARM: boot: dts: bcm2711: Fix HVS register range
Link: https://lore.kernel.org/r/20220228165537.1950863-1-f.fainelli@gmail.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
It was the intention to reverse the bits, not make them all zero by
using logical NOT operator.
Fixes: cc19db8b312a ("MIPS: ralink: mt7621: do memory detection on KSEG1")
Suggested-by: Chuanhong Guo <gch981213@gmail.com>
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>
Reviewed-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
|
|
No (active) developer owns this hardware, so let's remove Linux support.
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
|
Kees Cook
Dinh Nguyen
Krzysztof Kozlowski
Anshuman Khandual
Steve Wahl
Sean Christopherson
Arnd Bergmann
Hou Wenlong
Paolo Bonzini
Zhenzhong Duan
Anders Roxell
Michael Ellerman
Daniel Henrique Barboza
Christophe Leroy
Hari Bathini
Daniel Palmer
Pali Rohár
Ilya Lipnitskiy
Thomas Bogendoerfer