- 10 Jun, 2016 40 commits
-
-
James Hogan authored
BugLink: http://bugs.launchpad.net/bugs/1590455 commit 13eb192d upstream. In microMIPS kernels, handle_signal() sets the isa16 mode bit in the vdso address so that the sigreturn trampolines (which are offset from the VDSO) get executed as microMIPS. However commit ebb5e78c ("MIPS: Initial implementation of a VDSO") changed the offsets to come from the VDSO image, which already have the isa16 mode bit set correctly since they're extracted from the VDSO shared library symbol table. Drop the isa16 mode bit handling from handle_signal() to fix sigreturn for cores which support both microMIPS and normal MIPS. This doesn't fix microMIPS only cores, since the VDSO is still built for normal MIPS, but thats a separate problem. Fixes: ebb5e78c ("MIPS: Initial implementation of a VDSO") Signed-off-by:
James Hogan <james.hogan@imgtec.com> Cc: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13348/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Tim Gardner <tim.gardner@canonical.com> Signed-off-by:
Kamal Mostafa <kamal@canonical.com>
-
Maciej W. Rozycki authored
BugLink: http://bugs.launchpad.net/bugs/1590455 commit abf378be upstream. Correct the cases missed with commit 9b26616c ("MIPS: Respect the ISA level in FCSR handling") and prevent writes to read-only FCSR bits there. This in particular applies to FP context initialisation where any IEEE 754-2008 bits preset by `mips_set_personality_nan' are cleared before the relevant ptrace(2) call takes effect and the PTRACE_POKEUSR request addressing FPC_CSR where no masking of read-only FCSR bits is done. Remove the FCSR clearing from FP context initialisation then and unify PTRACE_POKEUSR/FPC_CSR and PTRACE_SETFPREGS handling, by factoring out code from `ptrace_setfpregs' and calling it from both places. This mostly matters to soft float configurations where the emulator can be switched this way to a mode which should not be accessible and cannot be set with the CTC1 instruction. With hard float configurations any effect is transient anyway as read-only bits will retain their values at the time the FP context is restored. Signed-off-by:
Maciej W. Rozycki <macro@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13239/Signed-off-by:
-
Maciej W. Rozycki authored
BugLink: http://bugs.launchpad.net/bugs/1590455 commit 42495484 upstream. Fix a floating-point context restoration regression introduced with commit 9b26616c ("MIPS: Respect the ISA level in FCSR handling") that causes a Floating Point exception and consequently a kernel oops with hard float configurations when one or more FCSR Enable and their corresponding Cause bits are set both at a time via a ptrace(2) call. To do so reinstate Cause bit masking originally introduced with commit b1442d39 ("MIPS: Prevent user from setting FCSR cause bits") to address this exact problem and then inadvertently removed from the PTRACE_SETFPREGS request with the commit referred above. Signed-off-by:
-
Paul Burton authored
BugLink: http://bugs.launchpad.net/bugs/1590455 commit bd239f1e upstream. Whilst a PR_SET_FP_MODE prctl is performed there are decisions made based upon whether the task is executing on the current CPU. This may change if we're preempted, so disable preemption to avoid such changes for the lifetime of the mode switch. Signed-off-by:
Paul Burton <paul.burton@imgtec.com> Fixes: 9791554b ("MIPS,prctl: add PR_[GS]ET_FP_MODE prctl options for MIPS") Reviewed-by:
Aurelien Jarno <aurelien@aurel32.net> Cc: Adam Buchbinder <adam.buchbinder@gmail.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/13144/Signed-off-by:
-
Paul Burton authored
BugLink: http://bugs.launchpad.net/bugs/1590455 commit 6533af4d upstream. If a kernel doesn't support MSA context (ie. CONFIG_CPU_HAS_MSA=n) then it will only keep 64 bits per FP register in thread context, and the calls to set_fpr64 in restore_msa_extcontext will overrun the end of the FP register context into the FCSR & MSACSR values. GCC 6.x has become smart enough to detect this & complain like so: arch/mips/kernel/signal.c: In function 'protected_restore_fp_context': ./arch/mips/include/asm/processor.h:114:17: error: array subscript is above array bounds [-Werror=array-bounds] fpr->val##width[FPR_IDX(width, idx)] = val; \ ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~ ./arch/mips/include/asm/processor.h:118:1: note: in expansion of macro 'BUILD_FPR_ACCESS' BUILD_FPR_ACCESS(64) The only way to trigger this code to run would be for a program to set up an artificial extended MSA context structure following a sigframe & execute sigreturn. Whilst this doesn't allow a program to write to any state that it couldn't already, it makes little sense to allow this "restoration" of MSA context in a system that doesn't support MSA. Fix this by killing a program with SIGSYS if it tries something as crazy as "restoring" fake MSA context in this way, also fixing the build error & allowing for most of restore_msa_extcontext to be optimised out of kernels without support for MSA. Signed-off-by:
Michal Toman <michal.toman@imgtec.com> Fixes: bf82cb30 ("MIPS: Save MSA extended context around signals") Tested-by:
Aaro Koskinen <aaro.koskinen@iki.fi> Cc: James Hogan <james.hogan@imgtec.com> Cc: Michal Toman <michal.toman@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13164/Signed-off-by:
-
James Hogan authored
BugLink: http://bugs.launchpad.net/bugs/1590455 commit ea168857 upstream. The MSA ld_*/st_* assembler macros for when the toolchain doesn't support MSA use addu to offset the base address. However it is a virtual memory pointer so fix it to use PTR_ADDU which expands to daddu for 64-bit kernels. Signed-off-by:
-
Paul Burton authored
BugLink: http://bugs.launchpad.net/bugs/1590455 commit 8a3c8b48 upstream. In revision 1.12 of the MSA specification, the copy_u.w instruction has been removed for MIPS32 & the copy_u.d instruction has been removed for MIPS64. Newer toolchains (eg. Codescape SDK essentials 2015.10) will complain about this like so: arch/mips/kernel/r4k_fpu.S:290: Error: opcode not supported on this processor: mips32r2 (mips32r2) `copy_u.w $1,$w26[3]' Since we always copy to the width of a GPR, simply use copy_s instead of copy_u to fix this. Signed-off-by:
-
Huacai Chen authored
BugLink: http://bugs.launchpad.net/bugs/1590455 commit 3484de7b upstream. Due to datasheet, reserving 0xff800000~0xffffffff (8MB below 4GB) is not enough for RS780E integrated GPU's TOM (top of memory) registers and MSI/MSI-x memory region, so we reserve 0xfe000000~0xffffffff (32MB below 4GB). Signed-off-by:
Huacai Chen <chenhc@lemote.com> Cc: Aurelien Jarno <aurelien@aurel32.net> Cc: Steven J . Hill <sjhill@realitydiluted.com> Cc: Fuxin Zhang <zhangfx@lemote.com> Cc: Zhangjin Wu <wuzhangjin@gmail.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/12889/Signed-off-by:
-
Huacai Chen authored
BugLink: http://bugs.launchpad.net/bugs/1590455 commit a95d0692 upstream. After commit 92923ca3 ("mm: meminit: only set page reserved in the memblock region"), the MIPS hibernation is broken. Because pages in nosave data section should be "reserved", but currently they aren't set to "reserved" at initialization. This patch makes hibernation work again. Signed-off-by:
-
Matthias Schiffer authored
BugLink: http://bugs.launchpad.net/bugs/1590455 commit f5b556c9 upstream. This makes the ath79 bootconsole behave the same way as the generic 8250 bootconsole. Also waiting for TEMT (transmit buffer is empty) instead of just THRE (transmit buffer is not full) ensures that all characters have been transmitted before the real serial driver starts reconfiguring the serial controller (which would sometimes result in garbage being transmitted.) This change does not cause a visible performance loss. In addition, this seems to fix a hang observed in certain configurations on many AR7xxx/AR9xxx SoCs during autoconfig of the real serial driver. A more complete follow-up patch will disable 8250 autoconfig for ath79 altogether (the serial controller is detected as a 16550A, which is not fully compatible with the ath79 serial, and the autoconfig may lead to undefined behavior on ath79.) Signed-off-by:
Matthias Schiffer <mschiffer@universe-factory.net> Signed-off-by:
-
Paul Burton authored
BugLink: http://bugs.launchpad.net/bugs/1590455 commit 37d22a0d upstream. It's possible for pages to become visible prior to update_mmu_cache running if a thread within the same address space preempts the current thread or runs simultaneously on another CPU. That is, the following scenario is possible: CPU0 CPU1 write to page flush_dcache_page flush_icache_page set_pte_at map page update_mmu_cache If CPU1 maps the page in between CPU0's set_pte_at, which marks it valid & visible, and update_mmu_cache where the dcache flush occurs then CPU1s icache will fill from stale data (unless it fills from the dcache, in which case all is good, but most MIPS CPUs don't have this property). Commit 4d46a67a ("MIPS: Fix race condition in lazy cache flushing.") attempted to fix that by performing the dcache flush in flush_icache_page such that it occurs before the set_pte_at call makes the page visible. However it has the problem that not all code that writes to pages exposed to userland call flush_icache_page. There are many callers of set_pte_at under mm/ and only 2 of them do call flush_icache_page. Thus the race window between a page becoming visible & being coherent between the icache & dcache remains open in some cases. To illustrate some of the cases, a WARN was added to __update_cache with this patch applied that triggered in cases where a page about to be flushed from the dcache was not the last page provided to flush_icache_page. That is, backtraces were obtained for cases in which the race window is left open without this patch. The 2 standout examples follow. When forking a process: [ 15.271842] [<80417630>] __update_cache+0xcc/0x188 [ 15.277274] [<80530394>] copy_page_range+0x56c/0x6ac [ 15.282861] [<8042936c>] copy_process.part.54+0xd40/0x17ac [ 15.289028] [<80429f80>] do_fork+0xe4/0x420 [ 15.293747] [<80413808>] handle_sys+0x128/0x14c When exec'ing an ELF binary: [ 14.445964] [<80417630>] __update_cache+0xcc/0x188 [ 14.451369] [<80538d88>] move_page_tables+0x414/0x498 [ 14.457075] [<8055d848>] setup_arg_pages+0x220/0x318 [ 14.462685] [<805b0f38>] load_elf_binary+0x530/0x12a0 [ 14.468374] [<8055ec3c>] search_binary_handler+0xbc/0x214 [ 14.474444] [<8055f6c0>] do_execveat_common+0x43c/0x67c [ 14.480324] [<8055f938>] do_execve+0x38/0x44 [ 14.485137] [<80413808>] handle_sys+0x128/0x14c These code paths write into a page, call flush_dcache_page then call set_pte_at without flush_icache_page inbetween. The end result is that the icache can become corrupted & userland processes may execute unexpected or invalid code, typically resulting in a reserved instruction exception, a trap or a segfault. Fix this race condition fully by performing any cache maintenance required to keep the icache & dcache in sync in set_pte_at, before the page is made valid. This has the added bonus of ensuring the cache maintenance always happens in one location, rather than being duplicated in flush_icache_page & update_mmu_cache. It also matches the way other architectures solve the same problem (see arm, ia64 & powerpc). Signed-off-by:
Ionela Voinescu <ionela.voinescu@imgtec.com> Cc: Lars Persson <lars.persson@axis.com> Fixes: 4d46a67a ("MIPS: Fix race condition in lazy cache flushing.") Cc: Steven J. Hill <sjhill@realitydiluted.com> Cc: David Daney <david.daney@cavium.com> Cc: Huacai Chen <chenhc@lemote.com> Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Jerome Marchand <jmarchan@redhat.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12722/Signed-off-by:
-
Paul Burton authored
BugLink: http://bugs.launchpad.net/bugs/1590455 commit f4281bba upstream. The following patch will expose __update_cache to highmem pages. Handle them by mapping them in for the duration of the cache maintenance, just like in __flush_dcache_page. The code for that isn't shared because we need the page address in __update_cache so sharing became messy. Given that the entirity is an extra 5 lines, just duplicate it. Signed-off-by:
-
Paul Burton authored
BugLink: http://bugs.launchpad.net/bugs/1590455 commit 234859e4 upstream. When flush_dcache_page is called on an executable page, that page is about to be provided to userland & we can presume that the icache contains no valid entries for its address range. However if the icache does not fill from the dcache then we cannot presume that the pages content has been written back as far as the memories that the dcache will fill from (ie. L2 or further out). This was being done for lowmem pages, but not for highmem which can lead to icache corruption. Fix this by mapping highmem pages & flushing their content from the dcache in __flush_dcache_page before providing the page to userland, just as is done for lowmem pages. Signed-off-by:
-
James Hogan authored
BugLink: http://bugs.launchpad.net/bugs/1590455 commit a7e89326 upstream. Commit f51246ef ("MIPS: Get rid of finish_arch_switch().") moved the __restore_watch() call from finish_arch_switch() (i.e. after resume() returns) to before the resume() call in switch_to(). This results in watchpoints only being restored when a task is descheduled, preventing the watchpoints from being effective most of the time, except due to chance before the watchpoints are lazily removed. Fix the call sequence from switch_to() through to mips_install_watch_registers() to pass the task_struct pointer of the next task, instead of using current. This allows the watchpoints for the next (non-current) task to be restored without reintroducing finish_arch_switch(). Fixes: f51246ef ("MIPS: Get rid of finish_arch_switch().") Signed-off-by:
-
James Hogan authored
BugLink: http://bugs.launchpad.net/bugs/1590455 commit 987e5b83 upstream. Since commit 8cb48fe1 ("MIPS: Provide correct siginfo_t.si_stime"), MIPS' uapi/asm/siginfo.h has included uapi/asm-generic/siginfo.h directly before defining MIPS' struct siginfo, in order to get the necessary definitions needed for the siginfo struct without the generic copy_siginfo() hitting compiler errors due to struct siginfo not yet being defined. Now that the generic copy_siginfo() is moved out to linux/signal.h we can safely include asm-generic/siginfo.h before defining the MIPS specific struct siginfo, which avoids the uapi/ include as well as breakage due to generic copy_siginfo() being defined before struct siginfo. Reported-by:
Christopher Ferris <cferris@google.com> Fixes: 8cb48fe1 ("MIPS: Provide correct siginfo_t.si_stime") Signed-off-by:
-
James Hogan authored
BugLink: http://bugs.launchpad.net/bugs/1590455 commit 5daebc47 upstream. Commit 85efde6f ("make exported headers use strict posix types") changed the asm-generic siginfo.h to use the __kernel_* types, and commit 3a471cbc ("remove __KERNEL_STRICT_NAMES") make the internal types accessible only to the kernel, but the MIPS implementation hasn't been updated to match. Switch to proper types now so that the exported asm/siginfo.h won't produce quite so many compiler errors when included alone by a user program. Signed-off-by:
-
James Hogan authored
BugLink: http://bugs.launchpad.net/bugs/1590455 commit 81a76d71 upstream. When showing backtraces in response to traps, for example crashes and address errors (usually unaligned accesses) when they are set in debugfs to be reported, unwind_stack will be used if the PC was in the kernel text address range. However since EVA it is possible for user and kernel address ranges to overlap, and even without EVA userland can still trigger an address error by jumping to a KSeg0 address. Adjust the check to also ensure that it was running in kernel mode. I don't believe any harm can come of this problem, since unwind_stack() is sufficiently defensive, however it is only meant for unwinding kernel code, so to be correct it should use the raw backtracing instead. Signed-off-by:
Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/11701/Signed-off-by:
-
James Hogan authored
BugLink: http://bugs.launchpad.net/bugs/1590455 commit a816b306 upstream. When unwinding through IRQs and exceptions, the unwinding only continues if the PC is a kernel text address, however since EVA it is possible for user and kernel address ranges to overlap, potentially allowing unwinding to continue to user mode if the user PC happens to be in the kernel text address range. Adjust the check to also ensure that the register state from before the exception is actually running in kernel mode, i.e. !user_mode(regs). I don't believe any harm can come of this problem, since the PC is only output, the stack pointer is checked to ensure it resides within the task's stack page before it is dereferenced in search of the return address, and the return address register is similarly only output (if the PC is in a leaf function or the beginning of a non-leaf function). However unwind_stack() is only meant for unwinding kernel code, so to be correct the unwind should stop there. Signed-off-by:
-
Maciej W. Rozycki authored
BugLink: http://bugs.launchpad.net/bugs/1590455 commit e49d3848 upstream. Fix a build regression from commit c9017757 ("MIPS: init upper 64b of vector registers when MSA is first used"): arch/mips/built-in.o: In function `enable_restore_fp_context': traps.c:(.text+0xbb90): undefined reference to `_init_msa_upper' traps.c:(.text+0xbb90): relocation truncated to fit: R_MIPS_26 against `_init_msa_upper' traps.c:(.text+0xbef0): undefined reference to `_init_msa_upper' traps.c:(.text+0xbef0): relocation truncated to fit: R_MIPS_26 against `_init_msa_upper' to !CONFIG_CPU_HAS_MSA configurations with older GCC versions, which are unable to figure out that calls to `_init_msa_upper' are indeed dead. Of the many ways to tackle this failure choose the approach we have already taken in `thread_msa_context_live'. [ralf@linux-mips.org: Drop patch segment to junk file.] Signed-off-by:
-
Paul Burton authored
BugLink: http://bugs.launchpad.net/bugs/1590455 commit ab4a92e6 upstream. When emulating a jalr instruction with rd == $0, the code in isBranchInstr was incorrectly writing to GPR $0 which should actually always remain zeroed. This would lead to any further instructions emulated which use $0 operating on a bogus value until the task is next context switched, at which point the value of $0 in the task context would be restored to the correct zero by a store in SAVE_SOME. Fix this by not writing to rd if it is $0. Fixes: 102cedc3 ("MIPS: microMIPS: Floating point support.") Signed-off-by:
-
Leonid Yegoshin authored
BugLink: http://bugs.launchpad.net/bugs/1590455 commit 41fa29e4 upstream. Error recovery pointers for fixups was improperly set as ".word" which is unsuitable for MIPS64. Replaced by STR(PTR) [ralf@linux-mips.org: Apply changes as requested in the review process.] Signed-off-by:
Markos Chandras <markos.chandras@imgtec.com> Fixes: b0a668fb ("MIPS: kernel: mips-r2-to-r6-emul: Add R2 emulator for MIPS R6") Cc: macro@linux-mips.org Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/9911/Signed-off-by:
-
Igor Redko authored
BugLink: http://bugs.launchpad.net/bugs/1587091 Add a new field, VIRTIO_BALLOON_S_AVAIL, to virtio_balloon memory statistics protocol, corresponding to 'Available' in /proc/meminfo. It indicates to the hypervisor how big the balloon can be inflated without pushing the guest system to swap. Signed-off-by:
Igor Redko <redkoi@virtuozzo.com> Signed-off-by:
Denis V. Lunev <den@openvz.org> Reviewed-by:
Roman Kagan <rkagan@virtuozzo.com> Cc: Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit 5057dcd0) Signed-off-by:
Chris J Arges <chris.j.arges@canonical.com> Signed-off-by:
-
Igor Redko authored
BugLink: http://bugs.launchpad.net/bugs/1587091 Add a new field, VIRTIO_BALLOON_S_AVAIL, to virtio_balloon memory statistics protocol, corresponding to 'Available' in /proc/meminfo. It indicates to the hypervisor how big the balloon can be inflated without pushing the guest system to swap. This metric would be very useful in VM orchestration software to improve memory management of different VMs under overcommit. This patch (of 2): Factor out calculation of the available memory counter into a separate exportable function, in order to be able to use it in other parts of the kernel. In particular, it appears a relevant metric to report to the hypervisor via virtio-balloon statistics interface (in a followup patch). Signed-off-by:
-
Michael Neuling authored
BugLink: http://bugs.launchpad.net/bugs/1588468 When detaching contexts, we may still have interrupts in the system which are yet to be delivered to any CPU and be acked in the PSL. This can result in a subsequent unrelated process getting an spurious IRQ or an interrupt for a non-existent context. This polls the PSL to ensure that the PSL is clear of IRQs for the detached context, before removing the context from the idr. Signed-off-by:
Michael Neuling <mikey@neuling.org> Tested-by:
Andrew Donnellan <andrew.donnellan@au1.ibm.com> Acked-by:
Ian Munsie <imunsie@au1.ibm.com> Tested-by:
Vaibhav Jain <vaibhav@linux.vnet.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> (cherry picked from commit 2bc79ffc) Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
-
Vaibhav Jain authored
BugLink: http://bugs.launchpad.net/bugs/1588468 Add a check at the beginning of cxl_probe function to ignore virtual pci devices created for each afu registered. This fixes the the errors messages logged about missing CXL vsec, when cxl probe is unable to find necessary vsec entries in device pci config space. The error message logged are of the form : cxl-pci 0004:00:00.0: ABORTING: CXL VSEC not found! cxl-pci 0004:00:00.0: cxl_init_adapter failed: -19 Cc: Ian Munsie <imunsie@au1.ibm.com> Cc: Frederic Barrat <fbarrat@linux.vnet.ibm.com> Signed-off-by:
-
Frederic Barrat authored
BugLink: http://bugs.launchpad.net/bugs/1588468 The cxl_get_phys_dev() API returns a struct device pointer which could belong to either a struct pci_dev (bare-metal) or platform_device (powerVM). To avoid potential problems in drivers, remove that API. It was introduced to allow drivers to read the VPD of the adapter, but the cxl driver now provides the cxl_pci_read_adapter_vpd() API for that purpose. Co-authored-by:
Christophe Lombard <clombard@linux.vnet.ibm.com> Signed-off-by:
Frederic Barrat <fbarrat@linux.vnet.ibm.com> Signed-off-by:
-
Frederic Barrat authored
BugLink: http://bugs.launchpad.net/bugs/1588468 To read the adapter VPD, drivers can't rely on pci config APIs, as it wouldn't work on powerVM. cxl introduced a new kernel API especially for this, so start using it. Co-authored-by:
Uma Krishnan <ukrishn@linux.vnet.ibm.com> Acked-by:
Matthew R. Ochs <mrochs@linux.vnet.ibm.com> Acked-by:
Manoj N. Kumar <manoj@linux.vnet.ibm.com> Signed-off-by:
-
Christophe Lombard authored
BugLink: http://bugs.launchpad.net/bugs/1588468 To ease debugging, add a few tracepoints around the cxl hcalls. Co-authored-by:
-
Christophe Lombard authored
BugLink: http://bugs.launchpad.net/bugs/1588468 Check the AFU state whenever an API is called. The hypervisor may issue a reset of the adapter when it detects a fault. When it happens, it launches an error recovery which will either move the AFU to a permanent failure state, or in the disabled state. If the AFU is found to be disabled, detach all existing contexts from it before issuing a AFU reset to re-enable it. Before detaching contexts, notify any kernel driver through the EEH callbacks of the AFU pci device. Co-authored-by:
-
Frederic Barrat authored
BugLink: http://bugs.launchpad.net/bugs/1588468 Like on bare-metal, the cxl driver creates a virtual PHB and a pci device for the AFU. The configuration space of the device is mapped to the configuration record of the AFU. Reuse the code defined in afu_cr_read8|16|32() when reading the configuration space of the AFU device. Even though the (virtual) AFU device is a pci device, the adapter is not. So a driver using the cxl kernel API cannot read the VPD of the adapter through the usual PCI interface. Therefore, we add a call to the cxl kernel API: ssize_t cxl_read_adapter_vpd(struct pci_dev *dev, void *buf, size_t count); Co-authored-by:
-
Frederic Barrat authored
BugLink: http://bugs.launchpad.net/bugs/1588468 Add new entry point to scan the device tree at boot in a guest, looking for cxl devices. Co-authored-by:
-
Christophe Lombard authored
BugLink: http://bugs.launchpad.net/bugs/1588468 The new flash.c file contains the logic to flash a new image on the adapter, through a hcall. It is an iterative process, with chunks of data of 1M at a time. There are also 2 phases: write and verify. The flash operation itself is driven from a user-land tool. Once flashing is successful, an rtas call is made to update the device tree with the new properties values for the adapter and the AFU(s) Add a new char device for the adapter, so that the flash tool can access the card, even if there is no valid AFU on it. Co-authored-by:
-
Christophe Lombard authored
BugLink: http://bugs.launchpad.net/bugs/1588468 Filter out a few adapter parameters which don't make sense in a guest. Document the changes. Co-authored-by:
-
Christophe Lombard authored
BugLink: http://bugs.launchpad.net/bugs/1588468 The new of.c file contains code to parse the device tree to find out about cxl adapters and AFUs. guest.c implements the guest-specific callbacks for the backend API. The process element ID is not known until the context is attached, so we have to separate the context ID assigned by the cxl driver from the process element ID visible to the user applications. In bare-metal, the 2 IDs match. Co-authored-by:
-
Uma Krishnan authored
BugLink: http://bugs.launchpad.net/bugs/1588468 In order to support cxlflash in the PowerVM environment, underlying hypervisor APIs have imposed a kernel API ordering change. For the superpipe access to LUN, user applications need a context. The cxlflash module creates this context by making a sequence of cxl calls. In the current code, a context is initialized via cxl_dev_context_init() followed by cxl_process_element(), a function that obtains the process element id. Finally, cxl_start_work() is called to attach the process element. In the PowerVM environment, a process element id cannot be obtained from the hypervisor until the process element is attached. The cxlflash module is unable to create contexts without a valid process element id. To fix this problem, cxl_start_work() is called before obtaining the process element id. Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> (cherry picked from commit 5d1952ac) Signed-off-by:
-
Matthew R. Ochs authored
BugLink: http://bugs.launchpad.net/bugs/1588468 The cxlflash_disk_attach() routine currently uses a cascading error gate strategy for its error cleanup path. While this strategy is commonly used to handle cleanup scenarios, it is too restrictive when function callouts need to be restructured. Problems range from inserting error path bugs in previously 'good' code to the cleanup path imposing design changes to how the normal path is structured. A less restrictive approach is needed to support ordering changes that come about when operating in different environments. To overcome this restriction, the error cleanup path is modified to have a single entrypoint and use conditional logic to cleanup where necessary. Entities that require multiple cleanup steps must be carefully vetted to ensure their APIs support state. In cases where they do not (none as of this commit) additional local variables can be used to maintain state on their behalf. Signed-off-by:
-
Matthew R. Ochs authored
BugLink: http://bugs.launchpad.net/bugs/1588468 Presently, context information structures are allocated and initialized in the same routine, create_context(). This imposes an ordering restriction such that all pieces of information needed to initialize a context must be known before the context is even allocated. This design point is not flexible when the order of context creation needs to be modified. Specifically, this can lead to problems when members of the context information structure are a part of an ordering dependency (i.e. - the 'work' structure embedded within the context). To remedy, the allocation is left as-is, inside of the existing create_context() routine and the initialization is transitioned to a new void routine, init_context(). At the same time, in anticipation of these routines not being called in sequence, a state boolean is added to the context information structure to track when the context has been initilized. The context teardown routine, destroy_context(), is modified to support being called with a non-initialized context. Signed-off-by:
-
Uma Krishnan authored
BugLink: http://bugs.launchpad.net/bugs/1588468 When operating in the PowerVM environment, the cxlflash module can receive an error from the hypervisor indicating that there are existing mappings in the page table for the process MMIO space. This issue exists because term_afu() currently invokes term_mc() before stop_afu(), allowing for the master context to be detached first and the problem state area to be unmapped second. To resolve this issue, stop_afu() should be called before term_mc(). Signed-off-by:
-
Manoj N. Kumar authored
BugLink: http://bugs.launchpad.net/bugs/1588468 The calls to pci_request_regions(), pci_resource_start(), pci_set_dma_mask(), pci_set_master() and pci_save_state() are all unnecessary for the IBM CXL flash adapter since data buffers are not required to be mapped to the device's memory. The use of services such as pci_set_dma_mask() are problematic on hypervisor managed systems as the IBM CXL flash adapter is operating under a virtual PCI Host Bridge (virtual PHB) which does not support these services. cxlflash 0001:00:00.0: init_pci: Failed to set PCI DMA mask rc=-5 The resolution is to simplify init_pci(), to a point where it does the bare minimum (pci_enable_device). Similarly, remove the call the pci_release_regions() from cxlflash_remove(). Signed-off-by:
-
Christophe Lombard authored
BugLink: http://bugs.launchpad.net/bugs/1588468 Introduce sub-structures containing the bare-metal specific fields in the structures describing the adapter (struct cxl) and AFU (struct cxl_afu). Update all their references. Co-authored-by:
-
