Some stack pointers used to also be thread_info pointers
and were called tp. Now that they are only stack pointers,
rename them sp.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/irq.c | 17 +++--
arch/powerpc/kernel/setup_64.c | 20 ++--
2 files
Now that current_thread_info is located at the beginning of 'current'
task struct, CURRENT_THREAD_INFO macro is not really needed any more.
This patch replaces it by loads of the value at PACACURRENT(r13).
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/exception-64s.h | 4
Now that thread_info is similar to task_struct, it's address is in r2
so CURRENT_THREAD_INFO() macro is useless. This patch removes it.
At the same time, as the 'cpu' field is not anymore in thread_info,
this patch renames it to TASK_CPU.
Signed-off-by: Christophe Leroy
---
The table of pointers 'current_set' has been used for retrieving
the stack and current. They used to be thread_info pointers as
they were pointing to the stack and current was taken from the
'task' field of the thread_info.
Now, the pointers of 'current_set' table are now both pointers
to
thread_info is not anymore in the stack, so the entire stack
can now be used.
There is also no risk anymore of corrupting task_cpu(p) with a
stack overflow so the patch removes the test.
When doing this, an explicit test for NULL stack pointer is
needed in validate_sp() as it is not anymore
This patch activates CONFIG_THREAD_INFO_IN_TASK which
moves the thread_info into task_struct.
Moving thread_info into task_struct has the following advantages:
- It protects thread_info from corruption in the case of stack
overflows.
- Its address is harder to determine if stack addresses are
This patch cleans the powerpc kernel before activating
CONFIG_THREAD_INFO_IN_TASK:
- The purpose of the pointer given to call_do_softirq() and
call_do_irq() is to point the new stack ==> change it to void* and
rename it 'sp'
- Don't use CURRENT_THREAD_INFO() to locate the stack.
- Fix a few
When moving to CONFIG_THREAD_INFO_IN_TASK, the thread_info 'cpu' field
gets moved into task_struct and only defined when CONFIG_SMP is set.
This patch ensures that TI_CPU is only used when CONFIG_SMP is set and
that task_struct 'cpu' field is not used directly out of SMP code.
Signed-off-by:
When activating CONFIG_THREAD_INFO_IN_TASK, linux/sched.h
includes asm/current.h. This generates a circular dependency.
To avoid that, asm/processor.h shall not be included in mmu-hash.h
In order to do that, this patch moves into a new header called
asm/task_size_user64.h the information from
The purpose of this serie is to activate CONFIG_THREAD_INFO_IN_TASK which
moves the thread_info into task_struct.
Moving thread_info into task_struct has the following advantages:
- It protects thread_info from corruption in the case of stack
overflows.
- Its address is harder to determine if
Kernel Userspace Access Prevention utilises a feature of
the Radix MMU which disallows read and write access to userspace
addresses. By utilising this, the kernel is prevented from accessing
user data from outside of trusted paths that perform proper safety
checks, such as copy_{to/from}_user()
This series is based on Christophe's series:
http://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=78469
with some minor changes.
I wanted to move my patches to apply at the tail of his series to make it
easier for the two of us to work on independent parts, so I'm resending my
part of
Execution protection already exists on radix, this just refactors
the radix init to provide the KUEP setup function instead.
Thus, the only functional change is that it can now be disabled.
Signed-off-by: Russell Currey
---
arch/powerpc/mm/pgtable-radix.c| 11 ---
__patch_instruction() is called in early boot, and uses
__put_user_size(), which includes the locks and unlocks for KUAP,
which could either be called too early, or in the Radix case, forced to
use "early_" versions of functions just to safely handle this one case.
__put_user_asm() does not do
With the following piece of code, the following compilation warning
is encountered:
if (_IOC_DIR(ioc) != _IOC_NONE) {
int verify = _IOC_DIR(ioc) & _IOC_READ ? VERIFY_WRITE :
VERIFY_READ;
if (!access_ok(verify, ioarg, _IOC_SIZE(ioc))) {
Rob Herring writes:
> Remove directly accessing device_type property and use the
> of_node_is_type accessor instead. While not using it here, this is
> part of eventually removing the struct device_node.type pointer.
>
> Cc: Frederic Barrat
> Cc: Arnd Bergmann
> Cc: Greg Kroah-Hartman
> Cc:
On Mon, Dec 10, 2018 at 01:50:35PM +1100, Alexey Kardashevskiy wrote:
>
>
> On 06/12/2018 09:40, David Gibson wrote:
> > On Wed, Dec 05, 2018 at 05:17:57PM +1100, Alexey Kardashevskiy wrote:
> >>
> >>
> >> On 05/12/2018 16:47, Alexey Kardashevskiy wrote:
> >>>
> >>>
> >>> On 05/12/2018 16:14,
This argument is required to extend the generic ptrace API with
PTRACE_GET_SYSCALL_INFO request: syscall_get_arch() is going
to be called from ptrace_request() along with syscall_get_nr(),
syscall_get_arguments(), syscall_get_error(), and
syscall_get_return_value() functions with a tracee as their
PTRACE_GET_SYSCALL_INFO is a generic ptrace API that lets ptracer obtain
details of the syscall the tracee is blocked in.
There are two reasons for a special syscall-related ptrace request.
Firstly, with the current ptrace API there are cases when ptracer cannot
retrieve necessary information
From: Elvira Khabirova
Arch code should use tracehook_*() helpers, as documented
in include/linux/tracehook.h,
ptrace_report_syscall() is not expected to be used outside that file.
The patch does not look very nice, but at least it is correct
and opens the way for PTRACE_GET_SYSCALL_INFO API.
syscall_get_error() is required to be implemented on this
architecture in addition to already implemented syscall_get_nr(),
syscall_get_arguments(), syscall_get_return_value(), and
syscall_get_arch() functions in order to extend the generic
ptrace API with PTRACE_GET_SYSCALL_INFO request.
Cc:
Hi,
I found in powerpc code, it is doable to reserve memory region in
movable zone, such as crashkernel does. But in x86 code, it checks the
hotpluggable attribute of memory, hence if manually specifying a
region in hotpluggable region, it will fail.
The x86 code:
/* 0 means: find the address
On 06/12/18 10:17 PM, Andrew Murray wrote:
For PowerPC PMUs that do not support context exclusion let's
advertise the PERF_PMU_CAP_NO_EXCLUDE capability. This ensures that
perf will prevent us from handling events where any exclusion flags
are set. Let's also remove the now unnecessary check
Add mem-loads/mem-stores events to sysfs.
The event is formed based on raw event encoding.
Primary PMU event used here is PM_MRK_INST_CMPL
along with MMCRA[SM] modes and Thresholding bit
Signed-off-by: Madhavan Srinivasan
---
Changelog v1:
- Added comments on the MMCRA/Raw-event encoding bits
Previously when a device was being emulated by an L1 guest for an L2
guest, that device couldn't then be passed through to an L3 guest. This
was because the L1 guest had no method for accessing L3 memory.
The hcall H_COPY_TOFROM_GUEST provides this access. Thus this setup for
passthrough can now
A guest cannot access quadrants 1 or 2 as this would result in an
exception. Thus introduce the hcall H_COPY_TOFROM_GUEST to be used by a
guest when it wants to perform an access to quadrants 1 or 2, for
example when it wants to access memory for one of its nested guests.
Also provide an
Allow for a device which is being emulated at L0 (the host) for an L1
guest to be passed through to a nested (L2) guest.
The existing kvmppc_hv_emulate_mmio function can be used here. The main
challenge is that for a load the result must be stored into the L2 gpr,
not an L1 gpr as would normally
The functions kvmppc_st and kvmppc_ld are used to access guest memory
from the host using a guest effective address. They do so by translating
through the process table to obtain a guest real address and then using
kvm_read_guest or kvm_write_guest to make the access with the guest real
address.
The kvmppc_ops struct is used to store function pointers to kvm
implementation specific functions.
Introduce two new functions load_from_eaddr and store_to_eaddr to be
used to load from and store to a guest effective address respectively.
Also implement these for the kvm-hv module. If we are
The POWER9 radix mmu has the concept of quadrants. The quadrant number
is the two high bits of the effective address and determines the fully
qualified address to be used for the translation. The fully qualified
address consists of the effective lpid, the effective pid and the
effective address.
There exists a function kvm_is_radix() which is used to determine if a
kvm instance is using the radix mmu. However this only applies to the
first level (L1) guest. Add a function kvmhv_vcpu_is_radix() which can
be used to determine if the current execution context of the vcpu is
radix, accounting
The kvm capability KVM_CAP_SPAPR_TCE_VFIO is used to indicate the
availability of in kernel tce acceleration for vfio. However it is
currently the case that this is only available on a powernv machine,
not for a pseries machine.
Thus make this capability dependent on having the cpu feature
This patch series allows for emulated devices to be passed through to nested
guests, irrespective of at which level the device is being emulated.
Note that the emulated device must be using dma, not virtio.
For example, passing through an emulated e1000:
1. Emulate the device at L(n) for L(n+1)
Andrew Murray writes:
> For PowerPC PMUs that do not support context exclusion let's
> advertise the PERF_PMU_CAP_NO_EXCLUDE capability. This ensures that
> perf will prevent us from handling events where any exclusion flags
> are set. Let's also remove the now unnecessary check for exclusion
>
On 06/12/2018 09:40, David Gibson wrote:
> On Wed, Dec 05, 2018 at 05:17:57PM +1100, Alexey Kardashevskiy wrote:
>>
>>
>> On 05/12/2018 16:47, Alexey Kardashevskiy wrote:
>>>
>>>
>>> On 05/12/2018 16:14, David Gibson wrote:
On Fri, Nov 23, 2018 at 04:52:49PM +1100, Alexey Kardashevskiy
On Thu, 2018-12-06 at 05:10:28 UTC, Michael Ellerman wrote:
> In commit 5e9dcb6188a4 ("powerpc/boot: Expose Kconfig symbols to
> wrapper") we added a dependency to serial.c on autoconf.h:
>
> $(obj)/serial.c: $(obj)/autoconf.h
>
> This works when building in-tree (ie. with KBUILD_OUTPUT unset)
On Thu, 2018-12-06 at 15:17:08 UTC, Oliver O'Halloran wrote:
> Making PAPR_SCM select LIBNVDIMM results in circular dependencies in
> Kconfig when another symbol depends on it. Fix this by replacing the
> select with a depends.
>
> Fixes: b5beae5e224f ("powerpc/pseries: Add driver for PAPR SCM
On Thu, 2018-12-06 at 09:27:01 UTC, Sandipan Das wrote:
> Now that there are different variants of pt_regs for userspace and
> kernel, the uapi for the BPF_PROG_TYPE_PERF_EVENT program type must
> be changed by exporting the user_pt_regs structure instead of the
> pt_regs structure that is
Alexei Starovoitov writes:
> On Thu, Dec 06, 2018 at 02:57:01PM +0530, Sandipan Das wrote:
>> Now that there are different variants of pt_regs for userspace and
>> kernel, the uapi for the BPF_PROG_TYPE_PERF_EVENT program type must
>> be changed by exporting the user_pt_regs structure instead of
Michael,
Any comments on these?
On 19/08/2018, Darren Stevens wrote:
> The A-Eon Amigaone X1000's Nemo motherboard has an AMD SB600
> connected to one of the PCI-e root ports on its PaSemi
> Pwrficient 1628M SoC. Normally the SB600 southbridge would be
> connected to a hidden PCI-e port on the
On Thu, Dec 06, 2018 at 02:57:01PM +0530, Sandipan Das wrote:
> Now that there are different variants of pt_regs for userspace and
> kernel, the uapi for the BPF_PROG_TYPE_PERF_EVENT program type must
> be changed by exporting the user_pt_regs structure instead of the
> pt_regs structure that is
Convert Rockchip SoC bindings to DT schema format using json-schema.
Cc: Mark Rutland
Cc: Heiko Stuebner
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Signed-off-by: Rob Herring
[move to per-board entries and added recently added
Next step: c1bfcad4b0cf38ce5b00f7ad880d3a13484c123a (dma-mapping,
powerpc: simplify the arch dma_set_mask override)
Result: No problems with the PASEMI onboard ethernet and with booting
the X5000 (P5020 board).
-- Christian
On 09 December 2018 at 3:20PM, Christian Zigotzky wrote:
Next
On arm and unicore32i the early_alloc_aligned() and and early_alloc() are
oneliner wrappers for memblock_alloc.
Replace their usage with direct call to memblock_alloc.
Suggested-by: Christoph Hellwig
Signed-off-by: Mike Rapoport
---
arch/arm/mm/mmu.c | 11 +++
There are several early memory allocations in arch/ code that use
memblock_phys_alloc() to allocate memory, convert the returned physical
address to the virtual address and then set the allocated memory to zero.
Exactly the same behaviour can be achieved simply by calling
memblock_alloc(): it
The pte_alloc_one_kernel() function allocates a page using
__get_free_page(GFP_KERNEL) when mm initialization is complete and
memblock_phys_alloc() on the earlier stages. The physical address of the
page allocated with memblock_phys_alloc() is converted to the virtual
address and in the both cases
Rather than use the memblock_alloc_base that returns a physical address and
then convert this address to the virtual one, use appropriate memblock
function that returns a virtual address.
There is a small functional change in the allocation of then NODE_DATA().
Instead of panicing if the local
Rather than use the memblock_alloc_base that returns a physical address and
then convert this address to the virtual one, use appropriate memblock
function that returns a virtual address.
Signed-off-by: Mike Rapoport
Tested-by: Michal Simek
---
arch/microblaze/mm/init.c | 5 +++--
1 file
There are a several places that allocate memory using memblock APIs that
return a physical address, convert the returned address to the virtual
address and frequently also memset(0) the allocated range.
Update these places to use memblock allocators already returning a virtual
address. Use
Hi,
These patches simplify some of the early memory allocations by replacing
usage of older memblock APIs with newer and shinier ones.
Quite a few places in the arch/ code allocated memory using a memblock API
that returns a physical address of the allocated area, then converted this
physical
Next step: 602307b034734ce77a05da4b99333a2eaf6b6482 (powerpc/fsl_pci:
simplify fsl_pci_dma_set_mask)
git checkout 602307b034734ce77a05da4b99333a2eaf6b6482
The PASEMI onboard ethernet works and the X5000 boots.
-- Christian
On 08 December 2018 at 2:47PM, Christian Zigotzky wrote:
Next step:
On Thu, Dec 06, 2018 at 04:47:23PM +, Andrew Murray wrote:
> For drivers that do not support context exclusion let's advertise the
> PERF_PMU_CAP_NO_EXCLUDE capability. This ensures that perf will
> prevent us from handling events where any exclusion flags are set.
> Let's also remove the now
Christoph Hellwig writes:
> Configure the dma settings at device setup time, and stop playing games
> with get_pci_dma_ops. This prepares for using the common dma_configure
> code later on.
>
> Signed-off-by: Christoph Hellwig
> ---
> arch/powerpc/platforms/cell/iommu.c | 20
On each sample, Monitor Mode Control Register A (MMCRA) content
is saved in pt_regs. MMCRA does not have a entry as-is in the pt_regs
but instead, MMCRA content is saved in the "dsisr" register of pt_regs.
Patch adds another entry to the perf_regs structure to include the "MMCRA"
printing which
On each sample, Sample Instruction Event Register (SIER) content
is saved in pt_regs. SIER does not have a entry as-is in the pt_regs
but instead, SIER content is saved in the "dar" register of pt_regs.
Patch adds another entry to the perf_regs structure to include the "SIER"
printing which
MMCRA[34:36] and MMCRA[38:44] expose the thresholding counter value.
Thresholding counter can be used to count latency cycles such as
load miss to reload. But threshold counter value is not relevant
when the sampled instruction type is unknown or reserved. Patch to
fix the thersholding counter
56 matches
Mail list logo
