On 27/10/2021 16:21, Nicholas Piggin wrote:
From: Laurent Vivier
Commit 112665286d08 ("KVM: PPC: Book3S HV: Context tracking exit guest
context before enabling irqs") moved guest_exit() into the interrupt
protected area to avoid wrong context warning (or worse). The problem is
that
On 27/10/2021 16:21, Nicholas Piggin wrote:
From: Laurent Vivier
Commit 112665286d08 ("KVM: PPC: Book3S HV: Context tracking exit guest
context before enabling irqs") moved guest_exit() into the interrupt
protected area to avoid wrong context warning (or worse). The problem is
that
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
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
the 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
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
with
VIRT_CPU_ACCOUNTING_GEN")
Fixes: 112665286d08 ("KVM: PPC: Book3S HV: Context tracking exit guest context
before enabling irqs")
Cc: npig...@gmail.com
Signed-off-by: Laurent Vivier
---
arch/powerpc/kvm/book3s_hv.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
) of a valid 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]: http
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 requir
On 29/06/2021 15:15, Cédric Le Goater wrote:
> On PowerVM, CPU-less nodes can be populated with hot-plugged CPUs at
> runtime. Today, the IPI is not created for such nodes, and hot-plugged
> CPUs use a bogus IPI, which leads to soft lockups.
>
> We could create the node IPI on demand but it is a b
* Map 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
ng() 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.
Sign
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
mas Gleixner 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/powerp
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.
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
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.
BugId: https://bugzilla.redhat.com/show_bug.cgi?id=1702939
Signed-off-by: Laurent
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
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
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 func
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-off-by: Laurent Vivier
---
arch/powerpc/platforms/pseries/msi.c |
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
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
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
__pci_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/
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/pseries:
d 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
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
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 w
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 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
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
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
;
> + 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
ch.dec_expires = 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
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&#
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&#
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
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
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
emory() 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 |
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
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
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
emory() 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 fi
emory() 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 fi
linuxppc-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 insertion
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
051f3ca02e46 ("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: P
051f3ca02e46 ("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: La
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
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 warn
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:
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/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 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 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 pmac-nub
for signals on guest entry")
Signed-off-by: Laurent Vivier
---
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 100644
--- a/arch/powerpc/kvm/bo
iver references
> the function __init pmu_init()
> If the reference is valid then annotate the
> variable with __init* or __refdata (see linux/init.h) or name the variable:
> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
>
> Signed-off-by: Mathieu Malaterr
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 via_pmu_drive
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
t;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
Thanks,
Laurent
On 22/12/2017 08:54, Paul Mackerras wrote:
> On Fri, Dec 22, 2017 at 03:34:20PM +1100, Michael Ellerman wrote:
>> Laurent Vivier writes:
>>
>>> On 12/12/2017 13:02, Cédric Le Goater wrote:
>>>> When restoring a pending interrupt, we are setting th
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 pe
t_icp() ignores the pending_pri value)
As xisr is 0, pending_pri must be set to 0xff.
Signed-off-by: Laurent Vivier
---
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_xive.c
index bf45784
alescing interrupts that haven't
>* been presented yet is always allowed.
>*/
> - if (val & KVM_XICS_PRESENTED || val & KVM_XICS_PENDING)
> + if (val & KVM_XICS_PRESENTED && !(val & KVM_XICS_PENDING))
> state->old_p = true;
> if (val & KVM_XICS_QUEUED || val & KVM_XICS_PENDING)
> state->old_q = true;
>
Reviewed-by: Laurent Vivier
Tested-by: Laurent Vivier
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().
>
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
---
arch/powerpc/kvm/book3s_xive.c | 20
1
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 th
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 that's true. The CP
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
---
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 8d3320562c70..abc533146514 100644
eba1ffe8
> ebc1fff0 ebe1fff8 7c0803a6 4bfdc2ac <0fe0> 7c0802a6 fb01ffc0
>
> Fixes: 943db62c316c ("powerpc/pseries: Revert 'Auto-online hotplugged
> memory'")
> Signed-off-by: Nathan Fontenot
tested the first scenario with 4.13.0-rc4 and qemu 2.10.0-rc2.
Tested-by: Laurent Vivier
Reviewed-by: Laurent Vivier
te) & 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
eleased
in this case too.
Signed-off-by: Laurent Vivier
---
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 100644
--- a/arch/powerpc/platfor
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 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 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 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
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
---
v2: split BOOK3S_INTERRUPT_MACHINE_CHECK and BOOK3S_INTERRUPT_TRACE
arch/powerpc/kvm/book3s_pr.c | 32 +++-
1 file changed, 31
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
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
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
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 "
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
---
arch/powerpc/kvm/book3s_pr.c | 31 +--
1 file changed, 29 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kvm
:
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
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
---
arch/powerpc/kvm/book3s_e
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 :
>
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 :
>>> On Thu, 2015-11-05 at 12:47 +0100, Laurent Vivier wrote:
>>>> When I try to cross compile a ppc64 kernel, it ge
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 differ
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
quot; 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
---
arch/powerpc/kernel/vdso64/Makefile | 2 +
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
---
arch/powerpc/boot/wrapper | 2 +-
1 file chang
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
-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
> wrote:
>
>> On kexec, all secondary offline CPUs are onlined before starting
>> the new kernel, this is not done in the case of k
1 - 100 of 105 matches
Mail list logo
