Le 10/09/2018 à 23:06, Nicholas Piggin a écrit :
On Mon, 10 Sep 2018 14:34:37 +
Christophe Leroy wrote:
Hi,
I'm having a hard time figuring out the best way to handle the following
situation:
On the powerpc8xx, handling 16k size pages requires to have page tables
with 4 identical
We use PHB in mode1 which uses bit 59 to select a correct DMA window.
However there is mode2 which uses bits 59:55 and allows up to 32 DMA
windows per a PE.
Even though documentation does not clearly specify that, it seems that
the actual hardware does not support bits 59:55 even in mode1, in
Le 10/09/2018 à 22:05, Dan Malek a écrit :
Hello Cristophe.
On Sep 10, 2018, at 7:34 AM, Christophe Leroy wrote:
On the powerpc8xx, handling 16k size pages requires to have page tables with 4
identical entries.
Do you think a 16k page is useful? Back in the day, the goal was to keep
On Mon, Sep 10, 2018 at 06:29:12PM +1000, Alexey Kardashevskiy wrote:
> The kvmppc_gpa_to_ua() helper itself takes care of the permission
> bits in the TCE and yet every single caller removes them.
>
> This changes semantics of kvmppc_gpa_to_ua() so it takes TCEs
> (which are GPAs + TCE
On Mon, Sep 10, 2018 at 06:29:07PM +1000, Alexey Kardashevskiy wrote:
> At the moment the real mode handler of H_PUT_TCE calls iommu_tce_xchg_rm()
> which in turn reads the old TCE and if it was a valid entry - marks
> the physical page dirty if it was mapped for writing. Since it is
> the real
Currently on P9N DD2.1 we end up taking infinite TM facility
unavailable exceptions on the first TM usage by userspace.
In the special case of TM no suspend (P9N DD2.1), Linux is told TM is
off via CPU dt-ftrs but told to (partially) use it via
OPAL_REINIT_CPUS_TM_SUSPEND_DISABLED. So HFSCR[TM]
From: Yuantian Tang
The compatible string is not correct in the clock node.
The clocks property refers to the wrong node too.
This patch is to fix them.
Signed-off-by: Tang Yuantian
---
arch/powerpc/boot/dts/fsl/t1023si-post.dtsi |8
1 files changed, 4 insertions(+), 4
On Mon, Sep 10, 2018 at 08:05:38PM +1000, Michael Neuling wrote:
>
> > > + /* Make sure we aren't patching a freed init section */
> > > + if (in_init_section(patch_addr) && init_freed())
> > > + return 0;
> > > +
> >
> > Do we even need the init_freed() check?
>
> Maybe not. If
Hi,
On Mon, 2018-09-10 at 07:37 +0200, Christophe Leroy wrote:
> Le 10/09/2018 à 01:13, Radu Rendec a écrit :
> >
> > I'm using U-boot as well, but it's just not configured to read or clear
> > the RSR. I'm curious: if U-boot reads/clears the RSR in your case, how
> > do you make the initial
Hello Cristophe.
> On Sep 10, 2018, at 7:34 AM, Christophe Leroy wrote:
>
> On the powerpc8xx, handling 16k size pages requires to have page tables with
> 4 identical entries.
Do you think a 16k page is useful? Back in the day, the goal was to keep the
fault handling and management
On Mon, 10 Sep 2018 14:34:37 +
Christophe Leroy wrote:
> Hi,
>
> I'm having a hard time figuring out the best way to handle the following
> situation:
>
> On the powerpc8xx, handling 16k size pages requires to have page tables
> with 4 identical entries.
>
> Initially I was thinking
On Mon, Sep 10, 2018 at 07:22:04AM +0200, Christophe LEROY wrote:
>
>
> Le 07/09/2018 à 21:41, Corentin Labbe a écrit :
> > This patch adds setbits32/clrbits32/clrsetbits32 and
> > setbits64/clrbits64/clrsetbits64 in linux/setbits.h header.
>
> So you changed the name of setbits32() ... to
On Mon, Sep 10, 2018 at 07:16:56AM +0200, Christophe LEROY wrote:
>
>
> Le 07/09/2018 à 21:41, Corentin Labbe a écrit :
> > Since setbits32/clrbits32 work on be32, it's better to remove ambiguity on
> > the used data type.
>
> Wouldn't it be better to call them setbits_be32() / clrbits_be32()
On Fri, Sep 07, 2018 at 03:00:40PM -0500, Scott Wood wrote:
> On Fri, 2018-09-07 at 19:41 +, Corentin Labbe wrote:
> > This patch adds setbits32/clrbits32/clrsetbits32 and
> > setbits64/clrbits64/clrsetbits64 in linux/setbits.h header.
> >
> > Signed-off-by: Corentin Labbe
> > ---
> >
On Sun, Sep 09, 2018 at 03:39:13PM +1000, Nicholas Piggin wrote:
> Re-sending this one with the used-uinitialized warning in patch
> 3 fixed.
>
> Greg these patches are needed to fix regressions in this merge
> window, please consider them for your tty tree.
All now queued up, thanks.
greg k-h
Hello Sam,
On 9/10/18 8:03 AM, Sam Bobroff wrote:
> Hi Sergey,
>
> On Thu, Sep 06, 2018 at 02:57:52PM +0300, Sergey Miroshnichenko wrote:
>> Reading an empty slot returns all ones, which triggers a false
>> EEH error event on PowerNV.
>>
>> New callbacks pcibios_rescan_prepare/done are
Hello Sam,
On 9/10/18 7:47 AM, Sam Bobroff wrote:
> Hi Sergey,
>
> On Thu, Sep 06, 2018 at 02:57:49PM +0300, Sergey Miroshnichenko wrote:
>> The pci_dn structures can be created not only from DT, but also
>> directly from newly discovered PCIe devices, so allocate them
>> dynamically.
>>
>>
Hello Sam,
On 9/10/18 7:23 AM, Sam Bobroff wrote:
> Hi Sergey,
>
> On Thu, Sep 06, 2018 at 02:57:48PM +0300, Sergey Miroshnichenko wrote:
>> The pci_dn structures are retrieved from a DT, but hot-plugged PCIe
>> devices don't have them. Don't stop PCIe I/O in absence of pci_dn, so
>> it is now
There are three instances in which dlpar hotplug events are invoked;
handling a hotplug interrupt (in a kvm guest), handling a dlpar
request through sysfs, and updating LMB affinity when handling a
PRRN event. Only in the case of handling a hotplug interrupt do we
have to put the work on a
When a PRRN event is received we are already running in a worker
thread. Instead of spawning off another worker thread on the prrn_work
workqueue to handle the PRRN event we can just call the PRRN handler
routine directly.
With this update we can also pass the scope variable for the PRRN
event
Stress testing has uncovered issues with handling continuously queued PRRN
events. Running PRRN events in this way can seriously load the system given
the sheer volume of dlpar actions being handled, eventually resulting
in a system oops (see below). This patchset ensures that PRRN
events are
On Mon, Sep 10, 2018 at 04:05:34PM +0200, Christophe LEROY wrote:
>
> This time it works, thanks for your help.
You're welcome.
> Should we find a may to automate that in the Makefile when
> CROSS_COMPILE is defined ?
The situation here with an old gcc is really an oddity.
I was instead
Enable the 'dtbs' target for powerpc. This allows building all the dts
files in arch/powerpc/boot/dts/ when COMPILE_TEST and OF_ALL_DTBS are
enabled.
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Rob Herring
---
There is nothing arch specific about building dtb files other than their
location under /arch/*/boot/dts/. Keeping each arch aligned is a pain.
The dependencies and supported targets are all slightly different.
Also, a cross-compiler for each arch is needed, but really the host
compiler
Align powerpc with other architectures which build the dtb files in the
same directory as the dts files. This is also in line with most other
build targets which are located in the same directory as the source.
This move will help enable the 'dtbs' target which builds all the dtbs
regardless of
This series addresses a couple of issues I have with building dts files.
First, the ability to build all the dts files in the tree. This has been
supported on most arches for some time with powerpc being the main
exception. The reason powerpc wasn't supported was it needed a change
in the
Hi,
I'm having a hard time figuring out the best way to handle the following
situation:
On the powerpc8xx, handling 16k size pages requires to have page tables
with 4 identical entries.
Initially I was thinking about handling this by simply modifying
pte_index() which changing pte_t type
On Sun, Sep 9, 2018 at 6:28 PM Masahiro Yamada
wrote:
>
> 2018-09-06 8:53 GMT+09:00 Rob Herring :
> > There is nothing arch specific about building dtb files other than their
> > location under /arch/*/boot/dts/. Keeping each arch aligned is a pain.
> > The dependencies and supported targets are
On Mon, Sep 10, 2018 at 2:09 PM Christophe Leroy
wrote:
>
> On little endian platforms, csum_ipv6_magic() keeps len and proto in
> CPU byte order. This generates a bad results leading to ICMPv6 packets
> from other hosts being dropped by powerpc64le platforms.
>
> In order to fix this, len and
Le 10/09/2018 à 15:56, Luc Van Oostenryck a écrit :
On Mon, Sep 10, 2018 at 01:19:07PM +, Christophe Leroy wrote:
On 09/10/2018 11:34 AM, Luc Van Oostenryck wrote:
On Mon, Sep 10, 2018 at 09:56:33AM +, Christophe Leroy wrote:
# export REAL_CC=ppc-linux-gcc
# make CHECK="cgcc
On Mon, Sep 10, 2018 at 01:19:07PM +, Christophe Leroy wrote:
>
>
> On 09/10/2018 11:34 AM, Luc Van Oostenryck wrote:
> > On Mon, Sep 10, 2018 at 09:56:33AM +, Christophe Leroy wrote:
> > >
> > > # export REAL_CC=ppc-linux-gcc
> > > # make CHECK="cgcc -target=ppc -D_CALL_ELF=2
fsl-mc bus support the new iommu-map property. Comply to this binding
for fsl_mc bus.
Signed-off-by: Nipun Gupta
Reviewed-by: Laurentiu Tudor
---
arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git
of_dma_configure() API expects coherent_dma_mask to be correctly
set in the devices. This patch does the needful.
Signed-off-by: Nipun Gupta
Reviewed-by: Robin Murphy
---
drivers/bus/fsl-mc/fsl-mc-bus.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c
This patch adds support of dma configuration for devices on fsl-mc
bus using 'dma_configure' callback for busses. Also, directly calling
arch_setup_dma_ops is removed from the fsl-mc bus.
Signed-off-by: Nipun Gupta
Reviewed-by: Laurentiu Tudor
Reviewed-by: Robin Murphy
---
Implement bus specific support for the fsl-mc bus including
registering arm_smmu_ops and bus specific device add operations.
Signed-off-by: Nipun Gupta
Reviewed-by: Robin Murphy
---
drivers/iommu/arm-smmu.c | 7 +++
drivers/iommu/iommu.c| 13 +
include/linux/fsl/mc.h |
With of_pci_map_rid available for all the busses, use the function
for configuration of devices on fsl-mc bus
Signed-off-by: Nipun Gupta
Reviewed-by: Robin Murphy
---
drivers/iommu/of_iommu.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/iommu/of_iommu.c
iommu-map property is also used by devices with fsl-mc. This
patch moves the of_pci_map_rid to generic location, so that it
can be used by other busses too.
'of_pci_map_rid' is renamed here to 'of_map_rid' and there is no
functional change done in the API.
Signed-off-by: Nipun Gupta
The existing IOMMU bindings cannot be used to specify the relationship
between fsl-mc devices and IOMMUs. This patch adds a generic binding for
mapping fsl-mc devices to IOMMUs, using iommu-map property.
Signed-off-by: Nipun Gupta
Reviewed-by: Rob Herring
Acked-by: Robin Murphy
---
This patchset defines IOMMU DT binding for fsl-mc bus and adds
support in SMMU for fsl-mc bus.
These patches
- Define property 'iommu-map' for fsl-mc bus (patch 1)
- Integrates the fsl-mc bus with the SMMU using this
IOMMU binding (patch 2,3,4)
- Adds the dma configuration support for
Hi Michael,
Do you plan to pull it for 4.20 ?
Cheers,
Laurent.
On 20/08/2018 16:29, Laurent Dufour wrote:
> On very large system we could see soft lockup fired when a process is
> exiting
>
> watchdog: BUG: soft lockup - CPU#851 stuck for 21s! [forkoff:215523]
> Modules linked in: pseries_rng
On 09/10/2018 11:34 AM, Luc Van Oostenryck wrote:
On Mon, Sep 10, 2018 at 09:56:33AM +, Christophe Leroy wrote:
# export REAL_CC=ppc-linux-gcc
# make CHECK="cgcc -target=ppc -D_CALL_ELF=2 -D__GCC__=5
-D__GCC_MINOR__=4" C=2 arch/powerpc/kernel/process.o
scripts/kconfig/conf --syncconfig
On Sun, Sep 09, 2018 at 07:04:25PM +0200, Benjamin Herrenschmidt wrote:
> On Fri, 2018-08-31 at 14:58 +1000, Benjamin Herrenschmidt wrote:
> >
> > > A long shot, but something to consider, is that I failed to cover the
> > > cases of dynamic devicetree updates (removing nodes that contain a
> > >
On Mon, Sep 10, 2018 at 09:56:33AM +, Christophe Leroy wrote:
>
> # export REAL_CC=ppc-linux-gcc
> # make CHECK="cgcc -target=ppc -D_CALL_ELF=2 -D__GCC__=5
> -D__GCC_MINOR__=4" C=2 arch/powerpc/kernel/process.o
> scripts/kconfig/conf --syncconfig Kconfig
> #
> # configuration written to
Commit-ID: e5e96fafd9028b1478b165db78c52d981c14f471
Gitweb: https://git.kernel.org/tip/e5e96fafd9028b1478b165db78c52d981c14f471
Author: Srikar Dronamraju
AuthorDate: Fri, 10 Aug 2018 22:30:18 +0530
Committer: Ingo Molnar
CommitDate: Mon, 10 Sep 2018 10:13:45 +0200
sched/topology: Set
On Mon, 10 Sep 2018 12:16:35 +0200
Christophe LEROY wrote:
> Le 10/09/2018 à 12:05, Michael Neuling a écrit :
> >
> >>> + /* Make sure we aren't patching a freed init section */
> >>> + if (in_init_section(patch_addr) && init_freed())
> >>> + return 0;
> >>> +
> >>
> >> Do we even
Le 10/09/2018 à 12:05, Michael Neuling a écrit :
+ /* Make sure we aren't patching a freed init section */
+ if (in_init_section(patch_addr) && init_freed())
+ return 0;
+
Do we even need the init_freed() check?
Maybe not. If userspace isn't up, then maybe
> > + /* Make sure we aren't patching a freed init section */
> > + if (in_init_section(patch_addr) && init_freed())
> > + return 0;
> > +
>
> Do we even need the init_freed() check?
Maybe not. If userspace isn't up, then maybe it's ok to skip.
> What user input can we process
> > For stable I've marked this as v4.13+ since that's when we refactored
> > code-patching.c but it could go back even further than that. In
> > reality though, I think we can only hit this since the first
> > spectre/meltdown changes.
>
> Which means it affects all maintained stable trees
On 09/10/2018 09:28 AM, Luc Van Oostenryck wrote:
On Mon, Sep 10, 2018 at 08:49:07AM +0200, Christophe LEROY wrote:
Le 07/09/2018 à 20:19, Nick Desaulniers a écrit :
On Fri, Sep 7, 2018 at 11:13 AM Luc Van Oostenryck wrote:
Sparse expand these macros to the same version than the compiler
On Mon, 10 Sep 2018 15:44:05 +1000
Michael Neuling wrote:
> This stops us from doing code patching in init sections after they've
> been freed.
>
> In this chain:
> kvm_guest_init() ->
> kvm_use_magic_page() ->
> fault_in_pages_readable() ->
>__get_user() ->
>
Hi Scott,
On 2018/9/8 4:35, Scott Wood wrote:
>
> On Fri, 2018-08-31 at 11:52 +0800, Ran Wang wrote:
> > This driver is to provide a independent framework for PM service
> > provider and consumer to configure system level wake up feature. For
> > example, RCPM driver could register a callback
Hi Scott,
On 2018/9/8 18:16, Scott Wood wrote:
>
> On Fri, 2018-08-31 at 11:52 +0800, Ran Wang wrote:
> > The NXP's QorIQ Processors based on ARM Core have RCPM module (Run
> > Control and Power Management), which performs all device-level tasks
> > associated with power management such as
When building with clang crt0's _zimage_start is not marked weak, which
breaks the build when linking the kernel image:
$ objdump -t arch/powerpc/boot/crt0.o |grep _zimage_start$
0058 g .text _zimage_start
ld: arch/powerpc/boot/wrapper.a(crt0.o): in
Clang's assembler does not like the syntax of the cmpdi:
arch/powerpc/boot/crt0.S:168:22: error: unexpected modifier on variable
reference
cmpdi 12,RELACOUNT@l
^
arch/powerpc/boot/crt0.S:168:11: error: unknown operand
cmpdi 12,RELACOUNT@l
Two fixes to get us closer to building with clang. With a one patch[1]
on top of clang master I can build and boot a powernv kernel:
$ make ARCH=powerpc powernv_defconfig
$ ./scripts/config -e PPC_DISABLE_WERROR -d FTRACE -d BTRFS_FS -d MD_RAID456
$ make CC=/scratch/joel/llvm-build/bin/clang-8
> > this to set the VIRTIO_F_IOMMU_PLATFORM flag. But for example
> > QEMU has the use of iommu_platform attribute disabled for virtio-gpu
> > device. So would also like to move towards not having to specify
> > the VIRTIO_F_IOMMU_PLATFORM flag.
>
> Specifying VIRTIO_F_IOMMU_PLATFORM is the
Hi Scott,
On 2018/9/8 4:23, Scott Wood wrote:
>
> On Fri, 2018-08-31 at 11:52 +0800, Ran Wang wrote:
> > +Optional properties:
> > + - big-endian : Indicate RCPM registers is big-endian. A RCPM node
> > + that doesn't have this property will be regarded as little-endian.
>
> You've just
The kvmppc_gpa_to_ua() helper itself takes care of the permission
bits in the TCE and yet every single caller removes them.
This changes semantics of kvmppc_gpa_to_ua() so it takes TCEs
(which are GPAs + TCE permission bits) to make the callers simpler.
This should cause no behavioural change.
At the moment if the PUT_TCE{_INDIRECT} handlers fail to update
the hardware tables, we print a warning once, clear the entry and
continue. This is so as at the time the assumption was that if
a VFIO device is hotplugged into the guest, and the userspace replays
virtual DMA mappings (i.e. TCEs) to
The userspace can request an arbitrary supported page size for a DMA
window and this works fine as long as the mapped memory is backed with
the pages of the same or bigger size; if this is not the case,
mm_iommu_ua_to_hpa{_rm}() fail and tables do not populated with
dangerously incorrect TCEs.
The KVM TCE handlers are written in a way so they fail when either
something went horribly wrong or the userspace did some obvious mistake
such as passing a misaligned address.
We are going to enhance the TCE checker to fail on attempts to map bigger
IOMMU page than the underlying pinned memory
At the moment the real mode handler of H_PUT_TCE calls iommu_tce_xchg_rm()
which in turn reads the old TCE and if it was a valid entry - marks
the physical page dirty if it was mapped for writing. Since it is
the real mode, realmode_pfn_to_page() is used instead of pfn_to_page()
to get the page
Hi,
Here is my current queue of TCE/KVM patches.
1/6 is a bugfix for https://bugzilla.redhat.com/show_bug.cgi?id=1620360
2/6..5/6 are to help with testing
https://bugzilla.redhat.com/show_bug.cgi?id=1613190
6/6 is a small cleanup
This is based on sha1
11da3a7 Linus Torvalds "Linux 4.19-rc3".
We return H_TOO_HARD from TCE update handlers when we think that
the next handler (realmode -> virtual mode -> user mode) has a chance to
handle the request; H_HARDWARE/H_CLOSED otherwise.
This changes the handlers to return H_TOO_HARD on every error giving
the userspace an opportunity to handle
On Mon, 10 Sep 2018 15:44:05 +1000
Michael Neuling wrote:
> This stops us from doing code patching in init sections after they've
> been freed.
>
> In this chain:
> kvm_guest_init() ->
> kvm_use_magic_page() ->
> fault_in_pages_readable() ->
>__get_user() ->
>
On Mon, Sep 10, 2018 at 9:42 AM Ondrej Mosnacek wrote:
> commit 0522236d4f9c5ab2e79889cb020d1acbe5da416e upstream.
>
> Conflicts:
> drivers/crypto/vmx/
> aes_cbc.c - adapted enable/disable calls to v4.4 state
> aes_xts.c - did not exist yet in v4.4
>
> This patch fixes sleep-in-atomic
commit 0522236d4f9c5ab2e79889cb020d1acbe5da416e upstream.
Conflicts:
drivers/crypto/vmx/
aes_cbc.c - adapted enable/disable calls to v4.4 state
aes_xts.c - did not exist yet in v4.4
This patch fixes sleep-in-atomic bugs in AES-CBC and AES-XTS VMX
implementations. The problem is that
On Thu, Sep 06, 2018 at 07:09:09PM -0500, Jiandi An wrote:
> For virtio device we have to pass in iommu_platform=true flag for
> this to set the VIRTIO_F_IOMMU_PLATFORM flag. But for example
> QEMU has the use of iommu_platform attribute disabled for virtio-gpu
> device. So would also like to
On little endian platforms, csum_ipv6_magic() keeps len and proto in
CPU byte order. This generates a bad results leading to ICMPv6 packets
from other hosts being dropped by powerpc64le platforms.
In order to fix this, len and proto should be converted to network
byte order ie bigendian byte
Christophe Leroy writes:
> On 09/06/2018 09:58 AM, Aneesh Kumar K.V wrote:
>> Christophe Leroy writes:
>>
>>> Today flags like for instance _PAGE_RW or _PAGE_USER are used through
>>> common parts of code.
>>> Using those directly in common parts of code have proven to lead to
>>> mistakes or
Thanks for looking into this patch Stewart
Stewart Smith writes:
> We're about to introduce an MPIPL reboot type (to take a firmware
> assisted kdump style thing), and we maybe should have a reboot type to
> force attempting a fast-reboot, and this makes me think if we should add
> those in
71 matches
Mail list logo
