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
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
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
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
> >
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
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
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,
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:
+
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
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
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
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
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
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
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:
> 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,
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
>
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:
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
expires.
This patch adds a watchdog driver for
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,
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 can result
> in a kernel panic if the new kernel is booted with 'mem=X' arg and
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
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
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
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
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
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.
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
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
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
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
> > > >
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
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
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
---
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
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
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
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
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
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
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
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
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
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
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:
> > > [ ... ]
> > >
> >
45 matches
Mail list logo
