> On 28-Jul-2020, at 6:14 AM, Michael Ellerman wrote:
>
> Athira Rajeev writes:
>>> On 27-Jul-2020, at 6:05 PM, Michael Ellerman wrote:
>>>
>>> Athira Rajeev writes:
> On 27-Jul-2020, at 11:39 AM, Nicholas Piggin wrote:
>
> Commit 2f92447f9f96 ("powerpc/book3s64/hash: Use
commit 9908c826d5ed ("powerpc/perf: Add Power10 PMU feature to
DT CPU features") defines MMCRA_BHRB_DISABLE as `0x20UL`.
Binutils version less than 2.28 doesn't support UL suffix.
linux-ppc/arch/powerpc/kernel/cpu_setup_power.S: Assembler messages:
I've forgotten to manual enable NVME when building pseries kernels
for machines with NVME adapters. Since it's a reasonably common
configuration, enable it by default.
Signed-off-by: Anton Blanchard
---
arch/powerpc/configs/pseries_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git
Hari Bathini writes:
> On 28/07/20 7:16 pm, Michael Ellerman wrote:
>> Hari Bathini writes:
>>> Kernel built with CONFIG_PPC_EARLY_DEBUG_OPAL enabled expects r8 & r9
>>> to be filled with OPAL base & entry addresses respectively. Setting
>>> these registers allows the kernel to perform OPAL
On Tue, 28 Jul 2020, 07:16 Mike Rapoport, wrote:
> From: Mike Rapoport
>
> There are several occurrences of the following pattern:
>
> for_each_memblock(memory, reg) {
> start = __pfn_to_phys(memblock_region_memory_base_pfn(reg);
> end =
Excerpts from Linus Torvalds's message of July 29, 2020 5:02 am:
> On Tue, Jul 28, 2020 at 3:53 AM Nicholas Piggin wrote:
>>
>> The quirk is a problem with coprocessor where it's supposed to
>> invalidate the translation after a fault but it doesn't, so we can get a
>> read-only TLB stuck after
On Wed, Jul 29, 2020 at 8:35 AM Gustavo Romero wrote:
>
> Currently pnv_ioda_setup_bus_dma() is outside of a CONFIG_IOMMU_API guard
> and if CONFIG_IOMMU_API=n the build can fail if the compiler sets
> -Werror=unused-function, because pnv_ioda_setup_bus_dma() is only used in
> functions guarded
Currently pnv_ioda_setup_bus_dma() is outside of a CONFIG_IOMMU_API guard
and if CONFIG_IOMMU_API=n the build can fail if the compiler sets
-Werror=unused-function, because pnv_ioda_setup_bus_dma() is only used in
functions guarded by a CONFIG_IOMMU_API guard.
That issue can be easily reproduced
On 28/07/20 7:14 pm, Michael Ellerman wrote:
Hari Bathini writes:
diff --git a/arch/powerpc/kexec/file_load_64.c
b/arch/powerpc/kexec/file_load_64.c
index 2df6f4273ddd..8df085a22fd7 100644
--- a/arch/powerpc/kexec/file_load_64.c
+++ b/arch/powerpc/kexec/file_load_64.c
@@ -17,9 +17,21 @@
On 28/07/20 7:16 pm, Michael Ellerman wrote:
Hari Bathini writes:
Kernel built with CONFIG_PPC_EARLY_DEBUG_OPAL enabled expects r8 & r9
to be filled with OPAL base & entry addresses respectively. Setting
these registers allows the kernel to perform OPAL calls before the
device tree is
Hi Laurent,
Laurent Dufour writes:
> Le 28/07/2020 à 19:37, Nathan Lynch a écrit :
>> The drmem lmb list can have hundreds of thousands of entries, and
>> unfortunately lookups take the form of linear searches. As long as
>> this is the case, traversals have the potential to monopolize the CPU
On Tue, Jul 28, 2020 at 3:53 AM Nicholas Piggin wrote:
>
> The quirk is a problem with coprocessor where it's supposed to
> invalidate the translation after a fault but it doesn't, so we can get a
> read-only TLB stuck after something else does a RO->RW upgrade on the
> TLB. Something like that
On 28.07.20 18:53, Scott Cheloha wrote:
> At memory hot-remove time we can retrieve an LMB's nid from its
> corresponding memory_block. There is no need to store the nid
> in multiple locations.
>
> Note that lmb_to_memblock() uses find_memory_block() to get the
> corresponding memory_block. As
Le 28/07/2020 à 19:37, Nathan Lynch a écrit :
The drmem lmb list can have hundreds of thousands of entries, and
unfortunately lookups take the form of linear searches. As long as
this is the case, traversals have the potential to monopolize the CPU
and provoke lockup reports, workqueue stalls,
The drmem lmb list can have hundreds of thousands of entries, and
unfortunately lookups take the form of linear searches. As long as
this is the case, traversals have the potential to monopolize the CPU
and provoke lockup reports, workqueue stalls, and the like unless
they explicitly yield.
At memory hot-remove time we can retrieve an LMB's nid from its
corresponding memory_block. There is no need to store the nid
in multiple locations.
Note that lmb_to_memblock() uses find_memory_block() to get the
corresponding memory_block. As find_memory_block() runs in sub-linear
time this
When running under older versions of qemu of under newer versions with old
machine types, some security features will not be reported to the guest.
This will lead the guest OS to consider itself Vulnerable to spectre_v2.
So, spectre_v2 test fails in such cases when the host is mitigated and miss
Hi,
On 27/07/20 06:32, Srikar Dronamraju wrote:
> Add percpu coregroup maps and masks to create coregroup domain.
> If a coregroup doesn't exist, the coregroup domain will be degenerated
> in favour of SMT/CACHE domain.
>
So there's at least one arm64 platform out there with the same "pairs of
On 07/28/20 at 05:15pm, Mike Rapoport wrote:
> On Tue, Jul 28, 2020 at 07:02:54PM +0800, Baoquan He wrote:
> > On 07/28/20 at 08:11am, Mike Rapoport wrote:
> > > From: Mike Rapoport
> > >
> > > numa_clear_kernel_node_hotplug() function first traverses numa_meminfo
> > > regions to set node ID in
On Tue, Jul 28, 2020 at 07:02:54PM +0800, Baoquan He wrote:
> On 07/28/20 at 08:11am, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > numa_clear_kernel_node_hotplug() function first traverses numa_meminfo
> > regions to set node ID in memblock.reserved and than traverses
> >
Hari Bathini writes:
> diff --git a/arch/powerpc/kexec/file_load_64.c
> b/arch/powerpc/kexec/file_load_64.c
> index a5c1442590b2..88408b17a7f6 100644
> --- a/arch/powerpc/kexec/file_load_64.c
> +++ b/arch/powerpc/kexec/file_load_64.c
> @@ -697,6 +699,69 @@ static int update_usable_mem_fdt(void
Hari Bathini writes:
> Kernel built with CONFIG_PPC_EARLY_DEBUG_OPAL enabled expects r8 & r9
> to be filled with OPAL base & entry addresses respectively. Setting
> these registers allows the kernel to perform OPAL calls before the
> device tree is parsed.
I'm not convinced we want to do this.
Hari Bathini writes:
> diff --git a/arch/powerpc/kexec/file_load_64.c
> b/arch/powerpc/kexec/file_load_64.c
> index 2df6f4273ddd..8df085a22fd7 100644
> --- a/arch/powerpc/kexec/file_load_64.c
> +++ b/arch/powerpc/kexec/file_load_64.c
> @@ -17,9 +17,21 @@
> #include
> #include
> #include
>
Hello Rafael,
On 27/07/20 7:12 pm, Rafael J. Wysocki wrote:
On Tue, Jul 21, 2020 at 2:43 PM Pratik Rajesh Sampat
wrote:
Fire directed smp_call_function_single IPIs from a specified source
CPU to the specified target CPU to reduce the noise we have to wade
through in the trace log.
And
add testcases for divde, divde., divdeu, divdeu. emulated
instructions to cover few scenarios,
* with same dividend and divisor to have undefine RT
for divdeu[.]
* with divide by zero to have undefine RT for both
divde[.] and divdeu[.]
* with negative
This patch adds emulation support for divde, divdeu instructions,
* Divide Doubleword Extended (divde[.])
* Divide Doubleword Extended Unsigned (divdeu[.])
Reviewed-by: Sandipan Das
Signed-off-by: Balamuruhan S
Acked-by: Naveen N. Rao
---
arch/powerpc/lib/sstep.c | 13
include instruction opcodes for divde and divdeu as macros.
Reviewed-by: Sandipan Das
Signed-off-by: Balamuruhan S
Acked-by: Naveen N. Rao
---
arch/powerpc/include/asm/ppc-opcode.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/powerpc/include/asm/ppc-opcode.h
Hi All,
This patchset adds support to emulate divde, divde., divdeu and divdeu.
instructions and testcases for it.
Resend v4: rebased on latest powerpc next branch
Changes in v4:
-
Fix review comments from Naveen,
* replace TEST_DIVDEU() instead of wrongly used TEST_DIVDEU_DOT() in
Hi Hari,
Some comments inline ...
Hari Bathini writes:
> diff --git a/arch/powerpc/kexec/ranges.c b/arch/powerpc/kexec/ranges.c
> new file mode 100644
> index ..21bea1b78443
> --- /dev/null
> +++ b/arch/powerpc/kexec/ranges.c
> @@ -0,0 +1,417 @@
> +// SPDX-License-Identifier:
* Mike Rapoport wrote:
> On Tue, Jul 28, 2020 at 12:44:40PM +0200, Ingo Molnar wrote:
> >
> > * Mike Rapoport wrote:
> >
> > > From: Mike Rapoport
> > >
> > > numa_clear_kernel_node_hotplug() function first traverses numa_meminfo
> > > regions to set node ID in memblock.reserved and than
Excerpts from pet...@infradead.org's message of July 26, 2020 10:11 pm:
> On Sun, Jul 26, 2020 at 02:14:34PM +1000, Nicholas Piggin wrote:
>> Excerpts from Peter Zijlstra's message of July 26, 2020 6:26 am:
>
>> > Which is 'funny' when it interleaves like:
>> >
>> >local_irq_disable();
>> >
On 07/28/20 at 08:11am, Mike Rapoport wrote:
> From: Mike Rapoport
>
> numa_clear_kernel_node_hotplug() function first traverses numa_meminfo
> regions to set node ID in memblock.reserved and than traverses
> memblock.reserved to update reserved_nodemask to include node IDs that were
> set in
On Tue, Jul 28, 2020 at 12:44:40PM +0200, Ingo Molnar wrote:
>
> * Mike Rapoport wrote:
>
> > From: Mike Rapoport
> >
> > numa_clear_kernel_node_hotplug() function first traverses numa_meminfo
> > regions to set node ID in memblock.reserved and than traverses
> > memblock.reserved to update
Excerpts from Linus Torvalds's message of July 28, 2020 4:37 am:
> [ Adding linux-arch, just to make other architectures aware of this issue too.
>
> We have a "flush_tlb_fix_spurious_fault()" thing to take care of the
> "TLB may contain stale entries, we can't take the same fault over and
>
* Mike Rapoport wrote:
> From: Mike Rapoport
>
> numa_clear_kernel_node_hotplug() function first traverses numa_meminfo
> regions to set node ID in memblock.reserved and than traverses
> memblock.reserved to update reserved_nodemask to include node IDs that were
> set in the first loop.
>
>
On Mon, Jul 27, 2020 at 10:12 PM Mike Rapoport wrote:
>
> From: Mike Rapoport
>
> The function free_highpages() in both arm and xtensa essentially open-code
> for_each_free_mem_range() loop to detect high memory pages that were not
> reserved and that should be initialized and passed to the
https://bugzilla.kernel.org/show_bug.cgi?id=206203
--- Comment #17 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 290641
--> https://bugzilla.kernel.org/attachment.cgi?id=290641=edit
kmemleak output (kernel 5.8-rc7, PowerMac G4 3,6)
Also happens on my G4 DP.
--
You are
https://bugzilla.kernel.org/show_bug.cgi?id=206203
--- Comment #16 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 290639
--> https://bugzilla.kernel.org/attachment.cgi?id=290639=edit
dmesg (kernel 5.8-rc7, PowerMac G4 3,6)
--
You are receiving this mail because:
You are watching
On Thu, Jul 23, 2020 at 10:41 PM Nathan Lynch wrote:
>
> Pingfan Liu writes:
> > This patch prepares for the incoming patch which swaps the order of KOBJ_
> > uevent and dt's updating.
> >
> > It has no functional effect, just groups lmb operation and memblock's in
> > order to insert dt
On Tue, Jul 28, 2020 at 08:11:40AM +0300, Mike Rapoport wrote:
> From: Mike Rapoport
>
> The memory size calculation in cma_early_percent_memory() traverses
> memblock.memory rather than simply call memblock_phys_mem_size(). The
> comment in that function suggests that at some point there should
40 matches
Mail list logo
