We might have memory@ nodes with "linux,usable-memory" set to zero
(for example, to replicate powernv's behaviour for GPU coherent memory)
which means that the memory needs an extra initialization but since
it can be used afterwards, the pseries platform will try mapping it
for DMA so the DMA
This new memory does not have page structs as it is not plugged to
the host so gup() will fail anyway.
This adds 2 helpers:
- mm_iommu_newdev() to preregister the "memory device" memory so
the rest of API can still be used;
- mm_iommu_is_devmem() to know if the physical address is one of thise
It is quite common for a device to support more than 32bit but less than
64bit for DMA, for example, GPUs often support 42..50bits. However
the pseries platform only allows huge DMA window (the one which allows
the use of more than 2GB of DMA space) for 64bit-capable devices mostly
because:
1. we
The powernv platform registers IOMMU groups and adds devices to them
from the pci_controller_ops::setup_bridge() hook except one case when
virtual functions (SRIOV VFs) are added from a bus notifier.
The pseries platform registers IOMMU groups from
the pci_controller_ops::dma_bus_setup() hook and
Am Montag, 12. November 2018, 03:35:19 CET schrieb Masahiro Yamada:
> Commit cafa0010cd51 ("Raise the minimum required gcc version to 4.6")
> bumped the minimum GCC version to 4.6 for all architectures.
>
> '$(call cc-option,-fno-unit-at-a-time)' is now dead code since
> '$(cc-version) -lt 0400'
This step is to help removing the npu struct from pnv_phb so it
can be used by pseries as well.
Signed-off-by: Alexey Kardashevskiy
Reviewed-by: David Gibson
---
arch/powerpc/platforms/powernv/npu-dma.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git
Registering new IOMMU groups and adding devices to them are separated in
code and the latter is dug in the DMA setup code which it does not
really belong to.
This moved IOMMU groups setup to a separate helper which registers a group
and adds devices as before. This does not make a difference as
This is for passing through NVIDIA V100 GPUs on POWER9 systems.
7/7 and https://github.com/aik/linux/commit/f41f5666d27b31c1
have the details of hardware setup.
This implements support for NVIDIA V100 GPU with coherent memory and
NPU/ATS support available in the POWER9 CPU. The aim is to
Since we are going to have 2 different preregistering helpers, let's
make it clear that mm_iommu_new() is only for the normal memory
(i.e.not device memory) and for existing areas mm_iommu_get() should be
used instead.
This removes the check for exact match as the check for overlap is
enough now.
Flushing caches using the dcbf instruction takes quite some time if we
need to flush gigabytes (16GB takes more than 15s); OPAL just added
a big hammer to flush all caches.
This adds opal_purge_cache() which will be used later to flush caches
for coherent GPU memory which might suddenly become
At the moment the kernel does not expect dynamic windows to ever start
at zero on a PCI bus as PAPR requires the hypervisor to create a 32bit
default window which starts from zero and the pseries kernel only
creates additional windows.
However PAPR permits removing the default window and creating
The powernv PCI code stores NPU data in the pnv_phb struct. The latter
is referenced by pci_controller::private_data. We are going to have NPU2
support in the pseries platform as well but it does not store any
private_data in in the pci_controller struct; and even if it did,
it would be a
POWER9 Witherspoon machines come with 4 or 6 V100 GPUs which are not
pluggable PCIe devices but implement PCIe links for config space and MMIO.
In addition to that the GPUs are interconnected to each other and also
have direct links to the P9 CPU. The links are NVLink2 and provide direct
access to
We already changed NPU API for GPUs to not to call OPAL and the remaining
bit is initializing NPU structures.
This uses a new QEMU capability which marks NPU-enabled vPHBs as
"IBM,npu-vphb" and initializes an NPU structure per vPHB.
Signed-off-by: Alexey Kardashevskiy
---
Normally mm_iommu_get() is supposed to add a reference and
mm_iommu_put() to remove it. However historically mm_iommu_find() does
the referencing and mm_iommu_get() is doing allocation and referencing.
We are going to add another helper to preregister device memory so
instead of having
When introduced, the NPU context init/destroy helpers called OPAL which
enabled/disabled PID (a userspace memory context ID) filtering in an NPU
per a GPU; this was a requirement for P9 DD1.0. However newer chip
revision added a PID wildcard support so there is no more need to
call OPAL every time
In order to make ATS work and translate addresses for arbitrary
LPID and PID, we need to program an NPU with LPID and allow PID wildcard
matching with a specific MSR mask.
This implements a helper to assign a GPU to LPAR and program the NPU
with a wildcard for PID and a helper to do clean-up. The
VFIO regions already support region capabilities with a limited set of
fields. However the subdriver might have to report to the userspace
additional bits.
This adds an add_capability() hook to vfio_pci_regops.
Signed-off-by: Alexey Kardashevskiy
---
Changes:
v3:
* removed confusing rationale
The iommu_table pointer stored in iommu_table_group may get stale
by accident, this adds referencing and removes a redundant comment
about this.
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/platforms/powernv/pci-ioda-tce.c | 3 ++-
arch/powerpc/platforms/powernv/pci-ioda.c | 4
At the moment NPU IOMMU is manipulated directly from the IODA2 PCI
PE code; PCI PE acts as a master to NPU PE. Soon we will have compound
IOMMU groups with several PEs from several different PHB (such as
interconnected GPUs and NPUs) so there will be no single master but
a one big IOMMU group.
So far we only allowed mapping of MMIO BARs to the userspace. However
there there are GPUs with on-board coherent RAM accessible via side
channels which we also want to map to the userspace. The first client
for this is NVIDIA V100 GPU with NVLink2 direct links to a POWER9
NPU-enabled CPU; such
> -static void topology_work_fn(struct work_struct *work)
> -{
> - rebuild_sched_domains();
> + if (changed)
> + rebuild_sched_domains();
> }
> static DECLARE_WORK(topology_work, topology_work_fn);
>
> @@ -1553,7 +1424,6 @@ void __init shared_proc_topology_init(void)
>
On Wed, 2018-11-07 at 05:38:53 UTC, Michael Ellerman wrote:
> Back in 2006 Ben added some workarounds for a misbehaviour in the
> Spider IO bridge used on early Cell machines, see commit
> 014da7ff47b5 ("[POWERPC] Cell "Spider" MMIO workarounds"). Later these
> were made to be generic, ie. not
On Mon, 2018-11-12 at 02:46:06 UTC, Michael Ellerman wrote:
> The selftest I recently added to test branching to an out-of-bounds
> NIP doesn't work on 64-bit big endian. It does fail but not in the
> right way. That is it SEGVs trying to load from the opd at BAD_NIP,
> but it never gets as far as
On Thu, 2018-11-01 at 05:21:05 UTC, Michael Ellerman wrote:
> With preempt enabled we see warnings in do_slb_fault():
>
> BUG: using smp_processor_id() in preemptible [] code:
> kworker/u33:0/98
> futex hash table entries: 4096 (order: 3, 524288 bytes)
> caller is
Satheesh Rajendran writes:
> On Mon, Nov 12, 2018 at 11:24:08PM +1100, Michael Ellerman wrote:
>> Satheesh Rajendran writes:
>>
>> > On Thu, Nov 08, 2018 at 04:23:07PM -0200, Breno Leitao wrote:
>> >> hi Satheesh,
>> >>
>> >> On 11/08/2018 03:08 AM, sathn...@linux.vnet.ibm.com wrote:
>> >> >
The skiboot firmware has a hot reset handler which fences the NVIDIA V100
GPU RAM on Witherspoons and makes accesses no-op instead of throwing HMIs:
https://github.com/open-power/skiboot/commit/fca2b2b839a67
Now we are going to pass V100 via VFIO which most certainly involves
KVM guests which are
The pci_dma_bus_setup_pSeries and pci_dma_dev_setup_pSeries hooks are
registered for the pseries platform which does not have FW_FEATURE_LPAR;
these would be pre-powernv platforms which we never supported PCI pass
through for anyway so remove it.
Signed-off-by: Alexey Kardashevskiy
Reviewed-by:
At the moment powernv registers an IOMMU group for each PE. There is
an exception though - NPU (an emulated PCI bridge representing an NVLink);
powernv attaches these bridges to the GPU IOMMU group which becomes
a master.
Now we have POWER9 systems with GPUs connected to each other directly,
Check that the values received by the portal interrupt coalesce
change APIs are in range.
Signed-off-by: Madalin Bucur
Signed-off-by: Roy Pledge
---
drivers/soc/fsl/qbman/qman.c | 33 ++---
include/soc/fsl/qman.h | 8 ++--
2 files changed, 32
Allow ethtool control of the DPAA QMan portal interrupt coalescing
settings.
Signed-off-by: Madalin Bucur
---
drivers/net/ethernet/freescale/dpaa/dpaa_ethtool.c | 49 ++
1 file changed, 49 insertions(+)
diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_ethtool.c
Add control of the DPAA portal interrupt coalescing settings from
ethtool.
changes from v1: added range checking for the QMan APIs
Madalin Bucur (2):
soc/qman: add return value to interrupt coalesce changing APIs
dpaa_eth: add ethtool coalesce control
YueHaibing wrote:
There is no need to have the 'intoffset' variable static since new value
always be assigned before use it.
Signed-off-by: YueHaibing
---
arch/powerpc/kernel/trace/ftrace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/trace/ftrace.c
There is no need to have the 'intoffset' variable static since new value
always be assigned before use it.
Signed-off-by: YueHaibing
---
arch/powerpc/kernel/trace/ftrace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/trace/ftrace.c
On 11/12/2018 11:02 PM, Bjorn Helgaas wrote:
>
> [EXTERNAL EMAIL]
> Please report any suspicious attachments, links, or requests for sensitive
> information.
>
>
> [+cc Jon, for related VMD firmware-first error enable issue]
>
> On Mon, Nov 12, 2018 at 08:05:41PM +,
Hi Adam,
On Fri, Nov 09, 2018 at 08:02:52PM +0100, Adam Borowski wrote:
> @@ -122,7 +104,6 @@ $(obj)/vmlinux.its.S: $(addprefix
> $(srctree)/arch/mips/$(PLATFORM)/,$(ITS_INPUTS
>
> targets += vmlinux.its
> targets += vmlinux.gz.its
> -targets += vmlinux.bz2.its
> targets += vmlinux.lzmo.its
On Tue, Nov 6, 2018 at 12:06 PM Masahiro Yamada
wrote:
>
> Collect basic Clang options such as --target, --prefix, --gcc-toolchain,
> -no-integrated-as into a single variable CLANG_FLAGS so that it can be
> easily reused in other parts of Makefile.
>
> Signed-off-by: Masahiro Yamada
> ---
On 11/13/2018 04:56 PM, Keith Busch wrote:
> On Tue, Nov 13, 2018 at 10:39:15PM +, alex_gagn...@dellteam.com wrote:
>> On 11/12/2018 11:02 PM, Bjorn Helgaas wrote:
>>> The whole issue of firmware-first, the mechanism by which firmware
>>> gets control, the System Error enables in Root Port
Hi mpe,
Even after the latest fix for the wild_bctr selftest I'm still getting the
following compilation (actually, an assembling error) because UL is not
understood by the assembler:
BUILD_TARGET=/home/gromero/git/linux/tools/testing/selftests/powerpc/mm; mkdir
-p $BUILD_TARGET; make
On Tue, Nov 6, 2018 at 12:06 PM Masahiro Yamada
wrote:
>
> We are still a way off the Clang's integrated assembler support for
> the kernel. Hence, -no-integrated-as is mandatory to build the kernel
> with Clang. If you had an ancient version of Clang that does not
> recognize this option, you
On Tue, Nov 13, 2018 at 10:39:15PM +, alex_gagn...@dellteam.com wrote:
> On 11/12/2018 11:02 PM, Bjorn Helgaas wrote:
> > The whole issue of firmware-first, the mechanism by which firmware
> > gets control, the System Error enables in Root Port Root Control
> > registers, etc., is very murky
On Tue, Nov 13, 2018 at 10:45:54PM +, Paul Burton wrote:
> On Fri, Nov 09, 2018 at 08:02:52PM +0100, Adam Borowski wrote:
> > @@ -122,7 +104,6 @@ $(obj)/vmlinux.its.S: $(addprefix
> > $(srctree)/arch/mips/$(PLATFORM)/,$(ITS_INPUTS
> >
> > targets += vmlinux.its
> > targets +=
On Mon, Nov 12, 2018 at 1:21 PM Joel Stanley wrote:
>
> The powerpc makefile will use these in it's boot wrapper.
>
> Signed-off-by: Joel Stanley
> ---
Applied to linux-kbuild.
Thanks!
> Makefile | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Makefile b/Makefile
> index
Hi Gromero ;)
Gustavo Romero writes:
> Hi mpe,
>
> Even after the latest fix for the wild_bctr selftest I'm still getting the
> following compilation (actually, an assembling error) because UL is not
> understood by the assembler:
>
>
On Tue, Nov 13, 2018 at 4:03 AM Nick Desaulniers
wrote:
>
> On Sun, Nov 11, 2018 at 8:21 PM Joel Stanley wrote:
> >
> > Clang needs to be told which target it is building for when cross
> > compiling.
>
> Neat! This will help us for continuous integration.
>
The add_ss, sub_ddmmss, umul_ppmm and udiv_qrnnd macros originate
from GMP's longlong.h.
This was found when compiling with clang:
arch/powerpc/math-emu/fnmsub.c:46:2: error: invalid use of a cast in a
inline asm context requiring an l-value: remove the cast or build with
When building a 32 bit powerpc kernel with Binutils 2.31.1 this warning
is emitted:
powerpc-linux-gnu-ld: warning: orphan section `.branch_lt' from
`arch/powerpc/kernel/head_44x.o' being placed in section `.branch_lt'
As of binutils commit 2d7ad24e8726 ("Support PLT16 relocs against local
Hi Alexey,
On Tuesday, 13 November 2018 7:28:07 PM AEDT Alexey Kardashevskiy wrote:
> static struct npu *npdev_to_npu(struct pci_dev *npdev)
> {
> - struct pnv_phb *nphb;
> + struct pci_controller *hose = pci_bus_to_host(npdev->bus);
> + struct npu *npu;
>
> - nphb =
> - /*
> - * Setup the NPU context table for a particular GPU. These need to be
> - * per-GPU as we need the tables to filter ATSDs when there are no
> - * active contexts on a particular GPU. It is safe for these to be
> - * called concurrently with destroy as the OPAL
On Tue, Nov 13, 2018 at 10:39:15PM +, alex_gagn...@dellteam.com wrote:
> On 11/12/2018 11:02 PM, Bjorn Helgaas wrote:
> >
> > [EXTERNAL EMAIL]
> > Please report any suspicious attachments, links, or requests for sensitive
> > information.
It looks like Dell's email system adds the above in
CONFIG_PCI_MSI was made mandatory by commit a311e738b6d8
("powerpc/powernv: Make PCI non-optional") so the #ifdef
checks around CONFIG_PCI_MSI here can be removed entirely.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/pci-ioda.c | 13 -
Reviewed-by: Alistair Popple
On Tuesday, 13 November 2018 7:28:06 PM AEDT Alexey Kardashevskiy wrote:
> This step is to help removing the npu struct from pnv_phb so it
> can be used by pseries as well.
>
> Signed-off-by: Alexey Kardashevskiy
> Reviewed-by: David Gibson
> ---
>
On Thu, 2018-11-08 at 21:27 -0600, Michael Roth wrote:
> While running a nested guest VCPU on L0 via H_ENTER_NESTED hcall, a
> pending signal in the L0 QEMU process can generate the following
> sequence:
>
> ret0 = kvmppc_pseries_do_hcall()
> ret1 = kvmhv_enter_nested_guest()
> ret2 =
Hello Alan,
On Tue, 12 Jun 2018 at 07:44, Stephen Rothwell wrote:
> Building Linus' tree, today's linux-next build (powerpc ppc64_defconfig)
> produced these warning:
>
> ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in
> section `.gnu.hash'.
> ld: warning: orphan
Running some container workloads on an IBM power9 server with the latest
mainline (rc2) triggered this,
[ 1283.894167] Unable to handle kernel paging request for data at address
0xc1da
[ 1283.894215] Faulting instruction address: 0xc0487ab8
[ 1283.894223] Oops: Kernel access
On Wed, Nov 14, 2018 at 01:32:18PM +1030, Joel Stanley wrote:
> When building a 32 bit powerpc kernel with Binutils 2.31.1 this warning
> is emitted:
>
> powerpc-linux-gnu-ld: warning: orphan section `.branch_lt' from
> `arch/powerpc/kernel/head_44x.o' being placed in section `.branch_lt'
>
>
On Wed, 14 Nov 2018 at 16:50, Oliver O'Halloran wrote:
>
> CONFIG_PCI_MSI was made mandatory by commit a311e738b6d8
> ("powerpc/powernv: Make PCI non-optional") so the #ifdef
> checks around CONFIG_PCI_MSI here can be removed entirely.
>
> Signed-off-by: Oliver O'Halloran
Reviewed-by: Joel
57 matches
Mail list logo
