Le 13/05/2016 à 08:16, Michael Ellerman a écrit :
On Thu, 2016-12-05 at 15:32:22 UTC, Christophe Leroy wrote:
With the ffs() function as defined in arch/powerpc/include/asm/bitops.h
GCC will not optimise the code in case of constant parameter, as shown
by the small exemple below.
int ffs_test
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Friday, May 13, 2016 1:33 PM
> > >
> > > As argued previously in this thread, there's nothing special about a
> > > DMA write to memory versus a DMA write to a special address that
> > > triggers an MSI vector. If the device is DM
On 5/12/2016 1:56 PM, Arnd Bergmann wrote:
> A patch that went into Linux-4.4 to fix big-endian mode on a Lantiq
> MIPS system unfortunately broke big-endian operation on PowerPC
> APM82181 as reported by Christian Lamparter, and likely other
> systems.
>
> It actually introduced multiple issues:
On Thu, 2016-12-05 at 15:32:22 UTC, Christophe Leroy wrote:
> With the ffs() function as defined in arch/powerpc/include/asm/bitops.h
> GCC will not optimise the code in case of constant parameter, as shown
> by the small exemple below.
>
> int ffs_test(void)
> {
> return 4 << ffs(31);
> }
>
On Fri, 13 May 2016 02:33:18 +
"Tian, Kevin" wrote:
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Friday, May 13, 2016 1:48 AM
> >
> > On Thu, 12 May 2016 04:53:19 +
> > "Tian, Kevin" wrote:
> >
> > > > From: Alex Williamson [mailto:alex.william...@redhat.co
On Thu, May 12, 2016 at 01:29:11PM +0200, Thomas Huth wrote:
> We are already using the privileged versions of MMCR0, MMCR1
> and MMCRA in the kernel, so for MMCR2, we should better use
> the privileged versions, too, to be consistent.
>
> Suggested-by: Paul Mackerras
> Signed-off-by: Thomas Huth
On Thu, May 12, 2016 at 01:26:44PM +0200, Thomas Huth wrote:
> The SIAR and SDAR registers are available twice, one time as SPRs
> 780 / 781 (unprivileged, but read-only), and one time as the SPRs
> 796 / 797 (privileged, but read and write). The Linux kernel code
> currently uses the unprivileged
> From: Tian, Kevin
> Sent: Friday, May 13, 2016 10:33 AM
>
> > means. The MSI-X vector table of a device is always considered
> > untrusted which is why we require user opt-ins to subvert that
> > protection. Thanks,
> >
>
> I only partially agree with this statement since there is different
>
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Friday, May 13, 2016 1:48 AM
>
> On Thu, 12 May 2016 04:53:19 +
> "Tian, Kevin" wrote:
>
> > > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > > Sent: Thursday, May 12, 2016 10:21 AM
> > >
> > > On Thu, 12 May
On Thu, 2016-05-12 at 11:58 +0200, Christian Lamparter wrote:
>
> > http://www.linuxplumbersconf.org/2012/wp-content/uploads/2012/09/2012-lpc-ref-big-little-endian-herrenschmidt.odp
> >
> > but there are at least two more twists that you completely missed here:
> >
> > - Some architectures (e.g.
A patch that went into Linux-4.4 to fix big-endian mode on a Lantiq
MIPS system unfortunately broke big-endian operation on PowerPC
APM82181 as reported by Christian Lamparter, and likely other
systems.
It actually introduced multiple issues:
- it broke big-endian ARM kernels: any machine that wa
On 5/12/2016 1:39 PM, Christian Lamparter wrote:
> On Thursday, May 12, 2016 11:40:28 AM John Youn wrote:
>> On 5/12/2016 6:30 AM, Christian Lamparter wrote:
>>> On Thursday, May 12, 2016 01:55:44 PM Arnd Bergmann wrote:
On Thursday 12 May 2016 11:58:18 Christian Lamparter wrote:
Dete
On Thursday 12 May 2016 22:39:36 Christian Lamparter wrote:
> On Thursday, May 12, 2016 11:40:28 AM John Youn wrote:
> > On 5/12/2016 6:30 AM, Christian Lamparter wrote:
> > > On Thursday, May 12, 2016 01:55:44 PM Arnd Bergmann wrote:
> > >>
> > >> If I recall correctly, the rough consensus was to
On Thursday, May 12, 2016 11:40:28 AM John Youn wrote:
> On 5/12/2016 6:30 AM, Christian Lamparter wrote:
> > On Thursday, May 12, 2016 01:55:44 PM Arnd Bergmann wrote:
> >> On Thursday 12 May 2016 11:58:18 Christian Lamparter wrote:
> >> Detecting the endianess of the
> >> device is probab
On 5/12/2016 6:30 AM, Christian Lamparter wrote:
> On Thursday, May 12, 2016 01:55:44 PM Arnd Bergmann wrote:
>> On Thursday 12 May 2016 11:58:18 Christian Lamparter wrote:
>> Detecting the endianess of the
>> device is probably the best future-proof solution, but it's also
>> considera
On Thu, 12 May 2016 04:53:19 +
"Tian, Kevin" wrote:
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Thursday, May 12, 2016 10:21 AM
> >
> > On Thu, 12 May 2016 01:19:44 +
> > "Tian, Kevin" wrote:
> >
> > > > From: Alex Williamson [mailto:alex.william...@redhat
With the ffs() function as defined in arch/powerpc/include/asm/bitops.h
GCC will not optimise the code in case of constant parameter, as shown
by the small exemple below.
int ffs_test(void)
{
return 4 << ffs(31);
}
c0012334 :
c0012334: 39 20 00 01 li r9,1
c0012338: 38
On 12/05/2016 11:27, Alexander Graf wrote:
> On 05/12/2016 11:10 AM, Laurent Vivier wrote:
>>
>> On 11/05/2016 13:49, Alexander Graf wrote:
>>> On 05/11/2016 01:14 PM, Laurent Vivier wrote:
On 11/05/2016 12:35, Alexander Graf wrote:
> On 03/15/2016 09:18 PM, Laurent Vivier wrote:
>>
We noticed that on ppc64, the sbrk system call in the 32-bit subsystem
returns executable memory. I assume it is related to this, in
arch/powerpc/include/asm/page.h:
/*
* Unfortunately the PLT is in the BSS in the PPC32 ELF ABI,
* and needs to be executable. This means the whole heap ends
Signed-off-by: Bharata B Rao
---
arch/powerpc/mm/numa.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 669a15e..4a87ccb 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -1163,18 +1
memory_hotplug_max() uses hot_add_drconf_memory_max() to get maxmimum
addressable memory by referring to ibm,dyanamic-memory property. There
are three problems with the current approach:
1 hot_add_drconf_memory_max() assumes that ibm,dynamic-memory includes
all the LMBs of the guest, but that is
This patchset fixes memory_hotplug_max() routine to return correct
value of maximum hotpluggable address.
In this version, whitespace fixes are separated into a different patch.
v2: https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg103342.html
Bharata B Rao (2):
powerpc,numa: Fix w
On Thursday, May 12, 2016 01:55:44 PM Arnd Bergmann wrote:
> On Thursday 12 May 2016 11:58:18 Christian Lamparter wrote:
> > > > > Detecting the endianess of the
> > > > > device is probably the best future-proof solution, but it's also
> > > > > considerably more work to do in the driver, and come
Currently, memory for fadump can be specified with fadump_reserve_mem=size,
where only a fixed size can be specified. Add the below syntax as well, to
support conditional reservation based on system memory size:
fadump_reserve_mem=:[,:,...]
This syntax helps using the same commandline par
Currently, crashkernel parameter supports the below syntax to parse size
based on memory range:
crashkernel=:[,:,...]
While such parsing is implemented for crashkernel parameter, it applies to
other parameters with similar syntax. So, move this code to a more generic
place for code reuse.
On Thursday 12 May 2016 11:58:18 Christian Lamparter wrote:
> > > > Detecting the endianess of the
> > > > device is probably the best future-proof solution, but it's also
> > > > considerably more work to do in the driver, and comes with a
> > > > tiny runtime overhead.
> > >
> > > The runtime ov
On Thursday 12 May 2016 14:43:43 Felipe Balbi wrote:
> >> How many more drivers will we have to 'fix' like this ?
> >
> > Endianess problems will keep coming up, and we have hundreds or thousands
> > of drivers that are written with a particular design in mind that could
> > be wrong as soon as som
Hi,
(Arnd, you didn't Cc dwc2's maintainer. I'm also not part of TI anymore)
Arnd Bergmann writes:
> On Thursday 12 May 2016 14:25:49 Felipe Balbi wrote:
>> > {
>> > u32 value = __raw_readl(addr);
>> >
>> > - /* In order to preserve endianness __raw_* operation is used.
>> > There
On Thursday 12 May 2016 14:25:49 Felipe Balbi wrote:
> > {
> > u32 value = __raw_readl(addr);
> >
> > - /* In order to preserve endianness __raw_* operation is used.
> > Therefore
> > - * a barrier is needed to ensure IO access is not re-ordered across
> > + /* in order to pr
On Thu, 2016-05-12 at 13:48 +1000, Gavin Shan wrote:
> On Tue, May 03, 2016 at 03:41:45PM +1000, Gavin Shan wrote:
> > The function pnv_pci_reset_secondary_bus() is called like below.
> > It's impossible for call the function on root bus. So it's safe
> > to remove the root bus case in the functi
On Thu, 2016-12-05 at 05:47:10 UTC, Alexey Kardashevskiy wrote:
> Before 3e68dc57 "powerpc/powernv: Remove DMA32 PE list", NPU PEs
> were linked to the NPU PHB via phb->ioda.pe_dma_list; after that fix,
> the phb->ioda.pe_list is used.
>
> During the pe_dma_list removal, list_add_tail(&phb->ioda.p
On Thu, 2016-12-05 at 05:47:09 UTC, Alexey Kardashevskiy wrote:
> The pnv_pci_init_ioda_phb() helper allocates a blob to store auxilary
> data such PE and M32/M64 segment allocation maps; this single blob has few
> partitions, size of each is derived from the PE number -
> phb->ioda.total_pe_num.
>
On Mon, 2016-11-04 at 19:17:23 UTC, "Guilherme G. Piccoli" wrote:
> Commit 39baadbf36ce ("powerpc/eeh: Remove eeh information from pci_dn")
> changed the pci_dn struct by removing its EEH-related members.
> As part of this clean-up, DDW mechanism was modified to read the device
> configuration addr
On Mon, 2016-11-04 at 19:17:22 UTC, "Guilherme G. Piccoli" wrote:
> This reverts commit 89a51df5ab1d38b257300b8ac940bbac3bb0eb9b.
>
> The function eeh_add_device_early() is used to perform EEH initialization in
> devices added later on the system, like in hotplug/DLPAR scenarios. Since the
> commi
On Wed, 2016-27-04 at 01:14:50 UTC, Gavin Shan wrote:
> The function eeh_pe_reset_and_recover() is used to recover EEH
> error when the passthrough device are transferred to guest and
> backwards, meaning the device's driver is vfio-pci or none.
> When the driver is vfio-pci that provides error_det
We are already using the privileged versions of MMCR0, MMCR1
and MMCRA in the kernel, so for MMCR2, we should better use
the privileged versions, too, to be consistent.
Suggested-by: Paul Mackerras
Signed-off-by: Thomas Huth
---
arch/powerpc/include/asm/reg.h | 2 +-
1 file changed, 1 insertion
Hi,
Arnd Bergmann writes:
> A patch that went into Linux-4.4 to fix big-endian mode on a Lantiq
> MIPS system unfortunately broke big-endian operation on PowerPC
> APM82181 as reported by Christian Lamparter, and likely other
> systems.
>
> It actually introduced multiple issues:
>
> - it broke
The SIAR and SDAR registers are available twice, one time as SPRs
780 / 781 (unprivileged, but read-only), and one time as the SPRs
796 / 797 (privileged, but read and write). The Linux kernel code
currently uses the unprivileged SPRs - while this is OK for reading,
writing to that register of cou
A patch that went into Linux-4.4 to fix big-endian mode on a Lantiq
MIPS system unfortunately broke big-endian operation on PowerPC
APM82181 as reported by Christian Lamparter, and likely other
systems.
It actually introduced multiple issues:
- it broke big-endian ARM kernels: any machine that wa
On Thu, May 12, 2016 at 09:27:40AM +0200, Thomas Huth wrote:
> On 12.05.2016 06:57, Paul Mackerras wrote:
> > On Mon, Apr 25, 2016 at 10:15:47AM +0200, Alexander Graf wrote:
> >>
> +#define SPRN_SIAR796
> >>
> >> I'm sure there's a reason (iSeries?) we used the r/o version before.
> >> Be
On Thu, 2016-12-05 at 08:26:36 UTC, Bharata B Rao wrote:
> memory_hotplug_max() uses hot_add_drconf_memory_max() to get maxmimum
> addressable memory by referring to ibm,dyanamic-memory property. There
> are three problems with the current approach:
...
>
> NOTE: There are some unnecessary changes
On Tuesday, May 10, 2016 09:23:59 AM Arnd Bergmann wrote:
> On Tuesday 10 May 2016 08:37:52 Benjamin Herrenschmidt wrote:
> > On Mon, 2016-05-09 at 17:08 +0200, Arnd Bergmann wrote:
> > >
> > > Unfortunately, I don't see any way this could be done in MIPS specific
> > > code: There is typically a
On 05/12/2016 11:10 AM, Laurent Vivier wrote:
On 11/05/2016 13:49, Alexander Graf wrote:
On 05/11/2016 01:14 PM, Laurent Vivier wrote:
On 11/05/2016 12:35, Alexander Graf wrote:
On 03/15/2016 09:18 PM, Laurent Vivier wrote:
While writing some instruction tests for kvm-unit-tests for powerpc,
On 11/05/2016 13:49, Alexander Graf wrote:
> On 05/11/2016 01:14 PM, Laurent Vivier wrote:
>>
>> On 11/05/2016 12:35, Alexander Graf wrote:
>>> On 03/15/2016 09:18 PM, Laurent Vivier wrote:
While writing some instruction tests for kvm-unit-tests for powerpc,
I've found that illegal inst
memory_hotplug_max() uses hot_add_drconf_memory_max() to get maxmimum
addressable memory by referring to ibm,dyanamic-memory property. There
are three problems with the current approach:
1 hot_add_drconf_memory_max() assumes that ibm,dynamic-memory includes
all the LMBs of the guest, but that is
On Thu, May 12, 2016 at 04:39:57PM +1000, Alexey Kardashevskiy wrote:
>On 05/12/2016 04:09 PM, Gavin Shan wrote:
>>On Thu, May 12, 2016 at 03:47:09PM +1000, Alexey Kardashevskiy wrote:
>>>The pnv_pci_init_ioda_phb() helper allocates a blob to store auxilary
>>>data such PE and M32/M64 segment alloc
On 12.05.2016 06:57, Paul Mackerras wrote:
> On Mon, Apr 25, 2016 at 10:15:47AM +0200, Alexander Graf wrote:
>>
+#define SPRN_SIAR796
>>
>> I'm sure there's a reason (iSeries?) we used the r/o version before. Better
>> introduce a new constant that gives us rw access and use that in the k
47 matches
Mail list logo
