aboutsummaryrefslogtreecommitdiffstats
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2021-10-25ARM: 9135/1: kprobes: address gcc -Wempty-body warningArnd Bergmann1-1/+1
Building with 'make W=1' shows a warning in some configurations when 'verbose()' is defined to be empty. arch/arm/probes/kprobes/test-core.c: In function 'kprobes_test_case_start': arch/arm/probes/kprobes/test-core.c:1367:26: error: suggest braces around empty body in an 'else' statement [-Werror=empty-body] 1367 | current_instruction); | ^ Change the definition of verbose() to use no_printk(), allowing format string checking and avoiding the warning. Link: https://lore.kernel.org/all/20210322114600.3528031-1-arnd@kernel.org/ Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2021-10-25ARM: 9101/1: sa1100/assabet: convert LEDs to gpiod APIsLinus Walleij1-11/+13
Convert the Assabet LEDs to use the gpiod APIs. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2021-10-25ARM: 9148/1: handle CONFIG_CPU_ENDIAN_BE32 in arch/arm/kernel/head.SLABBE Corentin1-2/+2
My intel-ixp42x-welltech-epbx100 no longer boot since 4.14. This is due to commit 463dbba4d189 ("ARM: 9104/2: Fix Keystone 2 kernel mapping regression") which forgot to handle CONFIG_CPU_ENDIAN_BE32 as possible BE config. Suggested-by: Krzysztof HaƂasa <khalasa@piap.pl> Fixes: 463dbba4d189 ("ARM: 9104/2: Fix Keystone 2 kernel mapping regression") Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2021-10-25KVM: x86: SGX must obey the KVM_INTERNAL_ERROR_EMULATION protocolDavid Edmondson1-11/+5
When passing the failing address and size out to user space, SGX must ensure not to trample on the earlier fields of the emulation_failure sub-union of struct kvm_run. Signed-off-by: David Edmondson <david.edmondson@oracle.com> Reviewed-by: Sean Christopherson <seanjc@google.com> Message-Id: <20210920103737.2696756-5-david.edmondson@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-10-25KVM: x86: On emulation failure, convey the exit reason, etc. to userspaceDavid Edmondson3-18/+63
Should instruction emulation fail, include the VM exit reason, etc. in the emulation_failure data passed to userspace, in order that the VMM can report it as a debugging aid when describing the failure. Suggested-by: Joao Martins <joao.m.martins@oracle.com> Signed-off-by: David Edmondson <david.edmondson@oracle.com> Reviewed-by: Sean Christopherson <seanjc@google.com> Message-Id: <20210920103737.2696756-4-david.edmondson@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-10-25KVM: x86: Get exit_reason as part of kvm_x86_ops.get_exit_infoDavid Edmondson5-13/+19
Extend the get_exit_info static call to provide the reason for the VM exit. Modify relevant trace points to use this rather than extracting the reason in the caller. Signed-off-by: David Edmondson <david.edmondson@oracle.com> Reviewed-by: Sean Christopherson <seanjc@google.com> Message-Id: <20210920103737.2696756-3-david.edmondson@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-10-25irq: arm: perform irqentry in entry codeMark Rutland3-11/+9
In preparation for removing HANDLE_DOMAIN_IRQ_IRQENTRY, have arch/arm perform all the irqentry accounting in its entry code. For configurations with CONFIG_GENERIC_IRQ_MULTI_HANDLER, we can use generic_handle_arch_irq(). Other than asm_do_IRQ(), all C calls to handle_IRQ() are from irqchip handlers which will be called from generic_handle_arch_irq(), so to avoid double accounting IRQ entry, the entry logic is moved from handle_IRQ() into asm_do_IRQ(). For ARMv7M the entry assembly is tightly coupled with the NVIC irqchip, and while the entry code should logically live under arch/arm/, moving the entry logic there makes things more convoluted. So for now, place the entry logic in the NVIC irqchip, but separated into a separate function to make the split of responsibility clear. For all other configurations without CONFIG_GENERIC_IRQ_MULTI_HANDLER, IRQ entry is already handled in arch code, and requires no changes. There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Marc Zyngier <maz@kernel.org> Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M Cc: Russell King <linux@armlinux.org.uk> Cc: Thomas Gleixner <tglx@linutronix.de>
2021-10-25irq: add a (temporary) CONFIG_HANDLE_DOMAIN_IRQ_IRQENTRYMark Rutland5-0/+5
Going forward we want architecture/entry code to perform all the necessary work to enter/exit IRQ context, with irqchip code merely handling the mapping of the interrupt to any handler(s). Among other reasons, this is necessary to consistently fix some longstanding issues with the ordering of lockdep/RCU/tracing instrumentation which many architectures get wrong today in their entry code. Importantly, rcu_irq_{enter,exit}() must be called precisely once per IRQ exception, so that rcu_is_cpu_rrupt_from_idle() can correctly identify when an interrupt was taken from an idle context which must be explicitly preempted. Currently handle_domain_irq() calls rcu_irq_{enter,exit}() via irq_{enter,exit}(), but entry code needs to be able to call rcu_irq_{enter,exit}() earlier for correct ordering across lockdep/RCU/tracing updates for sequences such as: lockdep_hardirqs_off(CALLER_ADDR0); rcu_irq_enter(); trace_hardirqs_off_finish(); To permit each architecture to be converted to the new style in turn, this patch adds a new CONFIG_HANDLE_DOMAIN_IRQ_IRQENTRY selected by all current users of HANDLE_DOMAIN_IRQ, which gates the existing behaviour. When CONFIG_HANDLE_DOMAIN_IRQ_IRQENTRY is not selected, handle_domain_irq() requires entry code to perform the irq_{enter,exit}() work, with an explicit check for this matching the style of handle_domain_nmi(). Subsequent patches will: 1) Add the necessary IRQ entry accounting to each architecture in turn, dropping CONFIG_HANDLE_DOMAIN_IRQ_IRQENTRY from that architecture's Kconfig. 2) Remove CONFIG_HANDLE_DOMAIN_IRQ_IRQENTRY once it is no longer selected. 3) Convert irqchip drivers to consistently use generic_handle_domain_irq() rather than handle_domain_irq(). 4) Remove handle_domain_irq() and CONFIG_HANDLE_DOMAIN_IRQ. ... which should leave us with a clear split of responsiblity across the entry and irqchip code, making it possible to perform additional cleanups and fixes for the aforementioned longstanding issues with entry code. There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Marc Zyngier <maz@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de>
2021-10-25irq: nds32: avoid CONFIG_HANDLE_DOMAIN_IRQMark Rutland1-1/+0
In preparation for removing HANDLE_DOMAIN_IRQ, have arch/nds32 perform all the necessary IRQ entry accounting in its entry code. Currently arch/nds32 is tightly coupled with the ativic32 irqchip, and while the entry code should logically live under arch/nds32/, moving the entry logic there makes things more convoluted. So for now, place the entry logic in the ativic32 irqchip, but separated into a separate function to make the split of responsibility clear. In future this should probably use GENERIC_IRQ_MULTI_HANDLER to cleanly decouple this. There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Marc Zyngier <maz@kernel.org> Cc: Greentime Hu <green.hu@gmail.com> Cc: Nick Hu <nickhu@andestech.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vincent Chen <deanbo422@gmail.com>
2021-10-25irq: arc: avoid CONFIG_HANDLE_DOMAIN_IRQMark Rutland2-2/+9
In preparation for removing HANDLE_DOMAIN_IRQ, have arch/arc perform all the necessary IRQ entry accounting in its entry code. There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Marc Zyngier <maz@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vineet Gupta <vgupta@kernel.org>
2021-10-25irq: mips: simplify do_domain_IRQ()Mark Rutland1-5/+1
There's no need fpr arch/mips's do_domain_IRQ() to open-code the NULL check performed by handle_irq_desc(), nor the resolution of the desc performed by generic_handle_domain_irq(). Use generic_handle_domain_irq() directly, as this is functioanlly equivalent and clearer. There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Marc Zyngier <maz@kernel.org> Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Thomas Gleixner <tglx@linutronix.de>
2021-10-25irq: mips: stop (ab)using handle_domain_irq()Mark Rutland2-2/+4
On MIPS, the only user of handle_domain_irq() is octeon_irq_ciu3_ip2(), which is called from the platform-specific plat_irq_dispatch() function invoked from the early assembly code. No other irqchip relevant to arch/mips uses handle_domain_irq(): * No other plat_irq_dispatch() function transitively calls handle_domain_irq(). * No other vectored IRQ dispatch function registered with set_vi_handler() calls handle_domain_irq(). * No chained irqchip handlers call handle_domain_irq(), which makes sense as this is meant to only be used by root irqchip handlers. Currently octeon_irq_ciu3_ip2() passes NULL as the `regs` argument to handle_domain_irq(), and as handle_domain_irq() will pass this to set_irq_regs(), any invoked IRQ handlers will erroneously see a NULL pt_regs if they call get_pt_regs(). Fix this by calling generic_handle_domain_irq() directly, and performing the necessary irq_{enter,exit}() logic directly in octeon_irq_ciu3_ip2(). At the same time, deselect HANDLE_DOMAIN_IRQ, which subsequent patches will remove. Other than the corrected behaviour of get_pt_regs(), there should be no functional change as a result of this patch. Fixes: ce210d35bb93c2c5 ("MIPS: OCTEON: Add support for OCTEON III interrupt controller.") Signed-off-by: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Marc Zyngier <maz@kernel.org> Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Thomas Gleixner <tglx@linutronix.de>
2021-10-25x86/of: Kill unused early_init_dt_scan_chosen_arch()Rob Herring1-5/+0
There are no callers for early_init_dt_scan_chosen_arch(), so remove it. Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Frank Rowand <frank.rowand@sony.com> Link: https://lkml.kernel.org/r/20211022164642.2815706-1-robh@kernel.org
2021-10-25KVM: s390: Add a routine for setting userspace CPU stateEric Farman2-3/+12
This capability exists, but we don't record anything when userspace enables it. Let's refactor that code so that a note can be made in the debug logs that it was enabled. Signed-off-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Link: https://lore.kernel.org/r/20211008203112.1979843-7-farman@linux.ibm.com Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
2021-10-25KVM: s390: Simplify SIGP Set Arch handlingEric Farman1-13/+1
The Principles of Operations describe the various reasons that each individual SIGP orders might be rejected, and the status bit that are set for each condition. For example, for the Set Architecture order, it states: "If it is not true that all other CPUs in the configu- ration are in the stopped or check-stop state, ... bit 54 (incorrect state) ... is set to one." However, it also states: "... if the CZAM facility is installed, ... bit 55 (invalid parameter) ... is set to one." Since the Configuration-z/Architecture-Architectural Mode (CZAM) facility is unconditionally presented, there is no need to examine each VCPU to determine if it is started/stopped. It can simply be rejected outright with the Invalid Parameter bit. Fixes: b697e435aeee ("KVM: s390: Support Configuration z/Architecture Mode") Signed-off-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Link: https://lore.kernel.org/r/20211008203112.1979843-2-farman@linux.ibm.com Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
2021-10-25KVM: s390: pv: avoid stalls when making pages secureClaudio Imbrenda2-6/+28
Improve make_secure_pte to avoid stalls when the system is heavily overcommitted. This was especially problematic in kvm_s390_pv_unpack, because of the loop over all pages that needed unpacking. Due to the locks being held, it was not possible to simply replace uv_call with uv_call_sched. A more complex approach was needed, in which uv_call is replaced with __uv_call, which does not loop. When the UVC needs to be executed again, -EAGAIN is returned, and the caller (or its caller) will try again. When -EAGAIN is returned, the path is the same as when the page is in writeback (and the writeback check is also performed, which is harmless). Fixes: 214d9bbcd3a672 ("s390/mm: provide memory management functions for protected KVM guests") Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Link: https://lore.kernel.org/r/20210920132502.36111-5-imbrenda@linux.ibm.com Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
2021-10-25KVM: s390: pv: avoid stalls for kvm_s390_pv_init_vmClaudio Imbrenda1-1/+1
When the system is heavily overcommitted, kvm_s390_pv_init_vm might generate stall notifications. Fix this by using uv_call_sched instead of just uv_call. This is ok because we are not holding spinlocks. Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Fixes: 214d9bbcd3a672 ("s390/mm: provide memory management functions for protected KVM guests") Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Message-Id: <20210920132502.36111-4-imbrenda@linux.ibm.com> Signed-off-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
2021-10-25KVM: s390: pv: avoid double free of sida pageClaudio Imbrenda1-10/+9
If kvm_s390_pv_destroy_cpu is called more than once, we risk calling free_page on a random page, since the sidad field is aliased with the gbea, which is not guaranteed to be zero. This can happen, for example, if userspace calls the KVM_PV_DISABLE IOCTL, and it fails, and then userspace calls the same IOCTL again. This scenario is only possible if KVM has some serious bug or if the hardware is broken. The solution is to simply return successfully immediately if the vCPU was already non secure. Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Fixes: 19e1227768863a1469797c13ef8fea1af7beac2c ("KVM: S390: protvirt: Introduce instruction data area bounce buffer") Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Message-Id: <20210920132502.36111-3-imbrenda@linux.ibm.com> Signed-off-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
2021-10-25KVM: s390: pv: add macros for UVC CC valuesClaudio Imbrenda1-0/+5
Add macros to describe the 4 possible CC values returned by the UVC instruction. Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Message-Id: <20210920132502.36111-2-imbrenda@linux.ibm.com> Signed-off-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
2021-10-25s390/mm: optimize reset_guest_reference_bit()David Hildenbrand1-2/+12
We already optimize get_guest_storage_key() to assume that if we don't have a PTE table and don't have a huge page mapped that the storage key is 0. Similarly, optimize reset_guest_reference_bit() to simply do nothing if there is no PTE table and no huge page mapped. Signed-off-by: David Hildenbrand <david@redhat.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Link: https://lore.kernel.org/r/20210909162248.14969-10-david@redhat.com Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
2021-10-25s390/mm: optimize set_guest_storage_key()David Hildenbrand1-2/+12
We already optimize get_guest_storage_key() to assume that if we don't have a PTE table and don't have a huge page mapped that the storage key is 0. Similarly, optimize set_guest_storage_key() to simply do nothing in case the key to set is 0. Signed-off-by: David Hildenbrand <david@redhat.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Link: https://lore.kernel.org/r/20210909162248.14969-9-david@redhat.com Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
2021-10-25s390/mm: no need for pte_alloc_map_lock() if we know the pmd is presentDavid Hildenbrand1-12/+3
pte_map_lock() is sufficient. Signed-off-by: David Hildenbrand <david@redhat.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Link: https://lore.kernel.org/r/20210909162248.14969-8-david@redhat.com Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
2021-10-25s390/uv: fully validate the VMA before calling follow_page()David Hildenbrand1-1/+1
We should not walk/touch page tables outside of VMA boundaries when holding only the mmap sem in read mode. Evil user space can modify the VMA layout just before this function runs and e.g., trigger races with page table removal code since commit dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in munmap"). find_vma() does not check if the address is >= the VMA start address; use vma_lookup() instead. Fixes: 214d9bbcd3a6 ("s390/mm: provide memory management functions for protected KVM guests") Signed-off-by: David Hildenbrand <david@redhat.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com> Link: https://lore.kernel.org/r/20210909162248.14969-6-david@redhat.com Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
2021-10-25s390/mm: fix VMA and page table handling code in storage key handling functionsDavid Hildenbrand1-18/+39
There are multiple things broken about our storage key handling functions: 1. We should not walk/touch page tables outside of VMA boundaries when holding only the mmap sem in read mode. Evil user space can modify the VMA layout just before this function runs and e.g., trigger races with page table removal code since commit dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in munmap"). gfn_to_hva() will only translate using KVM memory regions, but won't validate the VMA. 2. We should not allocate page tables outside of VMA boundaries: if evil user space decides to map hugetlbfs to these ranges, bad things will happen because we suddenly have PTE or PMD page tables where we shouldn't have them. 3. We don't handle large PUDs that might suddenly appeared inside our page table hierarchy. Don't manually allocate page tables, properly validate that we have VMA and bail out on pud_large(). All callers of page table handling functions, except get_guest_storage_key(), call fixup_user_fault() in case they receive an -EFAULT and retry; this will allocate the necessary page tables if required. To keep get_guest_storage_key() working as expected and not requiring kvm_s390_get_skeys() to call fixup_user_fault() distinguish between "there is simply no page table or huge page yet and the key is assumed to be 0" and "this is a fault to be reported". Although commit 637ff9efe5ea ("s390/mm: Add huge pmd storage key handling") introduced most of the affected code, it was actually already broken before when using get_locked_pte() without any VMA checks. Note: Ever since commit 637ff9efe5ea ("s390/mm: Add huge pmd storage key handling") we can no longer set a guest storage key (for example from QEMU during VM live migration) without actually resolving a fault. Although we would have created most page tables, we would choke on the !pmd_present(), requiring a call to fixup_user_fault(). I would have thought that this is problematic in combination with postcopy life migration ... but nobody noticed and this patch doesn't change the situation. So maybe it's just fine. Fixes: 9fcf93b5de06 ("KVM: S390: Create helper function get_guest_storage_key") Fixes: 24d5dd0208ed ("s390/kvm: Provide function for setting the guest storage key") Fixes: a7e19ab55ffd ("KVM: s390: handle missing storage-key facility") Signed-off-by: David Hildenbrand <david@redhat.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Link: https://lore.kernel.org/r/20210909162248.14969-5-david@redhat.com Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
2021-10-25s390/mm: validate VMA in PGSTE manipulation functionsDavid Hildenbrand1-0/+13
We should not walk/touch page tables outside of VMA boundaries when holding only the mmap sem in read mode. Evil user space can modify the VMA layout just before this function runs and e.g., trigger races with page table removal code since commit dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in munmap"). gfn_to_hva() will only translate using KVM memory regions, but won't validate the VMA. Further, we should not allocate page tables outside of VMA boundaries: if evil user space decides to map hugetlbfs to these ranges, bad things will happen because we suddenly have PTE or PMD page tables where we shouldn't have them. Similarly, we have to check if we suddenly find a hugetlbfs VMA, before calling get_locked_pte(). Fixes: 2d42f9477320 ("s390/kvm: Add PGSTE manipulation functions") Signed-off-by: David Hildenbrand <david@redhat.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Link: https://lore.kernel.org/r/20210909162248.14969-4-david@redhat.com Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
2021-10-25s390/gmap: don't unconditionally call pte_unmap_unlock() in __gmap_zap()David Hildenbrand1-2/+3
... otherwise we will try unlocking a spinlock that was never locked via a garbage pointer. At the time we reach this code path, we usually successfully looked up a PGSTE already; however, evil user space could have manipulated the VMA layout in the meantime and triggered removal of the page table. Fixes: 1e133ab296f3 ("s390/mm: split arch/s390/mm/pgtable.c") Signed-off-by: David Hildenbrand <david@redhat.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Link: https://lore.kernel.org/r/20210909162248.14969-3-david@redhat.com Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
2021-10-25s390/gmap: validate VMA in __gmap_zap()David Hildenbrand1-0/+6
We should not walk/touch page tables outside of VMA boundaries when holding only the mmap sem in read mode. Evil user space can modify the VMA layout just before this function runs and e.g., trigger races with page table removal code since commit dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in munmap"). The pure prescence in our guest_to_host radix tree does not imply that there is a VMA. Further, we should not allocate page tables (via get_locked_pte()) outside of VMA boundaries: if evil user space decides to map hugetlbfs to these ranges, bad things will happen because we suddenly have PTE or PMD page tables where we shouldn't have them. Similarly, we have to check if we suddenly find a hugetlbfs VMA, before calling get_locked_pte(). Note that gmap_discard() is different: zap_page_range()->unmap_single_vma() makes sure to stay within VMA boundaries. Fixes: b31288fa83b2 ("s390/kvm: support collaborative memory management") Signed-off-by: David Hildenbrand <david@redhat.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Link: https://lore.kernel.org/r/20210909162248.14969-2-david@redhat.com Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
2021-10-25powerpc/pseries/iommu: Create huge DMA window if no MMIO32 is presentAlexey Kardashevskiy1-6/+6
The iommu_init_table() helper takes an address range to reserve in the IOMMU table being initialized to exclude MMIO addresses, this is useful if the window stretches far beyond 4GB (although wastes some TCEs). At the moment the code searches for such MMIO32 range and fails if none found which is considered a problem while it really is not: it is actually better as this says there is no MMIO32 to reserve and we can use usually wasted TCEs. Furthermore PHYP never actually allows creating windows starting at busaddress=0 so this MMIO32 range is never useful. This removes error exit and initializes the table with zero range if no MMIO32 is detected. Fixes: 381ceda88c4c ("powerpc/pseries/iommu: Make use of DDW for indirect mapping") Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20211020132315.2287178-5-aik@ozlabs.ru
2021-10-25powerpc/pseries/iommu: Check if the default window in use before removing itAlexey Kardashevskiy1-6/+6
At the moment this check is performed after we remove the default window which is late and disallows to revert whatever changes enable_ddw() has made to DMA windows. This moves the check and error exit before removing the window. This raised the message severity from "debug" to "warning" as this should not happen in practice and cannot be triggered by the userspace. Fixes: 381ceda88c4c ("powerpc/pseries/iommu: Make use of DDW for indirect mapping") Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20211020132315.2287178-4-aik@ozlabs.ru
2021-10-25powerpc/pseries/iommu: Use correct vfree for it_mapAlexey Kardashevskiy1-1/+2
The it_map array is vzalloc'ed so use vfree() for it when creating a huge DMA window failed for whatever reason. While at this, write zero to it_map. Fixes: 381ceda88c4c ("powerpc/pseries/iommu: Make use of DDW for indirect mapping") Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20211020132315.2287178-3-aik@ozlabs.ru
2021-10-24ARM: dts: qcom: fix typo in IPQ8064 thermal-sensor nodeDavid Heidelberg1-1/+1
I added the missing dash inside the thermal-sensor-cells. Signed-off-by: David Heidelberg <david@ixit.cz> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20211020203723.233578-1-david@ixit.cz
2021-10-24Revert "arm64: dts: qcom: msm8916-asus-z00l: Add sensors"Bjorn Andersson1-51/+0
I didn't notice that I already had applied this patch and while this builds fine one copy is enough. This reverts commit 22efef1ca05d2c96730060750d00205c49b8b39c. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-10-24arm64: dts: qcom: ipq6018: Remove unused 'iface_clk' property from dma-controller nodeBhupesh Sharma1-3/+2
'iface_clk' clock is not used by the qcom, bam_dma driver, so remove the same from 'ipq6018' dts. This is a preparatory patch for subsequent patch in this series which converts the qcom_bam_dma device-tree binding into YAML format. Without this change, 'make dtbs_check' leads to the following error: $ arch/arm64/boot/dts/qcom/ipq6018-cp01-c1.dt.yaml: dma-controller@7984000: clock-names: ['iface_clk', 'bam_clk'] is too long Fix the same. Cc: Thara Gopinath <thara.gopinath@linaro.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Rob Herring <robh+dt@kernel.org> Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20211013105541.68045-4-bhupesh.sharma@linaro.org
2021-10-24arm64: dts: qcom: ipq6018: Remove unused 'qcom,config-pipe-trust-reg' propertyBhupesh Sharma1-1/+0
'qcom,config-pipe-trust-reg' property doesn't seem to be used by the qcom, bam_dma driver, so remove the same from 'ipq6018' dts. This is a preparatory patch for subsequent patch in this series which converts the qcom_bam_dma device-tree binding into YAML format. Without this change, 'make dtbs_check' leads to the following error: $ arch/arm64/boot/dts/qcom/ipq6018-cp01-c1.dt.yaml: dma-controller@704000: 'qcom,config-pipe-trust-reg' does not match any of the regexes: 'pinctrl-[0-9]+' Fix the same. Cc: Thara Gopinath <thara.gopinath@linaro.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Rob Herring <robh+dt@kernel.org> Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20211013105541.68045-3-bhupesh.sharma@linaro.org
2021-10-24arm64: dts: qcom: sm8350: Add CPU topology and idle-statesBjorn Andersson1-0/+141
Add CPU topology and define the idle states for the silver and gold cores as well as the cluster. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Robert Foss <robert.foss@linaro.org> Link: https://lore.kernel.org/r/20210825221600.1498939-1-bjorn.andersson@linaro.org
2021-10-24arm64: dts: qcom: Drop unneeded extra device-specific includesStephan Gerhold8-1969/+1937
For some reason apq8016-sbc, apq8096-db820c, msm8916-mtp and msm8996-mtp were added as separate .dts and .dtsi files where the first only contains the model name and the latter contains most of the actual definitions. Perhaps this was done with the expectation that there would be other devices also making use of exactly the same. However, this has not been the case until now and it also seems unlikely in the future. Having the extra .dtsi only clutters the file list and provides little benefit. Move the contents of the .dtsi into the .dts file to make this consistent with most other devices that simply define everything in the .dts. There are no functional changes introduced by this patch: The compiled ".dtb"s are completely identical. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20211018133656.32649-1-stephan@gerhold.net
2021-10-24arm64: dts: qcom: msm8916: Drop standalone smem nodeStephan Gerhold1-10/+5
SMEM can now be described directly in the reserved-memory. This is mainly meant for newer SoCs where there is only one SMEM region. However, even on older SoCs like MSM8916 there is clearly one main SMEM region (described by "memory-region") that holds the smem_header and one special extra region used only for data of the RPM ("qcom,rpm-msg-ram"). The definition in reserved-memory also looks cleaner for older SoCs, so make use of that in MSM8916 as well. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20211018110009.30837-2-stephan@gerhold.net
2021-10-24arm64: dts: qcom: Fix node name of rpm-msg-ram device nodesStephan Gerhold7-7/+7
According to the new DT schema for qcom,rpm-msg-ram the node name should be sram@. memory@ is reserved for definition of physical RAM (usable by Linux). This fixes the following dtbs_check error on various device trees: memory@60000: 'device_type' is a required property From schema: dtschema/schemas/memory.yaml Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20211018110009.30837-1-stephan@gerhold.net
2021-10-24arm64: dts: qcom: msm8916-asus-z00l: Add sensorsJ.R. Divya Antony1-0/+51
This device has MPU-6515 imu and Asahi Kasei AK09911 magnetometer, Add support for it. Signed-off-by: J.R. Divya Antony <d.antony.jr@gmail.com> Reviewed-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20211012112735.2765-3-d.antony.jr@gmail.com
2021-10-24arm64: dts: qcom: msm8916-asus-z00l: Add SDCardJ.R. Divya Antony1-0/+33
Enable SDHCI (SD Card) Storage. Signed-off-by: J.R. Divya Antony <d.antony.jr@gmail.com> Reviewed-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20211012112735.2765-2-d.antony.jr@gmail.com
2021-10-24arm64: dts: qcom: msm8916-asus-z00l: Add touchscreenJ.R. Divya Antony1-0/+41
Add support for touchscreen in this device. Signed-off-by: J.R. Divya Antony <d.antony.jr@gmail.com> Reviewed-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20211012112735.2765-1-d.antony.jr@gmail.com
2021-10-24arm64: dts: qcom: sdm845-oneplus: remove devinfo-size from ramoops nodeDavid Heidelberg1-1/+0
This property doesn't exist in Linux kernel. Fixes: 288ef8a42612 ("arm64: dts: sdm845: add oneplus6/6t devices") Reviewed-by: Caleb Connolly <caleb@connolly.tech> Signed-off-by: David Heidelberg <david@ixit.cz> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20211011200138.115688-1-david@ixit.cz
2021-10-24arm64: dts: qcom: sdm845: Fix Qualcomm crypto engine bus clockVladimir Zapolskiy1-1/+1
The change corrects the described bus clock of the QCE. Fixes: 3e482859f1ef ("dts: qcom: sdm845: Add dt entries to support crypto engine.") Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reviewed-by: Thara Gopinath <thara.gopinath@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20211011095534.1580406-1-vladimir.zapolskiy@linaro.org
2021-10-24arm64: dts: qcom: msm8996: Add device tree entries to support crypto engineVladimir Zapolskiy1-0/+22
The change adds description of Qualcomm crypto engine controller and BAM associated with it. The change is inspired by commit 3e482859f1ef ("dts: qcom: sdm845: Add dt entries to support crypto engine.") While performance of cryptographic algorithms executed on QCE is lower than e.g. ones tinkered for ARM NEON, the offloaded execution would make sense: # cryptsetup benchmark | grep aes aes-cbc 128b 71.0 MiB/s 71.9 MiB/s aes-cbc 256b 62.4 MiB/s 62.4 MiB/s aes-xts 256b 70.7 MiB/s 70.8 MiB/s aes-xts 512b 62.0 MiB/s 63.3 MiB/s Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Cc: Thara Gopinath <thara.gopinath@linaro.org> Acked-by: Thara Gopinath <thara.gopinath@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20211011094822.1580122-1-vladimir.zapolskiy@linaro.org
2021-10-24arm64: dts: qcom: msm8996: move clock-frequency from PN547 NFC to I2C busKrzysztof Kozlowski1-1/+1
Although the early NXP NCI NFC bindings required the clock-frequency property, it was never used by the driver and it is actually a property of I2C bus, not I2C slave. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20211011073143.32645-1-krzysztof.kozlowski@canonical.com
2021-10-24arm64: dts: qcom: msm8916-asus-z00l: Add sensorsJ.R. Divya Antony1-0/+51
This device has MPU-6515 imu and Asahi Kasei AK09911 magnetometer. Add support for it. Signed-off-by: J.R. Divya Antony <d.antony.jr@gmail.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20211010033750.15204-1-d.antony.jr@gmail.com
2021-10-24arm64: dts: qcom: sdm630: Add disabled Venus supportAngeloGioacchino Del Regno1-0/+51
Add support for the Venus video decoder/encoder but leave it disabled by default; it is expected to eventually get enabled in each machine specific DT, where required. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20211008102119.268869-3-angelogioacchino.delregno@collabora.com
2021-10-24arm64: dts: qcom: pm660l: Remove board-specific WLED configurationMarijn Suijten1-7/+0
This string- and electrical configuration depend on the board and panel, and should hence not be defined generically for every user of pm660l. SoMainline will pick this configuration again when enabling WLED on the Sony Nile platform. Fixes: 7b56a804e58b ("arm64: dts: qcom: pm660l: Add WLED support") Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> Reviewed-By: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20211007213400.258371-14-marijn.suijten@somainline.org
2021-10-24arm64: dts: qcom: Move WLED num-strings from pmi8994 to sony-xperia-toneMarijn Suijten2-1/+1
The number of WLED strings used by a certain platform depend on the panel connected to that board and may not be the same for every user of pmi8994. Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> Reviewed-By: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20211007213400.258371-13-marijn.suijten@somainline.org
2021-10-24arm64: dts: qcom: pmi8994: Remove hardcoded linear WLED enabled-stringsMarijn Suijten1-2/+0
The driver now sets an appropriate default for WLED4 (and WLED5) just like WLED3 making this linear array from 0-3 redundant. In addition the driver is now able to parse arrays of variable length solving the "all four strings *have to* be defined" comment. Besides the driver will now warn when both properties are specified to prevent ambiguity: the length of the array is enough to imply a set number of strings. Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> Reviewed-By: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20211007213400.258371-12-marijn.suijten@somainline.org