- 04 Oct, 2016 25 commits
-
-
Nicholas Piggin authored
Signed-off-by:
Nicholas Piggin <npiggin@gmail.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au>
-
Nicholas Piggin authored
Signed-off-by:
-
Nicholas Piggin authored
Signed-off-by:
-
Nicholas Piggin authored
Signed-off-by:
-
Nicholas Piggin authored
Signed-off-by:
-
Nicholas Piggin authored
Signed-off-by:
-
Nicholas Piggin authored
Signed-off-by:
-
Nicholas Piggin authored
Signed-off-by:
-
Nicholas Piggin authored
Signed-off-by:
-
Nicholas Piggin authored
Signed-off-by:
-
Nicholas Piggin authored
Signed-off-by:
-
Nicholas Piggin authored
Signed-off-by:
-
Nicholas Piggin authored
Signed-off-by:
-
Nicholas Piggin authored
Signed-off-by:
-
Nicholas Piggin authored
Signed-off-by:
-
Nicholas Piggin authored
Signed-off-by:
-
Nicholas Piggin authored
Signed-off-by:
-
Nicholas Piggin authored
Signed-off-by:
-
Nicholas Piggin authored
Signed-off-by:
-
Nicholas Piggin authored
Signed-off-by:
-
Nicholas Piggin authored
Signed-off-by:
-
Nicholas Piggin authored
Use assembler sections of fixed size and location to arrange the 64-bit Book3S exception vector code (64-bit Book3E also uses it in head_64.S for 0x0..0x100). This allows better flexibility in arranging exception code and hiding unimportant details behind macros. Gas sections can be a bit painful to use this way, mainly because the assembler does not know where they will be finally linked. Taking absolute addresses requires a bit of trickery for example, but it can be hidden behind macros for the most part. Generated code is mostly the same except locations, offsets, alignments. The "+ 0x2" is only required for the trap number / kvm exit number, which gets loaded as a constant into a register. Previously, code also used + 0x2 for label names, but we changed to using "H" to distinguish HV case for that. Remove the last vestiges of that. __after_prom_start is taking absolute address of a label in another fixed section. Newer toolchains seemed to compile this okay, but older ones do not. FIXED_SYMBOL_ABS_ADDR is more foolproof, it just takes an additional line to define. Signed-off-by:
-
Nicholas Piggin authored
With a subsequent patch to put text into different sections, (_end - _stext) can no longer be computed at link time to determine the end of the copy. Instead, calculate it at runtime with (copy_to_here - _stext) + (_end - copy_to_here). Signed-off-by:
-
Nicholas Piggin authored
Move exception handler alignment directives into the head-64.h macros, beause they will no longer work in-place after the next patch. This slightly changes functions that have alignments applied and therefore code generation, which is why it was not done initially (see earlier patch). Signed-off-by:
-
Michael Ellerman authored
Create arch/powerpc/include/asm/head-64.h with macros that specify an exception vector (name, type, location), which will be used to label and lay out exceptions into the object file. Naming is moved out of exception-64s.h, which is used to specify the implementation of exception handlers. objdump of generated code in exception vectors is unchanged except for names. Alignment directives scattered around are annoying, but done this way so that disassembly can verify identical instruction generation before and after patch. These get cleaned up in future patch. We change the way KVMTEST works, explicitly passing EXC_HV or EXC_STD rather than overloading the trap number. This removes the need to have SOFTEN values for the overloaded trap numbers, eg. 0x502. Signed-off-by:
-
- 29 Sep, 2016 9 commits
-
-
Anton Blanchard authored
__kernel_get_syscall_map() and __kernel_clock_getres() use cmpli to check if the passed in pointer is non zero. cmpli maps to a 32 bit compare on binutils, so we ignore the top 32 bits. A simple test case can be created by passing in a bogus pointer with the bottom 32 bits clear. Using a clk_id that is handled by the VDSO, then one that is handled by the kernel shows the problem: printf("%d\n", clock_getres(CLOCK_REALTIME, (void *)0x100000000)); printf("%d\n", clock_getres(CLOCK_BOOTTIME, (void *)0x100000000)); And we get: 0 -1 The bigger issue is if we pass a valid pointer with the bottom 32 bits clear, in this case we will return success but won't write any data to the pointer. I stumbled across this issue because the LLVM integrated assembler doesn't accept cmpli with 3 arguments. Fix this by converting them to cmpldi. Fixes: a7f290da ("[PATCH] powerpc: Merge vdso's and add vdso support to 32 bits kernel") Cc: stable@vger.kernel.org # v2.6.15+ Signed-off-by:Anton Blanchard <anton@samba.org> Signed-off-by:
-
Balbir Singh authored
When PCI Device pass-through is enabled via VFIO, KVM-PPC will pin pages using get_user_pages_fast(). One of the downsides of the pinning is that the page could be in CMA region. The CMA region is used for other allocations like the hash page table. Ideally we want the pinned pages to be from non CMA region. This patch (currently only for KVM PPC with VFIO) forcefully migrates the pages out (huge pages are omitted for the moment). There are more efficient ways of doing this, but that might be elaborate and might impact a larger audience beyond just the kvm ppc implementation. The magic is in new_iommu_non_cma_page() which allocates the new page from a non CMA region. I've tested the patches lightly at my end. The full solution requires migration of THP pages in the CMA region. That work will be done incrementally on top of this. Signed-off-by:
Balbir Singh <bsingharora@gmail.com> Acked-by:
Alexey Kardashevskiy <aik@ozlabs.ru> [mpe: Merged via powerpc tree as that's where the changes are] Signed-off-by:
-
Gavin Shan authored
This supports PCI surprise hotplug. The design is highlighted as below: * The PCI slot's surprise hotplug capability is exposed through device node property "ibm,slot-surprise-pluggable", meaning PCI surprise hotplug will be disabled if skiboot doesn't support it yet. * The interrupt because of presence or link state change is raised on surprise hotplug event. One event is allocated and queued to the PCI slot for workqueue to pick it up and process in serialized fashion. The code flow for surprise hotplug is same to that for managed hotplug except: the affected PEs are put into frozen state to avoid unexpected EEH error reporting in surprise hot remove path. Signed-off-by:Gavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by:
-
Gavin Shan authored
This removes likely() and unlikely() in pnv_php.c as the code isn't running in hot path. Those macros to affect CPU's branch stream don't help a lot for performance. I used them to identify the cases are likely or unlikely to happen. No logical changes introduced. Signed-off-by:
-
Gavin Shan authored
This unfreezes PE when it's initialized because the PE might be put into frozen state in the last hot remove path. It's not harmful to do so if the PE is already in unfrozen state. Signed-off-by:
-
Gavin Shan authored
This exports eeh_pe_state_mark(). It will be used to mark the surprise hot removed PE as isolated to avoid unexpected EEH error reporting in surprise remove path. Signed-off-by:
-
Gavin Shan authored
This exports @confirm_error_lock so that eeh_serialize_{lock, unlock}() can be used to freeze the affected PE in PCI surprise hot remove path. Signed-off-by: -
Gavin Shan authored
Function eeh_pe_set_option() is used to apply the requested options (enable, disable, unfreeze) in EEH virtualization path. The semantics of this function isn't complete until freezing is supported. This allows to freeze the indicated PE. The new semantics is going to be used in PCI surprise hot remove path, to freeze removed PCI devices (PE) to avoid unexpected EEH error reporting. Signed-off-by:
-
Gavin Shan authored
When issuing PHB reset, OPAL API opal_pci_poll() is called to drive the state machine in OPAL forward. However, we needn't always call the function under some circumstances like reset deassert. This avoids calling opal_pci_poll() when OPAL_SUCCESS is returned from opal_pci_reset(). Except the overhead introduced by additional one unnecessary OPAL call, I didn't run into real issue because of this. Reported-by:
Pridhiviraj Paidipeddi <ppaiddipe@in.ibm.com> Signed-off-by:
-
- 28 Sep, 2016 6 commits
-
-
Oliver O'Halloran authored
This patch adds an option to use XZ compression for the kernel image. Currently this is only enabled for 64-bit Book3S targets, which is roughly equivalent to the platforms that use the kernel's zImage wrapper, and that have been tested. The bulk of the 32-bit platforms and 64-bit BookE use uboot images, which relies on uboot implementing XZ. In future we can enable XZ support for those targets once someone has tested it. Signed-off-by:
Oliver O'Halloran <oohall@gmail.com> Signed-off-by:
-
Oliver O'Halloran authored
This modifies the wrapper script so that the -Z option takes an argument to specify the compression type. It can either be 'gz', 'xz' or 'none'. The legazy --no-gzip and -z options are still supported and will set the compression to none and gzip respectively, but they are not documented. Only XZ -6 is used for compression rather than XZ -9. Using compression levels higher than 6 requires the decompressor to build a large (64MB) dictionary when decompressing and some environments cannot satisfy such large allocations (e.g. POWER 6 LPAR partition firmware). Signed-off-by:
-
Oliver O'Halloran authored
This code is no longer used and can be removed. Signed-off-by:
-
Oliver O'Halloran authored
Currently the powerpc boot wrapper has its own wrapper around zlib to handle decompressing gzipped kernels. The kernel decompressor library functions now provide a generic interface that can be used in the pre-boot environment. This allows boot wrappers to easily support different compression algorithms. This patch converts the wrapper to use this new API, but does not add support for using new algorithms. Signed-off-by:
-
Oliver O'Halloran authored
Most architectures allow the compression algorithm used to produced the vmlinuz image to be selected as a kernel config option. In preperation for supporting algorithms other than gzip in the powerpc boot wrapper the makefile needs to be modified to use these config options. Signed-off-by:
-
Oliver O'Halloran authored
The powerpc boot wrapper is potentially compiled with a separate toolchain and/or toolchain flags than the rest of the kernel. The usual case is a 64-bit big endian kernel builds a 32-bit big endian wrapper. The main problem with this is that the wrapper does not have access to the kernel headers (without a lot of gross hacks). To get around this the required headers are copied into the build directory via several sed scripts which rewrite problematic includes. This patch moves these fixups out of the makefile into a separate .sed script file to clean up makefile slightly. Signed-off-by:
-
