* Re: Advice needed on SMP regression after cpu_core_mask change
From: Cédric Le Goater @ 2021-03-17 15:30 UTC (permalink / raw)
To: Daniel Henrique Barboza, linuxppc-dev
Cc: Greg Kurz, aneesh.kumar, Srikar Dronamraju, David Gibson
In-Reply-To: <daa5d05f-dbd0-05ad-7395-5d5a3d364fc6@gmail.com>
On 3/17/21 2:00 PM, Daniel Henrique Barboza wrote:
> Hello,
>
> Patch 4bce545903fa ("powerpc/topology: Update topology_core_cpumask") introduced
> a regression in both upstream and RHEL downstream kernels [1]. The assumption made
> in the commit:
>
> "Further analysis shows that cpu_core_mask and cpu_cpu_mask for any CPU would be
> equal on Power"
>
> Doesn't seem to be true. After this commit, QEMU is now unable to set single NUMA
> node SMP topologies such as:
>
> -smp 8,maxcpus=8,cores=2,threads=2,sockets=2
>
> lscpu will give the following output in this case:
>
> # lscpu
> Architecture: ppc64le
> Byte Order: Little Endian
> CPU(s): 8
> On-line CPU(s) list: 0-7
> Thread(s) per core: 2
> Core(s) per socket: 4
> Socket(s): 1
> NUMA node(s): 1
> Model: 2.2 (pvr 004e 1202)
> Model name: POWER9 (architected), altivec supported
> Hypervisor vendor: KVM
> Virtualization type: para
> L1d cache: 32K
> L1i cache: 32K
> NUMA node0 CPU(s): 0-7
>
>
> This is happening because the macro cpu_cpu_mask(cpu) expands to
> cpumask_of_node(cpu_to_node(cpu)), which in turn expands to node_to_cpumask_map[node].
> node_to_cpumask_map is a NUMA array that maps CPUs to NUMA nodes (Aneesh is on CC to
> correct me if I'm wrong). We're now associating sockets to NUMA nodes directly.
>
> If I add a second NUMA node then I can get the intended smp topology:
>
> -smp 8,maxcpus=8,cores=2,threads=2,sockets=2
> -numa node,memdev=mem0,cpus=0-3,nodeid=0 \
> -numa node,memdev=mem1,cpus=4-7,nodeid=1 \
>
> # lscpu
> Architecture: ppc64le
> Byte Order: Little Endian
> CPU(s): 8
> On-line CPU(s) list: 0-7
> Thread(s) per core: 2
> Core(s) per socket: 2
> Socket(s): 2
> NUMA node(s): 2
> Model: 2.2 (pvr 004e 1202)
> Model name: POWER9 (architected), altivec supported
> Hypervisor vendor: KVM
> Virtualization type: para
> L1d cache: 32K
> L1i cache: 32K
> NUMA node0 CPU(s): 0-3
> NUMA node1 CPU(s): 4-7
>
>
> However, if I try a single socket with multiple NUMA nodes topology, which is the case
> of Power10, e.g.:
>
>
> -smp 8,maxcpus=8,cores=4,threads=2,sockets=1
> -numa node,memdev=mem0,cpus=0-3,nodeid=0 \
> -numa node,memdev=mem1,cpus=4-7,nodeid=1 \
>
>
> This is the result:
>
> # lscpu
> Architecture: ppc64le
> Byte Order: Little Endian
> CPU(s): 8
> On-line CPU(s) list: 0-7
> Thread(s) per core: 2
> Core(s) per socket: 2
> Socket(s): 2
> NUMA node(s): 2
> Model: 2.2 (pvr 004e 1202)
> Model name: POWER9 (architected), altivec supported
> Hypervisor vendor: KVM
> Virtualization type: para
> L1d cache: 32K
> L1i cache: 32K
> NUMA node0 CPU(s): 0-3
> NUMA node1 CPU(s): 4-7
>
>
> This confirms my suspicions that, at this moment, we're making sockets == NUMA nodes.
Yes. I don't think we can do better on PAPR and the above examples
seem to confirm that the "sockets" definition is simply ignored.
> Cedric, the reason I'm CCing you is because this is related to ibm,chip-id. The commit
> after the one that caused the regression, 4ca234a9cbd7c3a65 ("powerpc/smp: Stop updating
> cpu_core_mask"), is erasing the code that calculated cpu_core_mask. cpu_core_mask, despite
> its shortcomings that caused its removal, was giving a precise SMP topology. And it was
> using physical_package_id/'ibm,chip-id' for that.
ibm,chip-id is a no-no on pSeries. I guess this is inherent to PAPR which
is hiding a lot of the underlying HW and topology. May be we are trying
to reconcile two orthogonal views of machine virtualization ...
> Checking in QEMU I can say that the ibm,chip-id calculation is the only place in the code
> that cares about cores per socket information. The kernel is now ignoring that, starting
> on 4bce545903fa, and now QEMU is unable to provide this info to the guest.
>
> If we're not going to use ibm,chip-id any longer, which seems sensible given that PAPR does
> not declare it, we need another way of letting the guest know how much cores per socket
> we want.
The RTAS call "ibm,get-system-parameter" with token "Processor Module
Information" returns that kind of information :
2 byte binary number (N) of module types followed by N module specifiers of the form:
2 byte binary number (M) of sockets of this module type
2 byte binary number (L) of chips per this module type
2 byte binary number (K) of cores per chip in this module type.
See the values in these sysfs files :
cat /sys/devices/hv_24x7/interface/{sockets,chipspersocket,coresperchip}
But I am afraid these are host level information and not guest/LPAR.
I didn't find any LPAR level properties or hcalls in the PAPR document.
They need to be specified.
or
We can add extra properties like ibm,chip-id but making sure it's only
used under the KVM hypervisor. My understanding is that's something we
are trying to avoid.
C.
^ permalink raw reply
* Re: Advice needed on SMP regression after cpu_core_mask change
From: Daniel Henrique Barboza @ 2021-03-17 16:05 UTC (permalink / raw)
To: Cédric Le Goater, linuxppc-dev
Cc: Greg Kurz, aneesh.kumar, Srikar Dronamraju, David Gibson
In-Reply-To: <4569097d-ce89-5a13-33a9-2a4ca10be7bd@kaod.org>
On 3/17/21 12:30 PM, Cédric Le Goater wrote:
> On 3/17/21 2:00 PM, Daniel Henrique Barboza wrote:
>> Hello,
>>
>> Patch 4bce545903fa ("powerpc/topology: Update topology_core_cpumask") introduced
>> a regression in both upstream and RHEL downstream kernels [1]. The assumption made
>> in the commit:
>>
>> "Further analysis shows that cpu_core_mask and cpu_cpu_mask for any CPU would be
>> equal on Power"
>>
>> Doesn't seem to be true. After this commit, QEMU is now unable to set single NUMA
>> node SMP topologies such as:
>>
>> -smp 8,maxcpus=8,cores=2,threads=2,sockets=2
>>
>> lscpu will give the following output in this case:
>>
>> # lscpu
>> Architecture: ppc64le
>> Byte Order: Little Endian
>> CPU(s): 8
>> On-line CPU(s) list: 0-7
>> Thread(s) per core: 2
>> Core(s) per socket: 4
>> Socket(s): 1
>> NUMA node(s): 1
>> Model: 2.2 (pvr 004e 1202)
>> Model name: POWER9 (architected), altivec supported
>> Hypervisor vendor: KVM
>> Virtualization type: para
>> L1d cache: 32K
>> L1i cache: 32K
>> NUMA node0 CPU(s): 0-7
>>
>>
>> This is happening because the macro cpu_cpu_mask(cpu) expands to
>> cpumask_of_node(cpu_to_node(cpu)), which in turn expands to node_to_cpumask_map[node].
>> node_to_cpumask_map is a NUMA array that maps CPUs to NUMA nodes (Aneesh is on CC to
>> correct me if I'm wrong). We're now associating sockets to NUMA nodes directly.
>>
>> If I add a second NUMA node then I can get the intended smp topology:
>>
>> -smp 8,maxcpus=8,cores=2,threads=2,sockets=2
>> -numa node,memdev=mem0,cpus=0-3,nodeid=0 \
>> -numa node,memdev=mem1,cpus=4-7,nodeid=1 \
>>
>> # lscpu
>> Architecture: ppc64le
>> Byte Order: Little Endian
>> CPU(s): 8
>> On-line CPU(s) list: 0-7
>> Thread(s) per core: 2
>> Core(s) per socket: 2
>> Socket(s): 2
>> NUMA node(s): 2
>> Model: 2.2 (pvr 004e 1202)
>> Model name: POWER9 (architected), altivec supported
>> Hypervisor vendor: KVM
>> Virtualization type: para
>> L1d cache: 32K
>> L1i cache: 32K
>> NUMA node0 CPU(s): 0-3
>> NUMA node1 CPU(s): 4-7
>>
>>
>> However, if I try a single socket with multiple NUMA nodes topology, which is the case
>> of Power10, e.g.:
>>
>>
>> -smp 8,maxcpus=8,cores=4,threads=2,sockets=1
>> -numa node,memdev=mem0,cpus=0-3,nodeid=0 \
>> -numa node,memdev=mem1,cpus=4-7,nodeid=1 \
>>
>>
>> This is the result:
>>
>> # lscpu
>> Architecture: ppc64le
>> Byte Order: Little Endian
>> CPU(s): 8
>> On-line CPU(s) list: 0-7
>> Thread(s) per core: 2
>> Core(s) per socket: 2
>> Socket(s): 2
>> NUMA node(s): 2
>> Model: 2.2 (pvr 004e 1202)
>> Model name: POWER9 (architected), altivec supported
>> Hypervisor vendor: KVM
>> Virtualization type: para
>> L1d cache: 32K
>> L1i cache: 32K
>> NUMA node0 CPU(s): 0-3
>> NUMA node1 CPU(s): 4-7
>>
>>
>> This confirms my suspicions that, at this moment, we're making sockets == NUMA nodes.
>
> Yes. I don't think we can do better on PAPR and the above examples
> seem to confirm that the "sockets" definition is simply ignored.
>
>> Cedric, the reason I'm CCing you is because this is related to ibm,chip-id. The commit
>> after the one that caused the regression, 4ca234a9cbd7c3a65 ("powerpc/smp: Stop updating
>> cpu_core_mask"), is erasing the code that calculated cpu_core_mask. cpu_core_mask, despite
>> its shortcomings that caused its removal, was giving a precise SMP topology. And it was
>> using physical_package_id/'ibm,chip-id' for that.
>
> ibm,chip-id is a no-no on pSeries. I guess this is inherent to PAPR which
> is hiding a lot of the underlying HW and topology. May be we are trying
> to reconcile two orthogonal views of machine virtualization ...
>
>> Checking in QEMU I can say that the ibm,chip-id calculation is the only place in the code
>> that cares about cores per socket information. The kernel is now ignoring that, starting
>> on 4bce545903fa, and now QEMU is unable to provide this info to the guest.
>>
>> If we're not going to use ibm,chip-id any longer, which seems sensible given that PAPR does
>> not declare it, we need another way of letting the guest know how much cores per socket
>> we want.
> The RTAS call "ibm,get-system-parameter" with token "Processor Module
> Information" returns that kind of information :
>
> 2 byte binary number (N) of module types followed by N module specifiers of the form:
> 2 byte binary number (M) of sockets of this module type
> 2 byte binary number (L) of chips per this module type
> 2 byte binary number (K) of cores per chip in this module type.
>
> See the values in these sysfs files :
>
> cat /sys/devices/hv_24x7/interface/{sockets,chipspersocket,coresperchip}
>
> But I am afraid these are host level information and not guest/LPAR.
I believe there might be some sort of reasoning behind not having this on
PAPR, but I'll say in advance that the virtual machine should act as the
real hardware, as close as possible. This is the kind of hcall that could
be used in this situation.
>
> I didn't find any LPAR level properties or hcalls in the PAPR document.
> They need to be specified.
>
> or
>
> We can add extra properties like ibm,chip-id but making sure it's only
> used under the KVM hypervisor. My understanding is that's something we
> are trying to avoid.
We can change PAPR to add ibm,chip-id. Problem is that ibm,chip-id today, with
the current kernel codebase, does not fix the issue because the code is
ignoring it hehehe
If we're going to change PAPR - and I believe we should, there's a clear
lack of proper support for SMP topologies - we're better make sure that whatever
attribute/hcall we add there fixes it in a robust way for the long term.
Thanks,
DHB
>
> C.
>
^ permalink raw reply
* Re: [PATCH v3 19/41] KVM: PPC: Book3S HV P9: Stop handling hcalls in real-mode in the P9 path
From: Fabiano Rosas @ 2021-03-17 16:22 UTC (permalink / raw)
To: Nicholas Piggin, kvm-ppc; +Cc: linuxppc-dev, Nicholas Piggin
In-Reply-To: <20210305150638.2675513-20-npiggin@gmail.com>
Nicholas Piggin <npiggin@gmail.com> writes:
> In the interest of minimising the amount of code that is run in
> "real-mode", don't handle hcalls in real mode in the P9 path.
>
> POWER8 and earlier are much more expensive to exit from HV real mode
> and switch to host mode, because on those processors HV interrupts get
> to the hypervisor with the MMU off, and the other threads in the core
> need to be pulled out of the guest, and SLBs all need to be saved,
> ERATs invalidated, and host SLB reloaded before the MMU is re-enabled
> in host mode. Hash guests also require a lot of hcalls to run. The
> XICS interrupt controller requires hcalls to run.
>
> By contrast, POWER9 has independent thread switching, and in radix mode
> the hypervisor is already in a host virtual memory mode when the HV
> interrupt is taken. Radix + xive guests don't need hcalls to handle
> interrupts or manage translations.
>
> So it's much less important to handle hcalls in real mode in P9.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
<snip>
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index 497f216ad724..1f2ba8955c6a 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -1147,7 +1147,7 @@ int kvmppc_pseries_do_hcall(struct kvm_vcpu *vcpu)
> * This has to be done early, not in kvmppc_pseries_do_hcall(), so
> * that the cede logic in kvmppc_run_single_vcpu() works properly.
> */
> -static void kvmppc_nested_cede(struct kvm_vcpu *vcpu)
> +static void kvmppc_cede(struct kvm_vcpu *vcpu)
The comment above needs to be updated I think.
> {
> vcpu->arch.shregs.msr |= MSR_EE;
> vcpu->arch.ceded = 1;
> @@ -1403,9 +1403,15 @@ static int kvmppc_handle_exit_hv(struct kvm_vcpu *vcpu,
> /* hcall - punt to userspace */
> int i;
>
> - /* hypercall with MSR_PR has already been handled in rmode,
> - * and never reaches here.
> - */
> + if (unlikely(vcpu->arch.shregs.msr & MSR_PR)) {
> + /*
> + * Guest userspace executed sc 1, reflect it back as a
> + * privileged program check interrupt.
> + */
> + kvmppc_core_queue_program(vcpu, SRR1_PROGPRIV);
> + r = RESUME_GUEST;
> + break;
> + }
>
> run->papr_hcall.nr = kvmppc_get_gpr(vcpu, 3);
> for (i = 0; i < 9; ++i)
> @@ -3740,15 +3746,36 @@ static int kvmhv_p9_guest_entry(struct kvm_vcpu *vcpu, u64 time_limit,
> /* H_CEDE has to be handled now, not later */
> if (trap == BOOK3S_INTERRUPT_SYSCALL && !vcpu->arch.nested &&
> kvmppc_get_gpr(vcpu, 3) == H_CEDE) {
> - kvmppc_nested_cede(vcpu);
> + kvmppc_cede(vcpu);
> kvmppc_set_gpr(vcpu, 3, 0);
> trap = 0;
> }
> } else {
> kvmppc_xive_push_vcpu(vcpu);
> trap = kvmhv_load_hv_regs_and_go(vcpu, time_limit, lpcr);
> - kvmppc_xive_pull_vcpu(vcpu);
> + /* H_CEDE has to be handled now, not later */
> + /* XICS hcalls must be handled before xive is pulled */
> + if (trap == BOOK3S_INTERRUPT_SYSCALL &&
> + !(vcpu->arch.shregs.msr & MSR_PR)) {
> + unsigned long req = kvmppc_get_gpr(vcpu, 3);
>
> + if (req == H_CEDE) {
> + kvmppc_cede(vcpu);
> + kvmppc_xive_cede_vcpu(vcpu); /* may un-cede */
> + kvmppc_set_gpr(vcpu, 3, 0);
> + trap = 0;
> + }
> + if (req == H_EOI || req == H_CPPR ||
> + req == H_IPI || req == H_IPOLL ||
> + req == H_XIRR || req == H_XIRR_X) {
> + unsigned long ret;
> +
> + ret = kvmppc_xive_xics_hcall(vcpu, req);
> + kvmppc_set_gpr(vcpu, 3, ret);
> + trap = 0;
> + }
> + }
I tried running L2 with xive=off and this code slows down the boot
considerably. I think we're missing a !vcpu->arch.nested in the
conditional.
This may also be missing these checks from kvmppc_pseries_do_hcall:
if (kvmppc_xics_enabled(vcpu)) {
if (xics_on_xive()) {
ret = H_NOT_AVAILABLE;
return RESUME_GUEST;
}
ret = kvmppc_xics_hcall(vcpu, req);
(...)
For H_CEDE there might be a similar situation since we're shadowing the
code above that runs after H_ENTER_NESTED by setting trap to 0 here.
> + kvmppc_xive_pull_vcpu(vcpu);
> }
>
> vcpu->arch.slb_max = 0;
> @@ -4408,8 +4435,11 @@ static int kvmppc_vcpu_run_hv(struct kvm_vcpu *vcpu)
> else
> r = kvmppc_run_vcpu(vcpu);
>
> - if (run->exit_reason == KVM_EXIT_PAPR_HCALL &&
> - !(vcpu->arch.shregs.msr & MSR_PR)) {
> + if (run->exit_reason == KVM_EXIT_PAPR_HCALL) {
> + if (WARN_ON_ONCE(vcpu->arch.shregs.msr & MSR_PR)) {
> + r = RESUME_GUEST;
> + continue;
> + }
> trace_kvm_hcall_enter(vcpu);
> r = kvmppc_pseries_do_hcall(vcpu);
> trace_kvm_hcall_exit(vcpu, r);
> diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> index c11597f815e4..2d0d14ed1d92 100644
> --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> @@ -1397,9 +1397,14 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
> mr r4,r9
> bge fast_guest_return
> 2:
> + /* If we came in through the P9 short path, no real mode hcalls */
> + lwz r0, STACK_SLOT_SHORT_PATH(r1)
> + cmpwi r0, 0
> + bne no_try_real
> /* See if this is an hcall we can handle in real mode */
> cmpwi r12,BOOK3S_INTERRUPT_SYSCALL
> beq hcall_try_real_mode
> +no_try_real:
>
> /* Hypervisor doorbell - exit only if host IPI flag set */
> cmpwi r12, BOOK3S_INTERRUPT_H_DOORBELL
> diff --git a/arch/powerpc/kvm/book3s_xive.c b/arch/powerpc/kvm/book3s_xive.c
> index 52cdb9e2660a..1e4871bbcad4 100644
> --- a/arch/powerpc/kvm/book3s_xive.c
> +++ b/arch/powerpc/kvm/book3s_xive.c
> @@ -158,6 +158,40 @@ void kvmppc_xive_pull_vcpu(struct kvm_vcpu *vcpu)
> }
> EXPORT_SYMBOL_GPL(kvmppc_xive_pull_vcpu);
>
> +void kvmppc_xive_cede_vcpu(struct kvm_vcpu *vcpu)
> +{
> + void __iomem *esc_vaddr = (void __iomem *)vcpu->arch.xive_esc_vaddr;
> +
> + if (!esc_vaddr)
> + return;
> +
> + /* we are using XIVE with single escalation */
> +
> + if (vcpu->arch.xive_esc_on) {
> + /*
> + * If we still have a pending escalation, abort the cede,
> + * and we must set PQ to 10 rather than 00 so that we don't
> + * potentially end up with two entries for the escalation
> + * interrupt in the XIVE interrupt queue. In that case
> + * we also don't want to set xive_esc_on to 1 here in
> + * case we race with xive_esc_irq().
> + */
> + vcpu->arch.ceded = 0;
> + /*
> + * The escalation interrupts are special as we don't EOI them.
> + * There is no need to use the load-after-store ordering offset
> + * to set PQ to 10 as we won't use StoreEOI.
> + */
> + __raw_readq(esc_vaddr + XIVE_ESB_SET_PQ_10);
> + } else {
> + vcpu->arch.xive_esc_on = true;
> + mb();
> + __raw_readq(esc_vaddr + XIVE_ESB_SET_PQ_00);
> + }
> + mb();
> +}
> +EXPORT_SYMBOL_GPL(kvmppc_xive_cede_vcpu);
> +
> /*
> * This is a simple trigger for a generic XIVE IRQ. This must
> * only be called for interrupts that support a trigger page
> @@ -2106,6 +2140,32 @@ static int kvmppc_xive_create(struct kvm_device *dev, u32 type)
> return 0;
> }
>
> +int kvmppc_xive_xics_hcall(struct kvm_vcpu *vcpu, u32 req)
> +{
> + struct kvmppc_vcore *vc = vcpu->arch.vcore;
> +
> + switch (req) {
> + case H_XIRR:
> + return xive_vm_h_xirr(vcpu);
> + case H_CPPR:
> + return xive_vm_h_cppr(vcpu, kvmppc_get_gpr(vcpu, 4));
> + case H_EOI:
> + return xive_vm_h_eoi(vcpu, kvmppc_get_gpr(vcpu, 4));
> + case H_IPI:
> + return xive_vm_h_ipi(vcpu, kvmppc_get_gpr(vcpu, 4),
> + kvmppc_get_gpr(vcpu, 5));
> + case H_IPOLL:
> + return xive_vm_h_ipoll(vcpu, kvmppc_get_gpr(vcpu, 4));
> + case H_XIRR_X:
> + xive_vm_h_xirr(vcpu);
> + kvmppc_set_gpr(vcpu, 5, get_tb() + vc->tb_offset);
> + return H_SUCCESS;
> + }
> +
> + return H_UNSUPPORTED;
> +}
> +EXPORT_SYMBOL_GPL(kvmppc_xive_xics_hcall);
> +
> int kvmppc_xive_debug_show_queues(struct seq_file *m, struct kvm_vcpu *vcpu)
> {
> struct kvmppc_xive_vcpu *xc = vcpu->arch.xive_vcpu;
^ permalink raw reply
* Re: [PATCH 12/14] swiotlb: move global variables into a new io_tlb_mem structure
From: Konrad Rzeszutek Wilk @ 2021-03-17 17:51 UTC (permalink / raw)
To: Christoph Hellwig
Cc: xen-devel, iommu, Dongli Zhang, Claire Chang, linuxppc-dev
In-Reply-To: <20210317135327.GA10797@lst.de>
On Wed, Mar 17, 2021 at 02:53:27PM +0100, Christoph Hellwig wrote:
> On Wed, Mar 17, 2021 at 01:42:07PM +0000, Konrad Rzeszutek Wilk wrote:
> > > - alloc_size = PAGE_ALIGN(io_tlb_nslabs * sizeof(size_t));
> > > - io_tlb_alloc_size = memblock_alloc(alloc_size, PAGE_SIZE);
> > > - if (!io_tlb_alloc_size)
> > > - panic("%s: Failed to allocate %zu bytes align=0x%lx\n",
> > > - __func__, alloc_size, PAGE_SIZE);
> >
> > Shouldn't this be converted to:
> > mem->alloc_size = memblock_alloc(alloc_size, PAGE_SIZE);
> > if (...)
> >
> > Seems that it got lost in the search and replace?
>
> Yes, I messed that up during the rebase. That being said it magically
> gets fixed in the next patch..
Yes. However if someone does a bisection they are going to be mighty unhappy
with you.
^ permalink raw reply
* Re: [PATCH] powerpc: kernel: Trivial typo fix in the file kgdb.c
From: Randy Dunlap @ 2021-03-17 17:56 UTC (permalink / raw)
To: Bhaskar Chowdhury, mpe, benh, paulus, jniethe5, alistair,
linuxppc-dev, linux-kernel
In-Reply-To: <20210317090413.120891-1-unixbhaskar@gmail.com>
On 3/17/21 2:04 AM, Bhaskar Chowdhury wrote:
>
> s/procesing/processing/
>
> Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
> ---
> arch/powerpc/kernel/kgdb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c
> index 409080208a6c..7dd2ad3603ad 100644
> --- a/arch/powerpc/kernel/kgdb.c
> +++ b/arch/powerpc/kernel/kgdb.c
> @@ -376,7 +376,7 @@ void kgdb_arch_set_pc(struct pt_regs *regs, unsigned long pc)
> }
>
> /*
> - * This function does PowerPC specific procesing for interfacing to gdb.
> + * This function does PowerPC specific processing for interfacing to gdb.
> */
> int kgdb_arch_handle_exception(int vector, int signo, int err_code,
> char *remcom_in_buffer, char *remcom_out_buffer,
> --
--
~Randy
^ permalink raw reply
* Re: [PATCH 12/14] swiotlb: move global variables into a new io_tlb_mem structure
From: Christoph Hellwig @ 2021-03-17 17:57 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Dongli Zhang, iommu, xen-devel, Claire Chang, linuxppc-dev,
Christoph Hellwig
In-Reply-To: <YFJBvFjtZUiBQj4k@Konrads-MacBook-Pro.local>
On Wed, Mar 17, 2021 at 01:51:56PM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Mar 17, 2021 at 02:53:27PM +0100, Christoph Hellwig wrote:
> > On Wed, Mar 17, 2021 at 01:42:07PM +0000, Konrad Rzeszutek Wilk wrote:
> > > > - alloc_size = PAGE_ALIGN(io_tlb_nslabs * sizeof(size_t));
> > > > - io_tlb_alloc_size = memblock_alloc(alloc_size, PAGE_SIZE);
> > > > - if (!io_tlb_alloc_size)
> > > > - panic("%s: Failed to allocate %zu bytes align=0x%lx\n",
> > > > - __func__, alloc_size, PAGE_SIZE);
> > >
> > > Shouldn't this be converted to:
> > > mem->alloc_size = memblock_alloc(alloc_size, PAGE_SIZE);
> > > if (...)
> > >
> > > Seems that it got lost in the search and replace?
> >
> > Yes, I messed that up during the rebase. That being said it magically
> > gets fixed in the next patch..
>
> Yes. However if someone does a bisection they are going to be mighty unhappy
> with you.
Sure, I was planning on fixing it anyway. Just waiting for feedback
on the rest of the patches before doing a respin.
^ permalink raw reply
* Re: [PATCH 12/14] swiotlb: move global variables into a new io_tlb_mem structure
From: Konrad Rzeszutek Wilk @ 2021-03-17 18:18 UTC (permalink / raw)
To: Christoph Hellwig, jgross
Cc: xen-devel, iommu, Dongli Zhang, Claire Chang, linuxppc-dev
In-Reply-To: <20210317175742.GA29280@lst.de>
On Wed, Mar 17, 2021 at 06:57:42PM +0100, Christoph Hellwig wrote:
> On Wed, Mar 17, 2021 at 01:51:56PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Wed, Mar 17, 2021 at 02:53:27PM +0100, Christoph Hellwig wrote:
> > > On Wed, Mar 17, 2021 at 01:42:07PM +0000, Konrad Rzeszutek Wilk wrote:
> > > > > - alloc_size = PAGE_ALIGN(io_tlb_nslabs * sizeof(size_t));
> > > > > - io_tlb_alloc_size = memblock_alloc(alloc_size, PAGE_SIZE);
> > > > > - if (!io_tlb_alloc_size)
> > > > > - panic("%s: Failed to allocate %zu bytes align=0x%lx\n",
> > > > > - __func__, alloc_size, PAGE_SIZE);
> > > >
> > > > Shouldn't this be converted to:
> > > > mem->alloc_size = memblock_alloc(alloc_size, PAGE_SIZE);
> > > > if (...)
> > > >
> > > > Seems that it got lost in the search and replace?
> > >
> > > Yes, I messed that up during the rebase. That being said it magically
> > > gets fixed in the next patch..
> >
> > Yes. However if someone does a bisection they are going to be mighty unhappy
> > with you.
>
> Sure, I was planning on fixing it anyway. Just waiting for feedback
> on the rest of the patches before doing a respin.
I put the patches up-to this one on :
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb devel/for-linus-5.13
Would you be OK rebasing on top of that and sending the patches?
Juergen, would you be OK testing that branch on your Xen setup?
^ permalink raw reply
* Re: [PATCH v2] mm: Move mem_init_print_info() into mm_init()
From: Dave Hansen @ 2021-03-17 18:48 UTC (permalink / raw)
To: Kefeng Wang, linux-kernel, Andrew Morton
Cc: linux-ia64, linux-sh, Peter Zijlstra, Catalin Marinas,
Dave Hansen, linux-mm, Guo Ren, sparclinux, linux-riscv,
Jonas Bonn, linux-s390, Yoshinori Sato, linux-hexagon,
Huacai Chen, Russell King, linux-csky, Ingo Molnar,
linux-snps-arc, linux-xtensa, Heiko Carstens, linux-um,
linux-m68k, openrisc, linux-arm-kernel, Richard Henderson,
linux-parisc, linux-mips, Palmer Dabbelt, linux-alpha,
linuxppc-dev, David S. Miller
In-Reply-To: <20210317015210.33641-1-wangkefeng.wang@huawei.com>
On 3/16/21 6:52 PM, Kefeng Wang wrote:
> mem_init_print_info() is called in mem_init() on each architecture,
> and pass NULL argument, so using void argument and move it into mm_init().
>
> Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
It's not a big deal but you might want to say something like:
Acked-by: Dave Hansen <dave.hansen@linux.intel.com> # x86 bits
Just to make it clear that I didn't look at the alpha bits at all. :)
^ permalink raw reply
* Re: [PATCH v3 19/41] KVM: PPC: Book3S HV P9: Stop handling hcalls in real-mode in the P9 path
From: Nicholas Piggin @ 2021-03-17 22:41 UTC (permalink / raw)
To: Fabiano Rosas, kvm-ppc; +Cc: linuxppc-dev
In-Reply-To: <87o8fh21iq.fsf@linux.ibm.com>
Excerpts from Fabiano Rosas's message of March 18, 2021 2:22 am:
> Nicholas Piggin <npiggin@gmail.com> writes:
>
>> In the interest of minimising the amount of code that is run in
>> "real-mode", don't handle hcalls in real mode in the P9 path.
>>
>> POWER8 and earlier are much more expensive to exit from HV real mode
>> and switch to host mode, because on those processors HV interrupts get
>> to the hypervisor with the MMU off, and the other threads in the core
>> need to be pulled out of the guest, and SLBs all need to be saved,
>> ERATs invalidated, and host SLB reloaded before the MMU is re-enabled
>> in host mode. Hash guests also require a lot of hcalls to run. The
>> XICS interrupt controller requires hcalls to run.
>>
>> By contrast, POWER9 has independent thread switching, and in radix mode
>> the hypervisor is already in a host virtual memory mode when the HV
>> interrupt is taken. Radix + xive guests don't need hcalls to handle
>> interrupts or manage translations.
>>
>> So it's much less important to handle hcalls in real mode in P9.
>>
>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>> ---
>
> <snip>
>
>> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
>> index 497f216ad724..1f2ba8955c6a 100644
>> --- a/arch/powerpc/kvm/book3s_hv.c
>> +++ b/arch/powerpc/kvm/book3s_hv.c
>> @@ -1147,7 +1147,7 @@ int kvmppc_pseries_do_hcall(struct kvm_vcpu *vcpu)
>> * This has to be done early, not in kvmppc_pseries_do_hcall(), so
>> * that the cede logic in kvmppc_run_single_vcpu() works properly.
>> */
>> -static void kvmppc_nested_cede(struct kvm_vcpu *vcpu)
>> +static void kvmppc_cede(struct kvm_vcpu *vcpu)
>
> The comment above needs to be updated I think.
>
>> {
>> vcpu->arch.shregs.msr |= MSR_EE;
>> vcpu->arch.ceded = 1;
>> @@ -1403,9 +1403,15 @@ static int kvmppc_handle_exit_hv(struct kvm_vcpu *vcpu,
>> /* hcall - punt to userspace */
>> int i;
>>
>> - /* hypercall with MSR_PR has already been handled in rmode,
>> - * and never reaches here.
>> - */
>> + if (unlikely(vcpu->arch.shregs.msr & MSR_PR)) {
>> + /*
>> + * Guest userspace executed sc 1, reflect it back as a
>> + * privileged program check interrupt.
>> + */
>> + kvmppc_core_queue_program(vcpu, SRR1_PROGPRIV);
>> + r = RESUME_GUEST;
>> + break;
>> + }
>>
>> run->papr_hcall.nr = kvmppc_get_gpr(vcpu, 3);
>> for (i = 0; i < 9; ++i)
>> @@ -3740,15 +3746,36 @@ static int kvmhv_p9_guest_entry(struct kvm_vcpu *vcpu, u64 time_limit,
>> /* H_CEDE has to be handled now, not later */
>> if (trap == BOOK3S_INTERRUPT_SYSCALL && !vcpu->arch.nested &&
>> kvmppc_get_gpr(vcpu, 3) == H_CEDE) {
>> - kvmppc_nested_cede(vcpu);
>> + kvmppc_cede(vcpu);
>> kvmppc_set_gpr(vcpu, 3, 0);
>> trap = 0;
>> }
>> } else {
>> kvmppc_xive_push_vcpu(vcpu);
>> trap = kvmhv_load_hv_regs_and_go(vcpu, time_limit, lpcr);
>> - kvmppc_xive_pull_vcpu(vcpu);
>> + /* H_CEDE has to be handled now, not later */
>> + /* XICS hcalls must be handled before xive is pulled */
>> + if (trap == BOOK3S_INTERRUPT_SYSCALL &&
>> + !(vcpu->arch.shregs.msr & MSR_PR)) {
>> + unsigned long req = kvmppc_get_gpr(vcpu, 3);
>>
>> + if (req == H_CEDE) {
>> + kvmppc_cede(vcpu);
>> + kvmppc_xive_cede_vcpu(vcpu); /* may un-cede */
>> + kvmppc_set_gpr(vcpu, 3, 0);
>> + trap = 0;
>> + }
>> + if (req == H_EOI || req == H_CPPR ||
>> + req == H_IPI || req == H_IPOLL ||
>> + req == H_XIRR || req == H_XIRR_X) {
>> + unsigned long ret;
>> +
>> + ret = kvmppc_xive_xics_hcall(vcpu, req);
>> + kvmppc_set_gpr(vcpu, 3, ret);
>> + trap = 0;
>> + }
>> + }
>
> I tried running L2 with xive=off and this code slows down the boot
> considerably. I think we're missing a !vcpu->arch.nested in the
> conditional.
You might be right, the real mode handlers never run if nested is set
so none of these should run I think.
>
> This may also be missing these checks from kvmppc_pseries_do_hcall:
>
> if (kvmppc_xics_enabled(vcpu)) {
> if (xics_on_xive()) {
> ret = H_NOT_AVAILABLE;
> return RESUME_GUEST;
> }
> ret = kvmppc_xics_hcall(vcpu, req);
> (...)
Well this is the formerly real-mode part of the hcall, whereas
pseries_do_hcall is the virt-mode handler so it expects the real mode
has already run.
Hmm, probably it shouldn't be setting trap = 0 if it did not handle the
hcall. I don't know if that's the problem you have or if it's the nested
test but probably should test for this anyway.
> For H_CEDE there might be a similar situation since we're shadowing the
> code above that runs after H_ENTER_NESTED by setting trap to 0 here.
Yes.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH v2] mm: Move mem_init_print_info() into mm_init()
From: Vineet Gupta @ 2021-03-18 0:40 UTC (permalink / raw)
To: Kefeng Wang, linux-kernel@vger.kernel.org, Andrew Morton
Cc: linux-ia64@vger.kernel.org, Peter Zijlstra, Catalin Marinas,
Dave Hansen, Guo Ren, Jonas Bonn, Yoshinori Sato,
linux-hexagon@vger.kernel.org, Huacai Chen, Russell King,
linux-csky@vger.kernel.org, linux-riscv@lists.infradea,
Ingo Molnar, linux-snps-arc@lists.infradead.org, Heiko Carstens,
linux-m68k@lists.linux-m68k.org, openrisc@lists.librecores.org,
linux-arm-kernel@lists.infradead.org, Richard Henderson,
linux-parisc@vger.kernel.org, linux-mips@vger.kernel.org,
Palmer Dabbelt, linux-alpha@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, David S. Miller
In-Reply-To: <20210317015210.33641-1-wangkefeng.wang@huawei.com>
On 3/16/21 6:52 PM, Kefeng Wang wrote:
> mem_init_print_info() is called in mem_init() on each architecture,
> and pass NULL argument, so using void argument and move it into mm_init().
>
> Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Acked-by: Vineet Gupta <vgupta@synopsys.com>
Thx,
-Vineet
^ permalink raw reply
* Re: [PATCH v2] mm: Move mem_init_print_info() into mm_init()
From: Kefeng Wang @ 2021-03-18 1:01 UTC (permalink / raw)
To: Dave Hansen, linux-kernel, Andrew Morton
Cc: linux-ia64, linux-sh, Peter Zijlstra, Catalin Marinas,
Dave Hansen, linux-mm, Guo Ren, sparclinux, linux-riscv,
Jonas Bonn, linux-s390, Yoshinori Sato, linux-hexagon,
Huacai Chen, Russell King, linux-csky, Ingo Molnar,
linux-snps-arc, linux-xtensa, Heiko Carstens, linux-um,
linux-m68k, openrisc, linux-arm-kernel, Richard Henderson,
linux-parisc, linux-mips, Palmer Dabbelt, linux-alpha,
linuxppc-dev, David S. Miller
In-Reply-To: <2a7d6e39-b293-7422-87b0-741f1ab0c22c@intel.com>
On 2021/3/18 2:48, Dave Hansen wrote:
> On 3/16/21 6:52 PM, Kefeng Wang wrote:
>> mem_init_print_info() is called in mem_init() on each architecture,
>> and pass NULL argument, so using void argument and move it into mm_init().
>>
>> Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
> It's not a big deal but you might want to say something like:
>
> Acked-by: Dave Hansen <dave.hansen@linux.intel.com> # x86 bits
>
> Just to make it clear that I didn't look at the alpha bits at all. :)
Get it, will be careful, thanks.
> .
>
^ permalink raw reply
* [powerpc:fixes-test] BUILD SUCCESS cc7a0bb058b85ea03db87169c60c7cfdd5d34678
From: kernel test robot @ 2021-03-18 1:08 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes-test
branch HEAD: cc7a0bb058b85ea03db87169c60c7cfdd5d34678 PCI: rpadlpar: Fix potential drc_name corruption in store functions
elapsed time: 1279m
configs tested: 210
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm allyesconfig
arm allmodconfig
arm64 allyesconfig
arm64 defconfig
x86_64 allyesconfig
riscv allmodconfig
i386 allyesconfig
riscv allyesconfig
nds32 alldefconfig
arm pxa255-idp_defconfig
arm lpc32xx_defconfig
sh sh7710voipgw_defconfig
powerpc ge_imp3a_defconfig
arm am200epdkit_defconfig
powerpc skiroot_defconfig
powerpc ksi8560_defconfig
sh se7721_defconfig
m68k defconfig
h8300 edosk2674_defconfig
powerpc redwood_defconfig
mips qi_lb60_defconfig
powerpc taishan_defconfig
powerpc allmodconfig
mips gpr_defconfig
powerpc socrates_defconfig
arc haps_hs_defconfig
arm spear13xx_defconfig
powerpc mpc512x_defconfig
powerpc xes_mpc85xx_defconfig
arm mmp2_defconfig
arm palmz72_defconfig
arm iop32x_defconfig
arm neponset_defconfig
powerpc kilauea_defconfig
arm bcm2835_defconfig
sh rsk7269_defconfig
sh se7751_defconfig
parisc generic-64bit_defconfig
powerpc mpc85xx_cds_defconfig
arm alldefconfig
sh landisk_defconfig
powerpc mvme5100_defconfig
m68k m5249evb_defconfig
sh titan_defconfig
powerpc ppc40x_defconfig
sh edosk7705_defconfig
s390 debug_defconfig
sh apsh4a3a_defconfig
m68k mvme16x_defconfig
m68k bvme6000_defconfig
powerpc mpc832x_mds_defconfig
arm ep93xx_defconfig
mips cobalt_defconfig
sh secureedge5410_defconfig
powerpc asp8347_defconfig
arm tegra_defconfig
powerpc pmac32_defconfig
arm rpc_defconfig
arc tb10x_defconfig
xtensa audio_kc705_defconfig
sh se7750_defconfig
arc nsim_700_defconfig
arm pxa910_defconfig
powerpc makalu_defconfig
sh se7206_defconfig
sh se7724_defconfig
arm cns3420vb_defconfig
mips rs90_defconfig
arm simpad_defconfig
mips gcw0_defconfig
powerpc eiger_defconfig
mips bmips_be_defconfig
m68k stmark2_defconfig
powerpc wii_defconfig
mips loongson1c_defconfig
sh sh7785lcr_defconfig
mips ip28_defconfig
powerpc adder875_defconfig
arm assabet_defconfig
arc alldefconfig
arm multi_v4t_defconfig
sh se7619_defconfig
sh sdk7786_defconfig
mips mpc30x_defconfig
powerpc mpc836x_mds_defconfig
arm clps711x_defconfig
powerpc arches_defconfig
sparc sparc32_defconfig
powerpc stx_gp3_defconfig
arm imx_v4_v5_defconfig
powerpc chrp32_defconfig
mips loongson1b_defconfig
h8300 h8300h-sim_defconfig
sh sh7757lcr_defconfig
sh alldefconfig
powerpc storcenter_defconfig
arm milbeaut_m10v_defconfig
mips ath79_defconfig
powerpc pcm030_defconfig
arm eseries_pxa_defconfig
powerpc lite5200b_defconfig
powerpc ppa8548_defconfig
powerpc ebony_defconfig
arm footbridge_defconfig
mips bcm47xx_defconfig
powerpc mpc7448_hpc2_defconfig
xtensa defconfig
arm lpc18xx_defconfig
sh lboxre2_defconfig
alpha allyesconfig
powerpc tqm8541_defconfig
alpha alldefconfig
arm lubbock_defconfig
ia64 zx1_defconfig
sh espt_defconfig
arc nsimosci_defconfig
parisc allyesconfig
powerpc sam440ep_defconfig
powerpc mpc8560_ads_defconfig
arm ixp4xx_defconfig
mips vocore2_defconfig
powerpc mpc5200_defconfig
powerpc motionpro_defconfig
nios2 alldefconfig
mips ip27_defconfig
xtensa common_defconfig
nios2 3c120_defconfig
mips ar7_defconfig
mips maltaup_defconfig
arm stm32_defconfig
mips ath25_defconfig
powerpc64 alldefconfig
s390 zfcpdump_defconfig
microblaze defconfig
powerpc cm5200_defconfig
sh sh7770_generic_defconfig
mips maltaup_xpa_defconfig
mips malta_kvm_defconfig
arm lart_defconfig
arm spitz_defconfig
sh sh7785lcr_32bit_defconfig
arm vf610m4_defconfig
xtensa alldefconfig
arm collie_defconfig
sh sh7763rdp_defconfig
powerpc sbc8548_defconfig
arm exynos_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
s390 defconfig
sparc allyesconfig
sparc defconfig
i386 tinyconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allnoconfig
x86_64 randconfig-a006-20210317
x86_64 randconfig-a001-20210317
x86_64 randconfig-a005-20210317
x86_64 randconfig-a004-20210317
x86_64 randconfig-a003-20210317
x86_64 randconfig-a002-20210317
i386 randconfig-a001-20210317
i386 randconfig-a005-20210317
i386 randconfig-a002-20210317
i386 randconfig-a003-20210317
i386 randconfig-a004-20210317
i386 randconfig-a006-20210317
i386 randconfig-a013-20210317
i386 randconfig-a016-20210317
i386 randconfig-a011-20210317
i386 randconfig-a012-20210317
i386 randconfig-a015-20210317
i386 randconfig-a014-20210317
riscv nommu_k210_defconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a011-20210317
x86_64 randconfig-a016-20210317
x86_64 randconfig-a013-20210317
x86_64 randconfig-a014-20210317
x86_64 randconfig-a015-20210317
x86_64 randconfig-a012-20210317
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:next-test] BUILD SUCCESS 11aa533b82d5785e0475fd1e2f47db1ccf8f5be4
From: kernel test robot @ 2021-03-18 1:08 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
branch HEAD: 11aa533b82d5785e0475fd1e2f47db1ccf8f5be4 powerpc/mm: Remove unneeded #ifdef CONFIG_PPC_MEM_KEYS
elapsed time: 1276m
configs tested: 135
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
x86_64 allyesconfig
riscv allmodconfig
i386 allyesconfig
riscv allyesconfig
powerpc ge_imp3a_defconfig
powerpc skiroot_defconfig
powerpc ksi8560_defconfig
sh se7721_defconfig
h8300 edosk2674_defconfig
powerpc redwood_defconfig
mips qi_lb60_defconfig
powerpc taishan_defconfig
mips gpr_defconfig
arm bcm2835_defconfig
sh rsk7269_defconfig
sh se7751_defconfig
parisc generic-64bit_defconfig
powerpc mpc85xx_cds_defconfig
arm alldefconfig
powerpc ppc40x_defconfig
sh edosk7705_defconfig
mips rt305x_defconfig
arm cm_x300_defconfig
sh defconfig
powerpc mpc834x_itx_defconfig
mips loongson1c_defconfig
sh sh7785lcr_defconfig
sh sdk7786_defconfig
mips mpc30x_defconfig
powerpc mpc836x_mds_defconfig
arm moxart_defconfig
powerpc wii_defconfig
mips ip32_defconfig
ia64 bigsur_defconfig
arm multi_v7_defconfig
powerpc pcm030_defconfig
arm eseries_pxa_defconfig
powerpc lite5200b_defconfig
powerpc ppa8548_defconfig
powerpc sam440ep_defconfig
powerpc mpc8560_ads_defconfig
arm ixp4xx_defconfig
mips vocore2_defconfig
powerpc mpc5200_defconfig
powerpc motionpro_defconfig
nios2 alldefconfig
mips ip27_defconfig
arm palmz72_defconfig
nios2 3c120_defconfig
mips ar7_defconfig
mips maltaup_defconfig
arm stm32_defconfig
mips ath25_defconfig
powerpc64 alldefconfig
powerpc adder875_defconfig
powerpc cm5200_defconfig
powerpc storcenter_defconfig
sh sh7770_generic_defconfig
mips maltaup_xpa_defconfig
arc haps_hs_defconfig
arm am200epdkit_defconfig
arm vf610m4_defconfig
xtensa alldefconfig
arm collie_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
sparc allyesconfig
sparc defconfig
i386 tinyconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20210317
i386 randconfig-a005-20210317
i386 randconfig-a002-20210317
i386 randconfig-a003-20210317
i386 randconfig-a004-20210317
i386 randconfig-a006-20210317
x86_64 randconfig-a006-20210317
x86_64 randconfig-a001-20210317
x86_64 randconfig-a005-20210317
x86_64 randconfig-a004-20210317
x86_64 randconfig-a003-20210317
x86_64 randconfig-a002-20210317
i386 randconfig-a013-20210317
i386 randconfig-a016-20210317
i386 randconfig-a011-20210317
i386 randconfig-a012-20210317
i386 randconfig-a015-20210317
i386 randconfig-a014-20210317
riscv nommu_k210_defconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a011-20210317
x86_64 randconfig-a016-20210317
x86_64 randconfig-a013-20210317
x86_64 randconfig-a014-20210317
x86_64 randconfig-a015-20210317
x86_64 randconfig-a012-20210317
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:merge] BUILD SUCCESS 87d76f542a24ecfa797e9bd3bb56c0f19aabff57
From: kernel test robot @ 2021-03-18 1:08 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
branch HEAD: 87d76f542a24ecfa797e9bd3bb56c0f19aabff57 Automatic merge of 'fixes' into merge (2021-03-17 14:13)
elapsed time: 1277m
configs tested: 174
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
x86_64 allyesconfig
riscv allmodconfig
i386 allyesconfig
riscv allyesconfig
powerpc ge_imp3a_defconfig
powerpc skiroot_defconfig
powerpc ksi8560_defconfig
sh se7721_defconfig
h8300 edosk2674_defconfig
powerpc redwood_defconfig
mips qi_lb60_defconfig
powerpc taishan_defconfig
mips gpr_defconfig
powerpc xes_mpc85xx_defconfig
arm mmp2_defconfig
arm palmz72_defconfig
arm iop32x_defconfig
arm neponset_defconfig
powerpc kilauea_defconfig
arm bcm2835_defconfig
sh rsk7269_defconfig
sh se7751_defconfig
parisc generic-64bit_defconfig
powerpc mpc85xx_cds_defconfig
arm alldefconfig
sh landisk_defconfig
powerpc mvme5100_defconfig
m68k m5249evb_defconfig
sh titan_defconfig
powerpc ppc40x_defconfig
sh edosk7705_defconfig
powerpc ppc64_defconfig
powerpc canyonlands_defconfig
arm spear13xx_defconfig
sh sh7785lcr_32bit_defconfig
powerpc mpc832x_mds_defconfig
arm ep93xx_defconfig
mips cobalt_defconfig
sh secureedge5410_defconfig
powerpc asp8347_defconfig
arm tegra_defconfig
powerpc pmac32_defconfig
mips loongson1c_defconfig
sh sh7785lcr_defconfig
mips ip28_defconfig
powerpc adder875_defconfig
arm assabet_defconfig
arc alldefconfig
arm multi_v4t_defconfig
sh se7619_defconfig
sh sdk7786_defconfig
mips mpc30x_defconfig
powerpc mpc836x_mds_defconfig
arm clps711x_defconfig
powerpc arches_defconfig
sparc sparc32_defconfig
powerpc stx_gp3_defconfig
powerpc pcm030_defconfig
arm eseries_pxa_defconfig
powerpc lite5200b_defconfig
powerpc ppa8548_defconfig
arm lpc18xx_defconfig
arm lpc32xx_defconfig
sh lboxre2_defconfig
powerpc tqm8541_defconfig
alpha alldefconfig
arm lubbock_defconfig
ia64 zx1_defconfig
powerpc akebono_defconfig
mips cavium_octeon_defconfig
xtensa generic_kc705_defconfig
parisc alldefconfig
arm cerfcube_defconfig
arm collie_defconfig
sh espt_defconfig
xtensa defconfig
arc nsimosci_defconfig
powerpc sam440ep_defconfig
powerpc mpc8560_ads_defconfig
arm ixp4xx_defconfig
mips vocore2_defconfig
powerpc mpc5200_defconfig
powerpc motionpro_defconfig
nios2 alldefconfig
mips ip27_defconfig
xtensa common_defconfig
m68k defconfig
nios2 3c120_defconfig
mips ar7_defconfig
mips maltaup_defconfig
arm stm32_defconfig
mips ath25_defconfig
powerpc64 alldefconfig
s390 zfcpdump_defconfig
arm am200epdkit_defconfig
powerpc wii_defconfig
microblaze defconfig
powerpc cm5200_defconfig
powerpc storcenter_defconfig
sh sh7770_generic_defconfig
mips maltaup_xpa_defconfig
arc haps_hs_defconfig
arm vf610m4_defconfig
xtensa alldefconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
sparc allyesconfig
sparc defconfig
i386 tinyconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a006-20210317
x86_64 randconfig-a001-20210317
x86_64 randconfig-a005-20210317
x86_64 randconfig-a004-20210317
x86_64 randconfig-a003-20210317
x86_64 randconfig-a002-20210317
i386 randconfig-a001-20210317
i386 randconfig-a005-20210317
i386 randconfig-a002-20210317
i386 randconfig-a003-20210317
i386 randconfig-a004-20210317
i386 randconfig-a006-20210317
i386 randconfig-a013-20210317
i386 randconfig-a016-20210317
i386 randconfig-a011-20210317
i386 randconfig-a012-20210317
i386 randconfig-a015-20210317
i386 randconfig-a014-20210317
riscv nommu_k210_defconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a011-20210317
x86_64 randconfig-a016-20210317
x86_64 randconfig-a013-20210317
x86_64 randconfig-a014-20210317
x86_64 randconfig-a015-20210317
x86_64 randconfig-a012-20210317
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [PATCH 1/2] audit: add support for the openat2 syscall
From: Richard Guy Briggs @ 2021-03-18 1:47 UTC (permalink / raw)
To: Linux-Audit Mailing List, LKML
Cc: linux-s390, linux-ia64, Paul Moore, linux-parisc,
Richard Guy Briggs, x86, Eric Paris, linux-fsdevel,
Alexander Viro, linux-alpha, sparclinux, Eric Paris, Steve Grubb,
linuxppc-dev
In-Reply-To: <cover.1616031035.git.rgb@redhat.com>
The openat2(2) syscall was added in kernel v5.6 with commit fddb5d430ad9
("open: introduce openat2(2) syscall")
Add the openat2(2) syscall to the audit syscall classifier.
See the github issue
https://github.com/linux-audit/audit-kernel/issues/67
Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
---
arch/alpha/kernel/audit.c | 2 ++
arch/ia64/kernel/audit.c | 2 ++
arch/parisc/kernel/audit.c | 2 ++
arch/parisc/kernel/compat_audit.c | 2 ++
arch/powerpc/kernel/audit.c | 2 ++
arch/powerpc/kernel/compat_audit.c | 2 ++
arch/s390/kernel/audit.c | 2 ++
arch/s390/kernel/compat_audit.c | 2 ++
arch/sparc/kernel/audit.c | 2 ++
arch/sparc/kernel/compat_audit.c | 2 ++
arch/x86/ia32/audit.c | 2 ++
arch/x86/kernel/audit_64.c | 2 ++
kernel/auditsc.c | 3 +++
lib/audit.c | 4 ++++
lib/compat_audit.c | 4 ++++
15 files changed, 35 insertions(+)
diff --git a/arch/alpha/kernel/audit.c b/arch/alpha/kernel/audit.c
index 96a9d18ff4c4..06a911b685d1 100644
--- a/arch/alpha/kernel/audit.c
+++ b/arch/alpha/kernel/audit.c
@@ -42,6 +42,8 @@ int audit_classify_syscall(int abi, unsigned syscall)
return 3;
case __NR_execve:
return 5;
+ case __NR_openat2:
+ return 6;
default:
return 0;
}
diff --git a/arch/ia64/kernel/audit.c b/arch/ia64/kernel/audit.c
index 5192ca899fe6..5eaa888c8fd3 100644
--- a/arch/ia64/kernel/audit.c
+++ b/arch/ia64/kernel/audit.c
@@ -43,6 +43,8 @@ int audit_classify_syscall(int abi, unsigned syscall)
return 3;
case __NR_execve:
return 5;
+ case __NR_openat2:
+ return 6;
default:
return 0;
}
diff --git a/arch/parisc/kernel/audit.c b/arch/parisc/kernel/audit.c
index 9eb47b2225d2..fc721a7727ba 100644
--- a/arch/parisc/kernel/audit.c
+++ b/arch/parisc/kernel/audit.c
@@ -52,6 +52,8 @@ int audit_classify_syscall(int abi, unsigned syscall)
return 3;
case __NR_execve:
return 5;
+ case __NR_openat2:
+ return 6;
default:
return 0;
}
diff --git a/arch/parisc/kernel/compat_audit.c b/arch/parisc/kernel/compat_audit.c
index 20c39c9d86a9..fc6d35918c44 100644
--- a/arch/parisc/kernel/compat_audit.c
+++ b/arch/parisc/kernel/compat_audit.c
@@ -35,6 +35,8 @@ int parisc32_classify_syscall(unsigned syscall)
return 3;
case __NR_execve:
return 5;
+ case __NR_openat2:
+ return 6;
default:
return 1;
}
diff --git a/arch/powerpc/kernel/audit.c b/arch/powerpc/kernel/audit.c
index a2dddd7f3d09..8f32700b0baa 100644
--- a/arch/powerpc/kernel/audit.c
+++ b/arch/powerpc/kernel/audit.c
@@ -54,6 +54,8 @@ int audit_classify_syscall(int abi, unsigned syscall)
return 4;
case __NR_execve:
return 5;
+ case __NR_openat2:
+ return 6;
default:
return 0;
}
diff --git a/arch/powerpc/kernel/compat_audit.c b/arch/powerpc/kernel/compat_audit.c
index 55c6ccda0a85..ebe45534b1c9 100644
--- a/arch/powerpc/kernel/compat_audit.c
+++ b/arch/powerpc/kernel/compat_audit.c
@@ -38,6 +38,8 @@ int ppc32_classify_syscall(unsigned syscall)
return 4;
case __NR_execve:
return 5;
+ case __NR_openat2:
+ return 6;
default:
return 1;
}
diff --git a/arch/s390/kernel/audit.c b/arch/s390/kernel/audit.c
index d395c6c9944c..d964cb94cfaf 100644
--- a/arch/s390/kernel/audit.c
+++ b/arch/s390/kernel/audit.c
@@ -54,6 +54,8 @@ int audit_classify_syscall(int abi, unsigned syscall)
return 4;
case __NR_execve:
return 5;
+ case __NR_openat2:
+ return 6;
default:
return 0;
}
diff --git a/arch/s390/kernel/compat_audit.c b/arch/s390/kernel/compat_audit.c
index 444fb1f66944..f7b32933ce0e 100644
--- a/arch/s390/kernel/compat_audit.c
+++ b/arch/s390/kernel/compat_audit.c
@@ -39,6 +39,8 @@ int s390_classify_syscall(unsigned syscall)
return 4;
case __NR_execve:
return 5;
+ case __NR_openat2:
+ return 6;
default:
return 1;
}
diff --git a/arch/sparc/kernel/audit.c b/arch/sparc/kernel/audit.c
index a6e91bf34d48..b6dcca9c6520 100644
--- a/arch/sparc/kernel/audit.c
+++ b/arch/sparc/kernel/audit.c
@@ -55,6 +55,8 @@ int audit_classify_syscall(int abi, unsigned int syscall)
return 4;
case __NR_execve:
return 5;
+ case __NR_openat2:
+ return 6;
default:
return 0;
}
diff --git a/arch/sparc/kernel/compat_audit.c b/arch/sparc/kernel/compat_audit.c
index 10eeb4f15b20..d2652a1083ad 100644
--- a/arch/sparc/kernel/compat_audit.c
+++ b/arch/sparc/kernel/compat_audit.c
@@ -39,6 +39,8 @@ int sparc32_classify_syscall(unsigned int syscall)
return 4;
case __NR_execve:
return 5;
+ case __NR_openat2:
+ return 6;
default:
return 1;
}
diff --git a/arch/x86/ia32/audit.c b/arch/x86/ia32/audit.c
index 6efe6cb3768a..57a02ade5503 100644
--- a/arch/x86/ia32/audit.c
+++ b/arch/x86/ia32/audit.c
@@ -39,6 +39,8 @@ int ia32_classify_syscall(unsigned syscall)
case __NR_execve:
case __NR_execveat:
return 5;
+ case __NR_openat2:
+ return 6;
default:
return 1;
}
diff --git a/arch/x86/kernel/audit_64.c b/arch/x86/kernel/audit_64.c
index 83d9cad4e68b..39de1e021258 100644
--- a/arch/x86/kernel/audit_64.c
+++ b/arch/x86/kernel/audit_64.c
@@ -53,6 +53,8 @@ int audit_classify_syscall(int abi, unsigned syscall)
case __NR_execve:
case __NR_execveat:
return 5;
+ case __NR_openat2:
+ return 6;
default:
return 0;
}
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 8bb9ac84d2fb..f5616e70d129 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -76,6 +76,7 @@
#include <linux/fsnotify_backend.h>
#include <uapi/linux/limits.h>
#include <uapi/linux/netfilter/nf_tables.h>
+#include <uapi/linux/openat2.h>
#include "audit.h"
@@ -195,6 +196,8 @@ static int audit_match_perm(struct audit_context *ctx, int mask)
return ((mask & AUDIT_PERM_WRITE) && ctx->argv[0] == SYS_BIND);
case 5: /* execve */
return mask & AUDIT_PERM_EXEC;
+ case 6: /* openat2 */
+ return mask & ACC_MODE((u32)((struct open_how *)ctx->argv[2])->flags);
default:
return 0;
}
diff --git a/lib/audit.c b/lib/audit.c
index 5004bff928a7..8f030b9a2d10 100644
--- a/lib/audit.c
+++ b/lib/audit.c
@@ -60,6 +60,10 @@ int audit_classify_syscall(int abi, unsigned syscall)
#endif
case __NR_execve:
return 5;
+#ifdef __NR_openat2
+ case __NR_openat2:
+ return 6;
+#endif
default:
return 0;
}
diff --git a/lib/compat_audit.c b/lib/compat_audit.c
index 77eabad69b4a..8aff0d0d9ba0 100644
--- a/lib/compat_audit.c
+++ b/lib/compat_audit.c
@@ -45,6 +45,10 @@ int audit_classify_compat_syscall(int abi, unsigned syscall)
#endif
case __NR_execve:
return 5;
+#ifdef __NR_openat2
+ case __NR_openat2:
+ return 6;
+#endif
default:
return 1;
}
--
2.27.0
^ permalink raw reply related
* Re: [PATCH] powerpc/numa: Fix topology_physical_package_id() on pSeries
From: Michael Ellerman @ 2021-03-18 2:26 UTC (permalink / raw)
To: Cédric Le Goater, linuxppc-dev
Cc: Nathan Lynch, Srikar Dronamraju, Daniel Henrique Barboza,
Greg Kurz, Vasant Hegde, Cédric Le Goater, David Gibson
In-Reply-To: <20210312143154.3181109-1-clg@kaod.org>
Cédric Le Goater <clg@kaod.org> writes:
> Initial commit 15863ff3b8da ("powerpc: Make chip-id information
> available to userspace") introduce a cpu_to_chip_id() routine for the
> PowerNV platform using the "ibm,chip-id" property to query the chip id
> of a CPU. But PAPR does not specify such a property and the node id
> query is broken.
>
> Use cpu_to_node() instead which guarantees to have a correct value on
> all platforms, PowerNV an pSeries.
I'm not convinced this is correct on any platforms :)
The node (nid) is just a number made up by Linux, so it's not a
"physical package id".
It might correspond to a "physical package" (whatever that means), on
existing skiboot, but it's not guaranteed.
The PAPR text around associativity and so on is incredibly dense, but I
think one thing that is clear is that firmware is allowed to present to
us whatever boundaries it thinks are most meaningful.
ie. if two things on one "physical package" have a meaningful distance
between them, then they might be presented to us as two nodes.
Having said that, if you look at the documentation in the kernel we
have:
physical_package_id: physical package id of cpu#. Typically
corresponds to a physical socket number, but the actual value
is architecture and platform dependent.
Which is nicely vague.
But then:
core_siblings: internal kernel map of cpu#'s hardware threads
within the same physical_package_id.
Which is not true for us already on bare metal. And is just wrong on
modern CPUs where there's multiple non-siblings in a single
core/chip/package.
So a patch to update the documentation would be good :)
As far as what we should do in our topology code, I think we should use
the chip-id when we have it - ie. on bare metal.
It may not be exactly correct, but it's at least not filtered through
any indirection about NUMA-ness, ie. the associativity properties.
Also we've been using it for several years and I don't think we should
risk breaking anything by changing the value now.
As far as pseries, I'm still a bit dubious, but maybe using nid is
better than providing nothing, even if it is a lie.
cheers
^ permalink raw reply
* Re: [PATCH -next] powerpc: kernel/time.c - cleanup warnings
From: heying (H) @ 2021-03-18 2:28 UTC (permalink / raw)
To: Christophe Leroy, mpe, benh, paulus, npiggin, msuchanek, peterz,
geert+renesas, kernelfans, frederic
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <3f4d196b-0a8e-d4c9-cabe-591f5916a2b9@csgroup.eu>
在 2021/3/17 19:16, Christophe Leroy 写道:
>
>
> Le 17/03/2021 à 11:34, He Ying a écrit :
>> We found these warnings in arch/powerpc/kernel/time.c as follows:
>> warning: symbol 'decrementer_max' was not declared. Should it be static?
>> warning: symbol 'rtc_lock' was not declared. Should it be static?
>> warning: symbol 'dtl_consumer' was not declared. Should it be static?
>>
>> Declare 'decrementer_max' in arch/powerpc/include/asm/time.h. And
>> include
>> proper header in which 'rtc_lock' is declared. Move 'dtl_consumer'
>> definition behind "include <asm/dtl.h>" because 'dtl_consumer' is
>> declared
>> there.
>>
>> Reported-by: Hulk Robot <hulkci@huawei.com>
>> Signed-off-by: He Ying <heying24@huawei.com>
>> ---
>> arch/powerpc/include/asm/time.h | 1 +
>> arch/powerpc/kernel/time.c | 7 +++----
>> 2 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/time.h
>> b/arch/powerpc/include/asm/time.h
>> index 8dd3cdb25338..2cd2b50bedda 100644
>> --- a/arch/powerpc/include/asm/time.h
>> +++ b/arch/powerpc/include/asm/time.h
>> @@ -22,6 +22,7 @@ extern unsigned long tb_ticks_per_jiffy;
>> extern unsigned long tb_ticks_per_usec;
>> extern unsigned long tb_ticks_per_sec;
>> extern struct clock_event_device decrementer_clockevent;
>> +extern u64 decrementer_max;
>> extern void generic_calibrate_decr(void);
>> diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
>> index b67d93a609a2..409967713ca6 100644
>> --- a/arch/powerpc/kernel/time.c
>> +++ b/arch/powerpc/kernel/time.c
>> @@ -55,6 +55,7 @@
>> #include <linux/sched/cputime.h>
>> #include <linux/sched/clock.h>
>> #include <linux/processor.h>
>> +#include <linux/mc146818rtc.h>
>
> I don't think that's the good place. It has no link to powerpc, it is
> only by chance that it has the same name.
>
> As rtc_lock is defined in powerpc time.c, I think you should declare
> it in powerpc asm/time.h
My first thought was the same as yours. I tried to add declaration in
powerpc asm/time.h, but got a compiling error:
drivers/rtc/rtc-vr41xx.c:75:24: error: static declaration of ‘rtc_lock’
follows non-static declaration
static DEFINE_SPINLOCK(rtc_lock);
In file included from ./arch/powerpc/include/asm/delay.h:7:0,
from ./arch/powerpc/include/asm/io.h:33,
from ./include/linux/io.h:13,
from drivers/rtc/rtc-vr41xx.c:11:
./arch/powerpc/include/asm/time.h:25:19: note: previous declaration of
‘rtc_lock’ was here
extern spinlock_t rtc_lock;
There's a conflict. Perhaps I can rename it in drivers/rtc/rtc-vr41xx.c.
But I find an existing declaration in linux/mc146818rtc.h and there's
only one definition for 'rtc_lock' in powerpc.
There's some includes of mc146818rtc.h in powperc. I wonder they point
to the same thing. But I'm not very sure
because the header's name looks a bit strange.
>
>
>> #include <asm/trace.h>
>> #include <asm/interrupt.h>
>> @@ -150,10 +151,6 @@ bool tb_invalid;
>> u64 __cputime_usec_factor;
>> EXPORT_SYMBOL(__cputime_usec_factor);
>> -#ifdef CONFIG_PPC_SPLPAR
>> -void (*dtl_consumer)(struct dtl_entry *, u64);
>> -#endif
>> -
>> static void calc_cputime_factors(void)
>> {
>> struct div_result res;
>> @@ -179,6 +176,8 @@ static inline unsigned long read_spurr(unsigned
>> long tb)
>> #include <asm/dtl.h>
>> +void (*dtl_consumer)(struct dtl_entry *, u64);
>> +
>> /*
>> * Scan the dispatch trace log and count up the stolen time.
>> * Should be called with interrupts disabled.
>>
> .
^ permalink raw reply
* Re: [PATCH] powerpc: arch/powerpc/kernel/setup_64.c - cleanup warnings
From: heying (H) @ 2021-03-18 2:37 UTC (permalink / raw)
To: Michael Ellerman, Daniel Axtens, benh, paulus, npiggin, akpm,
aneesh.kumar, rppt, ardb, clg, christophe.leroy
Cc: johnny.chenyi, linuxppc-dev, linux-kernel
In-Reply-To: <877dm6ouw5.fsf@mpe.ellerman.id.au>
在 2021/3/17 19:57, Michael Ellerman 写道:
> Daniel Axtens <dja@axtens.net> writes:
>> "heying (H)" <heying24@huawei.com> writes:
>>
>>> Thank you for your reply.
>>>
>>> 在 2021/3/17 11:04, Daniel Axtens 写道:
>>>> Hi He Ying,
>>>>
>>>> Thank you for this patch.
>>>>
>>>> I'm not sure what the precise rules for Fixes are, but I wonder if this
>>>> should have:
>>>>
>>>> Fixes: 9a32a7e78bd0 ("powerpc/64s: flush L1D after user accesses")
>>>> Fixes: f79643787e0a ("powerpc/64s: flush L1D on kernel entry")
>>> Is that necessary for warning cleanups? I thought 'Fixes' tags are
>>> needed only for
>>>
>>> bugfix patches. Can someone tell me whether I am right?
>> Yeah, I'm not sure either. Hopefully mpe will let us know.
> It's not necessary to add a Fixes tag for a patch like this, but you can
> add one if you think it's important that the fix gets backported.
>
> I don't think the cleanups in this case are that important, so I
> wouldn't bother with a Fixes tag.
Okay. That's a good explanation to me. Thanks.
^ permalink raw reply
* Re: [PATCH v9 3/8] powerpc/kprobes: Mark newly allocated probes as RO
From: Jordan Niethe @ 2021-03-18 2:42 UTC (permalink / raw)
To: Christophe Leroy
Cc: Christophe Leroy, ajd, Nicholas Piggin, naveen.n.rao,
linuxppc-dev, Daniel Axtens
In-Reply-To: <87553048-5f1f-0704-2256-d2c85b8e43c6@csgroup.eu>
On Wed, Mar 17, 2021 at 5:12 PM Christophe Leroy
<christophe.leroy@csgroup.eu> wrote:
>
>
>
> Le 16/03/2021 à 04:17, Jordan Niethe a écrit :
> > From: Russell Currey <ruscur@russell.cc>
> >
> > With CONFIG_STRICT_KERNEL_RWX=y and CONFIG_KPROBES=y, there will be one
> > W+X page at boot by default. This can be tested with
> > CONFIG_PPC_PTDUMP=y and CONFIG_PPC_DEBUG_WX=y set, and checking the
> > kernel log during boot.
> >
> > Add an arch specific insn page allocator which returns RO pages if
> > STRICT_KERNEL_RWX is enabled. This page is only written to with
> > patch_instruction() which is able to write RO pages.
> >
>
> Did you investigate BPF ? The problematic looks more or less similar to kprobe:
>
> bpf_jit_compile() in arch/powerpc/net/bpf_jit_comp.c calls module_alloc(), which provides it with
> PAGE_KERNEL_TEXT memory, ie RWX. That function is only used on PPC32 which still has Classic BPF,
> and this is about to go away with future series
> https://patchwork.ozlabs.org/project/linuxppc-dev/cover/cover.1608112796.git.christophe.leroy@csgroup.eu/
>
> PPC64 has Extended BPF instead, and PPC32 will it the future too.
> bpf_int_jit_compile() in arch/powerpc/net/bpf_jit_comp64.c calls bpf_jit_binary_alloc() which uses
> bpf_jit_alloc_exec().
>
> bpf_jit_alloc_exec() is a weak function that should be redefined for powerpc I think, more or less
> like alloc_insn_page() for kprobes.
Thanks, that is a good point. I will handle bpf with the next revision.
>
> Christophe
^ permalink raw reply
* Re: Errant readings on LM81 with T2080 SoC
From: Chris Packham @ 2021-03-18 3:46 UTC (permalink / raw)
To: Guenter Roeck, Wolfram Sang
Cc: linux-hwmon@vger.kernel.org, jdelvare@suse.com,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
linux-i2c@vger.kernel.org
In-Reply-To: <725c5e51-65df-e17d-e2da-0982efacf2d2@roeck-us.net>
On 12/03/21 10:34 am, Guenter Roeck wrote:
> On 3/11/21 1:17 PM, Chris Packham wrote:
>> On 11/03/21 9:18 pm, Wolfram Sang wrote:
>>>> Bummer. What is really weird is that you see clock stretching under
>>>> CPU load. Normally clock stretching is triggered by the device, not
>>>> by the host.
>>> One example: Some hosts need an interrupt per byte to know if they
>>> should send ACK or NACK. If that interrupt is delayed, they stretch the
>>> clock.
>>>
>> It feels like something like that is happening. Looking at the T2080
>> Reference manual there is an interesting timing diagram (Figure 14-2 if
>> someone feels like looking it up). It shows SCL low between the ACK for
>> the address and the data byte. I think if we're delayed in sending the
>> next byte we could violate Ttimeout or Tlow:mext from the SMBUS spec.
>>
> I think that really leaves you only two options that I can see:
> Rework the driver to handle critical actions (such as setting TXAK,
> and everything else that might result in clock stretching) in the
> interrupt handler, or rework the driver to handle everything in
> a high priority kernel thread.
I've made some reasonable progress on making i2c-mpc more interrupt
driven. Assuming it works out for my use-case is there an opinion on
making interrupt support mandatory? Looking at all the in-tree dts files
that use one of the compatible strings from i2c-mpc.c they all have
interrupt properties so in theory nothing is using the polling mode. But
there may be some out-of-tree boards or boards using an old dtb that
would be affected?
^ permalink raw reply
* [PATCH] powerpc/book3s64/kuap: Move Kconfig varriables to BOOK3S_64
From: Aneesh Kumar K.V @ 2021-03-18 3:48 UTC (permalink / raw)
To: linuxppc-dev, mpe; +Cc: Aneesh Kumar K.V
With below two commits:
commit c91435d95c49 ("powerpc/book3s64/hash/kuep: Enable KUEP on hash")
commit b2ff33a10c8b ("powerpc/book3s64/hash/kuap: Enable kuap on hash")
the kernel now supports kuap/kuep with hash translation. Hence select the
Kconfig even when radix is disabled.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
arch/powerpc/platforms/Kconfig.cputype | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index 2e666e569fdf..8e585d8e77ce 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -103,6 +103,8 @@ config PPC_BOOK3S_64
select ARCH_SUPPORTS_NUMA_BALANCING
select IRQ_WORK
select PPC_MM_SLICES
+ select PPC_HAVE_KUEP
+ select PPC_HAVE_KUAP
config PPC_BOOK3E_64
bool "Embedded processors"
@@ -365,8 +367,6 @@ config PPC_RADIX_MMU
bool "Radix MMU Support"
depends on PPC_BOOK3S_64
select ARCH_HAS_GIGANTIC_PAGE
- select PPC_HAVE_KUEP
- select PPC_HAVE_KUAP
default y
help
Enable support for the Power ISA 3.0 Radix style MMU. Currently this
--
2.30.2
^ permalink raw reply related
* [PATCH] powerpc/mm: Revert "powerpc/mm: Remove DEBUG_VM_PGTABLE support on powerpc"
From: Aneesh Kumar K.V @ 2021-03-18 3:48 UTC (permalink / raw)
To: linuxppc-dev, mpe; +Cc: Aneesh Kumar K.V
This reverts commit 675bceb097e6 ("powerpc/mm: Remove DEBUG_VM_PGTABLE support on powerpc")
All the related issues are fixed by the series
https://lore.kernel.org/linux-mm/20200902114222.181353-1-aneesh.kumar@linux.ibm.com
Hence enable it back
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
Documentation/features/debug/debug-vm-pgtable/arch-support.txt | 2 +-
arch/powerpc/Kconfig | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/features/debug/debug-vm-pgtable/arch-support.txt b/Documentation/features/debug/debug-vm-pgtable/arch-support.txt
index 7aff505af706..fa83403b4aec 100644
--- a/Documentation/features/debug/debug-vm-pgtable/arch-support.txt
+++ b/Documentation/features/debug/debug-vm-pgtable/arch-support.txt
@@ -21,7 +21,7 @@
| nios2: | TODO |
| openrisc: | TODO |
| parisc: | TODO |
- | powerpc: | TODO |
+ | powerpc: | ok |
| riscv: | ok |
| s390: | ok |
| sh: | TODO |
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 386ae12d8523..982c87d5c051 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -119,6 +119,7 @@ config PPC
#
select ARCH_32BIT_OFF_T if PPC32
select ARCH_HAS_DEBUG_VIRTUAL
+ select ARCH_HAS_DEBUG_VM_PGTABLE
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_FORTIFY_SOURCE
--
2.30.2
^ permalink raw reply related
* Re: Errant readings on LM81 with T2080 SoC
From: Guenter Roeck @ 2021-03-18 4:02 UTC (permalink / raw)
To: Chris Packham, Wolfram Sang
Cc: linux-hwmon@vger.kernel.org, jdelvare@suse.com,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
linux-i2c@vger.kernel.org
In-Reply-To: <9c912424-2cc9-8753-1352-1a5c27722cd2@alliedtelesis.co.nz>
On 3/17/21 8:46 PM, Chris Packham wrote:
>
> On 12/03/21 10:34 am, Guenter Roeck wrote:
>> On 3/11/21 1:17 PM, Chris Packham wrote:
>>> On 11/03/21 9:18 pm, Wolfram Sang wrote:
>>>>> Bummer. What is really weird is that you see clock stretching under
>>>>> CPU load. Normally clock stretching is triggered by the device, not
>>>>> by the host.
>>>> One example: Some hosts need an interrupt per byte to know if they
>>>> should send ACK or NACK. If that interrupt is delayed, they stretch the
>>>> clock.
>>>>
>>> It feels like something like that is happening. Looking at the T2080
>>> Reference manual there is an interesting timing diagram (Figure 14-2 if
>>> someone feels like looking it up). It shows SCL low between the ACK for
>>> the address and the data byte. I think if we're delayed in sending the
>>> next byte we could violate Ttimeout or Tlow:mext from the SMBUS spec.
>>>
>> I think that really leaves you only two options that I can see:
>> Rework the driver to handle critical actions (such as setting TXAK,
>> and everything else that might result in clock stretching) in the
>> interrupt handler, or rework the driver to handle everything in
>> a high priority kernel thread.
> I've made some reasonable progress on making i2c-mpc more interrupt
> driven. Assuming it works out for my use-case is there an opinion on
> making interrupt support mandatory? Looking at all the in-tree dts files
> that use one of the compatible strings from i2c-mpc.c they all have
> interrupt properties so in theory nothing is using the polling mode. But
> there may be some out-of-tree boards or boards using an old dtb that
> would be affected?
>
The polling code is from pre-git times. Like 2005 and earlier.
I'd say it is about time to get rid of it. Any out-of-tree users
had more than 15 years to upstream their code, after all.
Guenter
^ permalink raw reply
* [PATCH 01/10] alpha: use libata instead of the legacy ide driver
From: Christoph Hellwig @ 2021-03-18 4:56 UTC (permalink / raw)
To: David S. Miller, Jens Axboe, Geert Uytterhoeven
Cc: Thomas Bogendoerfer, linux-doc, Russell King, linux-kernel,
linux-ide, linux-m68k, Ivan Kokshaysky, linux-alpha, Matt Turner,
linux-mips, linuxppc-dev, linux-arm-kernel, Richard Henderson
In-Reply-To: <20210318045706.200458-1-hch@lst.de>
Switch the alpha defconfig from the legacy ide driver to libata.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/alpha/configs/defconfig | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/arch/alpha/configs/defconfig b/arch/alpha/configs/defconfig
index 724c4075df408e..dd2dd9f0861f18 100644
--- a/arch/alpha/configs/defconfig
+++ b/arch/alpha/configs/defconfig
@@ -25,19 +25,18 @@ CONFIG_PNP=y
CONFIG_ISAPNP=y
CONFIG_BLK_DEV_FD=y
CONFIG_BLK_DEV_LOOP=m
-CONFIG_IDE=y
-CONFIG_BLK_DEV_IDECD=y
-CONFIG_IDE_GENERIC=y
-CONFIG_BLK_DEV_GENERIC=y
-CONFIG_BLK_DEV_ALI15X3=y
-CONFIG_BLK_DEV_CMD64X=y
-CONFIG_BLK_DEV_CY82C693=y
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_BLK_DEV_SR=y
CONFIG_SCSI_AIC7XXX=m
CONFIG_AIC7XXX_CMDS_PER_DEVICE=253
# CONFIG_AIC7XXX_DEBUG_ENABLE is not set
+CONFIG_ATA=y
+# CONFIG_SATA_PMP is not set
+CONFIG_PATA_ALI=y
+CONFIG_PATA_CMD64X=y
+CONFIG_PATA_CYPRESS=y
+CONFIG_ATA_GENERIC=y
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
CONFIG_NET_ETHERNET=y
--
2.30.1
^ permalink raw reply related
* remove the legacy ide driver
From: Christoph Hellwig @ 2021-03-18 4:56 UTC (permalink / raw)
To: David S. Miller, Jens Axboe, Geert Uytterhoeven
Cc: Thomas Bogendoerfer, linux-doc, Russell King, linux-kernel,
linux-ide, linux-m68k, Ivan Kokshaysky, linux-alpha, Matt Turner,
linux-mips, linuxppc-dev, linux-arm-kernel, Richard Henderson
Hi all,
we've been trying to get rid of the legacy ide driver for a while now,
and finally scheduled a removal for 2021, which is three month old now.
In general distros and most defconfigs have switched to libata long ago,
but there are a few exceptions. This series first switches over all
remaining defconfigs to use libata and then removes the legacy ide
driver.
libata mostly covers all hardware supported by the legacy ide driver.
There are three mips drivers that are not supported, but the linux-mips
list could not identify any users of those. There also are two m68k
drivers that do not have libata equivalents, which might or might not
have users, so we'll need some input and possibly help from the m68k
community here.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox