Le 09/09/2022 à 07:50, Michael Ellerman a écrit :
> Hi Christophe,
>
> Thanks for trying to clean up this tangled mess.
>
> Christophe Leroy writes:
>> The only 64-bit Book3E CPUs we support is the e500mc.
>
> AFAIK the e500mc is 32-bit?
Yes it seems.
>
> We support e5500 and e6500 which a
Le 09/09/2022 à 01:25, isaku.yamah...@intel.com a écrit :
> [Vous ne recevez pas souvent de courriers de isaku.yamah...@intel.com.
> Découvrez pourquoi ceci est important à
> https://aka.ms/LearnAboutSenderIdentification ]
>
> From: Isaku Yamahata
>
> Move processor compatibility check from
Hi Christophe,
Thanks for trying to clean up this tangled mess.
Christophe Leroy writes:
> The only 64-bit Book3E CPUs we support is the e500mc.
AFAIK the e500mc is 32-bit?
We support e5500 and e6500 which are 64-bit Book3E.
They're derivatives of the e500mc AIUI.
So CONFIG_PPC_E500MC actual
On Fri, Sep 9, 2022 at 5:24 PM Anshuman Khandual
wrote:
>
>
>
> On 8/22/22 13:51, Yicong Yang wrote:
> > From: Barry Song
> >
> > on x86, batched and deferred tlb shootdown has lead to 90%
> > performance increase on tlb shootdown. on arm64, HW can do
> > tlb shootdown without software IPI. But s
On Fri, Sep 9, 2022 at 4:51 PM Anshuman Khandual
wrote:
>
>
>
> On 8/22/22 13:51, Yicong Yang wrote:
> > From: Barry Song
> >
> > Add uaddr to tlbbatch APIs so that platforms like ARM64 are
>
> I guess 'uaddr' refers to a virtual address from the process address
> space itself ? Please be more sp
On 8/22/22 13:51, Yicong Yang wrote:
> From: Barry Song
>
> on x86, batched and deferred tlb shootdown has lead to 90%
> performance increase on tlb shootdown. on arm64, HW can do
> tlb shootdown without software IPI. But sync tlbi is still
> quite expensive.
>
> Even running a simplest progr
ISA v2.06 (POWER7 and up) as well as e6500 support lbarx and lharx.
Add a compile option that allows code to use it, and add support in
cmpxchg and xchg 8 and 16 bit values without shifting and masking.
Signed-off-by: Nicholas Piggin
---
v2: Fixed lwarx->lharx typo, switched to PPC_HAS_
v3: Rebas
Le 08/09/2022 à 15:48, Segher Boessenkool a écrit :
> On Thu, Sep 08, 2022 at 06:00:24AM +, Christophe Leroy wrote:
>> Looking at it more deeply, I see strange things.
>
> I'll have to see full generated machine code to be able to see strange
> things, there isn't enough information at all h
On 8/22/22 13:51, Yicong Yang wrote:
> From: Barry Song
>
> Add uaddr to tlbbatch APIs so that platforms like ARM64 are
I guess 'uaddr' refers to a virtual address from the process address
space itself ? Please be more specific.
> able to apply this on their specific hardware features. For
>
On Fri, Sep 9, 2022 at 4:26 PM Anshuman Khandual
wrote:
>
>
>
> On 8/22/22 13:51, Yicong Yang wrote:
> > From: Barry Song
> >
> > This reverts commit 6bfef171d0d74cb050112e0e49feb20bfddf7f42.
> >
> > I was wrong. Though ARM64 has hardware TLB flush, but it is not free
> > and it is still expensiv
On 8/22/22 13:51, Yicong Yang wrote:
> From: Barry Song
>
> This reverts commit 6bfef171d0d74cb050112e0e49feb20bfddf7f42.
>
> I was wrong. Though ARM64 has hardware TLB flush, but it is not free
> and it is still expensive.
> We still have a good chance to enable batched and deferred TLB flus
On 8/22/22 13:51, Yicong Yang wrote:
> From: Anshuman Khandual
>
> The entire scheme of deferred TLB flush in reclaim path rests on the
> fact that the cost to refill TLB entries is less than flushing out
> individual entries by sending IPI to remote CPUs. But architecture
> can have different wa
Hi Christophe,
I love your patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on powerpc/topic/ppc-kvm linus/master v6.0-rc4
next-20220908]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest
From: Isaku Yamahata
Move processor compatibility check from kvm_arch_processor_compat() into
kvm_arch_hardware_setup(). The check does model name comparison with a
global variable, cur_cpu_spec. There is no point to check it at run time
on all processors.
Suggested-by: Sean Christopherson
Si
Hi!
On Thu, Sep 08, 2022 at 05:07:24PM +0200, Arnd Bergmann wrote:
> - if the XOR code has its frame size explode like this, it's
> probably an indication of the compiler doing something wrong,
> not the kernel code.
On the contrary, it is most likely an indication that the kernel code
wants
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 47c191411b68a771261be3dc0bd6f68394cef358 Add linux-next specific
files for 20220908
Error/Warning reports:
https://lore.kernel.org/linux-mm/202209042337.fqi69rlv-...@intel.com
https
Hi,
I am not sure if this is off topic for this list, but I am not sure
where else to ask. I google this and could not find anything. Googled
Big Endian Linux and it took me to link that lead me to this list.
I am looking for an LSI driver that was rewritten for big endian Linux.
I have tryi
On Thursday 08 September 2022 17:35:11 Pali Rohár wrote:
> On Thursday 08 September 2022 15:25:14 Christophe Leroy wrote:
> > Le 08/08/2022 à 20:40, Pali Rohár a écrit :
> > > On Friday 10 June 2022 00:24:20 Pali Rohár wrote:
> > >> On Friday 20 May 2022 14:30:02 Pali Rohár wrote:
> > >>> + linux-m
Le 08/09/2022 à 09:24, Aneesh Kumar K.V a écrit :
> Powerpc architecture supports 16GB hugetlb pages with hash translation. For 4K
> page size, this is implemented as a hugepage directory entry at PGD level and
> for 64K it is implemented as a huge page pte at PUD level
>
> With 16GB hugetlb siz
On 9/8/22 10:37, Christophe Leroy wrote:
CONFIG_PPC_FSL_BOOK3E is redundant with CONFIG_PPC_E500.
Replace it so that CONFIG_PPC_FSL_BOOK3E can be removed later.
Signed-off-by: Christophe Leroy
Cc: Wim Van Sebroeck
Cc: Guenter Roeck
Cc: linux-watch...@vger.kernel.org
Acked-by: Guenter Roeck
e500v1/v2 and e500mc are said to be mutually exclusive in Kconfig.
Split e500 cpu_specs[] and then restrict the non e500mc to PPC32
which is then 85xx.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/cpu_specs.h | 6 +-
arch/powerpc/kernel/cpu_specs_85xx.h | 60 +
e500 idle setup is a bit messy.
e500_idle() is used for PPC32 while book3e_idle() is used for PPC64.
As they are mutually exclusive, call them all e500_idle().
Use CONFIG_MPC_85xx instead of PPC32 + E500 in Makefile and rename
idle_e500.c to idle_85xx.c .
Rename idle_book3e.c to idle_64e.c and r
cpu_specs[] is full of #ifdefs depending on the different
types of CPU.
CPUs are mutually exclusive, it is therefore possible to split
cpu_specs[] into smaller more readable pieces.
Create cpu_specs_XXX.h that will each be dedicated on one
of the following mutually exclusive families:
- 40x
- 44x
Today there is:
if e500 or 8xx
if e500
mmu_psize_defs[] =
else if 8xx
mmu_psize_defs[] =
else
mmu_psize_defs[] =
endif
endif
The else leg is dead definition.
Drop that else leg and rewrite as:
if e500
mmu_psize_defs[] =
endif
if 8xx
mmu_psize_
PPC_85xx implies PPC32 so no need to check PPC32 in addition.
PPC64 && !PPC_BOOK3E_64 means PPC_BOOK3S_64.
PPC_BOOK3E_64 implies PPC_E500.
Signed-off-by: Christophe Leroy
---
arch/powerpc/Kconfig | 2 +-
arch/powerpc/platforms/Kconfig.cputype | 2 +-
arch/powerpc/xmon/xmon.c
PPC_85xx and PPC_BOOK3E_64 already select E500 so no need
to select it again by PPC_QEMU_E500 and CORENET_GENERIC
as they depend on PPC_85xx || PPC_BOOK3E_64.
PPC_BOOK3E_64 already selects E500MC so no need to
select it again by PPC_QEMU_E500 if PPC64, PPC_BOOK3E_64
is the only way into PPC_QEMU_E
CONFIG_PPC_FSL_BOOK3E is redundant with CONFIG_PPC_E500.
Remove it.
And rename five files accordingly.
Signed-off-by: Christophe Leroy
---
arch/powerpc/Kconfig | 2 +-
arch/powerpc/include/asm/barrier.h | 2 +-
arch/powerpc/include/asm/hugetlb.h
CONFIG_PPC_BOOK3E is redundant with CONFIG_PPC_BOOK3E_64.
The later is more explicit about the fact that it's a 64 bits target.
Remove CONFIG_PPC_BOOK3E.
Signed-off-by: Christophe Leroy
---
arch/powerpc/Kconfig | 2 +-
arch/powerpc/include/asm/cputable.h | 4 +--
a
CONFIG_PPC_BOOK3E_MMU is redundant with CONFIG_PPC_E500.
Remove it.
Also rename mmu-book3e.h to mmu-e500.h
Signed-off-by: Christophe Leroy
---
.../include/asm/nohash/{mmu-book3e.h => mmu-e500.h} | 0
arch/powerpc/include/asm/nohash/mmu.h | 4 ++--
arch/powerpc/kernel/
PPC_E500 is the same as PPC_85xx || PPC_BOOKE_64
Signed-off-by: Christophe Leroy
---
arch/powerpc/Kconfig | 2 +-
arch/powerpc/platforms/85xx/Kconfig| 2 +-
arch/powerpc/platforms/Kconfig.cputype | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/po
PPC_85xx is PPC32 only.
PPC_85xx always selects E500 and is the only PPC32 that
selects E500.
FSL_BOOKE is selected when E500 and PPC32 are selected.
So FSL_BOOKE is redundant with PPC_85xx.
Remove FSL_BOOKE.
And rename four files accordingly.
cpu_setup_fsl_booke.S is not renamed because it is
Move all prototypes out of cputable.h
For that rename cpu_setup_power.h to cpu_setup.h and move all
prototypes in it.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/cpu_setup.h | 49 ++
arch/powerpc/include/asm/cpu_setup_power.h | 12 --
arch/powerpc/
CONFIG_PPC_FSL_BOOK3E is redundant with CONFIG_PPC_E500.
Rename it so that CONFIG_PPC_FSL_BOOK3E can be removed later.
Signed-off-by: Christophe Leroy
Cc: Jonathan Corbet
Cc: linux-...@vger.kernel.org
---
Documentation/admin-guide/kernel-parameters.txt | 2 +-
1 file changed, 1 insertion(+), 1
CONFIG_PPC_BOOK3E_64 implies CONFIG_PPC_FSL_BOOK3E so no need of
additional #ifdefs in files built exclusively for CONFIG_PPC_BOOK3E_64.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/exceptions-64e.S | 8
arch/powerpc/mm/nohash/tlb_low_64e.S | 6 --
2 files changed, 14 del
CONFIG_PPC_FSL_BOOK3E is redundant with CONFIG_PPC_E500.
Replace it so that CONFIG_PPC_FSL_BOOK3E can be removed later.
Signed-off-by: Christophe Leroy
Cc: Wim Van Sebroeck
Cc: Guenter Roeck
Cc: linux-watch...@vger.kernel.org
---
drivers/watchdog/Kconfig | 8
drivers/watchdog/boo
The only 64-bit Book3E CPUs we support is the e500mc.
However our Kconfig allows configurating a kernel that has 64-bit
Book3E support, but no e500mc support enabled. Such a kernel
would never boot, it doesn't know about any CPUs.
To fix this, force e500mc to be selected whenever we are
building
CONFIG_PPC_FSL_BOOKE doesn't exist. Should be CONFIG_FSL_BOOKE.
Fixes: 49e3d8ea6248 ("powerpc/fsl_booke: Enable STRICT_KERNEL_RWX")
Cc: sta...@vger.kernel.org
Signed-off-by: Christophe Leroy
---
arch/powerpc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc
It will be used outside arch/powerpc, make it clear its a
powerpc configuration item.
And we already have CONFIG_PPC_E500MC, so that will make
it more consistant.
Signed-off-by: Christophe Leroy
---
arch/powerpc/Makefile | 2 +-
arch/powerpc/include/asm/cputable.h |
__machine_check_early_realmode_p{7/8/9} are already in mce.h
which is included. Remove them from cputable.c
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/cputable.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
ind
On 9/8/22 10:23 PM, Matthew Wilcox wrote:
> On Thu, Sep 08, 2022 at 12:56:59PM +0530, Aneesh Kumar K.V wrote:
>> +++ b/fs/dax.c
>> @@ -1304,7 +1304,7 @@ EXPORT_SYMBOL_GPL(dax_zero_range);
>> int dax_truncate_page(struct inode *inode, loff_t pos, bool *did_zero,
>> const struct iomap_o
On Thu, Sep 08, 2022 at 12:56:59PM +0530, Aneesh Kumar K.V wrote:
> +++ b/fs/dax.c
> @@ -1304,7 +1304,7 @@ EXPORT_SYMBOL_GPL(dax_zero_range);
> int dax_truncate_page(struct inode *inode, loff_t pos, bool *did_zero,
> const struct iomap_ops *ops)
> {
> - unsigned int blocksize =
On Thursday 08 September 2022 15:25:14 Christophe Leroy wrote:
> Le 08/08/2022 à 20:40, Pali Rohár a écrit :
> > On Friday 10 June 2022 00:24:20 Pali Rohár wrote:
> >> On Friday 20 May 2022 14:30:02 Pali Rohár wrote:
> >>> + linux-mm
> >>>
> >>> Do you know what are requirements for kernel to suppo
Le 08/08/2022 à 20:40, Pali Rohár a écrit :
> On Friday 10 June 2022 00:24:20 Pali Rohár wrote:
>> On Friday 20 May 2022 14:30:02 Pali Rohár wrote:
>>> + linux-mm
>>>
>>> Do you know what are requirements for kernel to support non-contiguous
>>> memory support and what is needed to enable it for
On Thu, Sep 8, 2022, at 2:27 AM, Michael Ellerman wrote:
> Christophe Leroy writes:
>
> Yeah that would make some sense.
>
> On 64-bit the largest frame in that file is 1424, which is below the
> default 2048 byte limit.
>
> So maybe just increase it for 32-bit && KASAN.
>
> What would be nice is
On Thu, Sep 08, 2022 at 06:00:24AM +, Christophe Leroy wrote:
> Looking at it more deeply, I see strange things.
I'll have to see full generated machine code to be able to see strange
things, there isn't enough information at all here yet. Sorry.
Use private mail if it is too big or unintere
On 9/7/22 23:23, Christophe Leroy wrote:
Hi All,
Le 18/07/2021 à 18:09, Oliver O'Halloran a écrit :
On Sun, Jul 18, 2021 at 2:24 AM Guenter Roeck wrote:
On Sat, Jul 17, 2021 at 05:57:50PM +0200, Christophe Leroy wrote:
Guenter Roeck a écrit :
This patch reverts commit 407d418f2fd4 ("powe
PAPR specifies accumulated virtual processor wait intervals that relate
to partition scheduling interval times. Implement these counters in the
same way as they are repoted by dtl.
Reviewed-by: Fabiano Rosas
Signed-off-by: Nicholas Piggin
---
This requires patch "powerpc/pseries: Add wait interv
Stolen time logging in dtl was removed from the P9 path, so guests had
no stolen time accounting. Add it back in a simpler way that still
avoids locks and per-core accounting code.
Fixes: ecb6a7207f92 ("KVM: PPC: Book3S HV P9: Remove most of the vcore logic")
Signed-off-by: Nicholas Piggin
---
a
Update the guest state and timing entry/exit accounting to use the new
API, which was introduced following issues found[1]. KVM HV does
possibly call instrumented code inside the guest context, and it does
call srcu inside the guest context which is fragile at best.
Switch to the new API, moving t
kvmhv_run_single_vcpu() disables PMIs as well as Linux irqs,
however the tick time accounting code enables and disables irqs and
not PMIs within this region. By chance this might not actually cause
a bug, but it is clearly an incorrect use of the APIs.
Fixes: 2251fbe76395e ("KVM: PPC: Book3S HV P9
On guest entry, vcpu->cpu and vcpu->arch.thread_cpu are set after
disabling host irqs. On guest exit there is a window whre tick time
accounting briefly enables irqs before these fields are cleared.
Move them up to ensure they are cleared before host irqs are run.
This is possibly not a problem, b
Commit 171476775d32 ("context_tracking: Convert state to atomic_t")
added a CONTEXT_IDLE state which can be encountered by interrupts from
kernel mode in the idle thread, causing a false positive warning.
Fixes: 171476775d32 ("context_tracking: Convert state to atomic_t")
Signed-off-by: Nicholas P
Le 08/09/2022 à 00:01, Nathan Lynch a écrit :
> At the time this was submitted by Leonardo, I confirmed -- or thought
> I had confirmed -- with PowerVM partition firmware development that
> the following RTAS functions:
>
> - ibm,get-xive
> - ibm,int-off
> - ibm,int-on
> - ibm,set-xive
>
> were s
Powerpc architecture supports 16GB hugetlb pages with hash translation. For 4K
page size, this is implemented as a hugepage directory entry at the PGD level
and for 64K it is implemented as a huge page pte at the PUD level
Hugetlbfs sets up file system blocksize same as page size and this patch
sw
On 07/09/2022 18:33, Pali Rohár wrote:
> On Wednesday 07 September 2022 14:38:42 Krzysztof Kozlowski wrote:
>> On 31/08/2022 10:17, Pali Rohár wrote:
>>> This new optional priority property allows to specify custom priority level
>>> of reset device. Prior this change priority level was hardcoded t
Powerpc architecture supports 16GB hugetlb pages with hash translation. For 4K
page size, this is implemented as a hugepage directory entry at PGD level and
for 64K it is implemented as a huge page pte at PUD level
With 16GB hugetlb size, offset within a page is greater than 32 bits. Hence
switch
56 matches
Mail list logo
