On Tue, Nov 26, 2019 at 04:21:37PM +1100, Jordan Niethe wrote:
> A prefixed instruction is composed of a word prefix followed by a word
> suffix. It does not make sense to be able to have a kprobe on the suffix
> of a prefixed instruction, so make this impossible.
>
> Kprobes work by replacing an
Selecting CONFIG_PPC_DEBUG_WX only impacts ptdump and pgtable_32/64
init calls. Declaring related functions in asm/pgtable.h implies
rebuilding almost everything.
Move ptdump_check_wx() declaration in mm/mmu_decl.h
Signed-off-by: Christophe Leroy
---
v2: use mm/mmu_decl.h instead of a new
Christophe Leroy writes:
> YueHaibing a écrit :
>
>> There expect the 'static' keyword to come first in a declaration
>>
>> arch/powerpc/platforms/powermac/smp.c:664:1: warning: static is not
>> at beginning of declaration [-Wold-style-declaration]
>>
On 10/01/2020 18:02, Oliver O'Halloran wrote:
> This is only used in pci-ioda.c so move it there and rename it to match.
>
> Signed-off-by: Oliver O'Halloran
Reviewed-by: Alexey Kardashevskiy
> ---
> arch/powerpc/platforms/powernv/pci-ioda.c | 22 +-
>
On 10/01/2020 18:02, Oliver O'Halloran wrote:
> pnv_pci_dma_dev_setup() does nothing but call the phb->dma_dev_setup()
> callback, if one exists. That callback is only set for normal PCIe PHBs so
> we can remove the layer of indirection and use the ioda version in
> the pci_controller_ops.
>
>
On 10/01/2020 18:02, Oliver O'Halloran wrote:
> An ioda_pe for each VF is allocated in pnv_pci_sriov_enable() before the
> pci_dev for the VF is created. We need to set the pe->pdev pointer at
> some point after the pci_dev is created. Currently we do that in:
>
> pcibios_bus_add_device()
>
On 10/01/2020 18:02, Oliver O'Halloran wrote:
> pcibios_bus_add_device() is the only caller of pcibios_setup_device().
> Fold them together since there's no real reason to keep them separate.
>
> Signed-off-by: Oliver O'Halloran
Reviewed-by: Alexey Kardashevskiy
> ---
>
Hi Timur,
On Mon, 13 Jan 2020 19:10:11 -0600 Timur Tabi wrote:
>
> On 1/13/20 2:25 PM, Stephen Rothwell wrote:
> > The problem is not really the declaration, the problem is that
> > ev_byte_channel_send always accesses 16 bytes from the buffer and it is
> > not always passed a buffer that long
Christophe Leroy writes:
> Selecting CONFIG_PPC_DEBUG_WX only impacts ptdump and pgtable_32/64
> init calls. Declaring related functions in asm/pgtable.h implies
> rebuilding almost everything.
>
> Move ptdump_check_wx() declaration in a new dedicated header file.
Can you put it in
On Thu, 2020-01-09 at 06:22 -0800, Christoph Hellwig wrote:
> On Thu, Jan 09, 2020 at 02:27:25PM +0530, Abdul Haleem wrote:
> > + CC Christoph Hellwig
>
> The only thing this commit changed for the dma coherent case (which
> ppc64 uses) is that we now look up the page to free by the DMA address
>
On Sun, Jan 12, 2020 at 8:33 PM Zong Li wrote:
>
> I'm not quite familiar with btf, so I have no idea why there are two
> weak symbols be added in 8580ac9404f6 ("bpf: Process in-kernel BTF")
I can explain what these weak symbols are for, but that won't change
the fact that compiler or linker are
On Mon, 2020-01-13 at 19:13 -0600, Timur Tabi wrote:
> On 1/13/20 7:10 PM, Timur Tabi wrote:
> > I would prefer that ev_byte_channel_send() is updated to access only
> > 'count' bytes. If that means adding a memcpy to the
> > ev_byte_channel_send() itself, then so be it. Trying to figure out
Cédric Le Goater writes:
> On 1/13/20 2:01 PM, Cédric Le Goater wrote:
>> From: Frederic Barrat
>>
>> A load on an ESB page returning all 1's means that the underlying
>> device has invalidated the access to the PQ state of the interrupt
>> through mmio. It may happen, for example when querying
On 1/13/20 7:10 PM, Timur Tabi wrote:
I would prefer that ev_byte_channel_send() is updated to access only
'count' bytes. If that means adding a memcpy to the
ev_byte_channel_send() itself, then so be it. Trying to figure out how
to stuff n bytes into 4 32-bit registers is probably not
Laurentiu Tudor writes:
> Hello,
>
> On 13.01.2020 15:48, Timur Tabi wrote:
>> On 1/13/20 6:26 AM, Michael Ellerman wrote:
>>> I've never heard of it, and I have no idea how to test it.
>>>
>>> It's not used by qemu, I guess there is/was a Freescale hypervisor that
>>> used it.
>>
>> Yes, there
On 1/13/20 2:25 PM, Stephen Rothwell wrote:
The problem is not really the declaration, the problem is that
ev_byte_channel_send always accesses 16 bytes from the buffer and it is
not always passed a buffer that long (in one case it is passed a
pointer to a single byte). So the alternative to
If a process (qemu) with a lot of CPUs (128) try to munmap() a large
chunk of memory (496GB) mapped with THP, it takes an average of 275
seconds, which can cause a lot of problems to the load (in qemu case,
the guest will lock for this time).
Trying to find the source of this bug, I found out
> On Dec 18, 2019, at 1:28 AM, Alexey Budankov
> wrote:
>
>
> Open access to bpf_trace monitoring for CAP_SYS_PERFMON privileged
> processes. For backward compatibility reasons access to bpf_trace
> monitoring remains open for CAP_SYS_ADMIN privileged processes but
> CAP_SYS_ADMIN usage for
> On Dec 18, 2019, at 1:24 AM, Alexey Budankov
> wrote:
>
>
> Introduce CAP_SYS_PERFMON capability devoted to secure system performance
> monitoring and observability operations so that CAP_SYS_PERFMON would
> assist CAP_SYS_ADMIN capability in its governing role for perf_events,
>
Hi Timur,
On Mon, 13 Jan 2020 10:03:18 -0600 Timur Tabi wrote:
>
> Why not simply correct the parameters of ev_byte_channel_send?
>
> static inline unsigned int ev_byte_channel_send(unsigned int handle,
> -unsigned int *count, const char buffer[EV_BYTE_CHANNEL_MAX_BYTES])
> +unsigned int
Hello,
Yangtao Li wrote:
> Use devm_platform_ioremap_resource() to simplify code.
Applied to mips-next.
> commit 23c25c732530
> https://git.kernel.org/mips/c/23c25c732530
>
> Signed-off-by: Yangtao Li
> Signed-off-by: Paul Burton
Thanks,
Paul
[ This message was auto-generated; if you
To avoid a double verification of the hw_counter validity,
provide __arch_is_hw_counter_valid()
Before:
clock-gettime-realtime:vdso: 1078 nsec/call
After:
clock-gettime-realtime:vdso: 1064 nsec/call
The * shows the test of the clock type.
The > shows the additional test on the counter,
__arch_get_hw_counter() returns the current value of the counter if
the counter is valid or a negative number if the counter is not valid.
This is suboptimal because the validity is checked twice: once before
reading the counter and once after reading the counter.
Optionaly split the
__arch_get_vdso_data() clobbers the link register, requiring
the caller to save it.
As the ASM calling function already has to set a stack frame and
saves the link register before calling the C vdso function,
retriving the vdso data pointer there is lighter.
The improvement is significant:
On powerpc, __arch_get_vdso_data() clobbers the link register,
requiring the caller to save it.
As the parent function already has to set a stack frame and saves
the link register before calling the C vdso function, retriving the
vdso data pointer there is lighter.
Give arches the opportunity to
__get_datapage() is only a few instructions to retrieve the
address of the page where the kernel stores data to the VDSO.
By inlining this function into its users, a bl/blr pair and
a mflr/mtlr pair is avoided, plus a few reg moves.
The improvement is noticeable (about 55 nsec/call on an 8xx)
The VDSO datapage and the text pages are always located immediately
next to each other, so it can be hardcoded without an indirection
through __kernel_datapage_offset
In order to ease things, move the data page in front like other
arches, that way there is no need to know the size of the library
Using __iter_div_ulong_rem() is suboptimal on 32 bits.
Nanoseconds are only 32 bits, and VDSO data is updated every 10ms
so nsec will never overflow 32 bits.
Add an equivalent of __iter_div_u64_rem() but based
on unsigned long to better fit with 32 bits arches.
Before:
gettimeofday:vdso:
VDSO_HRES and VDSO_RAW clocks are handled the same way.
Don't duplicate code.
Before the patch:
clock-getres-monotonic-raw:vdso: 737 nsec/call
clock-getres-monotonic-coarse:vdso: 753 nsec/call
clock-getres-monotonic:vdso: 691 nsec/call
After the patch:
clock-getres-monotonic-raw:
do_hres() is called from several places, so GCC doesn't inline
it at first.
do_hres() takes a struct __kernel_timespec * parameter for
passing the result. In the 32 bits case, this parameter corresponds
to a local var in the caller. In order to provide a pointer
to this structure, the caller has
This is a minimalistic conversion to VDSO generic C implementation.
On powerpc 8xx, performance is degraded by 40-45% for gettime and
by 50% for getres.
Optimisations will follow in next patches, some in the core
VDSO functions, some in the powerpc arch.
powerpc is a bit special for VDSO as
In order to allow use of generic C VDSO, remove time functions
from the 32 bits VDSO on PPC64.
This (temporary) removal is needed because powerpc kernel C headers
are not prepared for building 32 bits code on PPC64.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/vdso32/Makefile |
This is a third tentative to switch powerpc VDSO to generic C implementation.
This version should work on PPC64 (untested). VDSO32 for PPC64 is
impossible to build and has been de-activated, because the powerpc
ASM header files for C are not prepared to build 32 bits code with CONFIG_PPC64.
When __cvdso_clock_getres() became __cvdso_clock_getres_common()
and a new __cvdso_clock_getres() was added, static qualifier was
forgotten.
This change allows the compiler to inline __cvdso_clock_getres_common(),
and the performance improvement is significant:
Before:
From: Frederic Barrat
A load on an ESB page returning all 1's means that the underlying
device has invalidated the access to the PQ state of the interrupt
through mmio. It may happen, for example when querying a PHB interrupt
while the PHB is in an error state.
In that case, we should consider
On Thu, Jan 9, 2020 at 1:41 AM Stephen Rothwell wrote:
>
> ev_byte_channel_send() assumes that its third argument is a 16 byte array.
> Some places where it is called it may not be (or we can't easily tell
> if it is). Newer compilers have started producing warnings about this,
> so make sure we
On 1/13/20 8:34 AM, Laurentiu Tudor wrote:
There are a few users that I know of, but I can't tell if that's enough
to justify keeping the driver.
[1]https://source.codeaurora.org/external/qoriq/qoriq-yocto-sdk/hypervisor/
IIRC, the driver is the only reasonable way to get a serial console
Christophe Leroy writes:
> Is there a git tree with the latest VDSO status ?
>
> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git?h=timers%2Fvdso
> is 6 monthes old.
Will push a new one later today. I'll let you know.
Thanks,
tglx
Hello,
On 13.01.2020 15:48, Timur Tabi wrote:
> On 1/13/20 6:26 AM, Michael Ellerman wrote:
>> I've never heard of it, and I have no idea how to test it.
>>
>> It's not used by qemu, I guess there is/was a Freescale hypervisor that
>> used it.
>
> Yes, there is/was a Freescale hypervisor that I
On 1/13/20 2:01 PM, Cédric Le Goater wrote:
> From: Frederic Barrat
>
> A load on an ESB page returning all 1's means that the underlying
> device has invalidated the access to the PQ state of the interrupt
> through mmio. It may happen, for example when querying a PHB interrupt
> while the PHB
On 1/13/20 6:26 AM, Michael Ellerman wrote:
I've never heard of it, and I have no idea how to test it.
It's not used by qemu, I guess there is/was a Freescale hypervisor that
used it.
Yes, there is/was a Freescale hypervisor that I and a few others worked
on. I've added a couple people on
Hi Srikar,
Still some comments sorry ...
Srikar Dronamraju writes:
> Package_id is to find out all cores that are part of the same chip. On
> PowerNV machines, package_id defaults to chip_id. However ibm,chip_id
> property is not present in device-tree of PowerVM Lpars. Hence lscpu
> output
https://bugzilla.kernel.org/show_bug.cgi?id=205201
Michael Ellerman (mich...@ellerman.id.au) changed:
What|Removed |Added
Status|RESOLVED|CLOSED
Stephen Rothwell writes:
> ev_byte_channel_send() assumes that its third argument is a 16 byte array.
> Some places where it is called it may not be (or we can't easily tell
> if it is). Newer compilers have started producing warnings about this,
> so make sure we actually pass a 16 byte array.
Hi James,
On 01/11/2020 12:30 AM, Dave Anderson wrote:
- Original Message -
Hi Bhupesh,
On 25/12/2019 19:01, Bhupesh Sharma wrote:
On 12/12/2019 04:02 PM, James Morse wrote:
On 29/11/2019 19:59, Bhupesh Sharma wrote:
vabits_actual variable on arm64 indicates the actual VA space
Le 11/01/2020 à 20:59, Thomas Gleixner a écrit :
Christophe Leroy writes:
When __cvdso_clock_getres() became __cvdso_clock_getres_common()
and a new __cvdso_clock_getres() was added, static qualifier was
forgotten.
Fixes: 502a590a170b ("lib/vdso: Move fallback invocation to the callers")
Parse the device tree for nodes self-save, self-restore and populate
support for the preferred SPRs based what was advertised by the device
tree.
Signed-off-by: Pratik Rajesh Sampat
Reviewed-by: Ram Pai
---
arch/powerpc/platforms/powernv/idle.c | 104 ++
1 file changed,
This commit introduces and leverages the Self save API which OPAL now
supports.
Add the new Self Save OPAL API call in the list of OPAL calls.
Implement the self saving of the SPRs based on the support populated
while respecting it's preferences.
This implementation allows mixing of support for
Define a bitmask interface to determine support for the Self Restore,
Self Save or both.
Also define an interface to determine the preference of that SPR to
be strictly saved or restored or encapsulated with an order of preference.
The preference bitmask is shown as below:
Skiboot patches: https://patchwork.ozlabs.org/patch/1221011/
v2 patches: https://lkml.org/lkml/2020/1/12/253
Changelog
Patch v2 --> v3
1. Addressed minor comments from Ram Pai
Currently the stop-API supports a mechanism called as self-restore
which allows us to restore the values of certain SPRs
On Tue, Nov 26, 2019 at 04:21:38PM +1100, Jordan Niethe wrote:
> Uprobes can execute instructions out of line. Increase the size of the
> buffer used for this so that this works for prefixed instructions. Take
> into account the length of prefixed instructions when fixing up the nip.
>
>
I made a mistake while arranging the patches in the series. I'll re-arrange it
correctly now. Sorry about that.
On 13/01/20 1:21 pm, Ram Pai wrote:
On Mon, Jan 13, 2020 at 09:15:08AM +0530, Pratik Rajesh Sampat wrote:
This commit introduces and leverages the Self save API which OPAL now
Thanks for the review.
The support just signifies what is default. Self restore is known to be
supported by legacy systems.
I'll mention a comment saying that this can change when the system is
initialized.
On 13/01/20 1:14 pm, Ram Pai wrote:
On Mon, Jan 13, 2020 at 09:15:07AM +0530, Pratik
53 matches
Mail list logo
