[PATCHv2 3/3] powerpc/cpu: post the event cpux add/remove instead of online/offline during hotplug

Technically speaking, echo 1/0 > cpuX/online is only a subset of cpu hotplug/unplug, i.e. add/remove. The latter one includes the physical adding/removing of a cpu device. Some user space tools such as kexec-tools resort to the event add/remove to automatically rebuild dtb. If the dtb is not rebuil

[PATCHv2 2/3] powerpc/cpu: dynmamically to create/destroy the file physical_id during hotplug

In order to cope with the incoming patch [3/3], which causes the dir /sys/../cpuX is created/destroyed during hotplug, we also need to create the file cpuX/physical_id dynamically. Signed-off-by: Pingfan Liu Reported-by: Hari Bathini Reviewed-by: Hari Bathini --- arch/powerpc/kernel/sysfs.c |

[PATCHv2 1/3] powerpc/cpuidle: dynamically register/unregister cpuidle_device during hotplug

cpuidle_device is touched during the cpu hotplug. In order to cope with the incoming patch [3/3], which causes the dir /sys/../cpuX is created/destroyed during hotplug, we also need to create the file cpuX/cpuidle dynamically. Signed-off-by: Pingfan Liu Reviewed-by: Hari Bathini --- drivers/c

[PATCHv2 0/3] post the event cpux add/remove besides online/offline during hotplug

v1->v2: -1.improve the commit log and explain the reproducing of bug in [3/3] -2.re-fragment the series, and [3/3] is the motivation, while [1~2/3] are preparation. Pingfan Liu (3): powerpc/cpuidle: dynamically register/unregister cpuidle_device during hotplug powerpc/cpu: dynmam

[PATCH v2 5/5] KVM: PPC: Book3S HV: radix do not clear partition scoped page table when page fault races with other vCPUs.

When running a SMP radix guest, KVM can get into page fault / tlbie storms -- hundreds of thousands to the same address from different threads -- due to partition scoped page faults invalidating the page table entry if it was found to be already set up by a racing CPU. What can happen is that gues

[PATCH v2 4/5] KVM: PPC: Book3S HV: radix handle process scoped LPID flush in C, with relocation on

The radix guest code can has fewer restrictions about what context it can run in, so move this flushing out of assembly and have it use the Linux TLB flush implementations introduced previously. This allows powerpc:tlbie trace events to be used. This changes the tlbiel sequence to only execute RI

[PATCH v2 3/5] KVM: PPC: Book3S HV: radix use the Linux TLB flush function in kvmppc_radix_tlbie_page

This has the advantage of consolidating TLB flush code in fewer places, and it also implements powerpc:tlbie trace events. 1GB pages should be handled without further modification. Signed-off-by: Nicholas Piggin --- arch/powerpc/kvm/book3s_64_mmu_radix.c | 26 +++--- 1 file

[PATCH v2 2/5] powerpc/mm/radix: implement LPID based TLB flushes to be used by KVM

Implement a local TLB flush for invalidating an LPID with variants for process or partition scope. And a global TLB flush for invalidating a partition scoped page of an LPID. These will be used by KVM in subsequent patches. Signed-off-by: Nicholas Piggin --- .../include/asm/book3s/64/tlbflush-r

[PATCH v2 1/5] KVM: PPC: Book3S HV: radix use correct tlbie sequence in kvmppc_radix_tlbie_page

The standard eieio ; tlbsync ; ptesync must follow tlbie to ensure it is ordered with respect to subsequent operations. Signed-off-by: Nicholas Piggin --- arch/powerpc/kvm/book3s_64_mmu_radix.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/kvm/book3s_64_mmu_rad

[PATCH v2 0/5] KVM TLB flushing improvements (for radix)

This series moves some of the radix mode TLB flushing into powerpc/mm, which allows them them to implement the powerpc:tlbie tracepoints for KVM invalidations. This also fixes a partition scoped page fault performance issue that was found by looking at partition scoped tlbie traces. Since v1: - F

Re: [PATCH 1/1] PCI set flag PCI_SCAN_ALL_PCIE_DEVS for P.A. Semi boards

Hi Michael, Many thanks for your help. Did you merge Olof‘s patch? I still have to patch the 4.17 source code. Thanks, Christian Sent from my iPhone > On 19. Mar 2018, at 23:32, Michael Ellerman wrote: > > Bjorn Helgaas writes: > >>> On Fri, Mar 16, 2018 at 01:55:36PM +0100, Christian Zigo

Re: [PATCH RFC 1/1] KVM: PPC: Book3S HV: pack VCORE IDs to access full VCPU ID space

On Thu, Apr 12, 2018 at 05:02:06PM +1000, Sam Bobroff wrote: > It is not currently possible to create the full number of possible > VCPUs (KVM_MAX_VCPUS) on Power9 with KVM-HV when the guest uses less > threads per core than it's core stride (or "VSMT mode"). This is > because the VCORE ID and XIVE

Re: [RFC PATCH 0/3] Dealing with the aliases of SI_USER

Linus Torvalds writes: > ( > > On Sun, Apr 15, 2018 at 8:56 AM, Eric W. Biederman > wrote: >> >> Would you consider the patchset below for -rc2? > > Ugh. The point of this series is to squash the potential for regressions even from the weird broken code that fills in fields for si_code 0 that d

Re: [PATCH] ibmvnic: Clear pending interrupt after device reset

On 04/15/2018 07:55 PM, David Miller wrote: > From: Thomas Falcon > Date: Sun, 15 Apr 2018 18:53:36 -0500 > >> Due to a firmware bug, the hypervisor can send an interrupt to a >> transmit or receive queue just prior to a partition migration, not >> allowing the device enough time to handle it and

Re: [PATCH] ibmvnic: Clear pending interrupt after device reset

From: Thomas Falcon Date: Sun, 15 Apr 2018 18:53:36 -0500 > Due to a firmware bug, the hypervisor can send an interrupt to a > transmit or receive queue just prior to a partition migration, not > allowing the device enough time to handle it and send an EOI. When > the partition migrates, the inte

[PATCH] ibmvnic: Clear pending interrupt after device reset

Due to a firmware bug, the hypervisor can send an interrupt to a transmit or receive queue just prior to a partition migration, not allowing the device enough time to handle it and send an EOI. When the partition migrates, the interrupt is lost but an "EOI-pending" flag for the interrupt line is st

Re: [PATCH] ibmvnic: Clear pending interrupt after device reset

On 04/15/2018 06:27 PM, Thomas Falcon wrote: > Due to a firmware bug, the hypervisor can send an interrupt to a > transmit or receive queue just prior to a partition migration, not > allowing the device enough time to handle it and send an EOI. When > the partition migrates, the interrupt is lost b

Re: [RFC PATCH 0/3] Dealing with the aliases of SI_USER

( On Sun, Apr 15, 2018 at 8:56 AM, Eric W. Biederman wrote: > > Would you consider the patchset below for -rc2? Ugh. I have an irrational dislike of "clear_siginfo()". It's a nasty broken interface, which just mis-spells "memset()", and makes it non-obvious that you could clear it other ways to

Re: [PATCH 00/32] docs/vm: convert to ReST format

On Fri, Apr 13, 2018 at 01:55:51PM -0600, Jonathan Corbet wrote: > Sorry for the silence, I'm pedaling as fast as I can, honest... > > On Sun, 1 Apr 2018 09:38:58 +0300 > Mike Rapoport wrote: > > > My thinking was to start with mechanical RST conversion and then to start > > working on the conte

Re: [PATCH 00/32] docs/vm: convert to ReST format

On Fri, Apr 13, 2018 at 01:21:08PM -0700, Matthew Wilcox wrote: > On Fri, Apr 13, 2018 at 01:55:51PM -0600, Jonathan Corbet wrote: > > > I believe that keeping the mm docs together will give better visibility of > > > what (little) mm documentation we have and will make the updates easier. > > > Th

Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid

Russell King - ARM Linux writes: > On Fri, Apr 13, 2018 at 12:53:49PM -0700, Linus Torvalds wrote: >> On Fri, Apr 13, 2018 at 11:45 AM, Dave Martin wrote: >> > >> > Most uses I've seen do nothing more than use the FPE_xyz value to >> > format diagnostic messages while dying. I struggled to find

[RFC PATCH 3/3] signal: Stop special casing TRAP_FIXME and FPE_FIXME in siginfo_layout

After more experience with the cases where no one the si_code of 0 is used both as a signal specific si_code, and as SI_USER it appears that no one cares about the signal specific si_code case and the good solution is to just fix the architectures by using a different si_code. In none of the conv

[RFC PATCH 2/3] signal: Reduce copy_siginfo_to_user to just copy_to_user

Now that every instance of struct siginfo is now initialized it is no longer necessary to copy struct siginfo piece by piece to userspace but instead the entire structure can be copied. As well as making the code simpler and more efficient this means that copy_sinfo_to_user no longer cares which

[RFC PATCH 1/3] signal: Ensure every siginfo we send has all bits initialized

Call clear_siginfo to ensure every stack allocated siginfo is properly initialized before being passed to the signal sending functions. Note: It is not safe to depend on C initializers to initialize struct siginfo on the stack because C is allowed to skip holes when initializing a structure. The

[RFC PATCH 0/3] Dealing with the aliases of SI_USER

Linus, Would you consider the patchset below for -rc2? Dealing with the aliases of SI_USER has been a challenge as we have had a b0rked ABI in some cases since 2.5. So far no one except myself has suggested that changing the si_code of from 0 to something else for those problematic aliases of S

Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid

On Fri, Apr 13, 2018 at 12:53:49PM -0700, Linus Torvalds wrote: > On Fri, Apr 13, 2018 at 11:45 AM, Dave Martin wrote: > > > > Most uses I've seen do nothing more than use the FPE_xyz value to > > format diagnostic messages while dying. I struggled to find code that > > made a meaningful function

Re: [RFC] virtio: Use DMA MAP API for devices without an IOMMU

On Fri, Apr 06, 2018 at 06:37:18PM +1000, Benjamin Herrenschmidt wrote: > > > implemented as DMA API which the virtio core understands. There is no > > > need for an IOMMU to be involved for the device representation in this > > > case IMHO. > > > > This whole virtio translation issue is a mess.