On Sat, Apr 25, 2015 at 10:14:42PM +1000, Alexey Kardashevskiy wrote:
> At the moment writing new TCE value to the IOMMU table fails with EBUSY
> if there is a valid entry already. However PAPR specification allows
> the guest to write new TCE value without clearing it first.
>
> Another problem t
On Sat, Apr 25, 2015 at 10:14:44PM +1000, Alexey Kardashevskiy wrote:
> This is a part of moving TCE table allocation into an iommu_ops
> callback to support multiple IOMMU groups per one VFIO container.
>
> This moves a table creation window to the file with common powernv-pci
> helpers as it doe
On Sat, Apr 25, 2015 at 10:14:49PM +1000, Alexey Kardashevskiy wrote:
> Before the IOMMU user (VFIO) would take control over the IOMMU table
> belonging to a specific IOMMU group. This approach did not allow sharing
> tables between IOMMU groups attached to the same container.
>
> This introduces
On Sat, Apr 25, 2015 at 10:14:45PM +1000, Alexey Kardashevskiy wrote:
> This is a part of moving DMA window programming to an iommu_ops
> callback. pnv_pci_ioda2_set_window() takes an iommu_table_group as
> a first parameter (not pnv_ioda_pe) as it is going to be used as
> a callback for VFIO DDW c
On Sat, Apr 25, 2015 at 10:14:46PM +1000, Alexey Kardashevskiy wrote:
> TCE tables might get too big in case of 4K IOMMU pages and DDW enabled
> on huge guests (hundreds of GB of RAM) so the kernel might be unable to
> allocate contiguous chunk of physical memory to store the TCE table.
>
> To add
On Sat, Apr 25, 2015 at 10:14:43PM +1000, Alexey Kardashevskiy wrote:
> This moves iommu_table creation to the beginning to make following changes
> easier to review. This starts using table parameters from the iommu_table
> struct.
>
> This should cause no behavioural change.
>
> Signed-off-by:
On Sat, Apr 25, 2015 at 10:14:41PM +1000, Alexey Kardashevskiy wrote:
> This replaces direct accesses to TCE table with a helper which
> returns an TCE entry address. This does not make difference now but will
> when multi-level TCE tables get introduces.
>
> No change in behavior is expected.
>
On Sat, Apr 25, 2015 at 10:14:47PM +1000, Alexey Kardashevskiy wrote:
> This extends iommu_table_group_ops by a set of callbacks to support
> dynamic DMA windows management.
>
> create_table() creates a TCE table with specific parameters.
> it receives iommu_table_group to know nodeid in order to
* Arnaldo Carvalho de Melo [2015-04-28 10:54:53]:
> Em Tue, Apr 28, 2015 at 05:35:33PM +0530, Naveen N. Rao escreveu:
> > This patchset fixes various issues with perf probe on powerpc across ABIv1
> > and
> > ABIv2:
> > - in the presence of DWARF debug-info,
> > - in the absence of DWARF, but wi
Alexey Kardashevskiy writes:
> On 04/27/2015 06:02 PM, Nikunj A Dadhania wrote:
>> patch 1: Fixes a bug in pci-to-pci bridge while programming the limit
>> registers during probe
>> patch 2,3: Support 64-bit address translation and usb devices can have
>> 64-bit pci
On 2015/04/29 07:17AM, Masami Hiramatsu wrote:
> On 2015/04/28 22:54, Arnaldo Carvalho de Melo wrote:
> > Em Tue, Apr 28, 2015 at 05:35:33PM +0530, Naveen N. Rao escreveu:
> >> This patchset fixes various issues with perf probe on powerpc across ABIv1
> >> and
> >> ABIv2:
> >> - in the presence of
Subject should be "powerpc/pseries: ..." please.
On Tue, 2015-04-28 at 10:37 -0500, Nathan Fontenot wrote:
> The incorrect ordering of operations during cpu dlpar causes the affinity
> of cpus being added to be invalid. Phyp does not assign affinity information
> for a cpu until the rtas set-indic
On Sat, Apr 25, 2015 at 10:14:37PM +1000, Alexey Kardashevskiy wrote:
> This adds tce_iommu_take_ownership() and tce_iommu_release_ownership
> which call in a loop iommu_take_ownership()/iommu_release_ownership()
> for every table on the group. As there is just one now, no change in
> behaviour is
On Sat, Apr 25, 2015 at 10:14:33PM +1000, Alexey Kardashevskiy wrote:
> This is to make extended ownership and multiple groups support patches
> simpler for review.
>
> This should cause no behavioural change.
Um.. this doesn't appear to be true. Previously removing a group from
an enabled conta
On Sat, Apr 25, 2015 at 10:14:26PM +1000, Alexey Kardashevskiy wrote:
> This reverts commit 9e8d4a19ab66ec9e132d405357b9108a4f26efd3 as
> tce32_table has exactly the same life time as the whole PE.
>
> This makes use of a new iommu_reset_table() helper instead.
>
> Signed-off-by: Alexey Kardashev
On Sat, Apr 25, 2015 at 10:14:39PM +1000, Alexey Kardashevskiy wrote:
> The pnv_pci_ioda_tce_invalidate() helper invalidates TCE cache. It is
> supposed to be called on IODA1/2 and not called on p5ioc2. It receives
> start and end host addresses of TCE table.
>
> IODA2 actually needs PCI addresses
On Sat, Apr 25, 2015 at 10:14:36PM +1000, Alexey Kardashevskiy wrote:
> Modern IBM POWERPC systems support multiple (currently two) TCE tables
> per IOMMU group (a.k.a. PE). This adds a iommu_table_group container
> for TCE tables. Right now just one table is supported.
>
> For P5IOC2 and IODA, io
On Sat, Apr 25, 2015 at 10:14:40PM +1000, Alexey Kardashevskiy wrote:
> At the moment the DMA setup code looks for the "ibm,opal-tce-kill" property
> which contains the TCE kill register address. Writes to this register
> invalidates TCE cache on IODA/IODA2 hub.
>
> This moves the register address
On Sat, Apr 25, 2015 at 10:14:38PM +1000, Alexey Kardashevskiy wrote:
> This adds missing locks in iommu_take_ownership()/
> iommu_release_ownership().
>
> This marks all pages busy in iommu_table::it_map in order to catch
> errors if there is an attempt to use this table while ownership over it
>
On Sat, Apr 25, 2015 at 10:14:32PM +1000, Alexey Kardashevskiy wrote:
> This is a pretty mechanical patch to make next patches simpler.
>
> New tce_iommu_unuse_page() helper does put_page() now but it might skip
> that after the memory registering patch applied.
>
> As we are here, this removes u
On Sat, Apr 25, 2015 at 10:14:25PM +1000, Alexey Kardashevskiy wrote:
> The iommu_free_table helper release memory it is using (the TCE table and
> @it_map) and release the iommu_table struct as well. We might not want
> the very last step as we store iommu_table in parent structures.
>
> Signed-o
On 04/27/2015 06:02 PM, Nikunj A Dadhania wrote:
patch 1: Fixes a bug in pci-to-pci bridge while programming the limit
registers during probe
patch 2,3: Support 64-bit address translation and usb devices can have
64-bit pci memory BARs
patch 4: Use QEMU create device tr
When we test the cpu and memory hotplug feature in the server with x86
architecture and kernel4.0-rc4,we met the similar problem.
The situation is that when memory in node0 is offline,the system is down during
booting.
Following is the bug information:
[0.335176] BUG: unable to handle ker
On 2015/04/28 22:54, Arnaldo Carvalho de Melo wrote:
> Em Tue, Apr 28, 2015 at 05:35:33PM +0530, Naveen N. Rao escreveu:
>> This patchset fixes various issues with perf probe on powerpc across ABIv1
>> and
>> ABIv2:
>> - in the presence of DWARF debug-info,
>> - in the absence of DWARF, but with t
Le 25/03/2015 02:30, Scott Wood a écrit :
On Tue, Feb 03, 2015 at 12:39:27PM +0100, LEROY Christophe wrote:
The C version of csum_add() as defined in include/net/checksum.h gives the
following assembly:
0: 7c 04 1a 14 add r0,r4,r3
4: 7c 64 00 10 subfc
On Monday 27 April 2015 21:25:20 Suman Tripathi wrote:
> > On Monday 27 April 2015 20:33:25 Suman Tripathi wrote:
> > > > On Tuesday 21 April 2015 21:12:39 Suman Tripathi wrote:
> > > > > + host->quirks |= SDHCI_QUIRK_BROKEN_DMA;
> > > > > +
> > > > > + if (of_ge
The code accidentally used cpu_isset() previously in one place
(though properly node_isset() elsewhere).
Signed-off-by: Chris Metcalf
---
arch/tile/kernel/setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/tile/kernel/setup.c b/arch/tile/kernel/setup.c
index 6873f00
Le 25/03/2015 03:10, Scott Wood a écrit :
On Tue, 2015-02-03 at 12:39 +0100, Christophe Leroy wrote:
csum_tcpudp_magic() is only a few instructions, and does not modifies any other
register than the returned result. So it is not worth having it as a separate
function and suffer function branch
Le 25/03/2015 02:22, Scott Wood a écrit :
On Tue, Feb 03, 2015 at 12:39:27PM +0100, LEROY Christophe wrote:
Signed-off-by: Christophe Leroy
---
arch/powerpc/lib/checksum_32.S | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/lib/checksum_32.S b/arc
Em Tue, Apr 28, 2015 at 09:42:17PM +0530, Naveen N. Rao escreveu:
> On 2015/04/28 10:54AM, Arnaldo Carvalho de Melo wrote:
> > Em Tue, Apr 28, 2015 at 05:35:33PM +0530, Naveen N. Rao escreveu:
> > > This patchset fixes various issues with perf probe on powerpc across
> > > ABIv1 and
> > > ABIv2:
>
On 2015/04/28 10:54AM, Arnaldo Carvalho de Melo wrote:
> Em Tue, Apr 28, 2015 at 05:35:33PM +0530, Naveen N. Rao escreveu:
> > This patchset fixes various issues with perf probe on powerpc across ABIv1
> > and
> > ABIv2:
> > - in the presence of DWARF debug-info,
> > - in the absence of DWARF, but
The incorrect ordering of operations during cpu dlpar causes the affinity
of cpus being added to be invalid. Phyp does not assign affinity information
for a cpu until the rtas set-indicator calls are made to set the isolation
and allocation state. In the current code we call rtas configure-connecto
Em Tue, Apr 28, 2015 at 05:35:33PM +0530, Naveen N. Rao escreveu:
> This patchset fixes various issues with perf probe on powerpc across ABIv1 and
> ABIv2:
> - in the presence of DWARF debug-info,
> - in the absence of DWARF, but with the symbol table, and
> - in the absence of debug-info, but with
Em Tue, Apr 28, 2015 at 05:35:35PM +0530, Naveen N. Rao escreveu:
> If using the symbol table, symbol addresses are not being fixed up
> properly, resulting in probes being placed at wrong addresses:
>
> # perf probe do_fork
> Added new event:
> probe:do_fork(on do_fork)
>
> You
Em Tue, Apr 28, 2015 at 05:35:34PM +0530, Naveen N. Rao escreveu:
> Currently, perf probe considers patterns including a '.' to be a file.
> However, this causes problems on powerpc ABIv1 where all functions have
> a leading '.':
>
> $ perf probe -F | grep schedule_timeout_interruptible
> .sch
cc Chris
On Tue, Apr 28, 2015 at 2:24 PM, Rusty Russell wrote:
> Geert Uytterhoeven writes:
>>> Can't see that one with a simple grep: can you post warning?
>>
>> /home/kisskb/slave/src/arch/tile/kernel/setup.c: In function
>> 'zone_sizes_init':
>> /home/kisskb/slave/src/arch/tile/kernel/setup.
Geert Uytterhoeven writes:
>> Can't see that one with a simple grep: can you post warning?
>
> /home/kisskb/slave/src/arch/tile/kernel/setup.c: In function
> 'zone_sizes_init':
> /home/kisskb/slave/src/arch/tile/kernel/setup.c:777:3: warning:
> passing argument 2 of 'cpumask_test_cpu' from incomp
If using the symbol table, symbol addresses are not being fixed up
properly, resulting in probes being placed at wrong addresses:
# perf probe do_fork
Added new event:
probe:do_fork(on do_fork)
You can now use it in all perf tools, such as:
perf record -e probe:do_for
On powerpc ABIv2, if no debug-info is found and we use kallsyms, we need
to fixup the function entry to point to the local entry point. Use
offset of 8 since current toolchains always generate 2 instructions (8
bytes).
Signed-off-by: Naveen N. Rao
Reviewed-by: Srikar Dronamraju
---
Changes:
- No
Currently, perf probe considers patterns including a '.' to be a file.
However, this causes problems on powerpc ABIv1 where all functions have
a leading '.':
$ perf probe -F | grep schedule_timeout_interruptible
.schedule_timeout_interruptible
$ perf probe .schedule_timeout_interruptible
S
This patchset fixes various issues with perf probe on powerpc across ABIv1 and
ABIv2:
- in the presence of DWARF debug-info,
- in the absence of DWARF, but with the symbol table, and
- in the absence of debug-info, but with kallsyms.
Arnaldo,
I have moved all patches to use __weak functions. Kindl
Allow perf probe to work on ppc ABIv1 without the need to specify the
leading dot '.' for functions. 'perf probe do_fork' works with this
patch.
We do this by changing how symbol name comparison works on ppc ABIv1 -
we simply ignore and skip over the initial dot, if one exists, during
symbol name
From: Ananth N Mavinakayanahalli
ppc64 ELF ABIv2 has a Global Entry Point (GEP) and a Local Entry Point
(LEP). For purposes of probing, we need the LEP - the offset to which is
encoded in st_other.
Signed-off-by: Ananth N Mavinakayanahalli
Signed-off-by: Naveen N. Rao
Reviewed-by: Srikar Drona
Use symbol table lookups by default if DWARF is not necessary, since
powerpc ABIv2 encodes local entry points in the symbol table and the
function entry address in DWARF may not be appropriate for kprobes, as
described here:
https://sourceware.org/bugzilla/show_bug.cgi?id=17638
"The DWARF address
Use the proper prefix when ignoring SyS symbols on ppc ABIv1. While at
it, generalize symbol selection so architectures can implement their
own logic.
Signed-off-by: Naveen N. Rao
Reviewed-by: Srikar Dronamraju
---
Changes:
- Move logic to arch helper.
tools/perf/arch/powerpc/util/sym-handling
On 04/27/2015 07:17 PM, Vasant Hegde wrote:
> On 04/27/2015 04:45 PM, Jacek Anaszewski wrote:
>> On 04/27/2015 11:53 AM, Benjamin Herrenschmidt wrote:
>>> On Mon, 2015-04-27 at 09:24 +0200, Jacek Anaszewski wrote:
I was not aware that some other entity than the driver could be
interested
Alexey Kardashevskiy wrote:
> This reverts 4fbdf9cb is breaks LPFC on POWER7 machine, big endian kernel.
>
> This is the hardware used for verification:
> 0005:01:00.0 Fibre Channel [0c04]: Emulex Corporation Saturn-X: LightPulse
> Fibre Channel Host Adapter [10df:f100] (rev 03)
> 0005:01:00.1 Fi
On 04/28/2015 07:18 PM, Sebastian Herbszt wrote:
Alexey Kardashevskiy wrote:
This reverts 4fbdf9cb is breaks LPFC on POWER7 machine, big endian kernel.
This is the hardware used for verification:
0005:01:00.0 Fibre Channel [0c04]: Emulex Corporation Saturn-X: LightPulse
Fibre Channel Host Adap
On Tuesday 28 April 2015 15:40:35 Vasant Hegde wrote:
> +++ b/Documentation/devicetree/bindings/leds/leds-powernv.txt
> @@ -0,0 +1,29 @@
> +Device Tree binding for LEDs on IBM Power Systems
> +-
> +
> +The 'led' node under '/ibm,opal' lists service in
This patch adds paltform devices for leds. Also export LED related
OPAL API's so that led driver can use these APIs.
Signed-off-by: Vasant Hegde
---
arch/powerpc/platforms/powernv/opal.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/pow
This patch implements LED driver for PowerNV platform using the existing
generic LED class framework.
PowerNV platform has below type of LEDs:
- System attention
Indicates there is a problem with the system that needs attention.
- Identify
Helps the user locate/identify a particula
The following series implements LED driver for PowerNV platform.
PowerNV platform has below type of LEDs:
- System attention
Indicates there is a problem with the system that needs attention.
- Identify
Helps the user locate/identify a particular FRU or resource in the
system
From: Anshuman Khandual
This patch registers the following two new OPAL interfaces calls
for the platform LED subsystem. With the help of these new OPAL calls,
the kernel will be able to get or set the state of various individual
LEDs on the system at any given location code which is passed throu
On 04/28/2015 08:59 AM, Stewart Smith wrote:
Jacek Anaszewski writes:
Is the DT node we are discussing used by some other drivers than the
LED class driver? Or is it required in this form by other components of
your platform?
OS kernels are the chief consumers, Linux being the overwhelmingly
On 04/28/2015 02:23 PM, Viresh Kumar wrote:
> On 28 April 2015 at 13:48, Shilpasri G Bhat
> wrote:
>> My bad I haven't added explicit comment to state reason behind this change.
>>
>> I modified the definition of *throttle_check() to match the function
>> definition
>> to be called via smp_call
On 28 April 2015 at 13:48, Shilpasri G Bhat
wrote:
> My bad I haven't added explicit comment to state reason behind this change.
>
> I modified the definition of *throttle_check() to match the function
> definition
> to be called via smp_call() instead of adding an additional wrapper around
> *th
Today the number of bits of the broadcast masks that is output into
/proc/timer_list is sizeof(unsigned long). This means that on machines
with larger number of CPUs, the bitmasks of CPUs beyond this range do
not appear.
Fix this by using bitmap printing through "%*pb" instead, so as to
output the
This reverts 4fbdf9cb is breaks LPFC on POWER7 machine, big endian kernel.
This is the hardware used for verification:
0005:01:00.0 Fibre Channel [0c04]: Emulex Corporation Saturn-X: LightPulse
Fibre Channel Host Adapter [10df:f100] (rev 03)
0005:01:00.1 Fibre Channel [0c04]: Emulex Corporation S
Hi Viresh,
On 04/28/2015 12:18 PM, Viresh Kumar wrote:
> On 28 April 2015 at 11:53, Shilpasri G Bhat
> wrote:
>
>> Changes from v1:
>> - Add macros to define OCC_RESET, OCC_LOAD and OCC_THROTTLE
>> - Define a structure to store chip id, chip mask which has bits set
>> for cpus present in the c
On Tue, Apr 28, 2015 at 10:42:47AM +1000, Michael Ellerman wrote:
> Commit 34cb7954c0aa "Convert ICS mutex lock to spin lock" added an
> include of asm/spinlock.h, which does not work in the SMP=n case.
>
> It should instead include linux/spinlock.h
>
> Fixes: 34cb7954c0aa ("KVM: PPC: Book3S HV:
On 28.04.15 02:42, Michael Ellerman wrote:
> Commit 34cb7954c0aa "Convert ICS mutex lock to spin lock" added an
> include of asm/spinlock.h, which does not work in the SMP=n case.
>
> It should instead include linux/spinlock.h
>
> Fixes: 34cb7954c0aa ("KVM: PPC: Book3S HV: Convert ICS mutex loc
Hello Rui Zhang,
Please help to review this Thermal Management driver.
Thanks.
---
Best Regards,
Hongtao
> -Original Message-
> From: Jia Hongtao [mailto:hongtao@freescale.com]
> Sent: Friday, April 03, 2015 3:11 PM
> To: rui.zh...@intel.com
> Cc: linux...@vger.kernel.org; linuxppc-
On Tue, Apr 28, 2015 at 6:39 AM, Rusty Russell wrote:
>>> + /home/kisskb/slave/src/arch/mips/cavium-octeon/smp.c: error: passing
>>> argument 2 of 'cpumask_clear_cpu' discards 'volatile' qualifier from
>>> pointer target type [-Werror]: => 242:2
>>> + /home/kisskb/slave/src/arch/mips/kernel
Jacek Anaszewski writes:
> Is the DT node we are discussing used by some other drivers than the
> LED class driver? Or is it required in this form by other components of
> your platform?
OS kernels are the chief consumers, Linux being the overwhelmingly major
one here.
But this is what firmware
64 matches
Mail list logo
