Hi,
I'd also like to see this patch in the mainstream as it fixes a bug
appearing when we switch from vCPU context to hypervisor context (guest
crash).
Laurent
On 06/08/2015 03:25, Sam Bobroff wrote:
Ping?
I think I've addressed all the comments in this version. Is there anything
else
I
)
PPC_STL r6, SVCPU_FAULT_DAR(r13)
stw r7, SVCPU_FAULT_DSISR(r13)
PPC_STL r8, SVCPU_CTR(r13)
Reviewed-by: Laurent Vivier lviv...@redhat.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo
Le 10/11/2015 01:29, Michael Ellerman a écrit :
> On Sat, 2015-11-07 at 12:35 +0100, Laurent Vivier wrote:
>> Le 07/11/2015 00:24, Scott Wood a écrit :
>>> On Fri, 2015-11-06 at 23:22 +0100, Laurent Vivier wrote:
>>>> Le 06/11/2015 22:09, Scott Wood a écrit :
>
if the language is not english objdump output is not parsed correctly
and format is "". Later, "ld -m $format" fails.
This patch adds "LANG=C" to force english output for objdump.
Signed-off-by: Laurent Vivier <laur...@vivier.eu>
---
arch/powerpc/boot/wrapper
at" ld works well because it use the format of the
first object as output format.
As this case is correctly managed to build the other kernel
objects, this patch replaces $(GCC) by $(LD) to generate the
VDSO objects.
Signed-off-by: Laurent Vivier <laur...@vivier.eu>
---
arch/powerpc/k
Le 07/11/2015 00:12, Benjamin Herrenschmidt a écrit :
> On Fri, 2015-11-06 at 15:09 -0600, Scott Wood wrote:
>> On Thu, 2015-11-05 at 12:47 +0100, Laurent Vivier wrote:
>>> When I try to cross compile a ppc64 kernel, it generally
>>> fails on the VDSO stage. This
Le 07/11/2015 00:32, Segher Boessenkool a écrit :
> On Fri, Nov 06, 2015 at 04:55:49PM -0600, Segher Boessenkool wrote:
>> On Fri, Nov 06, 2015 at 03:09:40PM -0600, Scott Wood wrote:
>>> Why is GCC building ppc64 object files but telling the linker --oformat
>>> elf32-
>>> powerpcle? Are
On 04/11/2015 13:34, Hari Bathini wrote:
> On 10/16/2015 12:30 AM, Laurent Vivier wrote:
>> On kexec, all secondary offline CPUs are onlined before
>> starting the new kernel, this is not done in the case of kdump.
>>
>> If kdump is configured and a kernel c
Le 06/11/2015 22:09, Scott Wood a écrit :
> On Thu, 2015-11-05 at 12:47 +0100, Laurent Vivier wrote:
>> When I try to cross compile a ppc64 kernel, it generally
>> fails on the VDSO stage. This is true for powerpc64 cross-
>> compiler, but also when I try to build a ppc64le
On 16/10/2015 04:14, Michael Ellerman wrote:
> On Thu, 2015-10-15 at 21:00 +0200, Laurent Vivier wrote:
>> On kexec, all secondary offline CPUs are onlined before
>> starting the new kernel, this is not done in the case of kdump.
>>
>> If kdump is configured and a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 16/10/2015 04:29, David Gibson wrote:
> On Thu, 15 Oct 2015 21:00:58 +0200 Laurent Vivier
> <lviv...@redhat.com> wrote:
>
>> On kexec, all secondary offline CPUs are onlined before starting
>> the new kernel, t
, and thus OPAL cannot restart
it: this CPU has been lost...
Signed-off-by: Laurent Vivier <lviv...@redhat.com>
---
arch/powerpc/kernel/crash.c | 20
1 file changed, 20 insertions(+)
diff --git a/arch/powerpc/kernel/crash.c b/arch/powerpc/kernel/crash.c
index 51dbace
regression tested on a G3
> PowerMac. The nvram module was also tested on a PowerBook 520, Quadra 650
> and Atari Falcon. AFAIK, no testing has been done on PPC64 as yet.
For PPC64, tested on a PowerMac G5 (PowerMac11,2), kernel 4.3.0-rc4
with nvram tools 1.2.24 (Fedora 22 ppc64).
Couldn't emulate instruction 0x (op 0 xop 0)
kvmppc_handle_exit_pr: emulation at 700 failed ()
While the exception handler receives an interrupt for each instruction
executed after the illegal instruction.
Signed-off-by: Laurent Vivier <lviv...@redhat.com>
---
Ping?
On 15/03/2016 21:18, Laurent Vivier wrote:
> While writing some instruction tests for kvm-unit-tests for powerpc,
> I've found that illegal instructions are not managed correctly with kvm-pr,
> while it is fine with kvm-hv.
>
> When an illegal instruction (like ".l
Ping?
On 22/03/2016 15:53, Laurent Vivier wrote:
> Until now, when we connect gdb to the QEMU gdb-server, the
> single-step mode is not managed.
>
> This patch adds this, only for kvm-pr:
>
> If KVM_GUESTDBG_SINGLESTEP is set, we enable single-step trace bit in the
> MSR
On 08/04/2016 09:44, Thomas Huth wrote:
> On 08.04.2016 08:58, Laurent Vivier wrote:
>>
>>
>> On 08/04/2016 08:23, Thomas Huth wrote:
>>> On 22.03.2016 15:53, Laurent Vivier wrote:
>>>> Until now, when we connect gdb to the QEMU gdb-server
.
In kvmppc_handle_exit_pr, instead of routing the interrupt to
the guest, we return to host, with KVM_EXIT_DEBUG reason.
Signed-off-by: Laurent Vivier <lviv...@redhat.com>
---
v2: split BOOK3S_INTERRUPT_MACHINE_CHECK and BOOK3S_INTERRUPT_TRACE
arch/powerpc/kvm/book3s_pr.
On 08/04/2016 08:23, Thomas Huth wrote:
> On 22.03.2016 15:53, Laurent Vivier wrote:
>> Until now, when we connect gdb to the QEMU gdb-server, the
>> single-step mode is not managed.
>>
>> This patch adds this, only for kvm-pr:
>>
>> If KVM_GUESTDBG_SINGLES
:
qemu-system-ppc64 -machine pseries,accel=kvm \
-bios powerpc/boot_rom.bin \
-display none -serial stdio \
-kernel powerpc/emulator.elf -smp 1
Laurent
On 15/03/2016 21:18, Laurent Vivier wrote:
> While writing some instruction tests for kvm-u
.
In kvmppc_handle_exit_pr, instead of routing the interrupt to
the guest, we return to host, with KVM_EXIT_DEBUG reason.
Signed-off-by: Laurent Vivier <lviv...@redhat.com>
---
arch/powerpc/kvm/book3s_pr.c | 31 +--
1 file changed, 29 insertions(+), 2 deletions(-)
diff --git
On 12/05/2016 11:27, Alexander Graf wrote:
> On 05/12/2016 11:10 AM, Laurent Vivier wrote:
>>
>> On 11/05/2016 13:49, Alexander Graf wrote:
>>> On 05/11/2016 01:14 PM, Laurent Vivier wrote:
>>>> On 11/05/2016 12:35, Alexander Graf wrote:
>>>&g
On 11/05/2016 13:49, Alexander Graf wrote:
> On 05/11/2016 01:14 PM, Laurent Vivier wrote:
>>
>> On 11/05/2016 12:35, Alexander Graf wrote:
>>> On 03/15/2016 09:18 PM, Laurent Vivier wrote:
>>>> While writing some instruction tests for kvm-unit-tests for p
On 12/05/2016 16:23, Laurent Vivier wrote:
>
>
> On 12/05/2016 11:27, Alexander Graf wrote:
>> On 05/12/2016 11:10 AM, Laurent Vivier wrote:
>>>
>>> On 11/05/2016 13:49, Alexander Graf wrote:
>>>> On 05/11/2016 01:14 PM, Laurent Vivier wrote:
&g
On 17/05/2016 10:37, Alexander Graf wrote:
> On 05/17/2016 10:35 AM, Laurent Vivier wrote:
>>
>> On 12/05/2016 16:23, Laurent Vivier wrote:
>>>
>>> On 12/05/2016 11:27, Alexander Graf wrote:
>>>> On 05/12/2016 11:10 AM, Laurent Vivier wrote:
&g
On 11/05/2016 12:35, Alexander Graf wrote:
> On 03/15/2016 09:18 PM, Laurent Vivier wrote:
>> While writing some instruction tests for kvm-unit-tests for powerpc,
>> I've found that illegal instructions are not managed correctly with
>> kvm-pr,
>> while it is f
d3c9 38210090 e8010010 eba1ffe8
> ebc1fff0 ebe1fff8 7c0803a6 4bfdc2ac <0fe0> 7c0802a6 fb01ffc0
>
> Fixes: 943db62c316c ("powerpc/pseries: Revert 'Auto-online hotplugged
> memory'")
> Signed-off-by: Nathan Fontenot <nf...@linux.vnet.ibm.com>
tested the first scenario with 4.13.0-rc4 and qemu 2.10.0-rc2.
Tested-by: Laurent Vivier <lviv...@redhat.com>
Reviewed-by: Laurent Vivier <lviv...@redhat.com>
e released
in this case too.
Signed-off-by: Laurent Vivier <lviv...@redhat.com>
---
arch/powerpc/platforms/pseries/reconfig.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/platforms/pseries/reconfig.c
b/arch/powerpc/platforms/pseries/reconfig.c
index e5bf1e8..011ef21 1
e_raw(pte) & cpu_to_be64(_PAGE_DEVMAP));
> + uint64_t mask = cpu_to_be64(_PAGE_DEVMAP | _PAGE_PTE);
> +
> + return (pte_raw(pte) & mask) == mask;
> }
>
> static inline pte_t pte_modify(pte_t pte, pgprot_t newprot)
>
Tested-by: Laurent Vivier <lviv...@redhat.com>
On 23/08/2017 13:00, Michael Ellerman wrote:
> Hi Tejun,
>
> Tejun Heo writes:
>> Hello, Michael.
>>
>> On Tue, Aug 22, 2017 at 11:41:41AM +1000, Michael Ellerman wrote:
This is something powerpc needs to fix.
>>>
>>> There is no way for us to fix it.
>>
>> I don't think
On 23/08/2017 15:26, Tejun Heo wrote:
> Hello, Michael.
>
> On Wed, Aug 23, 2017 at 09:00:39PM +1000, Michael Ellerman wrote:
>>> I don't think that's true. The CPU id used in kernel doesn't have to
>>> match the physical one and arch code should be able to pre-map CPU IDs
>>> to nodes and use
(that is not present in cpumask) and raises the following warning:
WARN_ON(!cpumask_test_cpu(raw_smp_processor_id(), hctx->cpumask) &&
cpu_online(hctx->next_cpu));
To fix this problem, this patch modifies blk_mq_hctx_next_cpu()
to only return a CPU id present in cpumask.
Signed-o
.
Signed-off-by: Laurent Vivier <lviv...@redhat.com>
---
arch/powerpc/kernel/smp.c | 1 +
include/linux/workqueue.h | 1 +
kernel/workqueue.c| 21 +
3 files changed, 23 insertions(+)
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 8d3320
This is needed to map kvmppc_xive_set_xive() behavior
to kvmppc_xics_set_xive().
As we store the server, kvmppc_xive_get_xive() can return
the good value and we can also allow kvmppc_xive_int_on().
Signed-off-by: Laurent Vivier <lviv...@redhat.com>
---
arch/powerpc/kvm/book3s_xive.
On 05/12/2017 04:05, Paul Mackerras wrote:
> On Fri, Nov 24, 2017 at 07:38:13AM +1100, Benjamin Herrenschmidt wrote:
>> On Thu, 2017-11-23 at 10:06 +0100, Laurent Vivier wrote:
>>> This is needed to map kvmppc_xive_set_xive() behavior
>>> to kvmppc_xics_set_xive().
>
() ignores the pending_pri value)
As xisr is 0, pending_pri must be set to 0xff.
Signed-off-by: Laurent Vivier <lviv...@redhat.com>
---
arch/powerpc/kvm/book3s_xive.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kvm/book3s_xive.c b/arch/powerpc/kvm/book3s_
On 12/12/2017 13:02, Cédric Le Goater wrote:
> When restoring a pending interrupt, we are setting the Q bit to force
> a retrigger in xive_finish_unmask(). But we also need to force an EOI
> in this case to reach the same initial state : P=1, Q=0.
>
> This can be done by not setting 'old_p' for
state->old_p = true;
> if (val & KVM_XICS_QUEUED || val & KVM_XICS_PENDING)
> state->old_q = true;
>
Reviewed-by: Laurent Vivier <lviv...@redhat.com>
Tested-by: Laurent Vivier <lviv...@redhat.com>
On 12/06/2018 01:47, Finn Thain wrote:
> On Sun, 10 Jun 2018, Benjamin Herrenschmidt wrote:
...
> I don't know what the bootloader situation is, but it looks messy...
> http://nubus-pmac.sourceforge.net/#booters
>
> Laurent, does Emile work on these machines?
>
No, Emile doesn't work on
On 22/12/2017 08:54, Paul Mackerras wrote:
> On Fri, Dec 22, 2017 at 03:34:20PM +1100, Michael Ellerman wrote:
>> Laurent Vivier <lviv...@redhat.com> writes:
>>
>>> On 12/12/2017 13:02, Cédric Le Goater wrote:
>>>> When restoring a pending in
On 07/02/2018 18:49, Daniel Henrique Barboza wrote:
>
>
> On 02/07/2018 12:33 PM, Laurent Vivier wrote:
>> On 01/02/2018 06:09, Alexey Kardashevskiy wrote:
>>> Radix guests do normally invalidate process-scoped translations when
>>> a new pid is allocated but
On 07/02/2018 20:44, Mathieu Malaterre wrote:
> Remove the __init annotation from pmu_init() to avoid the
> following warning.
>
> WARNING: vmlinux.o(.data+0x4739c): Section mismatch in reference from the
> variable via_pmu_driver to the function .init.text:pmu_init()
> The variable
; + "r" (TLBIEL_INVAL_SET_LPID), "r" (lpid));
> trace_tlbie(lpid, 0, TLBIEL_INVAL_SET_LPID, lpid, 2, 0, 1);
> } else {
> asm volatile(PPC_TLBIE_5(%0,%1,2,0,0) : :
>
This patch fixes for me a VM migration crash on POWER9.
Tested-by: Laurent Vivier <lviv...@redhat.com>
Thanks,
Laurent
re <ma...@debian.org>
> Suggested-by: Laurent Vivier <lviv...@redhat.com>
> ---
> v2: pmu_init() is really an init function, leave __init marker
>
> drivers/macintosh/via-pmu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/m
ing for signals on guest entry")
Signed-off-by: Laurent Vivier <lviv...@redhat.com>
---
arch/powerpc/kvm/book3s_hv.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 89707354c2ef..8274c2807202 100
On 15/11/2018 10:19, Satheesh Rajendran wrote:
> On Wed, Nov 14, 2018 at 06:03:19PM +0100, Laurent Vivier wrote:
>> Trying to hotplug a CPU on an empty NUMA node (without
>> memory or CPU) crashes the kernel when the CPU is onlined.
>>
>> During the onlinin
rpc/numa: Ensure nodes initialized for hotplug)
Signed-off-by: Laurent Vivier
---
arch/powerpc/mm/numa.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 3a048e98a132..1b2d25a3c984 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powe
On 15/11/2018 10:19, Satheesh Rajendran wrote:
> On Wed, Nov 14, 2018 at 06:03:19PM +0100, Laurent Vivier wrote:
>> Trying to hotplug a CPU on an empty NUMA node (without
>> memory or CPU) crashes the kernel when the CPU is onlined.
>>
>> During the onlinin
On 20/03/2019 13:47, Michael Ellerman wrote:
> Laurent Vivier writes:
>> Hi Michael,
>>
>> as it seems good now, could you pick up this patch for merging?
>
> I'll start picking up patches for next starting after rc2, so next week.
>
> If you think it's a bu
3ca02e46 ("sched/topology: Introduce NUMA identity node sched
domain")
Cc: Suravee Suthikulpanit
Cc: Srikar Dronamraju
Cc: Borislav Petkov
Cc: David Gibson
Cc: Michael Ellerman
Cc: Nathan Fontenot
Cc: Michael Bringmann
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Ingo Molnar
Cc: Peter
3ca02e46 ("sched/topology: Introduce NUMA identity node sched
domain")
Cc: Suravee Suthikulpanit
Cc: Srikar Dronamraju
Cc: Borislav Petkov
CC: David Gibson
CC: Michael Ellerman
CC: Nathan Fontenot
CC: Michael Bringmann
CC: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Laurent
On 20/02/2019 18:08, Peter Zijlstra wrote:
> On Wed, Feb 20, 2019 at 05:55:20PM +0100, Laurent Vivier wrote:
>> index 3f35ba1d8fde..372278605f0d 100644
>> --- a/kernel/sched/topology.c
>> +++ b/kernel/sched/topology.c
>> @@ -1651,6 +1651,7 @@ void sched_init_numa(voi
xppc-dev@lists.ozlabs.org
Cc: Ingo Molnar
Cc: Peter Zijlstra
Signed-off-by: Laurent Vivier
---
Notes:
v3: fix the root cause of the problem (sched numa mask initialization)
v2: add scheduler maintainers in the CC: list
kernel/sched/topology.c | 4 +++-
1 file changed, 3 insertions(+),
On 13/03/2019 07:03, Christophe Leroy wrote:
>
>
> Le 08/03/2019 à 11:54, Laurent Vivier a écrit :
>> resize_hpt_for_hotplug() reports a warning when it cannot
>> resize the hash page table ("Unable to resize hash page
>> table to target order") but in som
() to
only report the problem when it is needed.
Reviewed-by: David Gibson
Signed-off-by: Laurent Vivier
---
Notes:
v3: move "||" to above line and remove parenthesis
v2: add warning messages for H_PARAMETER and H_RESOURCE
arch/powerpc/include/asm/sparsemem.h | 4 +
On 13/03/2019 09:28, Christophe Leroy wrote:
>
>
> Le 13/03/2019 à 09:01, Laurent Vivier a écrit :
>> On 13/03/2019 07:03, Christophe Leroy wrote:
>>>
>>>
>>> Le 08/03/2019 à 11:54, Laurent Vivier a écrit :
>>>> resize_hpt_for_hotplug() repo
() to
only report the problem when it is needed.
Signed-off-by: Laurent Vivier
---
arch/powerpc/include/asm/sparsemem.h | 4 ++--
arch/powerpc/mm/hash_utils_64.c | 17 ++---
arch/powerpc/mm/mem.c | 3 ++-
arch/powerpc/platforms/pseries/lpar.c | 1 -
4 files c
On 20/03/2019 13:47, Michael Ellerman wrote:
> Laurent Vivier writes:
>> Hi Michael,
>>
>> as it seems good now, could you pick up this patch for merging?
>
> I'll start picking up patches for next starting after rc2, so next week.
>
> If you think it's a bu
Hi Michael,
as it seems good now, could you pick up this patch for merging?
Thanks,
Laurent
On 13/03/2019 11:25, Laurent Vivier wrote:
> resize_hpt_for_hotplug() reports a warning when it cannot
> resize the hash page table ("Unable to resize hash page
> table to target order
() to
only report the problem when it is needed.
Signed-off-by: Laurent Vivier
---
arch/powerpc/include/asm/sparsemem.h | 4 ++--
arch/powerpc/mm/hash_utils_64.c | 17 ++---
arch/powerpc/mm/mem.c | 3 ++-
arch/powerpc/platforms/pseries/lpar.c | 3 ++-
4 files c
I forgot the version change note:
v2: add warning messages for H_PARAMETER and H_RESOURCE
Thanks,
Laurent
On 08/03/2019 11:54, Laurent Vivier wrote:
> resize_hpt_for_hotplug() reports a warning when it cannot
> resize the hash page table ("Unable to resize hash page
> table t
ODEV error.
If the operation cannot be done the real error message
will be reported by arch_add_memory() if create_section_mapping()
fails.
Fixes: 7339390d772dd
powerpc/pseries: Don't give a warning when HPT resizing isn't available
Signed-off-by: Laurent Vivier
---
Notes:
v2:
- us
On 07/02/2019 05:33, Michael Ellerman wrote:
> Hi Laurent,
>
> I'm not sure I'm convinced about this one. It seems like we're just
> throwing away the warning because it's annoying.
>
> Laurent Vivier writes:
>> resize_hpt_for_hotplug() reports a warning when it cannot
&
On 07/02/2019 04:03, David Gibson wrote:
> On Tue, Feb 05, 2019 at 09:21:33PM +0100, Laurent Vivier wrote:
>> resize_hpt_for_hotplug() reports a warning when it cannot
>> increase the hash page table ("Unable to resize hash page
>> table to target order") but this
e reported by arch_add_memory() if create_section_mapping()
fails.
Signed-off-by: Laurent Vivier
---
arch/powerpc/mm/hash_utils_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index 0cc7fbc3bd1c..b762bdceb
On 15/03/2019 13:25, Peter Zijlstra wrote:
> On Fri, Mar 15, 2019 at 12:12:45PM +0100, Laurent Vivier wrote:
>
>> Another way to avoid the nodes overlapping for the offline nodes at
>> startup is to ensure the default values don't define a distance that
>> merge all o
On 04/03/2019 20:59, Laurent Vivier wrote:
> When we hotplug a CPU in a memoryless/cpuless node,
> the kernel crashes when it rebuilds the sched_domains data.
>
> I reproduce this problem on POWER and with a pseries VM, with the following
> QEMU parameters:
>
> -machine p
kvmppc_get_gpr(vcpu, 3) == H_ENTER_NESTED)))
> kvmppc_core_dequeue_dec(vcpu);
>
> trace_kvm_guest_exit(vcpu);
>
Patches 2 and 3: tested I can boot and run an L2 nested guest with qemu
v4.0.0 and caps-large-decr=on in the case we have had a hang previously.
Tested-by: Laurent Vivier
ires = dec + tb;
> vcpu->cpu = -1;
>
Patches 2 and 3: tested I can boot and run an L2 nested guest with qemu
v4.0.0 and caps-large-decr=on in the case we have had a hang previously.
Tested-by: Laurent Vivier
Le 22/10/2020 à 05:23, Finn Thain a écrit :
> On Wed, 21 Oct 2020, Laurent Vivier wrote:
>
>> Le 21/10/2020 à 01:43, Finn Thain a écrit :
>>
>>> Laurent, can we avoid the irq == 0 warning splat like this?
>>>
>>> diff --git a/drivers/tty/serial/pmac_z
We can avoid to probe for the Zilog device (and generate ugly kernel warning)
if kernel is built for Mac but not on a Mac.
Signed-off-by: Laurent Vivier
---
drivers/tty/serial/pmac_zilog.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/tty/serial/pmac_zilog.c b/drivers
Le 20/10/2020 à 19:37, Greg KH a écrit :
> On Tue, Oct 20, 2020 at 06:37:41PM +0200, Laurent Vivier wrote:
>> Le 20/10/2020 à 18:28, Greg KH a écrit :
>>> On Tue, Oct 20, 2020 at 06:23:03PM +0200, Laurent Vivier wrote:
>>>> We can avoid to probe for the Zilog de
On 25/11/2020 15:54, Marc Zyngier wrote:
> On 2020-11-25 14:09, Laurent Vivier wrote:
>> On 25/11/2020 14:20, Thomas Gleixner wrote:
>>> Laurent,
>>>
>>> On Wed, Nov 25 2020 at 12:16, Laurent Vivier wrote:
>>>
>>> The proper subsystem prefix
e affinity parameter to
irq_create_mapping() we can forward the affinity from rtas_setup_msi_irqs()
to irq_domain_alloc_descs().
With this change, the virtqueues are correctly dispatched between the CPUs
on pseries.
BugId: https://bugzilla.redhat.com/show_bug.cgi?id=1702939
Signed-off-by: Laurent Vivie
On 25/11/2020 17:05, Denis Kirjanov wrote:
> On 11/25/20, Laurent Vivier wrote:
>> With virtio multiqueue, normally each queue IRQ is mapped to a CPU.
>>
>> But since commit 0d9f0a52c8b9f ("virtio_scsi: use virtio IRQ affinity")
>> this is broken on pseries.
On 25/11/2020 14:20, Thomas Gleixner wrote:
> Laurent,
>
> On Wed, Nov 25 2020 at 12:16, Laurent Vivier wrote:
>
> The proper subsystem prefix is: 'genirq/irqdomain:' and the first letter
> after the colon wants to be uppercase.
Ok.
>> This function ad
parameter
that can conveniently passed down to irq_domain_alloc_descs().
irq_create_mapping() is then re-implemented as a wrapper around
irq_create_mapping_affinity().
Signed-off-by: Laurent Vivier
Reviewed-by: Greg Kurz
---
include/linux/irqdomain.h | 12 ++--
kernel/irq/irqdomain.c
pper around original irq_create_mapping() with the
affinity parameter. Update comments
Laurent Vivier (2):
genirq/irqdomain: Add an irq_create_mapping_affinity() function
powerpc/pseries: pass MSI affinity to irq_create_mapping()
arch/powerpc/platforms/pseries/msi.c | 3 ++-
include/linux/irqdoma
leixner and
Marc Zyngier.
v2: add a wrapper around original irq_create_mapping() with the
affinity parameter. Update comments
Laurent Vivier (2):
genirq/irqdomain: Add an irq_create_mapping_affinity() function
powerpc/pseries: Pass MSI affinity to irq_create_mapping()
arch/powerpc/pla
parameter
that can conveniently passed down to irq_domain_alloc_descs().
irq_create_mapping() is then re-implemented as a wrapper around
irq_create_mapping_affinity().
Signed-off-by: Laurent Vivier
Reviewed-by: Greg Kurz
---
include/linux/irqdomain.h | 12 ++--
kernel/irq/irqdomain.c
pping() doesn't take an affinity parameter.
As the previous patch has added the affinity parameter to
irq_create_mapping() we can forward the affinity from rtas_setup_msi_irqs()
to irq_domain_alloc_descs().
With this change, the virtqueues are correctly dispatched between the CPUs
on pseries.
Signed-of
en updated with the help
of the following coccinelle script:
@@
expression a, b;
@@
<...
- irq_create_mapping(a, b)
+ irq_create_mapping(a, b, NULL)
...>
With some manual changes to comply with checkpatch errors.
No functional change.
Signed-off-by: Laurent Vivier
---
arch/arc/ker
IRQ: 289 CPU: 24
IRQ: 290 CPU: 25
IRQ: 291 CPU: 26
IRQ: 292 CPU: 27
IRQ: 293 CPU: 28
IRQ: 294 CPU: 29
IRQ: 295 CPU: 30
IRQ: 299 CPU: 31
This matches what we have on an x86_64 system.
Laurent Vivier (2):
genirq: add an affinity parameter to irq_create_mapping()
powerpc/pserie
ci_enable_msix_range()
__msi_domain_alloc_irqs()
__irq_domain_alloc_irqs()
__irq_alloc_descs()
Signed-off-by: Laurent Vivier
---
arch/powerpc/platforms/pseries/msi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/power
On 24/11/2020 23:19, Thomas Gleixner wrote:
> On Tue, Nov 24 2020 at 21:03, Laurent Vivier wrote:
>> This parameter is needed to pass it to irq_domain_alloc_descs().
>>
>> This seems to have been missed by
>> o06ee6d571f0e ("genirq: Add affinity hint to irq allocat
IRQ: 289 CPU: 24
IRQ: 290 CPU: 25
IRQ: 291 CPU: 26
IRQ: 292 CPU: 27
IRQ: 293 CPU: 28
IRQ: 294 CPU: 29
IRQ: 295 CPU: 30
IRQ: 299 CPU: 31
This matches what we have on an x86_64 system.
v2: add a wrapper around original irq_create_mapping() with the
affinity parameter. Update comments
Laurent
This function adds an affinity parameter to irq_create_mapping().
This parameter is needed to pass it to irq_domain_alloc_descs().
irq_create_mapping() is a wrapper around irq_create_mapping_affinity()
to pass NULL for the affinity parameter.
No functional change.
Signed-off-by: Laurent Vivier
e affinity parameter to
irq_create_mapping() we can forward the affinity from rtas_setup_msi_irqs()
to irq_domain_alloc_descs().
With this change, the virtqueues are correctly dispatched between the CPUs
on pseries.
Signed-off-by: Laurent Vivier
---
arch/powerpc/platforms/pseries/msi.c | 3 ++
Le 20/10/2020 à 18:28, Greg KH a écrit :
> On Tue, Oct 20, 2020 at 06:23:03PM +0200, Laurent Vivier wrote:
>> We can avoid to probe for the Zilog device (and generate ugly kernel warning)
>> if kernel is built for Mac but not on a Mac.
>>
>> Signed-off-by: Laurent Viv
Le 20/10/2020 à 20:32, Greg KH a écrit :
> On Tue, Oct 20, 2020 at 08:19:26PM +0200, Laurent Vivier wrote:
>> Le 20/10/2020 à 19:37, Greg KH a écrit :
>>> On Tue, Oct 20, 2020 at 06:37:41PM +0200, Laurent Vivier wrote:
>>>> Le 20/10/2020 à 18:28, Greg KH a écrit :
&g
Le 21/10/2020 à 01:43, Finn Thain a écrit :
> On Tue, 20 Oct 2020, Brad Boyer wrote:
>
>>
>> Wouldn't it be better to rearrange this code to only run if the devices
>> are present? This is a macio driver on pmac and a platform driver on
>> mac, so shouldn't it be possible to only run this code
ap one IPI interrupt per node for all cpus of that node.
>* Since the HW interrupt number doesn't have any meaning,
Tested-by: Laurent Vivier
virq = irq_create_mapping(NULL, hwirq);
> + else
> + virq = irq_create_mapping_affinity(NULL, hwirq,
> +entry->affinity);
>
> if (!virq) {
> pr_debug("rtas_msi: Failed mapping hwirq %d\n", hwirq);
>
Reviewed-by: Laurent Vivier
d PTE. See [1].
>
> But we do have pte_update(), which replaces the old PTE with the new,
> meaning there's no window where the PTE is invalid. And the hash MMU
> version hash__pte_update() deals with synchronising the hash page table
> correctly.
>
> [1]: https://lore.kernel.org/
ive: Map one IPI interrupt per node")
> Cc: sta...@vger.kernel.org # v5.13
> Reported-by: Geetika Moolchandani
> Cc: Srikar Dronamraju
> Cc: Laurent Vivier
> Signed-off-by: Cédric Le Goater
> Message-Id: <20210629131542.743888-1-...@kaod.org>
> Signed-off-by
Hi,
On 09/06/2021 03:34, Jordan Niethe wrote:
> From: Russell Currey
>
> To enable strict module RWX on powerpc, set:
>
> CONFIG_STRICT_MODULE_RWX=y
>
> You should also have CONFIG_STRICT_KERNEL_RWX=y set to have any real
> security benefit.
>
> ARCH_HAS_STRICT_MODULE_RWX is set to
On 13/10/2021 01:18, Michael Ellerman wrote:
Laurent Vivier writes:
Commit 112665286d08 moved guest_exit() in the interrupt protected
area to avoid wrong context warning (or worse), but the tick counter
cannot be updated and the guest time is accounted to the system time.
To fix the problem
On 15/10/2021 04:23, Nicholas Piggin wrote:
Excerpts from Laurent Vivier's message of October 13, 2021 7:30 pm:
On 13/10/2021 01:18, Michael Ellerman wrote:
Laurent Vivier writes:
Commit 112665286d08 moved guest_exit() in the interrupt protected
area to avoid wrong context warning (or worse
On 06/10/2021 12:42, Greg Kurz wrote:
On Wed, 6 Oct 2021 09:37:45 +0200
Laurent Vivier wrote:
Commit 61bd0f66ff92 has moved guest_enter() out of the interrupt
protected area to be able to have updated tick counters, but
commit 112665286d08 moved back to this area to avoid wrong
context
e main sequence of
vcpu_enter_guest(), including the call into vendor code to actually
enter and exit the guest."
Fixes: 112665286d08 ("KVM: PPC: Book3S HV: Context tracking exit guest context
before enabling irqs")
Cc: npig...@gmail.com
Cc: # 5.12
Signed-off-by: Laurent Vivi
1 - 100 of 104 matches
Mail list logo