[PATCH] powerpc: add va_end()

cppcheck picked up that there were a couple of missing va_end() calls in functions using va_start(). Signed-off-by: Daniel Axtens --- arch/powerpc/kernel/prom_init.c | 1 + arch/powerpc/platforms/powermac/bootx_init.c | 1 + 2 files changed, 2 insertions(+) diff

Re: [PATCH] crypto/nx842: Mask XERS0 bit in return value

On Sun, Dec 13, 2015 at 03:30:41AM -0800, Haren Myneni wrote: > > NX842 coprocessor sets 3rd bit in CR register with XER[S0] which is > nothing to do with NX request. Since this bit can be set with other > valuable return status, mast this bit. > > One of other bits (INITIATED, BUSY or REJECTED)

Re: [PATCH v3 2/3] powerpc: Add __raw_rm_writeq() function

On Thu, 2015-12-17 at 10:19 +0100, Gabriel Paubert wrote: > On Thu, Dec 17, 2015 at 01:43:12PM +1100, Alistair Popple wrote: > > Move __raw_rw_writeq() from platforms/powernv/pci-ioda.c to > ^ > Typo? > (not a big deal) Thanks for noticing, I saw this just in time and fixed it up

Re: Partial revert of "powerpc: Individual System V IPC system calls"

On Wed, 2015-16-12 at 10:53:29 UTC, Michael Ellerman wrote: > This partially reverts commit a34236155afb1cc41945e58388ac988431bcb0b8. > > While reviewing the glibc patch to exploit the individual IPC calls, > Arnd & Andreas noticed that we were still requiring userspace to pass > IPC_64 in order

Re: [RFC PATCH 2/3] vfio-pci: Allow to mmap sub-page MMIO BARs if all MMIO BARs are page aligned

On 2015/12/17 4:04, Alex Williamson wrote: On Fri, 2015-12-11 at 16:53 +0800, Yongji Xie wrote: Current vfio-pci implementation disallows to mmap sub-page(size < PAGE_SIZE) MMIO BARs because these BARs' mmio page may be shared with other BARs. But we should allow to mmap these sub-page MMIO

Re: [RFC PATCH 3/3] vfio-pci: Allow to mmap MSI-X table if EEH is supported

On 2015/12/17 4:14, Alex Williamson wrote: On Fri, 2015-12-11 at 16:53 +0800, Yongji Xie wrote: Current vfio-pci implementation disallows to mmap MSI-X table in case that user get to touch this directly. However, EEH mechanism could ensure that a given pci device can only shoot the MSIs

Re: [PATCH v3 2/3] powerpc: Add __raw_rm_writeq() function

On Thu, Dec 17, 2015 at 01:43:12PM +1100, Alistair Popple wrote: > Move __raw_rw_writeq() from platforms/powernv/pci-ioda.c to ^ Typo? (not a big deal) Gabriel > include/asm/io.h so that it can be used by other code. > > Signed-off-by: Alistair Popple >

RE: [RFC PATCH 3/3] vfio-pci: Allow to mmap MSI-X table if EEH is supported

> The MSI-X table is paravirtualized on vfio in general and interrupt > remapping theoretically protects against errant interrupts, so why is > this PPC64 specific? We have the same safeguards on x86 if we want to > decide they're sufficient. Offhand, the only way I can think that a > device can

Re: powerpc/powernv: pr_warn_once on unsupported OPAL_MSG type

On Fri, 2015-11-12 at 01:08:23 UTC, Stewart Smith wrote: > When running on newer OPAL firmware that supports sending extra > OPAL_MSG types, we would print a warning on *every* message received. > > This could be a problem for kernels that don't support OPAL_MSG_OCC > on machines that are running

[PATCH v3 3/9] powerpc/xics: Add icp_native_cause_ipi_rm

Function to cause an IPI by directly updating the MFFR register in the XICS. The function is meant for real-mode callers since they cannot use the smp_ops->cause_ipi function which uses an ioremapped address. Normal usage is for the the KVM real mode code to set the IPI message using

[PATCH v3 8/9] KVM: PPC: Book3S HV: Send IPI to host core to wake VCPU

This patch adds support to real-mode KVM to search for a core running in the host partition and send it an IPI message with VCPU to be woken. This avoids having to switch to the host partition to complete an H_IPI hypercall when the VCPU which is the target of the the H_IPI is not loaded (is not

Re: [PATCH 1/6] cxlflash: Fix to escalate LINK_RESET also on port 1

On 12/14/2015 11:30 AM, Matthew R. Ochs wrote: Acked-by: Matthew R. Ochs Reviewed-by: Uma Krishnan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org

Re: [RFC PATCH 3/3] vfio-pci: Allow to mmap MSI-X table if EEH is supported

On Thu, 2015-12-17 at 18:37 +0800, yongji xie wrote: > > On 2015/12/17 4:14, Alex Williamson wrote: > > On Fri, 2015-12-11 at 16:53 +0800, Yongji Xie wrote: > > > Current vfio-pci implementation disallows to mmap MSI-X table in > > > case that user get to touch this directly. > > > > > >

Re: [PATCH 2/6] cxlflash: Fix to avoid virtual LUN failover failure

On 12/10/2015 4:53 PM, Uma Krishnan wrote: From: "Matthew R. Ochs" Applications which use virtual LUN's that are backed by a physical LUN over both adapter ports may experience an I/O failure in the event of a link loss (e.g. cable pull). Virtual LUNs may be

[PATCH v3 6/9] KVM: PPC: Book3S HV: kvmppc_host_rm_ops - handle offlining CPUs

The kvmppc_host_rm_ops structure keeps track of which cores are are in the host by maintaining a bitmask of active/runnable online CPUs that have not entered the guest. This patch adds support to manage the bitmask when a CPU is offlined or onlined in the host. Signed-off-by: Suresh Warrier

[PATCH v3 9/9] KVM: PPC: Book3S HV: Add tunable to control H_IPI redirection

Redirecting the wakeup of a VCPU from the H_IPI hypercall to a core running in the host is usually a good idea, most workloads seemed to benefit. However, in one heavily interrupt-driven SMT1 workload, some regression was observed. This patch adds a kvm_hv module parameter called h_ipi_redirect to

Re: [RFC PATCH 3/3] vfio-pci: Allow to mmap MSI-X table if EEH is supported

On Thu, 2015-12-17 at 10:08 +, David Laight wrote: > > The MSI-X table is paravirtualized on vfio in general and interrupt > > remapping theoretically protects against errant interrupts, so why > > is > > this PPC64 specific? We have the same safeguards on x86 if we want > > to > > decide

Re: [PATCH v3 4/4] printk/nmi: Increase the size of NMI buffer and make it configurable

On Tue, 15 Dec 2015 15:26:21 +0100 Petr Mladek wrote: > > OK, thanks. So "not needed at present, might be needed in the future, > > useful for out-of-tree debug code"? > > It is possible that I got it a wrong way on arm. The NMI buffer is > usable there on two locations. > >

[PATCH v3 4/9] KVM: PPC: Book3S HV: Host-side RM data structures

This patch defines the data structures to support the setting up of host side operations while running in real mode in the guest, and also the functions to allocate and free it. The operations are for now limited to virtual XICS operations. Currently, we have only defined one operation in the

[PATCH v3 5/9] KVM: PPC: Book3S HV: Manage core host state

Update the core host state in kvmppc_host_rm_ops whenever the primary thread of the core enters the guest or returns back. Signed-off-by: Suresh Warrier --- arch/powerpc/kvm/book3s_hv.c | 44 1 file changed, 44

[PATCH v3 1/9] powerpc/smp: Support more IPI messages

This patch increases the number of demuxed messages for a controller with a single ipi to 8 for 64-bit systems This is required because we want to use the IPI mechanism to send messages from a CPU running in KVM real mode in a guest to a CPU in the host to take some action. Currently, we only

[PATCH v3 7/9] KVM: PPC: Book3S HV: Host side kick VCPU when poked by real-mode KVM

This patch adds the support for the kick VCPU operation for kvmppc_host_rm_ops. The kvmppc_xics_ipi_action() function provides the function to be invoked for a host side operation when poked by the real mode KVM. This is initiated by KVM by sending an IPI to any free host core. KVM real mode must

[PATCH v3 0/9] KVM: PPC: Book3S HV: Optimize wakeup VCPU from H_IPI

When the VCPU target of an H_IPI hypercall is not running in the guest, we need to do a kick VCPU (wake the VCPU thread) to make it runnable. The real-mode version of the H_IPI hypercall cannot do this because it involves waking a sleeping thread. Thus the hcall returns H_TOO_HARD which forces a

[PATCH v3 2/9] powerpc/smp: Add smp_muxed_ipi_set_message

smp_muxed_ipi_message_pass() invokes smp_ops->cause_ipi, which uses an ioremapped address to access registers on the XICS interrupt controller to cause the IPI. Because of this real mode callers cannot call smp_muxed_ipi_message_pass() for IPI messaging. This patch creates a separate function

Re: [RFC PATCH 2/3] vfio-pci: Allow to mmap sub-page MMIO BARs if all MMIO BARs are page aligned

On Thu, 2015-12-17 at 18:26 +0800, yongji xie wrote: > > On 2015/12/17 4:04, Alex Williamson wrote: > > On Fri, 2015-12-11 at 16:53 +0800, Yongji Xie wrote: > > > Current vfio-pci implementation disallows to mmap > > > sub-page(size < PAGE_SIZE) MMIO BARs because these BARs' mmio > > > page > > >

Re: [PATCH 5/6] cxlflash: Resolve oops in wait_port_offline

On 12/10/2015 4:54 PM, Uma Krishnan wrote: From: Manoj Kumar If an async error interrupt is generated, and the error requires the FC link to be reset, it cannot be performed in the interrupt context. So a work element is scheduled to complete the link reset in a

[PATCH] powerpc/opal-irqchip: Fix deadlock introduced by "Fix double endian conversion"

Commit 25642e1459ac ("powerpc/opal-irqchip: Fix double endian conversion") fixed an endian bug by calling opal_handle_events() in opal_event_unmask(). However this introduces a deadlock when an event is active during unmasking as opal_handle_events() calls generic_handle_irq() which may call

linux-next: manual merge of the akpm-current tree with the powerpc tree

Hi Andrew, Today's linux-next merge of the akpm-current tree got a conflict in: arch/powerpc/include/asm/pgtable.h between commit: ee4889c7bc2a ("powerpc/mm: Don't have generic headers introduce functions touching pte bits") from the powerpc tree and commit: e0e8474c0d55 ("mm, dax,

Re: [RFC PATCH 3/3] vfio-pci: Allow to mmap MSI-X table if EEH is supported

On Thu, 2015-12-17 at 14:41 -0700, Alex Williamson wrote: > > So I think it is safe to mmap/passthrough MSI-X table on PPC64 > > platform. > > And I'm not sure whether other architectures can ensure these two  > > points.  > > There is another consideration, which is the API exposed to the user.

Re: [v3, 1/6] powerpc/pseries: Consolidate CPU hotplug code to hotplug-cpu.c

On Wed, 2015-16-12 at 20:50:21 UTC, Nathan Fontenot wrote: > No functional changes, this patch is simply a move of the cpu hotplug > code from pseries/dlpar.c to pseries/hotplug-cpu.c. This is in an effort > to consolidate all of the cpu hotplug code in a common place. > > Signed-off-by: Nathan

Re: [v5] powerpc/mm: Add page soft dirty tracking

On Thu, 2015-03-12 at 10:29:19 UTC, Laurent Dufour wrote: > User space checkpoint and restart tool (CRIU) needs the page's change > to be soft tracked. This allows to do a pre checkpoint and then dump > only touched pages. > > This is done by using a newly assigned PTE bit (_PAGE_SOFT_DIRTY) when

Re: powerpc/476fpe: Add support for kexec

On Mon, 2015-14-12 at 03:31:24 UTC, Alistair Popple wrote: > PPC476FPE has a different PVR from previous PPC476 processors. The > kexec code checks the PVR in order to correctly setup the MMU. When > the initial support for 476FPE processors was added the corresponding > change in the kexec code

Re: powerpc/powernv: Fix M64 resource name in /proc/iomem

On Thu, 2015-22-10 at 01:03:08 UTC, Gavin Shan wrote: > The name of PCI root bus's M64 resource isn't initialized properly. > When dumping "/proc/iomem", "" is seen for those M64 resources > on PCI root buses. > >~# cat /proc/iomem | grep -e "BAD" >3b00-3b0fefff : >

Re: powerpc: Remove broken GregorianDay()

On Tue, 2015-15-12 at 07:09:14 UTC, Daniel Axtens wrote: > GregorianDay() is supposed to calculate the day of the week > (tm->tm_wday) for a given day/month/year. In that calcuation it > indexed into an array called MonthOffset using tm->tm_mon-1. However > tm_mon is zero-based, not one-based, so

Re: [v2] selftests/powerpc: Add script to test HMI functionality

On Sun, 2015-06-12 at 23:50:51 UTC, Daniel Axtens wrote: > HMIs (Hypervisor Management|Maintenance Interrupts) are a class of interrupt > on POWER systems. > > HMI support has traditionally been exceptionally difficult to test, however > Skiboot ships a tool that, with the correct magic numbers,

Re: [v2,1/3] powerpc/powernv: panic() on OPAL < V3

On Wed, 2015-09-12 at 06:18:18 UTC, Stewart Smith wrote: > The OpenPower Abstraction Layer firmware went through a couple > of iterations in the lab before being released. What we now know > as OPAL advertises itself as OPALv3. > > OPALv2 and OPALv1 never made it outside the lab, and the

Re: powerpc/pseries: Verify CPU doesn't exist before adding

On Fri, 2015-23-10 at 17:45:57 UTC, Nathan Fontenot wrote: > When DLPAR adding a CPU we should verify that the CPU does not already > exist. Failure to do so can generate a kernel oops; > > [9.465585] kernel BUG at arch/powerpc/platforms/pseries/dlpar.c:382! > [9.465796] Oops: Exception

Re: [PATCH] powerpc: add va_end()

On Thu, 2015-12-17 at 19:41 +1100, Daniel Axtens wrote: > cppcheck picked up that there were a couple of missing va_end() > calls in functions using va_start(). > > Signed-off-by: Daniel Axtens Hey Daniel, It's probably not worth a V2 but I think this could use a commit title

Re: [PATCH v4] perf: bpf: Fix build breakage due to libbpf

Em Thu, Dec 17, 2015 at 10:37:14AM +0530, Naveen N. Rao escreveu: > On 2015/12/17 09:29AM, Wang Nan wrote: > > The whole thread is: > > > > [PATCH v3 0/3] perf build: PowerPC: Fix build breakage due to libbpf: > > http://lkml.kernel.org/g/1450150557-127942-1-git-send-email-wangn...@huawei.com > >

Re: [PATCH] powerpc: add va_end()

On Thu, 2015-12-17 at 23:09 +1100, Russell Currey wrote: > On Thu, 2015-12-17 at 19:41 +1100, Daniel Axtens wrote: > > cppcheck picked up that there were a couple of missing va_end() > > calls in functions using va_start(). > > > > Signed-off-by: Daniel Axtens > Hey Daniel, > >

Re: [v3, 1/3] Revert "powerpc/pci: Remove unused struct pci_dn.pcidev field"

On Thu, 2015-17-12 at 02:43:11 UTC, Alistair Popple wrote: > This commit removed the pcidev field from struct pci_dn as it was no > longer in use by the kernel. However to support finding the > association of Nvlink devices to GPU devices from the device-tree this > field is required. > > This

Re: [1/4] powerpc/kernel: Drop HMT_MEDIUM_PPR_DISCARD

On Wed, 2015-25-11 at 03:25:16 UTC, Michael Ellerman wrote: > HMT_MEDIUM_PPR_DISCARD is a macro which is present at the start of most > of our first level exception handlers. It conditionally executes a > HMT_MEDIUM instruction, which sets the processor priority to medium. > > On on modern

Re: [1/4] selftests/powerpc: Move pick_online_cpu() up into utils.c

On Wed, 2015-02-12 at 09:44:08 UTC, Michael Ellerman wrote: > We want to use this in another test, so make it available at the top of > the powerpc selftests tree. > > Signed-off-by: Michael Ellerman Series applied to powerpc next.

Re: [1/5] powerpc/rtas: Add rtas_call_unlocked()

On Tue, 2015-24-11 at 11:26:08 UTC, Michael Ellerman wrote: > Most users of RTAS (Run-Time Abstraction Services) use rtas_call(), > which deals with locking as well as endian handling. > > However we have two users outside of rtas.c that can't use rtas_call() > because they have different locking

Re: [PATCH] powerpc: add va_end()

Hi all, Yes, sorry, that was a bit lax of me. Michael, your title sounds good. Thanks! Regards, Daniel > On Thu, 2015-12-17 at 23:09 +1100, Russell Currey wrote: >> On Thu, 2015-12-17 at 19:41 +1100, Daniel Axtens wrote: >> > cppcheck picked up that there were a couple of missing va_end() >>