Hi Ritesh,
thanks for looking into this patch,
Ritesh Harjani writes:
> Just a minor nit which I noticed.
>
> On 22/05/24 11:20AM, Vaibhav Jain wrote:
>> Presently ima_get_kexec_buffer() doesn't check if the previous kernel's
>> ima-kexec-buffer lies outside the addressable memory range. This ca
On 5/24/22 23:35, Alexey Kardashevskiy wrote:
On 5/21/22 04:35, Scott Cheloha wrote:
PAPR v2.12 defines a new hypercall, H_WATCHDOG. The hypercall permits
guest control of one or more virtual watchdog timers. The timers have
millisecond granularity. The guest is terminated when a timer
expi
Distro kernels tend to be moving to VIRT_CPU_ACCOUNTING_GEN, and there
is not much reason why PPC64 should be special here.
VIRT_CPU_ACCOUNTING_NATIVE does provide scaled vtime and stolen time
apportioned between system and user time, and vtime accounting is not
unconditionally enabled, and possib
On Thu, May 19, 2022 at 02:29:54PM +0800, Tong Tiangen wrote:
>
>
> 在 2022/5/13 23:26, Mark Rutland 写道:
> > On Wed, Apr 20, 2022 at 03:04:14AM +, Tong Tiangen wrote:
> > > During the processing of arm64 kernel hardware memory errors(do_sea()), if
> > > the errors is consumed in the kernel, th
Le 22/05/2017 à 07:13, Anton Blanchard a écrit :
Hi Michael,
ppc64 is the only architecture that turns on
VIRT_CPU_ACCOUNTING_NATIVE by default. The overhead of this option
is extremely high - a context switch microbenchmark using
sched_yield() is almost 20% slower.
Running on what? It sho
Hi Christophe,
On 24/05/22 18:47, Christophe Leroy wrote:
This draft series adds PPC32 support to Sathvika's series.
Verified on pmac32 on QEMU.
It should in principle also work for PPC64 BE but for the time being
something goes wrong. In the beginning I had a segfaut hence the first
patch. But
Am Mittwoch, 25. Mai 2022, 00:06:46 CEST schrieb Guenter Roeck:
> On Wed, May 25, 2022 at 01:46:38AM +0800, Guo Ren wrote:
> [ ... ]
>
> > > The problem is come from "__dls3's vdso decode part in musl's
> > > ldso/dynlink.c". The ehdr->e_phnum & ehdr->e_phentsize are wrong.
> > >
> > > I think the
On Wed, May 25, 2022 at 1:45 AM Peter Xu wrote:
> I observed that for each of the shared file-backed page faults, we're very
> likely to retry one more time for the 1st write fault upon no page. It's
> because we'll need to release the mmap lock for dirty rate limit purpose
> with balance_dirty_p
Hi Peter,
On 25/05/22 01:20, Peter Zijlstra wrote:
On Tue, May 24, 2022 at 06:59:50PM +, Christophe Leroy wrote:
Le 24/05/2022 à 20:02, Peter Zijlstra a écrit :
On Tue, May 24, 2022 at 08:01:39PM +0200, Peter Zijlstra wrote:
On Tue, May 24, 2022 at 03:17:45PM +0200, Christophe Leroy wrot
Am Mittwoch, 25. Mai 2022, 12:57:30 CEST schrieb Heiko Stübner:
> Am Mittwoch, 25. Mai 2022, 00:06:46 CEST schrieb Guenter Roeck:
> > On Wed, May 25, 2022 at 01:46:38AM +0800, Guo Ren wrote:
> > [ ... ]
> >
> > > > The problem is come from "__dls3's vdso decode part in musl's
> > > > ldso/dynlink.
On Tue, May 24, 2022 at 04:01:48PM +0530, Naveen N. Rao wrote:
> We need to know for sure either way. Nop'ing out the _mcount locations at
> boot allows us to discover existing long branch trampolines. If we want to
> avoid it, we need to note down those locations during build time.
>
> Do you ha
On Tue, May 24, 2022 at 07:45:31PM -0400, Peter Xu wrote:
> I observed that for each of the shared file-backed page faults, we're very
> likely to retry one more time for the 1st write fault upon no page. It's
> because we'll need to release the mmap lock for dirty rate limit purpose
> with balanc
The H_ENTER_NESTED hypercall receives as second parameter the address
of a region of memory containing the values for the nested guest
privileged registers. We currently use the pt_regs structure contained
within kvm_vcpu_arch for that end.
Most hypercalls that receive a memory address expect that
We have some debug information at /sys/kernel/debug/kvm//vcpu#/timings
which shows the time it takes to run various parts of the code.
That infrastructure was written in the P8 timeframe and wasn't updated
along with the guest entry point changes for P9.
Ideally we would be able to just add new/d
At debugfs/kvm//vcpu0/timings we show how long each part of the
code takes to run:
$ cat /sys/kernel/debug/kvm/*-*/vcpu0/timings
rm_entry: 123785 49398892 118 4898
rm_intr: 123780 6075890 22 390
rm_exit: 0 0 0 0 <-- NOK
guest: 123780 46732919988 402 9997638
cede: 0 0 0 0
Turn the existing Kconfig KVM_BOOK3S_HV_EXIT_TIMING into
KVM_BOOK3S_HV_P8_TIMING in preparation for the addition of a new
config for P9 timings.
This applies only to P8 code, the generic timing code is still kept
under KVM_BOOK3S_HV_EXIT_TIMING.
Signed-off-by: Fabiano Rosas
---
arch/powerpc/ker
We are currently doing the timing for debug purposes of the P9 entry
path using the accumulators and terminology defined by the old entry
path for P8 machines.
Not only the "real-mode" and "napping" mentions are out of place for
the P9 Radix entry path but also we cannot change them because the
ti
The next patch adds new timing points to the P9 entry path, some of
which are in the module code, so we need to export the timing
functions.
Signed-off-by: Fabiano Rosas
---
arch/powerpc/kvm/book3s_hv.h | 10 ++
arch/powerpc/kvm/book3s_hv_p9_entry.c | 11 ++-
2 files cha
Alter the data collection points for the debug timing code in the P9
path to be more in line with what the code does. The points where we
accumulate time are now the following:
vcpu_entry: From vcpu_run_hv entry until the start of the inner loop;
guest_entry: From the start of the inner loop unti
Call static_call_init() just after jump_label_init().
x86 already called it from setup_arch(). This is not a
problem as static_call_init() is guarded from double call.
Signed-off-by: Christophe Leroy
---
init/main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/init/main.c b/init/main.c
i
This reverts commit cf3013dfad89ad5ac7d16d56dced72d7c138a20e.
That commit is problematic as we miss some static calls.
Signed-off-by: Christophe Leroy
---
scripts/Makefile.build | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/Makefile.build b/scripts/Makefile.bui
This is first draft for implementing inline static calls on PPC32.
This series applies on top of the series v2 "objtool: Enable and implement
--mcount option on powerpc"
For the time being only the case where functions are within 'bl' reach
is supported. Otherwise panic() is invoked.
For the ot
Implement inline static calls:
- Put a 'bl' to the destination function
- Put a 'nop' when the destination function is NULL
- Put a 'li r3,0' when the destination is the RET0 function
For the time being it only works if the destination is
within 32Mb from the caller.
Signed-off-by: Christophe Ler
In order to allow other architectures than x86 to use 32 bits
relative relocations, define a R_REL32 macro that each architecture
will define, in the same way as already done for R_NONE.
Signed-off-by: Christophe Leroy
---
tools/objtool/arch/x86/include/arch/elf.h | 1 +
tools/objtool/check.c
Thx Heiko & Guenter,
On Wed, May 25, 2022 at 7:10 PM Heiko Stübner wrote:
>
> Am Mittwoch, 25. Mai 2022, 12:57:30 CEST schrieb Heiko Stübner:
> > Am Mittwoch, 25. Mai 2022, 00:06:46 CEST schrieb Guenter Roeck:
> > > On Wed, May 25, 2022 at 01:46:38AM +0800, Guo Ren wrote:
> > > [ ... ]
> > >
> >
On Wed, May 25, 2022 at 05:58:14PM +0200, Christophe Leroy wrote:
> This reverts commit cf3013dfad89ad5ac7d16d56dced72d7c138a20e.
>
> That commit is problematic as we miss some static calls.
Revert ?!?! who comitted this. And there's a ton more broken than just
static calls. This must absolutely
Hi!
On Wed, May 25, 2022 at 05:58:15PM +0200, Christophe Leroy wrote:
> In order to allow other architectures than x86 to use 32 bits
> relative relocations, define a R_REL32 macro that each architecture
> will define, in the same way as already done for R_NONE.
What are the expected semantics of
Hi
Am 21.05.22 um 04:49 schrieb Benjamin Herrenschmidt:
On Thu, 2022-05-19 at 09:27 +0200, Thomas Zimmermann wrote:
to build without PCI to see what happens.
If you bring any of the "heuristic" and palette support code in, you
need PCI. I don't see any reason to take it out.
Those old Macs
On Wed, May 25, 2022 at 03:44:04PM +0530, Sathvika Vasireddy wrote:
> On 24/05/22 18:47, Christophe Leroy wrote:
> >This draft series adds PPC32 support to Sathvika's series.
> >Verified on pmac32 on QEMU.
> >
> >It should in principle also work for PPC64 BE but for the time being
> >something goes
Le 25/05/2022 à 18:34, Peter Zijlstra a écrit :
> On Wed, May 25, 2022 at 05:58:14PM +0200, Christophe Leroy wrote:
>> This reverts commit cf3013dfad89ad5ac7d16d56dced72d7c138a20e.
>>
>> That commit is problematic as we miss some static calls.
>
> Revert ?!?! who comitted this. And there's a ton
Le 24/05/2022 à 15:33, Christophe Leroy a écrit :
Le 24/05/2022 à 13:00, Sathvika Vasireddy a écrit :
+{
+ switch (elf->ehdr.e_machine) {
+ case EM_X86_64:
+ return R_X86_64_64;
+ case EM_PPC64:
+ return R_PPC64_ADDR64;
+ default:
+ WARN("unkno
Hi Sathvika,
Le 25/05/2022 à 12:14, Sathvika Vasireddy a écrit :
> Hi Christophe,
>
> On 24/05/22 18:47, Christophe Leroy wrote:
>> This draft series adds PPC32 support to Sathvika's series.
>> Verified on pmac32 on QEMU.
>>
>> It should in principle also work for PPC64 BE but for the time being
On 25/05/22 23:09, Christophe Leroy wrote:
Hi Sathvika,
Le 25/05/2022 à 12:14, Sathvika Vasireddy a écrit :
Hi Christophe,
On 24/05/22 18:47, Christophe Leroy wrote:
This draft series adds PPC32 support to Sathvika's series.
Verified on pmac32 on QEMU.
It should in principle also work for
Am Mittwoch, 25. Mai 2022, 18:08:22 CEST schrieb Guo Ren:
> Thx Heiko & Guenter,
>
> On Wed, May 25, 2022 at 7:10 PM Heiko Stübner wrote:
> >
> > Am Mittwoch, 25. Mai 2022, 12:57:30 CEST schrieb Heiko Stübner:
> > > Am Mittwoch, 25. Mai 2022, 00:06:46 CEST schrieb Guenter Roeck:
> > > > On Wed, M
On Fri, 20 May 2022 14:25:05 -0500 "Eric W. Biederman"
wrote:
> > I am not strongly against taking off __weak, just wondering if there's
> > chance to fix it in recordmcount, and the cost comparing with kernel fix;
> > except of this issue, any other weakness of __weak. Noticed Andrew has
> > pi
OK, finally some changes for modules. It is still pretty boring,
but I am hopefull that the cleanup will yield nice results in the
future as further cleanups will make the code much easier to
read, maintain and test. Perhaps the most exciting thing is
Christophe Leroy's CONFIG_ARCH_WANTS_MODULES_DA
Sorry the subject should say "Modules changes".
I also forgot to itemize possible merge conflicts and resolutions
which linux-next reported:
powerpc:
https://lkml.kernel.org/r/20220520154055.7f964...@canb.auug.org.au
kbuild:
https://lkml.kernel.org/r/20220523120859.570f7...@canb.auug.org.au
L
On Thu, May 26, 2022 at 3:37 AM Heiko Stübner wrote:
>
> Am Mittwoch, 25. Mai 2022, 18:08:22 CEST schrieb Guo Ren:
> > Thx Heiko & Guenter,
> >
> > On Wed, May 25, 2022 at 7:10 PM Heiko Stübner wrote:
> > >
> > > Am Mittwoch, 25. Mai 2022, 12:57:30 CEST schrieb Heiko Stübner:
> > > > Am Mittwoch,
On Tue, May 24, 2022 at 11:20:42AM +0530, Vaibhav Jain wrote:
> Presently ima_get_kexec_buffer() doesn't check if the previous kernel's
> ima-kexec-buffer lies outside the addressable memory range. This can result
> in a kernel panic if the new kernel is booted with 'mem=X' arg and the
> ima-kexec-
Michal Simek , Thomas Bogendoerfer
, linux-par...@vger.kernel.org, Max Filippov
, linux-ker...@vger.kernel.org, Dinh Nguyen
, Palmer Dabbelt , Sven Schnelle
, Guo Ren , Borislav Petkov
, Johannes Berg ,
linuxppc-dev@lists.ozlabs.org, "David S . Miller"
Errors-To: linuxppc-dev-bounces+archive
nkel , Michal Simek , Thomas Bogendoerfer ,
linux-par...@vger.kernel.org, linux-m...@vger.kernel.org, Dinh Nguyen , Palmer Dabbelt , Sven
Schnelle , Guo Ren , Borislav Petkov , Johannes Berg
, linuxppc-dev@lists.ozlabs.org, "David S . Miller"
Errors-To: linuxppc-dev-bounces+archive=mail-archiv
Excerpts from Sachin Sant's message of March 9, 2022 6:37 pm:
>
>
>> On 07-Mar-2022, at 8:21 PM, Nicholas Piggin wrote:
>>
>> When a synchronous interrupt[1] is taken in a local_irq_disable() region
>> which has MSR[EE]=1, the interrupt handler will enable MSR[EE] as part
>> of enabling MSR[RI]
> On 26-May-2022, at 10:20 AM, Nicholas Piggin wrote:
>
> Excerpts from Sachin Sant's message of March 9, 2022 6:37 pm:
>>
>>
>>> On 07-Mar-2022, at 8:21 PM, Nicholas Piggin wrote:
>>>
>>> When a synchronous interrupt[1] is taken in a local_irq_disable() region
>>> which has MSR[EE]=1, the
When booting on a machine that uses the compat pmu driver we see this:
[0.071192] GENERIC_COMPAT performance monitor hardware support registered
Which is a bit shouty. Give it a nicer name.
Signed-off-by: Joel Stanley
---
Other options:
- ISAv3 (because it is relevant for PowerISA 3.0B
Arnout Vandecappelle writes:
> On 16/05/2022 15:17, Michael Ellerman wrote:
>> Arnout Vandecappelle writes:
>>> On 10/05/2022 04:20, Joel Stanley wrote:
The default defconfig target for the 64 bit powerpc kernel is
ppc64_defconfig, the big endian configuration.
When building f
Replace some stray tabs with whitespaces and remove an extra empty
line.
Juerg Haefliger (2):
powerpc: Kconfig: Replace tabs with whitespaces
powerpc: Kconfig.debug: Remove extra empty line
arch/powerpc/Kconfig | 6 +++---
arch/powerpc/Kconfig.debug | 1 -
2 files changed, 3 insertions
Remove a stray extra empty line.
Signed-off-by: Juerg Haefliger
---
arch/powerpc/Kconfig.debug | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
index 192f0ed0097f..2c019e4ac432 100644
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kc
Replace tabs after keywords with whitespaces to be consistent.
Signed-off-by: Juerg Haefliger
---
arch/powerpc/Kconfig | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 174edabb74fa..b4acaa77837a 100644
--- a/arch/powerpc/
48 matches
Mail list logo
