On 1/15/16, Denis Kirjanov wrote:
> On 1/15/16, Cyril Bur wrote:
>> This patch adds the ability to be able to save the FPU registers to the
>> thread struct without giving up (disabling the facility) next time the
>> process returns to userspace.
>>
>> This patch optimises the thread copy path (a
On 1/15/16, Cyril Bur wrote:
> This patch adds the ability to be able to save the FPU registers to the
> thread struct without giving up (disabling the facility) next time the
> process returns to userspace.
>
> This patch optimises the thread copy path (as a result of a fork() or
> clone()) so th
Current vfio-pci implementation disallows to mmap MSI-X
table in case that user get to touch this directly.
But we should allow to mmap these MSI-X tables if the PCI
host bridge supports filtering of MSIs.
Signed-off-by: Yongji Xie
---
drivers/vfio/pci/vfio_pci.c |6 --
1 file changed,
This patch enables msi_filtered bit for any IODA host bridge.
Signed-off-by: Yongji Xie
---
arch/powerpc/platforms/powernv/pci-ioda.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 414fd1a.
MSI-X tables are not allowed to be mmapped in vfio-pci
driver in case that user get to touch this directly.
This will cause some performance issues when when PCI
adapters have critical registers in the same page as
the MSI-X table.
However, some kind of PCI host bridge such as IODA bridge
on Power
When vfio passthrough a PCI device of which MMIO BARs
are smaller than PAGE_SIZE, guest will not handle the
mmio accesses to the BARs which leads to mmio emulations
in host.
This is because vfio will not allow to passthrough one
BAR's mmio page which may be shared with other BARs.
To solve this p
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 BARs if PCI
resource allocator can make sure these BARs' mmio page will
not be shared with other BARs.
Current vfio-pci implementation disallows to mmap
sub-page(size < PAGE_SIZE) MMIO BARs and MSI-X table. This is because
sub-page BARs' mmio page may be shared with other BARs and MSI-X table
should not be accessed directly from the guest for security reasons.
But these will easily cause some perfo
On Fri, 2016-01-15 at 16:04 +1100, Cyril Bur wrote:
> This patch adds the ability to be able to save the VSX registers to
> the
> thread struct without giving up (disabling the facility) next time
> the
> process returns to userspace.
>
> This patch builds on a previous optimisation for the FPU an
On Fri, 2016-01-15 at 16:04 +1100, Cyril Bur wrote:
> This patch adds the ability to be able to save the FPU registers to
> the
> thread struct without giving up (disabling the facility) next time
> the
> process returns to userspace.
>
> This patch optimises the thread copy path (as a result of a
On Fri, 2016-01-15 at 16:54 +1100, Cyril Bur wrote:
> On Fri, 15 Jan 2016 16:42:22 +1100
> Michael Neuling wrote:
>
> > On Fri, 2016-01-15 at 16:04 +1100, Cyril Bur wrote:
> > > With threads leaving the math bits enabled in their saved MSR to
> > > indicate
> > > that the hardware is hot and a re
> Currently the FPU, VEC and VSX facilities are lazily loaded. This is not a
> problem unless a process is using these facilities.
> Modern versions of GCC are very good at automatically vectorising code, new
> and modernised workloads make use of floating point and vector facilities,
> even the k
On Fri, 15 Jan 2016 16:42:22 +1100
Michael Neuling wrote:
> On Fri, 2016-01-15 at 16:04 +1100, Cyril Bur wrote:
> > With threads leaving the math bits enabled in their saved MSR to indicate
> > that the hardware is hot and a restore is not needed, children need to turn
> > it off as when they do
On Fri, 2016-01-15 at 16:04 +1100, Cyril Bur wrote:
> With threads leaving the math bits enabled in their saved MSR to indicate
> that the hardware is hot and a restore is not needed, children need to turn
> it off as when they do get scheduled, there's no way their registers could
> have been hot.
Michael Ellerman writes:
>> > > Applied to powerpc next, thanks.
>> > >
>> > > https://git.kernel.org/powerpc/c/affddff69c55eb68969448f35f
>> >
>> > The firmware interface changed slightly since this kernel patch[1], it
>> > added a parameter to OPAL_CONSOLE_FLUSH which accepted the terminal
>>
This patch adds the ability to be able to save the FPU registers to the
thread struct without giving up (disabling the facility) next time the
process returns to userspace.
This patch optimises the thread copy path (as a result of a fork() or
clone()) so that the parent thread can return to usersp
Currently the FPU, VEC and VSX facilities are lazily loaded. This is not a
problem unless a process is using these facilities.
Modern versions of GCC are very good at automatically vectorising code, new
and modernised workloads make use of floating point and vector facilities,
even the kernel make
This patch adds the ability to be able to save the VEC registers to the
thread struct without giving up (disabling the facility) next time the
process returns to userspace.
This patch builds on a previous optimisation for the FPU registers in the
thread copy path to avoid a possibly pointless relo
This patch adds the ability to be able to save the VSX registers to the
thread struct without giving up (disabling the facility) next time the
process returns to userspace.
This patch builds on a previous optimisation for the FPU and VEC registers
in the thread copy path to avoid a possibly pointl
Test that the non volatile floating point and Altivec registers get
correctly preserved across the fork() syscall.
fork() works nicely for this purpose, the registers should be the same for
both parent and child
Signed-off-by: Cyril Bur
---
tools/testing/selftests/powerpc/Makefile |
Load up the non volatile FPU and VMX regs and ensure that they are the
expected value in a signal handler
Signed-off-by: Cyril Bur
---
tools/testing/selftests/powerpc/math/.gitignore | 2 +
tools/testing/selftests/powerpc/math/Makefile | 4 +-
tools/testing/selftests/powerpc/math/fpu_s
Loop in assembly checking the registers with many threads.
Signed-off-by: Cyril Bur
---
tools/testing/selftests/powerpc/math/.gitignore| 2 +
tools/testing/selftests/powerpc/math/Makefile | 5 +-
tools/testing/selftests/powerpc/math/fpu_asm.S | 34 +++
tools/testing/selftes
With threads leaving the math bits enabled in their saved MSR to indicate
that the hardware is hot and a restore is not needed, children need to turn
it off as when they do get scheduled, there's no way their registers could
have been hot.
Signed-off-by: Cyril Bur
---
arch/powerpc/kernel/process
Cover-letter for V1 of the series is at
https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-November/136350.html
Version one of this series used a cmpb instruction in handcrafted assembly
which it turns out is not supported on older power machines. Michael
suggested replacing it with crandc, whic
> > + - fsl-lane-handle: phandle, specifies a reference to a node representing
> > a
> Serdes.
> > + - fsl-lane-reg: offset and length of the register set for the serdes
> > lane.
>
> These should be fsl,... not fsl-...
Will fix it.
Thank you!
Shaohui
___
> -Original Message-
> From: Andrew Lunn [mailto:and...@lunn.ch]
> Sent: Friday, January 15, 2016 12:44 AM
> To: shh@gmail.com
> Cc: devicet...@vger.kernel.org; net...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org; f.faine...@gmail.com; da...@davemloft.net; Shaohui Xie
> Subject: R
On Thu, Jan 14, 2016 at 04:27:18PM +0800, shh@gmail.com wrote:
> From: Shaohui Xie
>
> PCS PHY can support backplane (1000BASE-KX and 10GBASE-KR), this needs
> to change corresponding serdes lane settings, so a reference is needed
> for serdes lane. This patch describes properties needed for
Russell Currey writes:
> "p5ioc2 is used by approximately 2 machines in the world, and has never
> ever been a supported configuration."
>
> The code for p5ioc2 is essentially unused and complicates what is already
> a very complicated codebase. Its removal is essentially a "free win" in
> the ef
On 01/14/2016 04:47 PM, Paul E. McKenney wrote:
On Thu, Jan 14, 2016 at 03:33:40PM -0800, Leonid Yegoshin wrote:
Don't be fooled here by words "ordered" and "completed" - it is HW
design items and actually written poorly.
Just assume that SYNC_MB is absolutely the same as SYNC for any CPU
and co
On Thu, Jan 14, 2016 at 03:33:40PM -0800, Leonid Yegoshin wrote:
> On 01/14/2016 02:55 PM, Paul E. McKenney wrote:
> >OK, so it looks like Will was asking not about WRC+addr+addr, but instead
> >about WRC+sync+addr.
> (He actually asked twice about this and that too but skip this)
Fair enough! ;-
On 12/01/16 18:15, Aneesh Kumar K.V wrote:
> This is needed so that we can support both hash and radix page table
> using single kernel. Radix kernel uses a 4 level table.
>
> Signed-off-by: Aneesh Kumar K.V
> ---
> arch/powerpc/Kconfig | 1 +
> arch/powerpc/include/as
On Thu, 2016-01-14 at 17:59 -0200, Guilherme G. Piccoli wrote:
> On 01/13/2016 07:25 PM, Michael Ellerman wrote:
> > But for example what happens if the user boots with eeh=off on the command
> > line, and then hotplugs a device. It looks like because you're not using
> > eeh_enabled() you will in
On 01/14/2016 02:55 PM, Paul E. McKenney wrote:
OK, so it looks like Will was asking not about WRC+addr+addr, but instead
about WRC+sync+addr.
(He actually asked twice about this and that too but skip this)
I am guessing that the manual's "Older instructions which must be globally
performed wh
On 01/14/2016 02:24 PM, Paul E. McKenney wrote:
Actually, the Linux kernel doesn't have an acquire barrier, just an
smp_load_acquire(). Or did someone sneak one in while I wasn't looking?
That was an exactly starting point for this discussion. This patch just
pulls out from MIPS files smp_load_a
On Thu, Jan 14, 2016 at 01:36:50PM -0800, Leonid Yegoshin wrote:
> On 01/14/2016 01:29 PM, Paul E. McKenney wrote:
> >
> >>On 01/14/2016 12:34 PM, Paul E. McKenney wrote:
> >>>
> >>>The WRC+addr+addr is OK because data dependencies are not required to be
> >>>transitive, in other words, they are no
On Thu, Jan 14, 2016 at 01:45:44PM -0800, Leonid Yegoshin wrote:
> On 01/14/2016 01:34 PM, Paul E. McKenney wrote:
> >On Thu, Jan 14, 2016 at 12:46:43PM -0800, Leonid Yegoshin wrote:
> >>On 01/14/2016 12:15 PM, Peter Zijlstra wrote:
> >>>On Thu, Jan 14, 2016 at 11:42:02AM -0800, Leonid Yegoshin wro
On Thu, Jan 14, 2016 at 01:24:34PM -0800, Leonid Yegoshin wrote:
> On 01/14/2016 12:48 PM, Paul E. McKenney wrote:
> >
> >So SYNC_RMB is intended to implement smp_rmb(), correct?
> Yes.
> >
> >You could use SYNC_ACQUIRE() to implement read_barrier_depends() and
> >smp_read_barrier_depends(), but SY
On 01/14/2016 01:34 PM, Paul E. McKenney wrote:
On Thu, Jan 14, 2016 at 12:46:43PM -0800, Leonid Yegoshin wrote:
On 01/14/2016 12:15 PM, Peter Zijlstra wrote:
On Thu, Jan 14, 2016 at 11:42:02AM -0800, Leonid Yegoshin wrote:
An the only point - please use an appropriate SYNC_* barriers instead
On 01/14/2016 01:29 PM, Paul E. McKenney wrote:
On 01/14/2016 12:34 PM, Paul E. McKenney wrote:
The WRC+addr+addr is OK because data dependencies are not required to be
transitive, in other words, they are not required to flow from one CPU to
another without the help of an explicit memory bar
On Thu, Jan 14, 2016 at 12:46:43PM -0800, Leonid Yegoshin wrote:
> On 01/14/2016 12:15 PM, Peter Zijlstra wrote:
> >On Thu, Jan 14, 2016 at 11:42:02AM -0800, Leonid Yegoshin wrote:
> >>An the only point - please use an appropriate SYNC_* barriers instead of
> >>heavy bold hammer. That stuff was des
On Thu, Jan 14, 2016 at 01:01:05PM -0800, Leonid Yegoshin wrote:
> I need some time to understand your test examples. However,
Understood.
> On 01/14/2016 12:34 PM, Paul E. McKenney wrote:
> >
> >
> >The WRC+addr+addr is OK because data dependencies are not required to be
> >transitive, in other
On 01/14/2016 12:48 PM, Paul E. McKenney wrote:
So SYNC_RMB is intended to implement smp_rmb(), correct?
Yes.
You could use SYNC_ACQUIRE() to implement read_barrier_depends() and
smp_read_barrier_depends(), but SYNC_RMB probably does not suffice.
If smp_read_barrier_depends() is used to sep
I need some time to understand your test examples. However,
On 01/14/2016 12:34 PM, Paul E. McKenney wrote:
The WRC+addr+addr is OK because data dependencies are not required to be
transitive, in other words, they are not required to flow from one CPU to
another without the help of an explicit
On Thu, Jan 14, 2016 at 12:12:53PM -0800, Leonid Yegoshin wrote:
> On 01/14/2016 04:04 AM, Will Deacon wrote:
> >Consequently, it's important that the architecture back-ends
> >implement these portable primitives (e.g. smp_mb()) in a way that
> >satisfies the kernel memory model so that core code d
On 01/14/2016 12:15 PM, Peter Zijlstra wrote:
On Thu, Jan 14, 2016 at 11:42:02AM -0800, Leonid Yegoshin wrote:
An the only point - please use an appropriate SYNC_* barriers instead of
heavy bold hammer. That stuff was design explicitly to support the
requirements of Documentation/memory-barriers
On Thu, Jan 14, 2016 at 09:15:13PM +0100, Peter Zijlstra wrote:
> On Thu, Jan 14, 2016 at 11:42:02AM -0800, Leonid Yegoshin wrote:
> > An the only point - please use an appropriate SYNC_* barriers instead of
> > heavy bold hammer. That stuff was design explicitly to support the
> > requirements of
On Thu, Jan 14, 2016 at 09:15:13PM +0100, Peter Zijlstra wrote:
> On Thu, Jan 14, 2016 at 11:42:02AM -0800, Leonid Yegoshin wrote:
> > An the only point - please use an appropriate SYNC_* barriers instead of
> > heavy bold hammer. That stuff was design explicitly to support the
> > requirements of
On Thu, Jan 14, 2016 at 11:28:18AM -0800, Leonid Yegoshin wrote:
> On 01/14/2016 04:14 AM, Will Deacon wrote:
> >On Wed, Jan 13, 2016 at 02:26:16PM -0800, Leonid Yegoshin wrote:
> >
> >> Moreover, there are voices against guarantee that it will be in future
> >>and that voices point me to Docum
On Thu, Jan 14, 2016 at 11:42:02AM -0800, Leonid Yegoshin wrote:
> An the only point - please use an appropriate SYNC_* barriers instead of
> heavy bold hammer. That stuff was design explicitly to support the
> requirements of Documentation/memory-barriers.txt
That's madness. That document changes
On 01/14/2016 04:04 AM, Will Deacon wrote:
Consequently, it's important that the architecture back-ends implement
these portable primitives (e.g. smp_mb()) in a way that satisfies the
kernel memory model so that core code doesn't need to worry about the
underlying architecture for synchronisati
On 01/13/2016 07:25 PM, Michael Ellerman wrote:
But for example what happens if the user boots with eeh=off on the command
line, and then hotplugs a device. It looks like because you're not using
eeh_enabled() you will incorrectly initialise EEH anyway?
Thanks very much for this catch Michael!
On 01/14/2016 08:16 AM, Paul E. McKenney wrote:
On Thu, Jan 14, 2016 at 12:04:45PM +, Will Deacon wrote:
On Wed, Jan 13, 2016 at 12:58:22PM -0800, Leonid Yegoshin wrote:
On 01/13/2016 12:48 PM, Peter Zijlstra wrote:
On Wed, Jan 13, 2016 at 11:02:35AM -0800, Leonid Yegoshin wrote:
I ask H
On 01/14/2016 04:14 AM, Will Deacon wrote:
On Wed, Jan 13, 2016 at 02:26:16PM -0800, Leonid Yegoshin wrote:
Moreover, there are voices against guarantee that it will be in future
and that voices point me to Documentation/memory-barriers.txt section "DATA
DEPENDENCY BARRIERS" examples which
On Thu, Jan 14, 2016 at 12:04:45PM +, Will Deacon wrote:
> On Wed, Jan 13, 2016 at 12:58:22PM -0800, Leonid Yegoshin wrote:
> > On 01/13/2016 12:48 PM, Peter Zijlstra wrote:
> > >On Wed, Jan 13, 2016 at 11:02:35AM -0800, Leonid Yegoshin wrote:
> > >
> > >>I ask HW team about it but I have a que
On Thu, Jan 14, 2016 at 04:23:59PM +0800, shh@gmail.com wrote:
> From: Shaohui Xie
>
> This commit adds necessary definitions for the PHY layer to recognize
> backplane Ethernet 1000BASE-KX and 10GBASE-KR as valid PHY interfaces,
> "1000base-kx" for 1000BASE-KX, "10gbase-kr" for 10GBASE-KR.
>
On Mon, 2016-01-04 at 15:38 -0600, Scott Wood wrote:
> Highlights include moving QE code out of arch/powerpc (to be shared with
> arm), device tree updates, and minor fixes.
>
> Sorry for sending this in so late and not getting to everything in my
> queue -- in addition to the holidays I've been
On Wed, Jan 13, 2016 at 02:26:16PM -0800, Leonid Yegoshin wrote:
> On 01/13/2016 02:45 AM, Will Deacon wrote:
> >>
> >I don't think the address dependency is enough on its own. By that
> >reasoning, the following variant (WRC+addr+addr) would work too:
> >
> >
> >P0:
> >Wx = 1
> >
> >P1:
> >Rx == 1
On Wed, Jan 13, 2016 at 12:58:22PM -0800, Leonid Yegoshin wrote:
> On 01/13/2016 12:48 PM, Peter Zijlstra wrote:
> >On Wed, Jan 13, 2016 at 11:02:35AM -0800, Leonid Yegoshin wrote:
> >
> >>I ask HW team about it but I have a question - has it any relationship with
> >>replacing MIPS SYNC with light
On Tuesday 12 January 2016 04:25 AM, Sukadev Bhattiprolu wrote:
> Power8 supports a large number of events in each susbystem so when a
> user runs:
>
> perf stat -e branch-instructions sleep 1
> perf stat -e L1-dcache-loads sleep 1
>
> it is not clear as to which PMU events were monit
From: Vaibhav Jain
> Sent: 14 January 2016 07:51
> David Laight writes:
>
> > I don't even claim to understand the linux model for handling process
> > address maps, nor what the cxl driver is doing, but the above looks
> > more than dodgy.
> >
> > David
>
> Thanks for reviewing the patch.
>
On Wed, Jan 13, 2016 at 02:26:16PM -0800, Leonid Yegoshin wrote:
> And all that is out-of-topic here in my mind. I just want to be sure that
> this patchset still provides a use of a specific lightweight SYNCs on MIPS
> vs bold and heavy generalized "SYNC 0" in any case.
>
> - Leonid.
Of course i
From: Shaohui Xie
PCS PHY can support backplane (1000BASE-KX and 10GBASE-KR), this needs
to change corresponding serdes lane settings, so a reference is needed
for serdes lane. This patch describes properties needed for PCS PHY to
support backplane.
Signed-off-by: Shaohui Xie
---
changes in v2:
From: Shaohui Xie
This commit adds necessary definitions for the PHY layer to recognize
backplane Ethernet 1000BASE-KX and 10GBASE-KR as valid PHY interfaces,
"1000base-kx" for 1000BASE-KX, "10gbase-kr" for 10GBASE-KR.
Signed-off-by: Shaohui Xie
---
changes in v2:
new patch.
Documentation/dev
63 matches
Mail list logo
