date:20210504

Stephen Rothwell  writes:
> Hi all,
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
>   arch/powerpc/Kconfig
>
> between commit:
>
>   c6b05f4e233c ("powerpc/kconfig: Restore alphabetic order of the selects 
> under CONFIG_PPC")
>
> from the powerpc tree and commits:
>
>   fd7d5c273c43 ("mm: generalize HUGETLB_PAGE_SIZE_VARIABLE")
>   301ba77ae03c ("mm: generalize ARCH_ENABLE_MEMORY_[HOTPLUG|HOTREMOVE]")
>
> from the akpm-current tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Urgh, I did check linux-next to see if that patch would conflict but
didn't think it would conflict *that* badly.

I guess I'll leave it for now, but I can drop it if necessary.

cheers


> diff --cc arch/powerpc/Kconfig
> index ab17a56c3d10,d4333049b813..
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@@ -118,11 -118,10 +118,13 @@@ config PP
>   # Please keep this list sorted alphabetically.
>   #
>   select ARCH_32BIT_OFF_T if PPC32
> + select ARCH_ENABLE_MEMORY_HOTPLUG
> + select ARCH_ENABLE_MEMORY_HOTREMOVE
>  +select ARCH_HAS_COPY_MC if PPC64
>   select ARCH_HAS_DEBUG_VIRTUAL
>  +select ARCH_HAS_DEBUG_VM_PGTABLE
>   select ARCH_HAS_DEVMEM_IS_ALLOWED
>  +select ARCH_HAS_DMA_MAP_DIRECT  if PPC_PSERIES
>   select ARCH_HAS_ELF_RANDOMIZE
>   select ARCH_HAS_FORTIFY_SOURCE
>   select ARCH_HAS_GCOV_PROFILE_ALL
> @@@ -163,8 -162,9 +165,8 @@@
>   select BUILDTIME_TABLE_SORT
>   select CLONE_BACKWARDS
>   select DCACHE_WORD_ACCESS   if PPC64 && CPU_LITTLE_ENDIAN
> - select DMA_OPS_BYPASS   if PPC64
>   select DMA_OPS  if PPC64
> + select DMA_OPS_BYPASS   if PPC64
>  -select ARCH_HAS_DMA_MAP_DIRECT  if PPC64 && PPC_PSERIES
>   select DYNAMIC_FTRACE   if FUNCTION_TRACER
>   select EDAC_ATOMIC_SCRUB
>   select EDAC_SUPPORT
> @@@ -182,15 -181,12 +184,15 @@@
>   select GENERIC_STRNCPY_FROM_USER
>   select GENERIC_STRNLEN_USER
>   select GENERIC_TIME_VSYSCALL
>  -select GENERIC_GETTIMEOFDAY
>  +select GENERIC_VDSO_TIME_NS
>   select HAVE_ARCH_AUDITSYSCALL
> - select HAVE_ARCH_HUGE_VMAP  if PPC_BOOK3S_64 && 
> PPC_RADIX_MMU
>  +select HAVE_ARCH_HUGE_VMALLOC   if HAVE_ARCH_HUGE_VMAP
> + select HAVE_ARCH_HUGE_VMAP  if PPC_BOOK3S_64 && 
> PPC_RADIX_MMU
>   select HAVE_ARCH_JUMP_LABEL
>  +select HAVE_ARCH_JUMP_LABEL_RELATIVE
>   select HAVE_ARCH_KASAN  if PPC32 && PPC_PAGE_SHIFT <= 14
>   select HAVE_ARCH_KASAN_VMALLOC  if PPC32 && PPC_PAGE_SHIFT <= 14
>  +select HAVE_ARCH_KFENCE if PPC32
>   select HAVE_ARCH_KGDB
>   select HAVE_ARCH_MMAP_RND_BITS
>   select HAVE_ARCH_MMAP_RND_COMPAT_BITS   if COMPAT
> @@@ -231,19 -227,23 +233,20 @@@
>   select HAVE_LIVEPATCH   if HAVE_DYNAMIC_FTRACE_WITH_REGS
>   select HAVE_MOD_ARCH_SPECIFIC
>   select HAVE_NMI if PERF_EVENTS || (PPC64 && 
> PPC_BOOK3S)
>  -select HAVE_HARDLOCKUP_DETECTOR_ARCHif (PPC64 && PPC_BOOK3S)
>  -select HAVE_OPTPROBES   if PPC64
>  +select HAVE_OPTPROBES
>   select HAVE_PERF_EVENTS
>   select HAVE_PERF_EVENTS_NMI if PPC64
>  -select HAVE_HARDLOCKUP_DETECTOR_PERFif PERF_EVENTS && 
> HAVE_PERF_EVENTS_NMI && !HAVE_HARDLOCKUP_DETECTOR_ARCH
>   select HAVE_PERF_REGS
>   select HAVE_PERF_USER_STACK_DUMP
>  -select HUGETLB_PAGE_SIZE_VARIABLE   if PPC_BOOK3S_64 && HUGETLB_PAGE
>  -select MMU_GATHER_RCU_TABLE_FREE
>  -select MMU_GATHER_PAGE_SIZE
>   select HAVE_REGS_AND_STACK_ACCESS_API
>  -select HAVE_RELIABLE_STACKTRACE if PPC_BOOK3S_64 && 
> CPU_LITTLE_ENDIAN
>  +select HAVE_RELIABLE_STACKTRACE
>  +select HAVE_RSEQ
>   select HAVE_SOFTIRQ_ON_OWN_STACK
>  +select HAVE_STACKPROTECTOR  if PPC32 && 
> $(cc-option,-mstack-protector-guard=tls -mstack-protector-guard-reg=r2)
>  +select HAVE_STACKPROTECTOR  if PPC64 && 
> $(cc-option,-mstack-protector-guard=tls -mstack-protector-guard-reg=r13)
>   select HAVE_SYSCALL_TRACEPOINTS
>   select HAVE_VIRT_CPU_ACCOUNTING
>  -select HAVE_IRQ_TIME_ACCOUNTING
>  -select HAVE_RSEQ
> ++select HUGETLB_PAGE_SIZE_VARIABLE   if PPC_BOOK3S_64 && HUGETLB_PAGE
>   select IOMMU_HELPER if PPC64
>   select IRQ_DOMAIN
>   select IRQ_FORCED_THREADING

Re: [PATCH 1/2] powerpc/asm-offset: Remove unused items related to paca





Le 04/05/2021 à 12:40, Christophe Leroy a écrit :



Le 04/05/2021 à 12:14, Nicholas Piggin a écrit :

Excerpts from Christophe Leroy's message of May 4, 2021 2:46 am:

PACA_SIZE, PACACONTEXTID, PACALOWSLICESPSIZE, PACAHIGHSLICEPSIZE,
PACA_SLB_ADDR_LIMIT, MMUPSIZEDEFSIZE, PACASLBCACHE, PACASLBCACHEPTR,
PACASTABRR, PACAVMALLOCSLLP, MMUPSIZESLLP, PACACONTEXTSLLP,
PACALPPACAPTR, LPPACA_DTLIDX and PACA_DTL_RIDX are not used anymore
by ASM code.


Reviewed-by: Nicholas Piggin 

Also I think SIGSEGV, NMI_MASK, THREAD_DBCR0, KUAP?, TI_FLAGS,
TI_PREEMPT, [ID]CACHEL1*, STACK_REGS_KUAP, EXC_LVL_SIZE, KVM_NEED_FLUSH,
KVM_FWNMI, VCPU_DEC, VCPU_SPMC, HSTATE_XICS_PHYS, HSTATE_SAVED_XIRR,
PPC_DBELL_MSGTYPE I think. While we're cleaning it up.


Yes, thanks for checking.

I think we can safely remove KUAP.

But we can't remove EXC_LVL_SIZE, it is used in kernel/head_booke.h which is probably included in 
head_44x.S and head_fsl_booke.S


DCACHEL1*BLOCKSIZE are also still used.

Christophe




Christophe

Re: [PATCH 1/2] powerpc/64s: Fix crashes when toggling stf barrier

2021-05-04 Thread Nathan Lynch

Michael Ellerman  writes:
> Nathan Lynch  writes:
>> post_mobility_fixup() does cpus_read_unlock() before calling
>> pseries_setup_security_mitigations(), I think that will need to be
>> changed?
>
> I don't think so.
>
> I'm using stop_machine_cpuslocked() but that's because I'm a goose and
> forgot to switch to stop_machine() after I reworked the code to not take
> cpus_read_lock() by hand. I really shouldn't send patches after 11pm.
>
> I don't think it's important to keep the cpus lock held from where we
> take it in post_mobility_fixup(). If some CPUs come or go between there
> and here that's fine.

Yes, agreed.

Re: [PATCH 1/2] powerpc/64s: Fix crashes when toggling stf barrier

Nathan Lynch  writes:
> Michael Ellerman  writes:
>> -void do_stf_barrier_fixups(enum stf_barrier_type types)
>> +static int __do_stf_barrier_fixups(void *data)
>>  {
>> +enum stf_barrier_type types = (enum stf_barrier_type)data;
>> +
>>  do_stf_entry_barrier_fixups(types);
>>  do_stf_exit_barrier_fixups(types);
>> +
>> +return 0;
>> +}
>> +
>> +void do_stf_barrier_fixups(enum stf_barrier_type types)
>> +{
>> +/*
>> + * The call to the fallback entry flush, and the fallback/sync-ori exit
>> + * flush can not be safely patched in/out while other CPUs are executing
>> + * them. So call __do_stf_barrier_fixups() on one CPU while all other 
>> CPUs
>> + * spin in the stop machine core with interrupts hard disabled.
>> + */
>> +stop_machine_cpuslocked(__do_stf_barrier_fixups, (void *)types, NULL);
>
> Would it be preferable to avoid the explicit casts:
>
>   stop_machine_cpuslocked(__do_stf_barrier_fixups, , NULL);
>
> ...
>
> static int __do_stf_barrier_fixups(void *data)
> {
>   enum stf_barrier_type *types = data;
>
>   do_stf_entry_barrier_fixups(*types);
>   do_stf_exit_barrier_fixups(*types);
>
> ?

Yes.

That will also avoid the pesky issue of undefined behaviour :facepalm:

> post_mobility_fixup() does cpus_read_unlock() before calling
> pseries_setup_security_mitigations(), I think that will need to be
> changed?

I don't think so.

I'm using stop_machine_cpuslocked() but that's because I'm a goose and
forgot to switch to stop_machine() after I reworked the code to not take
cpus_read_lock() by hand. I really shouldn't send patches after 11pm.

I don't think it's important to keep the cpus lock held from where we
take it in post_mobility_fixup(). If some CPUs come or go between there
and here that's fine.

I'll send a v2.

cheers

[powerpc:next-test] BUILD REGRESSION a5014a5c936a2a9a223e699e1f3abd54d5f68d2c

   defconfig
nios2allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
arc defconfig
sh   allmodconfig
nios2   defconfig
arc  allyesconfig
nds32 allnoconfig
parisc  defconfig
s390 allyesconfig
s390 allmodconfig
s390defconfig
sparcallyesconfig
sparc   defconfig
i386defconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
i386 randconfig-a003-20210504
i386 randconfig-a006-20210504
i386 randconfig-a001-20210504
i386 randconfig-a005-20210504
i386 randconfig-a004-20210504
i386 randconfig-a002-20210504
i386 randconfig-a003-20210503
i386 randconfig-a006-20210503
i386 randconfig-a001-20210503
i386 randconfig-a005-20210503
i386 randconfig-a004-20210503
i386 randconfig-a002-20210503
x86_64   randconfig-a014-20210504
x86_64   randconfig-a015-20210504
x86_64   randconfig-a012-20210504
x86_64   randconfig-a013-20210504
x86_64   randconfig-a011-20210504
x86_64   randconfig-a016-20210504
i386 randconfig-a015-20210504
i386 randconfig-a013-20210504
i386 randconfig-a016-20210504
i386 randconfig-a014-20210504
i386 randconfig-a012-20210504
i386 randconfig-a011-20210504
riscvnommu_k210_defconfig
riscvnommu_virt_defconfig
riscv allnoconfig
riscv   defconfig
riscv  rv32_defconfig
um   allmodconfig
umallnoconfig
um   allyesconfig
um  defconfig
x86_64rhel-8.3-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  rhel-8.3-kbuiltin
x86_64  kexec

clang tested configs:
x86_64   randconfig-a001-20210504
x86_64   randconfig-a003-20210504
x86_64   randconfig-a005-20210504
x86_64   randconfig-a002-20210504
x86_64   randconfig-a006-20210504
x86_64   randconfig-a004-20210504
x86_64   randconfig-a014-20210503
x86_64   randconfig-a015-20210503
x86_64   randconfig-a012-20210503
x86_64   randconfig-a011-20210503
x86_64   randconfig-a013-20210503
x86_64   randconfig-a016-20210503

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org

[powerpc:next] BUILD SUCCESS c6b05f4e233cc666f003e9fe68b2f765952875a9

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
next
branch HEAD: c6b05f4e233cc666f003e9fe68b2f765952875a9  powerpc/kconfig: Restore 
alphabetic order of the selects under CONFIG_PPC

elapsed time: 723m

configs tested: 137
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm defconfig
arm64allyesconfig
arm64   defconfig
arm  allyesconfig
arm  allmodconfig
x86_64   allyesconfig
riscvallmodconfig
i386 allyesconfig
riscvallyesconfig
arm mxs_defconfig
mips allyesconfig
mipsmaltaup_xpa_defconfig
arm   viper_defconfig
arm  imote2_defconfig
arm   imx_v6_v7_defconfig
arm  pcm027_defconfig
powerpc tqm8560_defconfig
mipsar7_defconfig
powerpc asp8347_defconfig
sparc64  alldefconfig
mipse55_defconfig
mipsvocore2_defconfig
powerpcicon_defconfig
powerpcsocrates_defconfig
powerpc tqm5200_defconfig
sh  sdk7780_defconfig
m68k  atari_defconfig
m68kmvme147_defconfig
arm  integrator_defconfig
ia64  tiger_defconfig
m68k   bvme6000_defconfig
powerpc tqm8548_defconfig
m68km5272c3_defconfig
mips   ip22_defconfig
powerpc  makalu_defconfig
powerpc powernv_defconfig
arm   sama5_defconfig
arm   spitz_defconfig
powerpccell_defconfig
nios2 10m50_defconfig
arm   h3600_defconfig
powerpc   lite5200b_defconfig
h8300   defconfig
armzeus_defconfig
powerpc mpc837x_mds_defconfig
powerpc ppa8548_defconfig
arm  pxa3xx_defconfig
mips  rm200_defconfig
arc haps_hs_defconfig
sh   se7712_defconfig
arm  collie_defconfig
arm  gemini_defconfig
armspear6xx_defconfig
parisc   allyesconfig
m68kstmark2_defconfig
sh   se7780_defconfig
powerpcadder875_defconfig
mipsnlm_xlp_defconfig
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
m68k allyesconfig
nds32   defconfig
nios2allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
arc defconfig
sh   allmodconfig
nios2   defconfig
arc  allyesconfig
nds32 allnoconfig
parisc  defconfig
s390 allyesconfig
s390 allmodconfig
s390defconfig
sparcallyesconfig
sparc   defconfig
i386defconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
i386 randconfig-a003-20210504
i386 randconfig-a006-20210504
i386 randconfig-a001-20210504
i386 randconfig-a005-20210504
i386 randconfig-a004-20210504
i386 randconfig-a002-20210504
i386 randconfig-a003-20210503
i386 randconfig-a006-20210503
i386 randconfig-a001-20210503
i386 randconfig-a005-20210503
i386 randconfig-a004-20210503
i386 randconfig-a002-20210503
x86_64   randconfig-a014-20210504

[powerpc:merge] BUILD SUCCESS 7619d98e5041d5c25aba5428704dba6121237a9a

  allmodconfig
powerpc   allnoconfig
i386 randconfig-a003-20210504
i386 randconfig-a006-20210504
i386 randconfig-a001-20210504
i386 randconfig-a005-20210504
i386 randconfig-a004-20210504
i386 randconfig-a002-20210504
i386 randconfig-a003-20210503
i386 randconfig-a006-20210503
i386 randconfig-a001-20210503
i386 randconfig-a005-20210503
i386 randconfig-a004-20210503
i386 randconfig-a002-20210503
x86_64   randconfig-a014-20210504
x86_64   randconfig-a015-20210504
x86_64   randconfig-a012-20210504
x86_64   randconfig-a013-20210504
x86_64   randconfig-a011-20210504
x86_64   randconfig-a016-20210504
i386 randconfig-a015-20210504
i386 randconfig-a013-20210504
i386 randconfig-a016-20210504
i386 randconfig-a014-20210504
i386 randconfig-a012-20210504
i386 randconfig-a011-20210504
riscvnommu_k210_defconfig
riscv allnoconfig
riscv   defconfig
riscv  rv32_defconfig
um   allmodconfig
umallnoconfig
um   allyesconfig
um  defconfig
x86_64rhel-8.3-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  rhel-8.3-kbuiltin
x86_64  kexec

clang tested configs:
x86_64   randconfig-a001-20210504
x86_64   randconfig-a003-20210504
x86_64   randconfig-a005-20210504
x86_64   randconfig-a002-20210504
x86_64   randconfig-a006-20210504
x86_64   randconfig-a004-20210504
x86_64   randconfig-a014-20210503
x86_64   randconfig-a015-20210503
x86_64   randconfig-a012-20210503
x86_64   randconfig-a011-20210503
x86_64   randconfig-a013-20210503
x86_64   randconfig-a016-20210503

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org

Re: [PATCH 4/4] powerpc/powernv: Remove POWER9 PVR version check for entry and uaccess flushes

2021-05-04 Thread Joel Stanley

On Tue, 4 May 2021 at 09:16, Nicholas Piggin  wrote:
>
> Excerpts from Joel Stanley's message of May 4, 2021 10:51 am:
> > On Mon, 3 May 2021 at 13:04, Nicholas Piggin  wrote:
> >>
> >> These aren't necessarily POWER9 only, and it's not to say some new
> >> vulnerability may not get discovered on other processors for which
> >> we would like the flexibility of having the workaround enabled by
> >> firmware.
> >>
> >> Remove the restriction that they only apply to POWER9.
> >
> > I was wondering how these worked which led me to reviewing your patch.
> > From what I could see, these are enabled by default (SEC_FTR_DEFAULT
> > in arch/powerpc/include/asm/security_features.h), so unless all
> > non-POWER9 machines have set the "please don't" bit in their firmware
> > this patch will enable the feature for those machines. Is that what
> > you wanted?
>
> Yes. POWER7/8 should be affected (it's similar mechanism that requires
> the meltdown RFI flush, which those processors need).
>
> POWER10 we haven't released a bare metal firmware with the right bits
> yet. Not urgent at the moment but wouldn't hurt to specify them and
> add the Linux code for them.

Thanks for the explanation. This could go in the commit message if you re-spin.

Reviewed-by: Joel Stanley

linux-next: manual merge of the akpm-current tree with the powerpc tree

2021-05-04 Thread Stephen Rothwell

Hi all,

Today's linux-next merge of the akpm-current tree got a conflict in:

  arch/powerpc/Kconfig

between commit:

  c6b05f4e233c ("powerpc/kconfig: Restore alphabetic order of the selects under 
CONFIG_PPC")

from the powerpc tree and commits:

  fd7d5c273c43 ("mm: generalize HUGETLB_PAGE_SIZE_VARIABLE")
  301ba77ae03c ("mm: generalize ARCH_ENABLE_MEMORY_[HOTPLUG|HOTREMOVE]")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/powerpc/Kconfig
index ab17a56c3d10,d4333049b813..
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@@ -118,11 -118,10 +118,13 @@@ config PP
# Please keep this list sorted alphabetically.
#
select ARCH_32BIT_OFF_T if PPC32
+   select ARCH_ENABLE_MEMORY_HOTPLUG
+   select ARCH_ENABLE_MEMORY_HOTREMOVE
 +  select ARCH_HAS_COPY_MC if PPC64
select ARCH_HAS_DEBUG_VIRTUAL
 +  select ARCH_HAS_DEBUG_VM_PGTABLE
select ARCH_HAS_DEVMEM_IS_ALLOWED
 +  select ARCH_HAS_DMA_MAP_DIRECT  if PPC_PSERIES
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_FORTIFY_SOURCE
select ARCH_HAS_GCOV_PROFILE_ALL
@@@ -163,8 -162,9 +165,8 @@@
select BUILDTIME_TABLE_SORT
select CLONE_BACKWARDS
select DCACHE_WORD_ACCESS   if PPC64 && CPU_LITTLE_ENDIAN
-   select DMA_OPS_BYPASS   if PPC64
select DMA_OPS  if PPC64
+   select DMA_OPS_BYPASS   if PPC64
 -  select ARCH_HAS_DMA_MAP_DIRECT  if PPC64 && PPC_PSERIES
select DYNAMIC_FTRACE   if FUNCTION_TRACER
select EDAC_ATOMIC_SCRUB
select EDAC_SUPPORT
@@@ -182,15 -181,12 +184,15 @@@
select GENERIC_STRNCPY_FROM_USER
select GENERIC_STRNLEN_USER
select GENERIC_TIME_VSYSCALL
 -  select GENERIC_GETTIMEOFDAY
 +  select GENERIC_VDSO_TIME_NS
select HAVE_ARCH_AUDITSYSCALL
-   select HAVE_ARCH_HUGE_VMAP  if PPC_BOOK3S_64 && 
PPC_RADIX_MMU
 +  select HAVE_ARCH_HUGE_VMALLOC   if HAVE_ARCH_HUGE_VMAP
+   select HAVE_ARCH_HUGE_VMAP  if PPC_BOOK3S_64 && 
PPC_RADIX_MMU
select HAVE_ARCH_JUMP_LABEL
 +  select HAVE_ARCH_JUMP_LABEL_RELATIVE
select HAVE_ARCH_KASAN  if PPC32 && PPC_PAGE_SHIFT <= 14
select HAVE_ARCH_KASAN_VMALLOC  if PPC32 && PPC_PAGE_SHIFT <= 14
 +  select HAVE_ARCH_KFENCE if PPC32
select HAVE_ARCH_KGDB
select HAVE_ARCH_MMAP_RND_BITS
select HAVE_ARCH_MMAP_RND_COMPAT_BITS   if COMPAT
@@@ -231,19 -227,23 +233,20 @@@
select HAVE_LIVEPATCH   if HAVE_DYNAMIC_FTRACE_WITH_REGS
select HAVE_MOD_ARCH_SPECIFIC
select HAVE_NMI if PERF_EVENTS || (PPC64 && 
PPC_BOOK3S)
 -  select HAVE_HARDLOCKUP_DETECTOR_ARCHif (PPC64 && PPC_BOOK3S)
 -  select HAVE_OPTPROBES   if PPC64
 +  select HAVE_OPTPROBES
select HAVE_PERF_EVENTS
select HAVE_PERF_EVENTS_NMI if PPC64
 -  select HAVE_HARDLOCKUP_DETECTOR_PERFif PERF_EVENTS && 
HAVE_PERF_EVENTS_NMI && !HAVE_HARDLOCKUP_DETECTOR_ARCH
select HAVE_PERF_REGS
select HAVE_PERF_USER_STACK_DUMP
 -  select HUGETLB_PAGE_SIZE_VARIABLE   if PPC_BOOK3S_64 && HUGETLB_PAGE
 -  select MMU_GATHER_RCU_TABLE_FREE
 -  select MMU_GATHER_PAGE_SIZE
select HAVE_REGS_AND_STACK_ACCESS_API
 -  select HAVE_RELIABLE_STACKTRACE if PPC_BOOK3S_64 && 
CPU_LITTLE_ENDIAN
 +  select HAVE_RELIABLE_STACKTRACE
 +  select HAVE_RSEQ
select HAVE_SOFTIRQ_ON_OWN_STACK
 +  select HAVE_STACKPROTECTOR  if PPC32 && 
$(cc-option,-mstack-protector-guard=tls -mstack-protector-guard-reg=r2)
 +  select HAVE_STACKPROTECTOR  if PPC64 && 
$(cc-option,-mstack-protector-guard=tls -mstack-protector-guard-reg=r13)
select HAVE_SYSCALL_TRACEPOINTS
select HAVE_VIRT_CPU_ACCOUNTING
 -  select HAVE_IRQ_TIME_ACCOUNTING
 -  select HAVE_RSEQ
++  select HUGETLB_PAGE_SIZE_VARIABLE   if PPC_BOOK3S_64 && HUGETLB_PAGE
select IOMMU_HELPER if PPC64
select IRQ_DOMAIN
select IRQ_FORCED_THREADING


pgp6QZ3TUKD3N.pgp
Description: OpenPGP digital signature

Re: [PATCH v7] powerpc/irq: Inline call_do_irq() and call_do_softirq()

2021-05-04 Thread Nick Desaulniers

On Fri, Apr 30, 2021 at 2:33 PM Nick Desaulniers
 wrote:
>
> On Tue, Apr 27, 2021 at 1:42 PM Nick Desaulniers
>  wrote:
> >
> > On Mon, Apr 26, 2021 at 11:39 PM Christophe Leroy
> >  wrote:
> > >
> > > As you can see, CLANG doesn't save/restore 'lr' allthought 'lr' is 
> > > explicitely listed in the
> > > registers clobbered by the inline assembly:
> >
> > Ah, thanks for debugging this. Will follow up in
> > https://bugs.llvm.org/show_bug.cgi?id=50147.
>
> Looks like there's a fix posted for LLVM in: https://reviews.llvm.org/D101657
>
> Though trying to test it in QEMU, I'm hitting some assertion failure
> booting a kernel (even without that patch to LLVM):
> qemu-system-ppc: ../../hw/pci/pci.c:253: pci_bus_change_irq_level:
> Assertion `irq_num >= 0' failed.
> That's with
> QEMU emulator version 5.2.0 (Debian 1:5.2+dfsg-9)
>
> I didn't see anything in https://bugs.launchpad.net/qemu/ about it,
> but figured I'd share in case that assertion failure looked familiar
> to anyone.

Nathan pointed out some previous reports; looks like others are
hitting this, too:
https://github.com/ClangBuiltLinux/linux/issues/1345#issuecomment-830451276


-- 
Thanks,
~Nick Desaulniers

Re: [PATCH 1/2] powerpc/64s: Fix crashes when toggling stf barrier

2021-05-04 Thread Nathan Lynch

Michael Ellerman  writes:
> -void do_stf_barrier_fixups(enum stf_barrier_type types)
> +static int __do_stf_barrier_fixups(void *data)
>  {
> + enum stf_barrier_type types = (enum stf_barrier_type)data;
> +
>   do_stf_entry_barrier_fixups(types);
>   do_stf_exit_barrier_fixups(types);
> +
> + return 0;
> +}
> +
> +void do_stf_barrier_fixups(enum stf_barrier_type types)
> +{
> + /*
> +  * The call to the fallback entry flush, and the fallback/sync-ori exit
> +  * flush can not be safely patched in/out while other CPUs are executing
> +  * them. So call __do_stf_barrier_fixups() on one CPU while all other 
> CPUs
> +  * spin in the stop machine core with interrupts hard disabled.
> +  */
> + stop_machine_cpuslocked(__do_stf_barrier_fixups, (void *)types, NULL);

Would it be preferable to avoid the explicit casts:

stop_machine_cpuslocked(__do_stf_barrier_fixups, , NULL);

...

static int __do_stf_barrier_fixups(void *data)
{
enum stf_barrier_type *types = data;

do_stf_entry_barrier_fixups(*types);
do_stf_exit_barrier_fixups(*types);

?

post_mobility_fixup() does cpus_read_unlock() before calling
pseries_setup_security_mitigations(), I think that will need to be
changed?

Re: [PATCH v4] pseries/drmem: update LMBs after LPM

2021-05-04 Thread Nathan Lynch

Hi Laurent,

Bear with me while I work through the commit message:

Laurent Dufour  writes:
> After a LPM, the device tree node ibm,dynamic-reconfiguration-memory may be
> updated by the hypervisor in the case the NUMA topology of the LPAR's
> memory is updated.

Yes, the RTAS functions ibm,update-nodes and ibm,update-properties,
which the OS invokes after resuming, may bring in updated properties
under the ibm,dynamic-reconfiguration-memory node, including the
ibm,associativity-lookup-arrays property.

> This is caught by the kernel,

"Caught" makes me think this is an error condition, as in catching an
exception. I guess "handled" better conveys your meaning?

> but the memory's node is updated because
> there is no way to move a memory block between nodes.

"The memory's node" refers the ibm,dynamic-reconfiguration-memory DT
node, yes? Or is it referring to Linux's NUMA nodes? ("move a memory
block between nodes" in your statement here refers to Linux's NUMA
nodes, that much is clear to me.)

I am failing to follow the cause->effect relationship stated. True,
changing a block's node assignment while it's in use isn't safe. I don't
see why that implies that "the memory's node is updated"? In fact this
seems contradictory.

This statement makes more sense to me if I change it to "the memory's
node is _not_ updated" -- is this what you intended?

> If later a memory block is added or removed, drmem_update_dt() is called
> and it is overwriting the DT node to match the added or removed LMB.

I understand this, but I will expand on it.

dlpar_memory()
  -> dlpar_memory_add_by_count()
-> dlpar_add_lmb()
  -> update_lmb_associativity_index()
... lmb->aa_index = 
  -> drmem_update_dt()

update_lmb_associativity_index() retrieves the firmware description of
the new block, and sets the aa_index of the matching entry in the
drmem_info array to the value matching the firmware description.

Then, drmem_update_dt() walks the drmem_info array and synthesizes a new
/ibm,dynamic-reconfiguration-memory/ibm,dynamic-memory-v2 property based
on the recently updated information in that array.

> But the LMB's associativity node has not been updated after the DT
> node update and thus the node is overwritten by the Linux's topology
> instead of the hypervisor one.

So, an example of the problem is:

1. VM migrates. On resume, ibm,associativity-lookup-arrays is changed
   via ibm,update-properties. Entries in the drmem_info array remain
   unchanged, with aa_index values that correspond to the source
   system's ibm,associativity-lookup-arrays property, now inaccessible.

2. A memory block is added. We look up the new block's entry in the
   drmem_info array, and set the aa_index to the value matching the
   current ibm,associativity-lookup-arrays.

3. Then, the ibm,associativity-lookup-arrays property is completely
   regenerated from the drmem_info array, which reflects a mixture of
   information from the source and destination systems.

Do I understand correctly?

> Introduce a hook called when the ibm,dynamic-reconfiguration-memory node is
> updated to force an update of the LMB's associativity. However, ignore the
> call to that hook when the update has been triggered by drmem_update_dt().
> Because, in that case, the LMB tree has been used to set the DT property
> and thus it doesn't need to be updated back. Since drmem_update_dt() is
> called under the protection of the device_hotplug_lock and the hook is
> called in the same context, use a simple boolean variable to detect that
> call.

This strikes me as almost a revert of e978a3ccaa71 ("powerpc/pseries:
remove obsolete memory hotplug DT notifier code").

I'd rather avoid smuggling through global state information that ought
to be passed in function parameters, if it should be passed around at
all. Despite having (IMO) relatively simple responsibilities, this code
is difficult to change and review; adding this property makes it
worse. If the structure of the code is pushing us toward this kind of
compromise, then the code probably needs more fundamental changes.

I'm probably forgetting something -- can anyone remind me why we need an
array of these:

struct drmem_lmb {
u64 base_addr;
u32 drc_index;
u32 aa_index;
u32 flags;
};

which is just a less efficient representation of what's already in the
device tree? If we got rid of it, would this problem disappear?

Re: [PATCH net v3] ibmvnic: Continue with reset if set link down failed

2021-05-04 Thread Dany Madden


On 2021-05-04 12:31, Lijun Pan wrote:

On Tue, May 4, 2021 at 2:27 PM Lijun Pan  wrote:


On Tue, May 4, 2021 at 2:14 PM Dany Madden  wrote:
>
> When ibmvnic gets a FATAL error message from the vnicserver, it marks
> the Command Respond Queue (CRQ) inactive and resets the adapter. If this
> FATAL reset fails and a transmission timeout reset follows, the CRQ is
> still inactive, ibmvnic's attempt to set link down will also fail. If
> ibmvnic abandons the reset because of this failed set link down and this
> is the last reset in the workqueue, then this adapter will be left in an
> inoperable state.
>
> Instead, make the driver ignore this link down failure and continue to
> free and re-register CRQ so that the adapter has an opportunity to
> recover.
>
> Fixes: ed651a10875f ("ibmvnic: Updated reset handling")
> Signed-off-by: Dany Madden 
> Reviewed-by: Rick Lindsley 
> Reviewed-by: Sukadev Bhattiprolu 
> ---
> Changes in V2:
> - Update description to clarify background for the patch
> - Include Reviewed-by tags
> Changes in V3:
> - Add comment above the code change
> ---
>  drivers/net/ethernet/ibm/ibmvnic.c | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/ibm/ibmvnic.c 
b/drivers/net/ethernet/ibm/ibmvnic.c
> index 5788bb956d73..9e005a08d43b 100644
> --- a/drivers/net/ethernet/ibm/ibmvnic.c
> +++ b/drivers/net/ethernet/ibm/ibmvnic.c
> @@ -2017,8 +2017,15 @@ static int do_reset(struct ibmvnic_adapter *adapter,
> rtnl_unlock();
> rc = set_link_state(adapter, IBMVNIC_LOGICAL_LNK_DN);
> rtnl_lock();
> -   if (rc)
> -   goto out;
> +
> +   /* Attempted to set the link down. It could fail if 
the
> +* vnicserver has already torn down the CRQ. We will
> +* note it and continue with reset to reinit the CRQ.
> +*/
> +   if (rc) {
> +   netdev_dbg(netdev,
> +  "Setting link down failed rc=%d. 
Continue anyway\n", rc);
> +   }

There are other places which check and rely on the return value of
this function. Your change makes that inconsistent. Can you stop


To be more specific, __ibmvnic_close, __ibmvnic_open both call this
set_link_state.
Inconsistent would have been not checking for the rc at all. Here we 
checked and noted it that there are times that it's ok to continue.





posting new versions and soliciting the maintainer to accept it before
there is material change? There are many ways to make reset
successful. I think this is the worst approach of all.


Can you show me a patch that is better than this one, that has gone thru 
a 30+ hours of testing?





>
> if (adapter->state == VNIC_OPEN) {
> /* When we dropped rtnl, ibmvnic_open() got
> --
> 2.18.2
>

Re: [PATCH v2 net-next resend] ibmvnic: remove default label from to_string switch

2021-05-04 Thread Lijun Pan

On Tue, May 4, 2021 at 2:19 PM Michal Suchanek  wrote:
>
> This way the compiler warns when a new value is added to the enum but
> not to the string translation like:
>
> drivers/net/ethernet/ibm/ibmvnic.c: In function 'adapter_state_to_string':
> drivers/net/ethernet/ibm/ibmvnic.c:832:2: warning: enumeration value 
> 'VNIC_FOOBAR' not handled in switch [-Wswitch]
>   switch (state) {
>   ^~
> drivers/net/ethernet/ibm/ibmvnic.c: In function 'reset_reason_to_string':
> drivers/net/ethernet/ibm/ibmvnic.c:1935:2: warning: enumeration value 
> 'VNIC_RESET_FOOBAR' not handled in switch [-Wswitch]
>   switch (reason) {
>   ^~
>
> Signed-off-by: Michal Suchanek 
> Acked-by: Lijun Pan 
> ---
> v2: Fix typo in commit message
> ---

Hi Michal,

Thank you for reposting the patch and including the Ack-by tag. I
think you need to wait till next Tuesday or so when net-next reopens,
then you can repost the patch.
http://vger.kernel.org/~davem/net-next.html.

Thanks,
Lijun

Re: [PATCH net v3] ibmvnic: Continue with reset if set link down failed

2021-05-04 Thread Lijun Pan

On Tue, May 4, 2021 at 2:27 PM Lijun Pan  wrote:
>
> On Tue, May 4, 2021 at 2:14 PM Dany Madden  wrote:
> >
> > When ibmvnic gets a FATAL error message from the vnicserver, it marks
> > the Command Respond Queue (CRQ) inactive and resets the adapter. If this
> > FATAL reset fails and a transmission timeout reset follows, the CRQ is
> > still inactive, ibmvnic's attempt to set link down will also fail. If
> > ibmvnic abandons the reset because of this failed set link down and this
> > is the last reset in the workqueue, then this adapter will be left in an
> > inoperable state.
> >
> > Instead, make the driver ignore this link down failure and continue to
> > free and re-register CRQ so that the adapter has an opportunity to
> > recover.
> >
> > Fixes: ed651a10875f ("ibmvnic: Updated reset handling")
> > Signed-off-by: Dany Madden 
> > Reviewed-by: Rick Lindsley 
> > Reviewed-by: Sukadev Bhattiprolu 
> > ---
> > Changes in V2:
> > - Update description to clarify background for the patch
> > - Include Reviewed-by tags
> > Changes in V3:
> > - Add comment above the code change
> > ---
> >  drivers/net/ethernet/ibm/ibmvnic.c | 11 +--
> >  1 file changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/ibm/ibmvnic.c 
> > b/drivers/net/ethernet/ibm/ibmvnic.c
> > index 5788bb956d73..9e005a08d43b 100644
> > --- a/drivers/net/ethernet/ibm/ibmvnic.c
> > +++ b/drivers/net/ethernet/ibm/ibmvnic.c
> > @@ -2017,8 +2017,15 @@ static int do_reset(struct ibmvnic_adapter *adapter,
> > rtnl_unlock();
> > rc = set_link_state(adapter, 
> > IBMVNIC_LOGICAL_LNK_DN);
> > rtnl_lock();
> > -   if (rc)
> > -   goto out;
> > +
> > +   /* Attempted to set the link down. It could fail if 
> > the
> > +* vnicserver has already torn down the CRQ. We will
> > +* note it and continue with reset to reinit the 
> > CRQ.
> > +*/
> > +   if (rc) {
> > +   netdev_dbg(netdev,
> > +  "Setting link down failed rc=%d. 
> > Continue anyway\n", rc);
> > +   }
>
> There are other places which check and rely on the return value of
> this function. Your change makes that inconsistent. Can you stop

To be more specific, __ibmvnic_close, __ibmvnic_open both call this
set_link_state.

> posting new versions and soliciting the maintainer to accept it before
> there is material change? There are many ways to make reset
> successful. I think this is the worst approach of all.
>
>
> >
> > if (adapter->state == VNIC_OPEN) {
> > /* When we dropped rtnl, ibmvnic_open() got
> > --
> > 2.18.2
> >

Re: [PATCH net v3] ibmvnic: Continue with reset if set link down failed

2021-05-04 Thread Lijun Pan

On Tue, May 4, 2021 at 2:14 PM Dany Madden  wrote:
>
> When ibmvnic gets a FATAL error message from the vnicserver, it marks
> the Command Respond Queue (CRQ) inactive and resets the adapter. If this
> FATAL reset fails and a transmission timeout reset follows, the CRQ is
> still inactive, ibmvnic's attempt to set link down will also fail. If
> ibmvnic abandons the reset because of this failed set link down and this
> is the last reset in the workqueue, then this adapter will be left in an
> inoperable state.
>
> Instead, make the driver ignore this link down failure and continue to
> free and re-register CRQ so that the adapter has an opportunity to
> recover.
>
> Fixes: ed651a10875f ("ibmvnic: Updated reset handling")
> Signed-off-by: Dany Madden 
> Reviewed-by: Rick Lindsley 
> Reviewed-by: Sukadev Bhattiprolu 
> ---
> Changes in V2:
> - Update description to clarify background for the patch
> - Include Reviewed-by tags
> Changes in V3:
> - Add comment above the code change
> ---
>  drivers/net/ethernet/ibm/ibmvnic.c | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/ibm/ibmvnic.c 
> b/drivers/net/ethernet/ibm/ibmvnic.c
> index 5788bb956d73..9e005a08d43b 100644
> --- a/drivers/net/ethernet/ibm/ibmvnic.c
> +++ b/drivers/net/ethernet/ibm/ibmvnic.c
> @@ -2017,8 +2017,15 @@ static int do_reset(struct ibmvnic_adapter *adapter,
> rtnl_unlock();
> rc = set_link_state(adapter, IBMVNIC_LOGICAL_LNK_DN);
> rtnl_lock();
> -   if (rc)
> -   goto out;
> +
> +   /* Attempted to set the link down. It could fail if 
> the
> +* vnicserver has already torn down the CRQ. We will
> +* note it and continue with reset to reinit the CRQ.
> +*/
> +   if (rc) {
> +   netdev_dbg(netdev,
> +  "Setting link down failed rc=%d. 
> Continue anyway\n", rc);
> +   }

There are other places which check and rely on the return value of
this function. Your change makes that inconsistent. Can you stop
posting new versions and soliciting the maintainer to accept it before
there is material change? There are many ways to make reset
successful. I think this is the worst approach of all.


>
> if (adapter->state == VNIC_OPEN) {
> /* When we dropped rtnl, ibmvnic_open() got
> --
> 2.18.2
>

[PATCH v2 net-next resend] ibmvnic: remove default label from to_string switch

2021-05-04 Thread Michal Suchanek

This way the compiler warns when a new value is added to the enum but
not to the string translation like:

drivers/net/ethernet/ibm/ibmvnic.c: In function 'adapter_state_to_string':
drivers/net/ethernet/ibm/ibmvnic.c:832:2: warning: enumeration value 
'VNIC_FOOBAR' not handled in switch [-Wswitch]
  switch (state) {
  ^~
drivers/net/ethernet/ibm/ibmvnic.c: In function 'reset_reason_to_string':
drivers/net/ethernet/ibm/ibmvnic.c:1935:2: warning: enumeration value 
'VNIC_RESET_FOOBAR' not handled in switch [-Wswitch]
  switch (reason) {
  ^~

Signed-off-by: Michal Suchanek 
Acked-by: Lijun Pan 
---
v2: Fix typo in commit message
---
 drivers/net/ethernet/ibm/ibmvnic.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/ibm/ibmvnic.c 
b/drivers/net/ethernet/ibm/ibmvnic.c
index 5788bb956d73..4d439413f6d9 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -846,9 +846,8 @@ static const char *adapter_state_to_string(enum vnic_state 
state)
return "REMOVING";
case VNIC_REMOVED:
return "REMOVED";
-   default:
-   return "UNKNOWN";
}
+   return "UNKNOWN";
 }
 
 static int ibmvnic_login(struct net_device *netdev)
@@ -1946,9 +1945,8 @@ static const char *reset_reason_to_string(enum 
ibmvnic_reset_reason reason)
return "TIMEOUT";
case VNIC_RESET_CHANGE_PARAM:
return "CHANGE_PARAM";
-   default:
-   return "UNKNOWN";
}
+   return "UNKNOWN";
 }
 
 /*
-- 
2.26.2

[PATCH net v3] ibmvnic: Continue with reset if set link down failed

2021-05-04 Thread Dany Madden

When ibmvnic gets a FATAL error message from the vnicserver, it marks
the Command Respond Queue (CRQ) inactive and resets the adapter. If this
FATAL reset fails and a transmission timeout reset follows, the CRQ is
still inactive, ibmvnic's attempt to set link down will also fail. If
ibmvnic abandons the reset because of this failed set link down and this
is the last reset in the workqueue, then this adapter will be left in an
inoperable state.

Instead, make the driver ignore this link down failure and continue to
free and re-register CRQ so that the adapter has an opportunity to
recover.

Fixes: ed651a10875f ("ibmvnic: Updated reset handling")
Signed-off-by: Dany Madden 
Reviewed-by: Rick Lindsley 
Reviewed-by: Sukadev Bhattiprolu 
---
Changes in V2:
- Update description to clarify background for the patch
- Include Reviewed-by tags
Changes in V3:
- Add comment above the code change
---
 drivers/net/ethernet/ibm/ibmvnic.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/ibm/ibmvnic.c 
b/drivers/net/ethernet/ibm/ibmvnic.c
index 5788bb956d73..9e005a08d43b 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -2017,8 +2017,15 @@ static int do_reset(struct ibmvnic_adapter *adapter,
rtnl_unlock();
rc = set_link_state(adapter, IBMVNIC_LOGICAL_LNK_DN);
rtnl_lock();
-   if (rc)
-   goto out;
+
+   /* Attempted to set the link down. It could fail if the
+* vnicserver has already torn down the CRQ. We will
+* note it and continue with reset to reinit the CRQ.
+*/
+   if (rc) {
+   netdev_dbg(netdev,
+  "Setting link down failed rc=%d. 
Continue anyway\n", rc);
+   }
 
if (adapter->state == VNIC_OPEN) {
/* When we dropped rtnl, ibmvnic_open() got
-- 
2.18.2

[RFC PATCH v5 15/16] watchdog: Expose lockup_detector_reconfigure()

When there are more than one implementation of the NMI watchdog, there may
be situations in which switching from one to another is needed. For
if the time-stamp counter becomes unstable, the HPET-based NMI watchdog
an no longer be used.

Switching to another hardlockup detector can be done cleanly by updating
the arch-specific stub and then reconfiguring the whole lockup detector.
Expose lockup_detector_reconfigure() to achieve this goal.

Cc: "H. Peter Anvin" 
Cc: Ashok Raj 
Cc: Andi Kleen 
Cc: Tony Luck 
Cc: Nicholas Piggin 
Cc: Peter Zijlstra 
Cc: Andrew Morton 
Cc: Stephane Eranian 
Cc: Suravee Suthikulpanit 
Cc: "Ravi V. Shankar" 
Cc: x...@kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Ricardo Neri 
---
Changes since v4:
 * Switching to the perf-based lockup detector under the hood is hacky.
   Instead, reconfigure the whole lockup detector.

Changes since v3:
 * None

Changes since v2:
 * Introduced this patch.

Changes since v1:
 * N/A
---
 include/linux/nmi.h | 2 ++
 kernel/watchdog.c   | 4 ++--
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/include/linux/nmi.h b/include/linux/nmi.h
index cf12380e51b3..73827a477288 100644
--- a/include/linux/nmi.h
+++ b/include/linux/nmi.h
@@ -16,6 +16,7 @@ void lockup_detector_init(void);
 void lockup_detector_soft_poweroff(void);
 void lockup_detector_cleanup(void);
 bool is_hardlockup(void);
+void lockup_detector_reconfigure(void);
 
 extern int watchdog_user_enabled;
 extern int nmi_watchdog_user_enabled;
@@ -37,6 +38,7 @@ extern int sysctl_hardlockup_all_cpu_backtrace;
 static inline void lockup_detector_init(void) { }
 static inline void lockup_detector_soft_poweroff(void) { }
 static inline void lockup_detector_cleanup(void) { }
+static inline void lockup_detector_reconfigure(void) { }
 #endif /* !CONFIG_LOCKUP_DETECTOR */
 
 #ifdef CONFIG_SOFTLOCKUP_DETECTOR
diff --git a/kernel/watchdog.c b/kernel/watchdog.c
index 4615064ee282..96f06938dc83 100644
--- a/kernel/watchdog.c
+++ b/kernel/watchdog.c
@@ -531,7 +531,7 @@ int lockup_detector_offline_cpu(unsigned int cpu)
return 0;
 }
 
-static void lockup_detector_reconfigure(void)
+void lockup_detector_reconfigure(void)
 {
cpus_read_lock();
watchdog_nmi_stop();
@@ -577,7 +577,7 @@ static __init void lockup_detector_setup(void)
 }
 
 #else /* CONFIG_SOFTLOCKUP_DETECTOR */
-static void lockup_detector_reconfigure(void)
+void lockup_detector_reconfigure(void)
 {
cpus_read_lock();
watchdog_nmi_stop();
-- 
2.17.1

[RFC PATCH v5 12/16] watchdog/hardlockup: Use parse_option_str() to handle "nmi_watchdog"

Prepare hardlockup_panic_setup() to handle a comma-separated list of
options. Thus, it can continue parsing its own command-line options while
ignoring paremeters that are relevant only to specific implementations of
the hardlockup detector. Such implementations may use an early_param to
parse their own options.

Cc: "H. Peter Anvin" 
Cc: Ashok Raj 
Cc: Andi Kleen 
Cc: Tony Luck 
Cc: Nicholas Piggin 
Cc: Peter Zijlstra 
Cc: Andrew Morton 
Cc: Stephane Eranian 
Cc: Suravee Suthikulpanit 
Cc: "Ravi V. Shankar" 
Cc: x...@kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Ricardo Neri 
---
Changes since v4:
 * None

Changes since v3:
 * None

Changes since v2:
 * Introduced this patch.

Changes since v1:
 * None
---
 kernel/watchdog.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/kernel/watchdog.c b/kernel/watchdog.c
index 107bc38b1945..4615064ee282 100644
--- a/kernel/watchdog.c
+++ b/kernel/watchdog.c
@@ -73,13 +73,13 @@ void __init hardlockup_detector_disable(void)
 
 static int __init hardlockup_panic_setup(char *str)
 {
-   if (!strncmp(str, "panic", 5))
+   if (parse_option_str(str, "panic"))
hardlockup_panic = 1;
-   else if (!strncmp(str, "nopanic", 7))
+   else if (parse_option_str(str, "nopanic"))
hardlockup_panic = 0;
-   else if (!strncmp(str, "0", 1))
+   else if (parse_option_str(str, "0"))
nmi_watchdog_user_enabled = 0;
-   else if (!strncmp(str, "1", 1))
+   else if (parse_option_str(str, "1"))
nmi_watchdog_user_enabled = 1;
return 1;
 }
-- 
2.17.1

[RFC PATCH v5 05/16] watchdog/hardlockup: Decouple the hardlockup detector from perf

The current default implementation of the hardlockup detector assumes that
it is implemented using perf events. However, the hardlockup detector can
be driven by other sources of non-maskable interrupts (e.g., a properly
configured timer).

Group and wrap in #ifdef CONFIG_HARDLOCKUP_DETECTOR_PERF all the code
specific to perf: create and manage perf events, stop and start the perf-
based detector.

The generic portion of the detector (monitor the timers' thresholds, check
timestamps and detect hardlockups as well as the implementation of
arch_touch_nmi_watchdog()) is now selected with the new intermediate config
symbol CONFIG_HARDLOCKUP_DETECTOR_CORE.

The perf-based implementation of the detector selects the new intermediate
symbol. Other implementations should do the same.

Cc: "H. Peter Anvin" 
Cc: Ashok Raj 
Cc: Andi Kleen 
Cc: Tony Luck 
Cc: Nicholas Piggin 
Cc: Peter Zijlstra 
Cc: Andrew Morton 
Cc: Stephane Eranian 
Cc: Suravee Suthikulpanit 
Cc: "Ravi V. Shankar" 
Cc: x...@kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Ricardo Neri 
---
Changes since v4:
 * None

Changes since v3:
 * Squashed into this patch a previous patch to make
   arch_touch_nmi_watchdog() part of the core detector code.

Changes since v2:
 * Undid split of the generic hardlockup detector into a separate file.
   (Thomas Gleixner)
 * Added a new intermediate symbol CONFIG_HARDLOCKUP_DETECTOR_CORE to
   select generic parts of the detector (Paul E. McKenney,
   Thomas Gleixner).

Changes since v1:
 * Make the generic detector code with CONFIG_HARDLOCKUP_DETECTOR.
---
 include/linux/nmi.h   |  5 -
 kernel/Makefile   |  2 +-
 kernel/watchdog_hld.c | 32 
 lib/Kconfig.debug |  4 
 4 files changed, 29 insertions(+), 14 deletions(-)

diff --git a/include/linux/nmi.h b/include/linux/nmi.h
index 1b68f48ad440..cf12380e51b3 100644
--- a/include/linux/nmi.h
+++ b/include/linux/nmi.h
@@ -94,8 +94,11 @@ static inline void hardlockup_detector_disable(void) {}
 # define NMI_WATCHDOG_SYSCTL_PERM  0444
 #endif
 
-#if defined(CONFIG_HARDLOCKUP_DETECTOR_PERF)
+#if defined(CONFIG_HARDLOCKUP_DETECTOR_CORE)
 extern void arch_touch_nmi_watchdog(void);
+#endif
+
+#if defined(CONFIG_HARDLOCKUP_DETECTOR_PERF)
 extern void hardlockup_detector_perf_stop(void);
 extern void hardlockup_detector_perf_restart(void);
 extern void hardlockup_detector_perf_disable(void);
diff --git a/kernel/Makefile b/kernel/Makefile
index e8a6715f38dc..03ac041abfff 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -95,7 +95,7 @@ obj-$(CONFIG_FAIL_FUNCTION) += fail_function.o
 obj-$(CONFIG_KGDB) += debug/
 obj-$(CONFIG_DETECT_HUNG_TASK) += hung_task.o
 obj-$(CONFIG_LOCKUP_DETECTOR) += watchdog.o
-obj-$(CONFIG_HARDLOCKUP_DETECTOR_PERF) += watchdog_hld.o
+obj-$(CONFIG_HARDLOCKUP_DETECTOR_CORE) += watchdog_hld.o
 obj-$(CONFIG_SECCOMP) += seccomp.o
 obj-$(CONFIG_RELAY) += relay.o
 obj-$(CONFIG_SYSCTL) += utsname_sysctl.o
diff --git a/kernel/watchdog_hld.c b/kernel/watchdog_hld.c
index b352e507b17f..bb6435978c46 100644
--- a/kernel/watchdog_hld.c
+++ b/kernel/watchdog_hld.c
@@ -22,12 +22,8 @@
 
 static DEFINE_PER_CPU(bool, hard_watchdog_warn);
 static DEFINE_PER_CPU(bool, watchdog_nmi_touch);
-static DEFINE_PER_CPU(struct perf_event *, watchdog_ev);
-static DEFINE_PER_CPU(struct perf_event *, dead_event);
-static struct cpumask dead_events_mask;
 
 static unsigned long hardlockup_allcpu_dumped;
-static atomic_t watchdog_cpus = ATOMIC_INIT(0);
 
 notrace void arch_touch_nmi_watchdog(void)
 {
@@ -98,14 +94,6 @@ static inline bool watchdog_check_timestamp(void)
 }
 #endif
 
-static struct perf_event_attr wd_hw_attr = {
-   .type   = PERF_TYPE_HARDWARE,
-   .config = PERF_COUNT_HW_CPU_CYCLES,
-   .size   = sizeof(struct perf_event_attr),
-   .pinned = 1,
-   .disabled   = 1,
-};
-
 void inspect_for_hardlockups(struct pt_regs *regs)
 {
if (__this_cpu_read(watchdog_nmi_touch) == true) {
@@ -157,6 +145,24 @@ void inspect_for_hardlockups(struct pt_regs *regs)
return;
 }
 
+#ifdef CONFIG_HARDLOCKUP_DETECTOR_PERF
+#undef pr_fmt
+#define pr_fmt(fmt) "NMI perf watchdog: " fmt
+
+static DEFINE_PER_CPU(struct perf_event *, watchdog_ev);
+static DEFINE_PER_CPU(struct perf_event *, dead_event);
+static struct cpumask dead_events_mask;
+
+static atomic_t watchdog_cpus = ATOMIC_INIT(0);
+
+static struct perf_event_attr wd_hw_attr = {
+   .type   = PERF_TYPE_HARDWARE,
+   .config = PERF_COUNT_HW_CPU_CYCLES,
+   .size   = sizeof(struct perf_event_attr),
+   .pinned = 1,
+   .disabled   = 1,
+};
+
 /* Callback function for perf event subsystem */
 static void watchdog_overflow_callback(struct perf_event *event,
   struct perf_sample_data *data,
@@ -298,3 +304,5 @@ int __init hardlockup_detector_perf_init(void)
}
return ret;
 }
+
+#endif /*

[RFC PATCH v5 04/16] watchdog/hardlockup: Define a generic function to detect hardlockups

The procedure to detect hardlockups is independent of the underlying
mechanism that generates the non-maskable interrupt used to drive the
detector. Thus, it can be put in a separate, generic function. In this
manner, it can be invoked by various implementations of the NMI watchdog.

For this purpose, move the bulk of watchdog_overflow_callback() to the
new function inspect_for_hardlockups(). This function can then be called
from the applicable NMI handlers.

Cc: "H. Peter Anvin" 
Cc: Ashok Raj 
Cc: Andi Kleen 
Cc: Tony Luck 
Cc: Nicholas Piggin 
Cc: Peter Zijlstra 
Cc: Andrew Morton 
Cc: Stephane Eranian 
Cc: Suravee Suthikulpanit 
Cc: "Ravi V. Shankar" 
Cc: x...@kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Ricardo Neri 
---
Changes since v4:
 * None

Changes since v3:
 * None

Changes since v2:
 * None

Changes since v1:
 * None
---
 include/linux/nmi.h   |  1 +
 kernel/watchdog_hld.c | 18 +++---
 2 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/include/linux/nmi.h b/include/linux/nmi.h
index 750c7f395ca9..1b68f48ad440 100644
--- a/include/linux/nmi.h
+++ b/include/linux/nmi.h
@@ -207,6 +207,7 @@ int proc_nmi_watchdog(struct ctl_table *, int , void *, 
size_t *, loff_t *);
 int proc_soft_watchdog(struct ctl_table *, int , void *, size_t *, loff_t *);
 int proc_watchdog_thresh(struct ctl_table *, int , void *, size_t *, loff_t *);
 int proc_watchdog_cpumask(struct ctl_table *, int, void *, size_t *, loff_t *);
+void inspect_for_hardlockups(struct pt_regs *regs);
 
 #ifdef CONFIG_HAVE_ACPI_APEI_NMI
 #include 
diff --git a/kernel/watchdog_hld.c b/kernel/watchdog_hld.c
index 247bf0b1582c..b352e507b17f 100644
--- a/kernel/watchdog_hld.c
+++ b/kernel/watchdog_hld.c
@@ -106,14 +106,8 @@ static struct perf_event_attr wd_hw_attr = {
.disabled   = 1,
 };
 
-/* Callback function for perf event subsystem */
-static void watchdog_overflow_callback(struct perf_event *event,
-  struct perf_sample_data *data,
-  struct pt_regs *regs)
+void inspect_for_hardlockups(struct pt_regs *regs)
 {
-   /* Ensure the watchdog never gets throttled */
-   event->hw.interrupts = 0;
-
if (__this_cpu_read(watchdog_nmi_touch) == true) {
__this_cpu_write(watchdog_nmi_touch, false);
return;
@@ -163,6 +157,16 @@ static void watchdog_overflow_callback(struct perf_event 
*event,
return;
 }
 
+/* Callback function for perf event subsystem */
+static void watchdog_overflow_callback(struct perf_event *event,
+  struct perf_sample_data *data,
+  struct pt_regs *regs)
+{
+   /* Ensure the watchdog never gets throttled */
+   event->hw.interrupts = 0;
+   inspect_for_hardlockups(regs);
+}
+
 static int hardlockup_detector_event_create(void)
 {
unsigned int cpu = smp_processor_id();
-- 
2.17.1

Re: [PATCH V2 net] ibmvnic: Continue with reset if set link down failed

2021-05-04 Thread Dany Madden


On 2021-04-22 19:26, Rick Lindsley wrote:

On 4/22/21 10:21 AM, Michal Suchánek wrote:

Merging do_reset and do_hard_reset might be a good code cleanup which 
is

out of the scope of this fix.


I agree, on both points. Accepting the patch, and improving the reset
path are not in conflict with each other.

My position is that improving the reset path is certainly on the table,
but not with this bug or this fix.  Within the context of this 
discovered
problem, the issue is well understood, the fix is small and addresses 
the

immediate problem, and it has not generated new bugs under subsequent
testing.  For those reasons, the submitted patch has my support.

Rick


Thanks for all the feedback on the patch. Refactoring the ibmvnic reset 
functions is something we plan to evaluate, as this would potentially 
simplify the reset code. In the mean time, the proposed patch is simple, 
and has been validated in our test environment to solve an issue 
resulting in vnic interfaces getting stuck in an offline state following 
a vnic timeout reset. Given that, I suggest we merge this patch while we 
look at further optimizations in future. I will submit a V3 patch 
shortly.


Dany

Re: [powerpc:next-test 8/8] arch/powerpc/lib/feature-fixups.c:304:30: error: cast to smaller integer type 'enum l1d_flush_type' from 'void *'





Le 04/05/2021 à 20:31, kernel test robot a écrit :

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
next-test
head:   a5014a5c936a2a9a223e699e1f3abd54d5f68d2c
commit: a5014a5c936a2a9a223e699e1f3abd54d5f68d2c [8/8] powerpc/64s: Fix crashes 
when toggling entry flush barrier
config: powerpc-randconfig-r022-20210503 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 
8f5a2a5836cc8e4c1def2bdeb022e7b496623439)
reproduce (this is a W=1 build):
 wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
 chmod +x ~/bin/make.cross
 # install powerpc cross compiling tool for clang build
 # apt-get install binutils-powerpc-linux-gnu
 # 
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?id=a5014a5c936a2a9a223e699e1f3abd54d5f68d2c
 git remote add powerpc 
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
 git fetch --no-tags powerpc next-test
 git checkout a5014a5c936a2a9a223e699e1f3abd54d5f68d2c
 # save the attached .config to linux build tree
 COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
ARCH=powerpc

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

arch/powerpc/lib/feature-fixups.c:233:32: error: cast to smaller integer 
type 'enum stf_barrier_type' from 'void *' [-Werror,-Wvoid-pointer-to-enum-cast]
enum stf_barrier_type types = (enum stf_barrier_type)data;
  ^~~

arch/powerpc/lib/feature-fixups.c:304:30: error: cast to smaller integer type 
'enum l1d_flush_type' from 'void *' [-Werror,-Wvoid-pointer-to-enum-cast]

enum l1d_flush_type types = (enum l1d_flush_type)data;
^
2 errors generated.


vim +304 arch/powerpc/lib/feature-fixups.c

301 
302 static int __do_entry_flush_fixups(void *data)
303 {
  > 304  enum l1d_flush_type types = (enum l1d_flush_type)data;


That looks strange to use an enumeration for 'types', as we perform logical ops with it below (eg: 
types & L1D_FLUSH_ORI).


I think it should be an int.


305 unsigned int instrs[3], *dest;
306 long *start, *end;
307 int i;
308 
309 instrs[0] = 0x6000; /* nop */
310 instrs[1] = 0x6000; /* nop */
311 instrs[2] = 0x6000; /* nop */
312 
313 i = 0;
314 if (types == L1D_FLUSH_FALLBACK) {
315 instrs[i++] = 0x7d4802a6; /* mflr r10   */
316 instrs[i++] = 0x6000; /* branch patched below */
317 instrs[i++] = 0x7d4803a6; /* mtlr r10   */
318 }
319 
320 if (types & L1D_FLUSH_ORI) {
321 instrs[i++] = 0x63ff; /* ori 31,31,0 speculation 
barrier */
322 instrs[i++] = 0x63de; /* ori 30,30,0 L1d flush*/
323 }
324 
325 if (types & L1D_FLUSH_MTTRIG)
326 instrs[i++] = 0x7c12dba6; /* mtspr TRIG2,r0 (SPR #882) 
*/
327 
328 start = PTRRELOC(&__start___entry_flush_fixup);
329 end = PTRRELOC(&__stop___entry_flush_fixup);
330 for (i = 0; start < end; start++, i++) {
331 dest = (void *)start + *start;
332 
333 pr_devel("patching dest %lx\n", (unsigned long)dest);
334 
335 patch_instruction((struct ppc_inst *)dest, 
ppc_inst(instrs[0]));
336 
337 if (types == L1D_FLUSH_FALLBACK)
338 patch_branch((struct ppc_inst *)(dest + 1), 
(unsigned long)_flush_fallback,
339  BRANCH_SET_LINK);
340 else
341 patch_instruction((struct ppc_inst *)(dest + 
1), ppc_inst(instrs[1]));
342 
343 patch_instruction((struct ppc_inst *)(dest + 2), 
ppc_inst(instrs[2]));
344 }
345 
346 start = PTRRELOC(&__start___scv_entry_flush_fixup);
347 end = PTRRELOC(&__stop___scv_entry_flush_fixup);
348 for (; start < end; start++, i++) {
349 dest = (void *)start + *start;
350 
351 pr_devel("patching dest %lx\n", (unsigned long)dest);
352 
353 patch_instruction((struct ppc_inst *)dest, 
ppc_inst(instrs[0]));
354 
355 if (types == L1D_FLUSH_FALLBACK)
356 patch_branch((struct ppc_inst *)(dest + 1), 
(unsigned long)_entry_flush_fallback,
357  BRANCH_SET_LINK);
358 else
359

Re: [PATCH v3 1/2] KVM: PPC: Book3S HV: Sanitise vcpu registers in nested path

2021-05-04 Thread Fabiano Rosas

Nicholas Piggin  writes:

> An error message when you try to start the nested guest telling you
> pass -machine cap-htm=off would be better... I guess that should
> really all work with caps etc today though so TM's a bad example.
> But assume we don't have a cap for the bit we disable? Maybe we
> should have caps for all HFSCR bits, or I'm just worried about
> something not very important.

I'm avoiding returning an error from H_ENTER_NESTED at first run
specifically because of this. I think it interferes with L1 migration.

Say we have an L1 that has an workload that involves nested guests. It
can boot and run them just fine (i.e. it uses the same HFSCR value for
its guests as L0). If we migrate that L1 into a host that uses different
HFSCR bits and therefore will always fail the H_ENTER_NESTED, that is
effectively the same as migrating into a host that does not provide
KVM_CAP_PPC_NESTED_HV.

We would need some way to inform the migration code that the remote host
will not allow L1 to run nested guests with that particular HFSCR value
so that it can decide whether that host is a suitable migration
target. Otherwise we're migrating the guest into a host that will not
allow its operation to continue.

Returning an error later on during the nested guest lifetime I think it
is less harmful, but nothing really went wrong with the hypercall. It
did its job and ran L2 like L1 asked, although it ignored some bits. Can
we say that L1 misconfigured L2 when there is no way for L1 to negotiate
which bits it can use? The same set of bits could be considered valid by
another L0. It seems that as long as we hardcode some bits we shouldn't
fail the hcall because of them.

I think since this is all a bit theoretical right now, forwarding a
program interrupt into L1 is a good less permanent solution for the
moment, it does not alter the hcall's API and if we start stumbling into
similar issues in the future we'll have more information then to come up
with a proper solution.

>
> Thanks,
> Nick

[powerpc:next-test 8/8] arch/powerpc/lib/feature-fixups.c:304:30: error: cast to smaller integer type 'enum l1d_flush_type' from 'void *'

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
next-test
head:   a5014a5c936a2a9a223e699e1f3abd54d5f68d2c
commit: a5014a5c936a2a9a223e699e1f3abd54d5f68d2c [8/8] powerpc/64s: Fix crashes 
when toggling entry flush barrier
config: powerpc-randconfig-r022-20210503 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 
8f5a2a5836cc8e4c1def2bdeb022e7b496623439)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install powerpc cross compiling tool for clang build
# apt-get install binutils-powerpc-linux-gnu
# 
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?id=a5014a5c936a2a9a223e699e1f3abd54d5f68d2c
git remote add powerpc 
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
git fetch --no-tags powerpc next-test
git checkout a5014a5c936a2a9a223e699e1f3abd54d5f68d2c
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
ARCH=powerpc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

   arch/powerpc/lib/feature-fixups.c:233:32: error: cast to smaller integer 
type 'enum stf_barrier_type' from 'void *' [-Werror,-Wvoid-pointer-to-enum-cast]
   enum stf_barrier_type types = (enum stf_barrier_type)data;
 ^~~
>> arch/powerpc/lib/feature-fixups.c:304:30: error: cast to smaller integer 
>> type 'enum l1d_flush_type' from 'void *' 
>> [-Werror,-Wvoid-pointer-to-enum-cast]
   enum l1d_flush_type types = (enum l1d_flush_type)data;
   ^
   2 errors generated.


vim +304 arch/powerpc/lib/feature-fixups.c

   301  
   302  static int __do_entry_flush_fixups(void *data)
   303  {
 > 304  enum l1d_flush_type types = (enum l1d_flush_type)data;
   305  unsigned int instrs[3], *dest;
   306  long *start, *end;
   307  int i;
   308  
   309  instrs[0] = 0x6000; /* nop */
   310  instrs[1] = 0x6000; /* nop */
   311  instrs[2] = 0x6000; /* nop */
   312  
   313  i = 0;
   314  if (types == L1D_FLUSH_FALLBACK) {
   315  instrs[i++] = 0x7d4802a6; /* mflr r10   */
   316  instrs[i++] = 0x6000; /* branch patched below */
   317  instrs[i++] = 0x7d4803a6; /* mtlr r10   */
   318  }
   319  
   320  if (types & L1D_FLUSH_ORI) {
   321  instrs[i++] = 0x63ff; /* ori 31,31,0 speculation 
barrier */
   322  instrs[i++] = 0x63de; /* ori 30,30,0 L1d flush*/
   323  }
   324  
   325  if (types & L1D_FLUSH_MTTRIG)
   326  instrs[i++] = 0x7c12dba6; /* mtspr TRIG2,r0 (SPR #882) 
*/
   327  
   328  start = PTRRELOC(&__start___entry_flush_fixup);
   329  end = PTRRELOC(&__stop___entry_flush_fixup);
   330  for (i = 0; start < end; start++, i++) {
   331  dest = (void *)start + *start;
   332  
   333  pr_devel("patching dest %lx\n", (unsigned long)dest);
   334  
   335  patch_instruction((struct ppc_inst *)dest, 
ppc_inst(instrs[0]));
   336  
   337  if (types == L1D_FLUSH_FALLBACK)
   338  patch_branch((struct ppc_inst *)(dest + 1), 
(unsigned long)_flush_fallback,
   339   BRANCH_SET_LINK);
   340  else
   341  patch_instruction((struct ppc_inst *)(dest + 
1), ppc_inst(instrs[1]));
   342  
   343  patch_instruction((struct ppc_inst *)(dest + 2), 
ppc_inst(instrs[2]));
   344  }
   345  
   346  start = PTRRELOC(&__start___scv_entry_flush_fixup);
   347  end = PTRRELOC(&__stop___scv_entry_flush_fixup);
   348  for (; start < end; start++, i++) {
   349  dest = (void *)start + *start;
   350  
   351  pr_devel("patching dest %lx\n", (unsigned long)dest);
   352  
   353  patch_instruction((struct ppc_inst *)dest, 
ppc_inst(instrs[0]));
   354  
   355  if (types == L1D_FLUSH_FALLBACK)
   356  patch_branch((struct ppc_inst *)(dest + 1), 
(unsigned long)_entry_flush_fallback,
   357   BRANCH_SET_LINK);
   358  else
   359  patch_instruction((struct ppc_inst *)(dest + 
1), ppc_inst(instrs[1]));
   360  
   361  patch_instruction((struct ppc_inst *)(dest + 2), 
ppc_inst(instrs[2]));
   362  }
   363  
   364  
   365

Re: [PATCH v2] powerpc/64: BE option to use ELFv2 ABI for big endian kernels

2021-05-04 Thread Michal Suchánek

On Tue, May 04, 2021 at 11:11:25PM +0530, Naveen N. Rao wrote:
> Nicholas Piggin wrote:
> > Excerpts from Michal Suchánek's message of May 4, 2021 6:17 am:
> > > On Mon, May 03, 2021 at 11:34:25AM +0200, Michal Suchánek wrote:
> > > > On Mon, May 03, 2021 at 09:11:16AM +0200, Michal Suchánek wrote:
> > > > > On Mon, May 03, 2021 at 10:58:33AM +1000, Nicholas Piggin wrote:
> > > > > > Excerpts from Michal Suchánek's message of May 3, 2021 2:57 am:
> > > > > > > On Tue, Apr 28, 2020 at 09:25:17PM +1000, Nicholas Piggin wrote:
> > > > > > >> Provide an option to use ELFv2 ABI for big endian builds. This 
> > > > > > >> works on
> > > > > > >> GCC and clang (since 2014). It is less well tested and supported 
> > > > > > >> by the
> > > > > > >> GNU toolchain, but it can give some useful advantages of the 
> > > > > > >> ELFv2 ABI
> > > > > > >> for BE (e.g., less stack usage). Some distros even build BE ELFv2
> > > > > > >> userspace.
> > > > > > > > > > Fixes BTFID failure on BE for me and the ELF ABIv2
> > > > kernel boots.
> > > > > > > > What's the BTFID failure? Anything we can do to fix it
> > > > on the v1 ABI or > > at least make it depend on BUILD_ELF_V2?
> > > > > > Looks like symbols are prefixed with a dot in ABIv1 and
> > > > BTFID tool is
> > > > > not aware of that. It can be disabled on ABIv1 easily.
> 
> Yes, I think BTF is generated by pahole, so we will need to add support for
> recognising dot symbols there.

There are symbols both with and without dot, and the dwarves
development is headed towards using the ones without dot. Not sure it's
the correct way to resolve it, though.
https://lore.kernel.org/lkml/8c3cbd22-eb26-ea8b-c8bb-35a629d6d...@kernel.org/

> 
> > > > > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> > > > > index 678c13967580..e703c26e9b80 100644
> > > > > --- a/lib/Kconfig.debug
> > > > > +++ b/lib/Kconfig.debug
> > > > > @@ -305,6 +305,7 @@ config DEBUG_INFO_BTF
> > > > >   bool "Generate BTF typeinfo"
> > > > >   depends on !DEBUG_INFO_SPLIT && !DEBUG_INFO_REDUCED
> > > > >   depends on !GCC_PLUGIN_RANDSTRUCT || COMPILE_TEST
> > > > > + depends on !PPC64 || BUILD_ELF_V2
> > > > >   help
> > > > > Generate deduplicated BTF type information from DWARF debug 
> > > > > info.
> > > > > Turning this on expects presence of pahole tool, which will 
> > > > > convert
> > > > > > > > > > > > > Tested-by: Michal Suchánek 
> > > > > > > > > > Also can we enable mprofile on BE now?
> > > > > > > > > > I don't see anything endian-specific in the mprofile
> > > > code at a glance
> > > > > > > but don't have any idea how to test it.
> > > > > > > > AFAIK it's just a different ABI for the _mcount call so
> > > > just running
> > > > > > some ftrace and ftrace with call graph should test it reasonably 
> > > > > > well.
> > > > 
> > > > It does not crash and burn but there are some regressions from LE to BE
> > > > on the ftrace kernel selftest:
> > > > 
> > > > @@ -16,10 +16,10 @@
> > > >  [n] event tracing - enable/disable with event level files  [PASS]
> > > >  [n] event tracing - restricts events based on pid notrace filtering
> > > > [PASS]
> > > >  [n] event tracing - restricts events based on pid  [PASS]
> > > > -[n] event tracing - enable/disable with subsystem level files  [PASS]
> > > > +[n] event tracing - enable/disable with subsystem level files  [FAIL]
> > > >  [n] event tracing - enable/disable with top level files[PASS]
> > > > -[n] Test trace_printk from module  [UNRESOLVED]
> > > > +[n] Test trace_printk from module  [FAIL]
> > > > -[n] ftrace - function graph filters with stack tracer  [PASS]
> > > > +[n] ftrace - function graph filters with stack tracer  [FAIL]
> > > >  [n] ftrace - function graph filters[PASS]
> > > >  [n] ftrace - function trace with cpumask   [PASS]
> > > >  [n] ftrace - test for function event triggers  [PASS]
> > > > @@ -96,7 +96,8 @@
> > > >  [n] (instance)  event tracing - enable/disable with event level files  
> > > > [PASS]
> > > >  [n] (instance)  event tracing - restricts events based on pid notrace 
> > > > filtering[PASS]
> > > >  [n] (instance)  event tracing - restricts events based on pid  [PASS]
> > > > -[n] (instance)  event tracing - enable/disable with subsystem level 
> > > > files  [PASS]
> > > > +[n] (instance)  event tracing - enable/disable with subsystem level 
> > > > files  [FAIL]
> > > > +rmdir: failed to remove 
> > > > '/sys/kernel/tracing/instances/ftracetest.mceByV': Device or resource 
> > > > busy
> > > >  [n] (instance)  ftrace - test for function event triggers  [PASS]
> > > >  [n] (instance)  ftrace - function pid notrace filters  [PASS]
> > > >  [n] (instance)  ftrace - function pid filters  [PASS]
> > > > 
> > > > I needed to add a test timeout to get this far because
> > > > "event tracing - enable/disable with subsystem level files" gets stuck.
> 
> Does that test pass on LE for you? In the past, I have seen

Re: [PATCH v2] powerpc/64: BE option to use ELFv2 ABI for big endian kernels

2021-05-04 Thread Naveen N. Rao


Nicholas Piggin wrote:

Excerpts from Michal Suchánek's message of May 4, 2021 6:17 am:

On Mon, May 03, 2021 at 11:34:25AM +0200, Michal Suchánek wrote:

On Mon, May 03, 2021 at 09:11:16AM +0200, Michal Suchánek wrote:
> On Mon, May 03, 2021 at 10:58:33AM +1000, Nicholas Piggin wrote:
> > Excerpts from Michal Suchánek's message of May 3, 2021 2:57 am:
> > > On Tue, Apr 28, 2020 at 09:25:17PM +1000, Nicholas Piggin wrote:
> > >> Provide an option to use ELFv2 ABI for big endian builds. This works on
> > >> GCC and clang (since 2014). It is less well tested and supported by the
> > >> GNU toolchain, but it can give some useful advantages of the ELFv2 ABI
> > >> for BE (e.g., less stack usage). Some distros even build BE ELFv2
> > >> userspace.
> > > 
> > > Fixes BTFID failure on BE for me and the ELF ABIv2 kernel boots.
> > 
> > What's the BTFID failure? Anything we can do to fix it on the v1 ABI or 
> > at least make it depend on BUILD_ELF_V2?
> 
> Looks like symbols are prefixed with a dot in ABIv1 and BTFID tool is

> not aware of that. It can be disabled on ABIv1 easily.


Yes, I think BTF is generated by pahole, so we will need to add support 
for recognising dot symbols there.


> 
> Thanks
> 
> Michal
> 
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug

> index 678c13967580..e703c26e9b80 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -305,6 +305,7 @@ config DEBUG_INFO_BTF
>bool "Generate BTF typeinfo"
>depends on !DEBUG_INFO_SPLIT && !DEBUG_INFO_REDUCED
>depends on !GCC_PLUGIN_RANDSTRUCT || COMPILE_TEST
> +  depends on !PPC64 || BUILD_ELF_V2
>help
>  Generate deduplicated BTF type information from DWARF debug info.
>  Turning this on expects presence of pahole tool, which will convert
> 
> > 
> > > 
> > > Tested-by: Michal Suchánek 
> > > 
> > > Also can we enable mprofile on BE now?
> > > 
> > > I don't see anything endian-specific in the mprofile code at a glance

> > > but don't have any idea how to test it.
> > 
> > AFAIK it's just a different ABI for the _mcount call so just running

> > some ftrace and ftrace with call graph should test it reasonably well.

It does not crash and burn but there are some regressions from LE to BE
on the ftrace kernel selftest:

--- ftraceLE.txt2021-05-03 11:19:14.83000 +0200
+++ ftraceBE.txt2021-05-03 11:27:24.77000 +0200
@@ -7,8 +7,8 @@
 [n] Change the ringbuffer size [PASS]
 [n] Snapshot and tracing setting   [PASS]
 [n] trace_pipe and trace_marker[PASS]
-[n] Test ftrace direct functions against tracers   [UNRESOLVED]
-[n] Test ftrace direct functions against kprobes   [UNRESOLVED]
+[n] Test ftrace direct functions against tracers   [FAIL]
+[n] Test ftrace direct functions against kprobes   [FAIL]


Strange to see those fail. I don't think my patch to enable ftrace 
direct functions is upstream yet ;)



 [n] Generic dynamic event - add/remove kprobe events   [PASS]
 [n] Generic dynamic event - add/remove synthetic events[PASS]
 [n] Generic dynamic event - selective clear (compatibility)[PASS]
@@ -16,10 +16,10 @@
 [n] event tracing - enable/disable with event level files  [PASS]
 [n] event tracing - restricts events based on pid notrace filtering[PASS]
 [n] event tracing - restricts events based on pid  [PASS]
-[n] event tracing - enable/disable with subsystem level files  [PASS]
+[n] event tracing - enable/disable with subsystem level files  [FAIL]
 [n] event tracing - enable/disable with top level files[PASS]
-[n] Test trace_printk from module  [UNRESOLVED]
-[n] ftrace - function graph filters with stack tracer  [PASS]
+[n] Test trace_printk from module  [FAIL]
+[n] ftrace - function graph filters with stack tracer  [FAIL]
 [n] ftrace - function graph filters[PASS]
 [n] ftrace - function trace with cpumask   [PASS]
 [n] ftrace - test for function event triggers  [PASS]
@@ -27,7 +27,7 @@
 [n] ftrace - function pid notrace filters  [PASS]
 [n] ftrace - function pid filters  [PASS]
 [n] ftrace - stacktrace filter command [PASS]
-[n] ftrace - function trace on module  [UNRESOLVED]
+[n] ftrace - function trace on module  [FAIL]
 [n] ftrace - function profiler with function tracing   [PASS]
 [n] ftrace - function profiling[PASS]
 [n] ftrace - test reading of set_ftrace_filter [PASS]
@@ -44,10 +44,10 @@
 [n] Kprobe event argument syntax   [PASS]
 [n] Kprobe dynamic event with arguments[PASS]
 [n] Kprobes event arguments with types [PASS]
-[n] Kprobe event user-memory access[UNSUPPORTED]
+[n] Kprobe event user-memory access[FAIL]
 [n] Kprobe event auto/manual naming[PASS]
 [n] Kprobe dynamic event with function tracer  [PASS]
-[n] Kprobe dynamic event - probing module  [UNRESOLVED]
+[n] Kprobe dynamic event - probing module  [FAIL]
 [n] Create/delete multiprobe on kprobe event   [PASS]
 [n] Kprobe event parser error log check[PASS]
 [n] Kretprobe dynamic event with

[powerpc:next-test 7/8] arch/powerpc/lib/feature-fixups.c:233:32: error: cast to smaller integer type 'enum stf_barrier_type' from 'void *'

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
next-test
head:   a5014a5c936a2a9a223e699e1f3abd54d5f68d2c
commit: 682ebb015052696ac93cf8df28142d83be8dbcc3 [7/8] powerpc/64s: Fix crashes 
when toggling stf barrier
config: powerpc-randconfig-r022-20210503 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 
8f5a2a5836cc8e4c1def2bdeb022e7b496623439)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install powerpc cross compiling tool for clang build
# apt-get install binutils-powerpc-linux-gnu
# 
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?id=682ebb015052696ac93cf8df28142d83be8dbcc3
git remote add powerpc 
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
git fetch --no-tags powerpc next-test
git checkout 682ebb015052696ac93cf8df28142d83be8dbcc3
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
ARCH=powerpc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

>> arch/powerpc/lib/feature-fixups.c:233:32: error: cast to smaller integer 
>> type 'enum stf_barrier_type' from 'void *' 
>> [-Werror,-Wvoid-pointer-to-enum-cast]
   enum stf_barrier_type types = (enum stf_barrier_type)data;
 ^~~
   1 error generated.


vim +233 arch/powerpc/lib/feature-fixups.c

   230  
   231  static int __do_stf_barrier_fixups(void *data)
   232  {
 > 233  enum stf_barrier_type types = (enum stf_barrier_type)data;
   234  
   235  do_stf_entry_barrier_fixups(types);
   236  do_stf_exit_barrier_fixups(types);
   237  
   238  return 0;
   239  }
   240  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip

Re: remove the nvlink2 pci_vfio subdriver v2

2021-05-04 Thread Daniel Vetter

On Tue, May 04, 2021 at 12:53:27PM -0300, Jason Gunthorpe wrote:
> On Tue, May 04, 2021 at 04:23:40PM +0200, Daniel Vetter wrote:
> 
> > Just my 2cents from drm (where we deprecate old gunk uapi quite often):
> > Imo it's best to keep the uapi headers as-is, but exchange the
> > documentation with a big "this is removed, never use again" warning:
> 
> We in RDMA have been doing the opposite, the uapi headers are supposed
> to reflect the current kernel. This helps make the kernel
> understandable.
> 
> When userspace needs backwards compat to ABI that the current kernel
> doesn't support then userspace has distinct copies of that information
> in some compat location. It has happened a few times over the last 15
> years.
> 
> We keep full copies of the current kernel headers in the userspace
> source tree, when the kernel headers change in a compile incompatible
> way we fix everything while updating to the new kernel headers.

Yeah we do the same since forever (it's either from libdrm package, or
directly in the corresponding userspace header). So largely include/uapi
is for documentation

> > - it's good to know which uapi numbers (like parameter extensions or
> >   whatever they are in this case) are defacto reserved, because there are
> >   binaries (qemu in this) that have code acting on them out there.
> 
> Numbers and things get marked reserved or the like
> 
> > Anyway feel free to ignore since this might be different than drivers/gpu.
> 
> AFAIK drives/gpu has a lot wider userspace, rdma manages this OK
> because we only have one library package that provides the user/kernel
> interface.

But since we have some many projects we've started asking all the userspace
projects to directly take the kernel ones (after the make step to filter
them) so that there's only one source of truth. And also to make sure they
don't merge stuff before the kernel side is reviewed Which also
means we can't ditch anything userspace might still need on older trees
and stuff.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH 4/4] powerpc/pseries: warn if recursing into the hcall tracing code

2021-05-04 Thread Naveen N. Rao


Nicholas Piggin wrote:

Excerpts from Naveen N. Rao's message of May 4, 2021 8:25 pm:

Nicholas Piggin wrote:

Excerpts from Naveen N. Rao's message of April 27, 2021 11:59 pm:

Nicholas Piggin wrote:

+ *
+ * H_CONFER from spin locks must be treated separately though and use _notrace
+ * plpar_hcall variants, see yield_to_preempted().
  */
 static DEFINE_PER_CPU(unsigned int, hcall_trace_depth);

@@ -1843,7 +1846,7 @@ notrace void __trace_hcall_entry(unsigned long opcode, 
unsigned long *args)

depth = this_cpu_ptr(_trace_depth);

-   if (*depth)
+   if (WARN_ON_ONCE(*depth))
goto out;


I don't think this will be helpful. The hcall trace depth tracking is 
for the tracepoint and I suspect that this warning will be triggered 
quite easily. Since we have recursion protection, I don't think we 
should warn here.


What would trigger recursion?


The trace code that this protects: trace_hcall_entry(). The tracing code 
itself can end up doing a hcall as we see in the first patch in this 
series:

  plpar_hcall_norets_trace+0x34/0x8c (unreliable)
  __pv_queued_spin_lock_slowpath+0x684/0x710
  trace_clock_global+0x148/0x150
  ring_buffer_lock_reserve+0x12c/0x630
  trace_event_buffer_lock_reserve+0x80/0x220
  trace_event_buffer_reserve+0x7c/0xd0
  trace_event_raw_event_hcall_entry+0x68/0x150
  __trace_hcall_entry+0x160/0x180


There is also a comment aroung hcall_trace_depth that mentions this:

  /*
   * Since the tracing code might execute hcalls we need to guard against
   * recursion. One example of this are spinlocks calling H_YIELD on
   * shared processor partitions.
   */


Right but since fixing those, my thought is we better not cause more
any recursion, so we should fix anything that does.


Ah ok, I got confused by the reference to recursion, since the current 
fix did not involve hcall trace recursion per se.


Yes, with the current patch set, we have ensured that at least the 
qspinlock code doesn't invoke tracing if it has to do H_CONFER hcall. I 
am not entirely sure if that's the only hcall that could be invoked by 
the tracing code.


The reason I felt that this warning isn't useful is because it can be 
triggered by the perf NMI -- if the perf NMI happens while we are 
tracing a different hcall.



Thanks,
Naveen

Re: [PATCH] vfio/pci: Revert nvlink removal uAPI breakage

On Tue, 04 May 2021 09:52:02 -0600
Alex Williamson  wrote:

> Revert the uAPI changes from the below commit with notice that these
> regions and capabilities are no longer provided.
> 
> Fixes: b392a1989170 ("vfio/pci: remove vfio_pci_nvlink2")
> Reported-by: Greg Kurz 
> Signed-off-by: Alex Williamson 
> ---
> 
> Greg (Kurz), please double check this resolves the issue.  Thanks!
> 

It does. Feel free to add:

Reviewed-by: Greg Kurz 

and

Tested-by: Greg Kurz 

Thanks for the quick fix.

Cheers,

--
Greg

>  include/uapi/linux/vfio.h |   46 
> +
>  1 file changed, 42 insertions(+), 4 deletions(-)
> 
> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> index 34b1f53a3901..ef33ea002b0b 100644
> --- a/include/uapi/linux/vfio.h
> +++ b/include/uapi/linux/vfio.h
> @@ -333,10 +333,21 @@ struct vfio_region_info_cap_type {
>  #define VFIO_REGION_SUBTYPE_INTEL_IGD_LPC_CFG(3)
>  
>  /* 10de vendor PCI sub-types */
> -/* subtype 1 was VFIO_REGION_SUBTYPE_NVIDIA_NVLINK2_RAM, don't use */
> +/*
> + * NVIDIA GPU NVlink2 RAM is coherent RAM mapped onto the host address space.
> + *
> + * Deprecated, region no longer provided
> + */
> +#define VFIO_REGION_SUBTYPE_NVIDIA_NVLINK2_RAM   (1)
>  
>  /* 1014 vendor PCI sub-types */
> -/* subtype 1 was VFIO_REGION_SUBTYPE_IBM_NVLINK2_ATSD, don't use */
> +/*
> + * IBM NPU NVlink2 ATSD (Address Translation Shootdown) register of NPU
> + * to do TLB invalidation on a GPU.
> + *
> + * Deprecated, region no longer provided
> + */
> +#define VFIO_REGION_SUBTYPE_IBM_NVLINK2_ATSD (1)
>  
>  /* sub-types for VFIO_REGION_TYPE_GFX */
>  #define VFIO_REGION_SUBTYPE_GFX_EDID(1)
> @@ -630,9 +641,36 @@ struct vfio_device_migration_info {
>   */
>  #define VFIO_REGION_INFO_CAP_MSIX_MAPPABLE   3
>  
> -/* subtype 4 was VFIO_REGION_INFO_CAP_NVLINK2_SSATGT, don't use */
> +/*
> + * Capability with compressed real address (aka SSA - small system address)
> + * where GPU RAM is mapped on a system bus. Used by a GPU for DMA routing
> + * and by the userspace to associate a NVLink bridge with a GPU.
> + *
> + * Deprecated, capability no longer provided
> + */
> +#define VFIO_REGION_INFO_CAP_NVLINK2_SSATGT  4
> +
> +struct vfio_region_info_cap_nvlink2_ssatgt {
> + struct vfio_info_cap_header header;
> + __u64 tgt;
> +};
>  
> -/* subtype 5 was VFIO_REGION_INFO_CAP_NVLINK2_LNKSPD, don't use */
> +/*
> + * Capability with an NVLink link speed. The value is read by
> + * the NVlink2 bridge driver from the bridge's "ibm,nvlink-speed"
> + * property in the device tree. The value is fixed in the hardware
> + * and failing to provide the correct value results in the link
> + * not working with no indication from the driver why.
> + *
> + * Deprecated, capability no longer provided
> + */
> +#define VFIO_REGION_INFO_CAP_NVLINK2_LNKSPD  5
> +
> +struct vfio_region_info_cap_nvlink2_lnkspd {
> + struct vfio_info_cap_header header;
> + __u32 link_speed;
> + __u32 __pad;
> +};
>  
>  /**
>   * VFIO_DEVICE_GET_IRQ_INFO - _IOWR(VFIO_TYPE, VFIO_BASE + 9,
> 
>

Re: [PATCH] vfio/pci: Revert nvlink removal uAPI breakage

2021-05-04 Thread Cornelia Huck

On Tue, 04 May 2021 09:52:02 -0600
Alex Williamson  wrote:

> Revert the uAPI changes from the below commit with notice that these
> regions and capabilities are no longer provided.
> 
> Fixes: b392a1989170 ("vfio/pci: remove vfio_pci_nvlink2")
> Reported-by: Greg Kurz 
> Signed-off-by: Alex Williamson 
> ---
> 
> Greg (Kurz), please double check this resolves the issue.  Thanks!
> 
>  include/uapi/linux/vfio.h |   46 
> +
>  1 file changed, 42 insertions(+), 4 deletions(-)

I had already hacked up a QEMU patch that moved the definitions into
local headers, but this one is less of a hassle. (Code compiles fine
after doing a headers update.)

Reviewed-by: Cornelia Huck

Re: remove the nvlink2 pci_vfio subdriver v2

2021-05-04 Thread Jason Gunthorpe

On Tue, May 04, 2021 at 04:23:40PM +0200, Daniel Vetter wrote:

> Just my 2cents from drm (where we deprecate old gunk uapi quite often):
> Imo it's best to keep the uapi headers as-is, but exchange the
> documentation with a big "this is removed, never use again" warning:

We in RDMA have been doing the opposite, the uapi headers are supposed
to reflect the current kernel. This helps make the kernel
understandable.

When userspace needs backwards compat to ABI that the current kernel
doesn't support then userspace has distinct copies of that information
in some compat location. It has happened a few times over the last 15
years.

We keep full copies of the current kernel headers in the userspace
source tree, when the kernel headers change in a compile incompatible
way we fix everything while updating to the new kernel headers.

> - it's good to know which uapi numbers (like parameter extensions or
>   whatever they are in this case) are defacto reserved, because there are
>   binaries (qemu in this) that have code acting on them out there.

Numbers and things get marked reserved or the like

> Anyway feel free to ignore since this might be different than drivers/gpu.

AFAIK drives/gpu has a lot wider userspace, rdma manages this OK
because we only have one library package that provides the user/kernel
interface.

Jason

[PATCH] vfio/pci: Revert nvlink removal uAPI breakage

2021-05-04 Thread Alex Williamson

Revert the uAPI changes from the below commit with notice that these
regions and capabilities are no longer provided.

Fixes: b392a1989170 ("vfio/pci: remove vfio_pci_nvlink2")
Reported-by: Greg Kurz 
Signed-off-by: Alex Williamson 
---

Greg (Kurz), please double check this resolves the issue.  Thanks!

 include/uapi/linux/vfio.h |   46 +
 1 file changed, 42 insertions(+), 4 deletions(-)

diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index 34b1f53a3901..ef33ea002b0b 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -333,10 +333,21 @@ struct vfio_region_info_cap_type {
 #define VFIO_REGION_SUBTYPE_INTEL_IGD_LPC_CFG  (3)
 
 /* 10de vendor PCI sub-types */
-/* subtype 1 was VFIO_REGION_SUBTYPE_NVIDIA_NVLINK2_RAM, don't use */
+/*
+ * NVIDIA GPU NVlink2 RAM is coherent RAM mapped onto the host address space.
+ *
+ * Deprecated, region no longer provided
+ */
+#define VFIO_REGION_SUBTYPE_NVIDIA_NVLINK2_RAM (1)
 
 /* 1014 vendor PCI sub-types */
-/* subtype 1 was VFIO_REGION_SUBTYPE_IBM_NVLINK2_ATSD, don't use */
+/*
+ * IBM NPU NVlink2 ATSD (Address Translation Shootdown) register of NPU
+ * to do TLB invalidation on a GPU.
+ *
+ * Deprecated, region no longer provided
+ */
+#define VFIO_REGION_SUBTYPE_IBM_NVLINK2_ATSD   (1)
 
 /* sub-types for VFIO_REGION_TYPE_GFX */
 #define VFIO_REGION_SUBTYPE_GFX_EDID(1)
@@ -630,9 +641,36 @@ struct vfio_device_migration_info {
  */
 #define VFIO_REGION_INFO_CAP_MSIX_MAPPABLE 3
 
-/* subtype 4 was VFIO_REGION_INFO_CAP_NVLINK2_SSATGT, don't use */
+/*
+ * Capability with compressed real address (aka SSA - small system address)
+ * where GPU RAM is mapped on a system bus. Used by a GPU for DMA routing
+ * and by the userspace to associate a NVLink bridge with a GPU.
+ *
+ * Deprecated, capability no longer provided
+ */
+#define VFIO_REGION_INFO_CAP_NVLINK2_SSATGT4
+
+struct vfio_region_info_cap_nvlink2_ssatgt {
+   struct vfio_info_cap_header header;
+   __u64 tgt;
+};
 
-/* subtype 5 was VFIO_REGION_INFO_CAP_NVLINK2_LNKSPD, don't use */
+/*
+ * Capability with an NVLink link speed. The value is read by
+ * the NVlink2 bridge driver from the bridge's "ibm,nvlink-speed"
+ * property in the device tree. The value is fixed in the hardware
+ * and failing to provide the correct value results in the link
+ * not working with no indication from the driver why.
+ *
+ * Deprecated, capability no longer provided
+ */
+#define VFIO_REGION_INFO_CAP_NVLINK2_LNKSPD5
+
+struct vfio_region_info_cap_nvlink2_lnkspd {
+   struct vfio_info_cap_header header;
+   __u32 link_speed;
+   __u32 __pad;
+};
 
 /**
  * VFIO_DEVICE_GET_IRQ_INFO - _IOWR(VFIO_TYPE, VFIO_BASE + 9,

Re: remove the nvlink2 pci_vfio subdriver v2

2021-05-04 Thread Alex Williamson

On Tue, 4 May 2021 16:11:31 +0200
Greg Kurz  wrote:

> On Tue, 4 May 2021 15:30:15 +0200
> Greg Kroah-Hartman  wrote:
> 
> > On Tue, May 04, 2021 at 03:20:34PM +0200, Greg Kurz wrote:  
> > > On Tue, 4 May 2021 14:59:07 +0200
> > > Greg Kroah-Hartman  wrote:
> > >   
> > > > On Tue, May 04, 2021 at 02:22:36PM +0200, Greg Kurz wrote:  
> > > > > On Fri, 26 Mar 2021 07:13:09 +0100
> > > > > Christoph Hellwig  wrote:
> > > > >   
> > > > > > Hi all,
> > > > > > 
> > > > > > the nvlink2 vfio subdriver is a weird beast.  It supports a hardware
> > > > > > feature without any open source component - what would normally be
> > > > > > the normal open source userspace that we require for kernel drivers,
> > > > > > although in this particular case user space could of course be a
> > > > > > kernel driver in a VM.  It also happens to be a complete mess that
> > > > > > does not properly bind to PCI IDs, is hacked into the vfio_pci 
> > > > > > driver
> > > > > > and also pulles in over 1000 lines of code always build into powerpc
> > > > > > kernels that have Power NV support enabled.  Because of all these
> > > > > > issues and the lack of breaking userspace when it is removed I think
> > > > > > the best idea is to simply kill.
> > > > > > 
> > > > > > Changes since v1:
> > > > > >  - document the removed subtypes as reserved
> > > > > >  - add the ACK from Greg
> > > > > > 
> > > > > > Diffstat:
> > > > > >  arch/powerpc/platforms/powernv/npu-dma.c |  705 
> > > > > > ---
> > > > > >  b/arch/powerpc/include/asm/opal.h|3 
> > > > > >  b/arch/powerpc/include/asm/pci-bridge.h  |1 
> > > > > >  b/arch/powerpc/include/asm/pci.h |7 
> > > > > >  b/arch/powerpc/platforms/powernv/Makefile|2 
> > > > > >  b/arch/powerpc/platforms/powernv/opal-call.c |2 
> > > > > >  b/arch/powerpc/platforms/powernv/pci-ioda.c  |  185 ---
> > > > > >  b/arch/powerpc/platforms/powernv/pci.c   |   11 
> > > > > >  b/arch/powerpc/platforms/powernv/pci.h   |   17 
> > > > > >  b/arch/powerpc/platforms/pseries/pci.c   |   23 
> > > > > >  b/drivers/vfio/pci/Kconfig   |6 
> > > > > >  b/drivers/vfio/pci/Makefile  |1 
> > > > > >  b/drivers/vfio/pci/vfio_pci.c|   18 
> > > > > >  b/drivers/vfio/pci/vfio_pci_private.h|   14 
> > > > > >  b/include/uapi/linux/vfio.h  |   38 -  
> > > > > 
> > > > > 
> > > > > Hi Christoph,
> > > > > 
> > > > > FYI, these uapi changes break build of QEMU.  
> > > > 
> > > > What uapi changes?
> > > >   
> > > 
> > > All macros and structure definitions that are being removed
> > > from include/uapi/linux/vfio.h by patch 1.
> > >   
> > > > What exactly breaks?
> > > >   
> > > 
> > > These macros and types are used by the current QEMU code base.
> > > Next time the QEMU source tree updates its copy of the kernel
> > > headers, the compilation of affected code will fail.  
> > 
> > So does QEMU use this api that is being removed, or does it just have
> > some odd build artifacts of the uapi things?
> >   
> 
> These are region subtypes definition and associated capabilities.
> QEMU basically gets information on VFIO regions from the kernel
> driver and for those regions with a nvlink2 subtype, it tries
> to extract some more nvlink2 related info.


Urgh, let's put the uapi header back in place with a deprecation
notice.  Userspace should never have a dependency on the existence of a
given region, but clearly will have code to parse the data structure
describing that region.  I'll post a patch.  Thanks,

Alex

Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1

Le 04/05/2021 à 16:59, Christian Zigotzky a écrit :

Am 04.05.21 um 16:41 schrieb Christophe Leroy:

Le 04/05/2021 à 13:02, Christian Zigotzky a écrit :

Am 04.05.21 um 12:07 schrieb Christian Zigotzky:

Am 04.05.21 um 11:49 schrieb Christophe Leroy:

Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :

Am 04.05.21 um 11:11 schrieb Christophe Leroy:

Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :

Am 04.05.21 um 10:58 schrieb Christophe Leroy:

Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :

On 04 May 2021 at 09:47am, Christophe Leroy wrote:

Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :

Hi Christophe,

Thanks for your answer but I think I don't know how it works with the
cherry-pick.

$ git bisect start

As you suspect the problem to be specific to powerpc, I can do

git bisect start -- arch/powerpc

$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

You said that powerpc-5.13-1 is bad so you can narrow the search I think:

git bisect bad powerpc-5.13-1
git bisect good 887f3ceb51cd3~

I tried it but without any success.

git bisect bad powerpc-5.13-1

Output:
fatal: Needed a single revision
Bad rev input: powerpc-5.13-1

I don't understand, on my side it works. Maybe a difference between your version of git and
mine.

In that case, just use the SHA corresponding to the merge:

git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

Christophe

Do you use a BookE machine?

No I don't unfortunately, and I have tried booting in QEMU a kernel built with your config,
but it freezes before any output.

You can use my kernels and distributions.

Ok, I'll see if I can do something with them.

In the meantime, have you been able to bisect ?

Thanks
Christophe

I am bisecting currently.

$ git bisect start -- arch/powerpc
$ git bisect good 887f3ceb51cd3~
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
OK, there is another issue after the second bisecting step. The boot stops after loading the dtb
and uImage file. I can't solve 2 issues with bisecting at the same time.

In that case, you can use 'git bisect skip' to skip the one that is not booting
at all.
In my point of view 'git bisect skip' isn't a good idea because I will not find out if the skipped
commit is good or bad and maybe the first bad commit.

The second problem may be completely unrelated to the first one so it could
work.

In any case, if 'git bisect' finds out that the bad commit is in the middle of a skipped area, it
will tell you. So I think it is worth it.

The second solution could be to first focus on that 'boot stops after loading problem' and try to
find out which commit introduces the bug, then which one fixes it. But it may not be necessary.

Other solution, as you were thinking that the conversion of 'booke' to C interrupt entry/exit, you
can also try around that: See if d738ee8 has the problem and 2e2a441 doesn't have the problem.

If so, you can bisect between those two commits (There are 8 commits inbetween).

Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1


Am 04.05.21 um 16:41 schrieb Christophe Leroy:



Le 04/05/2021 à 13:02, Christian Zigotzky a écrit :

Am 04.05.21 um 12:07 schrieb Christian Zigotzky:

Am 04.05.21 um 11:49 schrieb Christophe Leroy:



Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :

Am 04.05.21 um 11:11 schrieb Christophe Leroy:



Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :

Am 04.05.21 um 10:58 schrieb Christophe Leroy:



Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :

On 04 May 2021 at 09:47am, Christophe Leroy wrote:

Hi

Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :

Hi Christophe,

Thanks for your answer but I think I don't know how it works 
with the cherry-pick.


$ git bisect start


As you suspect the problem to be specific to powerpc, I can do

git bisect start -- arch/powerpc



$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c


You said that powerpc-5.13-1 is bad so you can narrow the 
search I think:


git bisect bad powerpc-5.13-1
git bisect good 887f3ceb51cd3~

I tried it but without any success.

git bisect bad powerpc-5.13-1

Output:
fatal: Needed a single revision
Bad rev input: powerpc-5.13-1


I don't understand, on my side it works. Maybe a difference 
between your version of git and mine.


In that case, just use the SHA corresponding to the merge:

git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

Christophe

Do you use a BookE machine?


No I don't unfortunately, and I have tried booting in QEMU a 
kernel built with your config, but it freezes before any output.

You can use my kernels and distributions.



Ok, I'll see if I can do something with them.

In the meantime, have you been able to bisect ?

Thanks
Christophe

I am bisecting currently.

$ git bisect start -- arch/powerpc
$ git bisect good 887f3ceb51cd3~
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
OK, there is another issue after the second bisecting step. The boot 
stops after loading the dtb and uImage file. I can't solve 2 issues 
with bisecting at the same time.


In that case, you can use 'git bisect skip' to skip the one that is 
not booting at all.
In my point of view 'git bisect skip' isn't a good idea because I will 
not find out if the skipped commit is good or bad and maybe the first 
bad commit.

Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1


Am 04.05.21 um 16:48 schrieb Christophe Leroy:



Le 04/05/2021 à 15:48, Christian Zigotzky a écrit :

Am 04.05.21 um 13:02 schrieb Christian Zigotzky:

Am 04.05.21 um 12:07 schrieb Christian Zigotzky:

Am 04.05.21 um 11:49 schrieb Christophe Leroy:



Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :

Am 04.05.21 um 11:11 schrieb Christophe Leroy:



Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :

Am 04.05.21 um 10:58 schrieb Christophe Leroy:



Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :

On 04 May 2021 at 09:47am, Christophe Leroy wrote:

Hi

Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :

Hi Christophe,

Thanks for your answer but I think I don't know how it 
works with the cherry-pick.


$ git bisect start


As you suspect the problem to be specific to powerpc, I can do

git bisect start -- arch/powerpc



$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c


You said that powerpc-5.13-1 is bad so you can narrow the 
search I think:


git bisect bad powerpc-5.13-1
git bisect good 887f3ceb51cd3~

I tried it but without any success.

git bisect bad powerpc-5.13-1

Output:
fatal: Needed a single revision
Bad rev input: powerpc-5.13-1


I don't understand, on my side it works. Maybe a difference 
between your version of git and mine.


In that case, just use the SHA corresponding to the merge:

git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

Christophe

Do you use a BookE machine?


No I don't unfortunately, and I have tried booting in QEMU a 
kernel built with your config, but it freezes before any output.

You can use my kernels and distributions.



Ok, I'll see if I can do something with them.

In the meantime, have you been able to bisect ?

Thanks
Christophe

I am bisecting currently.

$ git bisect start -- arch/powerpc
$ git bisect good 887f3ceb51cd3~
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
OK, there is another issue after the second bisecting step. The boot 
stops after loading the dtb and uImage file. I can't solve 2 issues 
with bisecting at the same time.

Xorg restarts again and again.

Here are some interesting error messages:

May 04 15:24:53 dc1.a-eon.tld kernel: lxsession[7255]: segfault (11) 
at 80 nip ff6a770 lr ff6a760 code 1 in 
libglib-2.0.so.0.4800.2[feaf000+11f000]
May 04 15:24:53 dc1.a-eon.tld kernel: lxsession[7255]: code: 4bfc9401 
3920 91210054 8061005c 2f83 419c0014 3880 4bfc93e5
May 04 15:24:53 dc1.a-eon.tld kernel: lxsession[7255]: code: 3920 
9121005c 2f8f 419e0008 <93ef> 418e000c 81210040 913b


May 04 15:37:40 mintppc.a-eon.tld kernel: packagekitd[4290]: segfault 
(11) at 8 nip 92dbc8 lr 92dae8 code 1 in packagekitd[92+51000]
May 04 15:37:40 mintppc.a-eon.tld kernel: packagekitd[4290]: code: 
38800080 3be001f4 4cc63182 4802c8ad 4b64 6000 81210018 80be8048
May 04 15:37:40 mintppc.a-eon.tld kernel: packagekitd[4290]: code: 
7fa6eb78 38800010 807e801c 3be0 <80e90008> 4cc63182 4802c881 
4b38


Yes it shows you get a segfault for some reason.
So yes, 887f3ceb51cd3 could have been the reason but 525642624783 
fixes it already.


Therefore I think a proper bisect is needed to identify the culprit 
commit to understand the reason and fix it.


You are running a 32 bits userspace on a 64 bits kernel ?

I use 32-bit and 64-bit userlands with 64-bit kernels. Both userlands 
are affected by the Xorg issue.

Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1





Le 04/05/2021 à 15:48, Christian Zigotzky a écrit :

Am 04.05.21 um 13:02 schrieb Christian Zigotzky:

Am 04.05.21 um 12:07 schrieb Christian Zigotzky:

Am 04.05.21 um 11:49 schrieb Christophe Leroy:



Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :

Am 04.05.21 um 11:11 schrieb Christophe Leroy:



Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :

Am 04.05.21 um 10:58 schrieb Christophe Leroy:



Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :

On 04 May 2021 at 09:47am, Christophe Leroy wrote:

Hi

Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :

Hi Christophe,

Thanks for your answer but I think I don't know how it works with the 
cherry-pick.

$ git bisect start


As you suspect the problem to be specific to powerpc, I can do

git bisect start -- arch/powerpc



$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c


You said that powerpc-5.13-1 is bad so you can narrow the search I think:

git bisect bad powerpc-5.13-1
git bisect good 887f3ceb51cd3~

I tried it but without any success.

git bisect bad powerpc-5.13-1

Output:
fatal: Needed a single revision
Bad rev input: powerpc-5.13-1


I don't understand, on my side it works. Maybe a difference between your version of git and 
mine.


In that case, just use the SHA corresponding to the merge:

git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

Christophe

Do you use a BookE machine?


No I don't unfortunately, and I have tried booting in QEMU a kernel built with your config, 
but it freezes before any output.

You can use my kernels and distributions.



Ok, I'll see if I can do something with them.

In the meantime, have you been able to bisect ?

Thanks
Christophe

I am bisecting currently.

$ git bisect start -- arch/powerpc
$ git bisect good 887f3ceb51cd3~
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
OK, there is another issue after the second bisecting step. The boot stops after loading the dtb 
and uImage file. I can't solve 2 issues with bisecting at the same time.

Xorg restarts again and again.

Here are some interesting error messages:

May 04 15:24:53 dc1.a-eon.tld kernel: lxsession[7255]: segfault (11) at 80 nip ff6a770 lr 
ff6a760 code 1 in libglib-2.0.so.0.4800.2[feaf000+11f000]
May 04 15:24:53 dc1.a-eon.tld kernel: lxsession[7255]: code: 4bfc9401 3920 91210054 8061005c 
2f83 419c0014 3880 4bfc93e5
May 04 15:24:53 dc1.a-eon.tld kernel: lxsession[7255]: code: 3920 9121005c 2f8f 419e0008 
<93ef> 418e000c 81210040 913b


May 04 15:37:40 mintppc.a-eon.tld kernel: packagekitd[4290]: segfault (11) at 8 nip 92dbc8 lr 92dae8 
code 1 in packagekitd[92+51000]
May 04 15:37:40 mintppc.a-eon.tld kernel: packagekitd[4290]: code: 38800080 3be001f4 4cc63182 
4802c8ad 4b64 6000 81210018 80be8048
May 04 15:37:40 mintppc.a-eon.tld kernel: packagekitd[4290]: code: 7fa6eb78 38800010 807e801c 
3be0 <80e90008> 4cc63182 4802c881 4b38


Yes it shows you get a segfault for some reason.
So yes, 887f3ceb51cd3 could have been the reason but 525642624783 fixes it 
already.

Therefore I think a proper bisect is needed to identify the culprit commit to understand the reason 
and fix it.


You are running a 32 bits userspace on a 64 bits kernel ?

Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1





Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :

Am 04.05.21 um 11:11 schrieb Christophe Leroy:



Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :

Am 04.05.21 um 10:58 schrieb Christophe Leroy:



Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :

On 04 May 2021 at 09:47am, Christophe Leroy wrote:

Hi

Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :

Hi Christophe,

Thanks for your answer but I think I don't know how it works with the 
cherry-pick.

$ git bisect start


As you suspect the problem to be specific to powerpc, I can do

git bisect start -- arch/powerpc



$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c


You said that powerpc-5.13-1 is bad so you can narrow the search I think:

git bisect bad powerpc-5.13-1
git bisect good 887f3ceb51cd3~

I tried it but without any success.

git bisect bad powerpc-5.13-1

Output:
fatal: Needed a single revision
Bad rev input: powerpc-5.13-1


I don't understand, on my side it works. Maybe a difference between your 
version of git and mine.

In that case, just use the SHA corresponding to the merge:

git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

Christophe

Do you use a BookE machine?


No I don't unfortunately, and I have tried booting in QEMU a kernel built with your config, but it 
freezes before any output.

You can use my kernels and distributions.

Download Fedora 28 PPC64: http://www.xenosoft.de/fedora28-2.img.tar.gz
Download size: 4.1 GB
MD5 checksum: 1784ca69651531522161498720a89414

Default username and password:
Username: amigaone
Password: amigaone
Root Password: amigaone

You can start the MATE desktop with "startx".

Download MintPPC (Debian Sid) PPC32: 
http://www.xenosoft.de/MintPPC32-X5000.tar.gz
MD5 checksum: b31c1c1ca1fcf5d4cdf110c4bce11654

The password for both 'root' and 'mintppc' is 'mintppc'.

Download kernel 5.12.0 for the AmigaOne X5000 and for the virtual e5500 QEMU machine without the bad 
commit: http://www.xenosoft.de/linux-image-5.12-X1000_X5000.tar.gz
Download git kernel for the AmigaOne X5000 and for the virtual e5500 QEMU machine with the bad 
commit: http://www.xenosoft.de/linux-image-5.13-alpha3-X1000_X5000.tar.gz


QEMU command with KVM on the X5000: qemu-system-ppc64 -M ppce500 -cpu e5500 -enable-kvm -m 1024 
-kernel uImage -drive format=raw,file=MintPPC32-X5000.img,index=0,if=virtio -netdev user,id=mynet0 
-device e1000,netdev=mynet0 -append "rw root=/dev/vda" -device virtio-vga -device virtio-mouse-pci 
-device virtio-keyboard-pci -device pci-ohci,id=newusb -device usb-audio,bus=newusb.0 -smp 4


QEMU command for Fedora 28 without KVM and with VNC connect: qemu-system-ppc64 -M ppce500 -cpu e5500 
-m 1024 -kernel uImage -drive format=raw,file=fedora28-2.img,index=0,if=virtio -netdev 
user,id=mynet0 -device virtio-net-pci,netdev=mynet0 -append "rw root=/dev/vda" -device virtio-vga 
-usb -device usb-ehci,id=ehci -device usb-tablet -device virtio-keyboard-pci -smp 4 -vnc :1


QEMU command for MintPPC without KVM and with VNC connect: qemu-system-ppc64 -M ppce500 -cpu e5500 
-m 1024 -kernel uImage -drive format=raw,file=MintPPC32-X5000.img,index=0,if=virtio -netdev 
user,id=mynet0 -device virtio-net-pci,netdev=mynet0 -append "rw root=/dev/vda" -device virtio-vga 
-usb -device usb-ehci,id=ehci -device usb-tablet -device virtio-keyboard-pci -smp 4 -vnc :1


It doesn't work, it remains stuck.

But I'm probably not in the best situation: I'm on a PC running Windows 7, with Virtualbox running 
Fedora core 33 and I try to run powerpc QEMU on the fedora core 33. Maybe too many layers to succeed.

Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1

Le 04/05/2021 à 13:02, Christian Zigotzky a écrit :

Am 04.05.21 um 12:07 schrieb Christian Zigotzky:

Am 04.05.21 um 11:49 schrieb Christophe Leroy:

Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :

Am 04.05.21 um 11:11 schrieb Christophe Leroy:

Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :

Am 04.05.21 um 10:58 schrieb Christophe Leroy:

Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :

On 04 May 2021 at 09:47am, Christophe Leroy wrote:

Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :

Hi Christophe,

Thanks for your answer but I think I don't know how it works with the
cherry-pick.

$ git bisect start

As you suspect the problem to be specific to powerpc, I can do

git bisect start -- arch/powerpc

$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

You said that powerpc-5.13-1 is bad so you can narrow the search I think:

git bisect bad powerpc-5.13-1
git bisect good 887f3ceb51cd3~

I tried it but without any success.

git bisect bad powerpc-5.13-1

Output:
fatal: Needed a single revision
Bad rev input: powerpc-5.13-1

I don't understand, on my side it works. Maybe a difference between your version of git and
mine.

In that case, just use the SHA corresponding to the merge:

git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

Christophe

Do you use a BookE machine?

No I don't unfortunately, and I have tried booting in QEMU a kernel built with your config, but
it freezes before any output.

You can use my kernels and distributions.

Ok, I'll see if I can do something with them.

In the meantime, have you been able to bisect ?

Thanks
Christophe

I am bisecting currently.

$ git bisect start -- arch/powerpc
$ git bisect good 887f3ceb51cd3~
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
OK, there is another issue after the second bisecting step. The boot stops after loading the dtb and
uImage file. I can't solve 2 issues with bisecting at the same time.

In that case, you can use 'git bisect skip' to skip the one that is not booting
at all.

Re: remove the nvlink2 pci_vfio subdriver v2

On Tue, 4 May 2021 15:30:15 +0200
Greg Kroah-Hartman  wrote:

> On Tue, May 04, 2021 at 03:20:34PM +0200, Greg Kurz wrote:
> > On Tue, 4 May 2021 14:59:07 +0200
> > Greg Kroah-Hartman  wrote:
> > 
> > > On Tue, May 04, 2021 at 02:22:36PM +0200, Greg Kurz wrote:
> > > > On Fri, 26 Mar 2021 07:13:09 +0100
> > > > Christoph Hellwig  wrote:
> > > > 
> > > > > Hi all,
> > > > > 
> > > > > the nvlink2 vfio subdriver is a weird beast.  It supports a hardware
> > > > > feature without any open source component - what would normally be
> > > > > the normal open source userspace that we require for kernel drivers,
> > > > > although in this particular case user space could of course be a
> > > > > kernel driver in a VM.  It also happens to be a complete mess that
> > > > > does not properly bind to PCI IDs, is hacked into the vfio_pci driver
> > > > > and also pulles in over 1000 lines of code always build into powerpc
> > > > > kernels that have Power NV support enabled.  Because of all these
> > > > > issues and the lack of breaking userspace when it is removed I think
> > > > > the best idea is to simply kill.
> > > > > 
> > > > > Changes since v1:
> > > > >  - document the removed subtypes as reserved
> > > > >  - add the ACK from Greg
> > > > > 
> > > > > Diffstat:
> > > > >  arch/powerpc/platforms/powernv/npu-dma.c |  705 
> > > > > ---
> > > > >  b/arch/powerpc/include/asm/opal.h|3 
> > > > >  b/arch/powerpc/include/asm/pci-bridge.h  |1 
> > > > >  b/arch/powerpc/include/asm/pci.h |7 
> > > > >  b/arch/powerpc/platforms/powernv/Makefile|2 
> > > > >  b/arch/powerpc/platforms/powernv/opal-call.c |2 
> > > > >  b/arch/powerpc/platforms/powernv/pci-ioda.c  |  185 ---
> > > > >  b/arch/powerpc/platforms/powernv/pci.c   |   11 
> > > > >  b/arch/powerpc/platforms/powernv/pci.h   |   17 
> > > > >  b/arch/powerpc/platforms/pseries/pci.c   |   23 
> > > > >  b/drivers/vfio/pci/Kconfig   |6 
> > > > >  b/drivers/vfio/pci/Makefile  |1 
> > > > >  b/drivers/vfio/pci/vfio_pci.c|   18 
> > > > >  b/drivers/vfio/pci/vfio_pci_private.h|   14 
> > > > >  b/include/uapi/linux/vfio.h  |   38 -
> > > > 
> > > > 
> > > > Hi Christoph,
> > > > 
> > > > FYI, these uapi changes break build of QEMU.
> > > 
> > > What uapi changes?
> > > 
> > 
> > All macros and structure definitions that are being removed
> > from include/uapi/linux/vfio.h by patch 1.
> > 
> > > What exactly breaks?
> > > 
> > 
> > These macros and types are used by the current QEMU code base.
> > Next time the QEMU source tree updates its copy of the kernel
> > headers, the compilation of affected code will fail.
> 
> So does QEMU use this api that is being removed, or does it just have
> some odd build artifacts of the uapi things?
> 

These are region subtypes definition and associated capabilities.
QEMU basically gets information on VFIO regions from the kernel
driver and for those regions with a nvlink2 subtype, it tries
to extract some more nvlink2 related info.

> What exactly is the error messages here?
> 

[55/143] Compiling C object libqemu-ppc64-softmmu.fa.p/hw_vfio_pci-quirks.c.o
FAILED: libqemu-ppc64-softmmu.fa.p/hw_vfio_pci-quirks.c.o 
cc -Ilibqemu-ppc64-softmmu.fa.p -I. -I../.. -Itarget/ppc -I../../target/ppc 
-I../../capstone/include/capstone -Iqapi -Itrace -Iui -Iui/shader 
-I/usr/include/pixman-1 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include 
-fdiagnostics-color=auto -pipe -Wall -Winvalid-pch -Werror -std=gnu99 -O2 -g 
-isystem /home/greg/Work/qemu/qemu-virtiofs/linux-headers -isystem 
linux-headers -iquote . -iquote /home/greg/Work/qemu/qemu-virtiofs -iquote 
/home/greg/Work/qemu/qemu-virtiofs/include -iquote 
/home/greg/Work/qemu/qemu-virtiofs/disas/libvixl -iquote 
/home/greg/Work/qemu/qemu-virtiofs/tcg/ppc -iquote 
/home/greg/Work/qemu/qemu-virtiofs/accel/tcg -pthread -U_FORTIFY_SOURCE 
-D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE 
-Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings 
-Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv 
-Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security 
-Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs 
-Wendif-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2 
-Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi 
-fstack-protector-strong -fPIC -isystem../../linux-headers 
-isystemlinux-headers -DNEED_CPU_H 
'-DCONFIG_TARGET="ppc64-softmmu-config-target.h"' 
'-DCONFIG_DEVICES="ppc64-softmmu-config-devices.h"' -MD -MQ 
libqemu-ppc64-softmmu.fa.p/hw_vfio_pci-quirks.c.o -MF 
libqemu-ppc64-softmmu.fa.p/hw_vfio_pci-quirks.c.o.d -o 
libqemu-ppc64-softmmu.fa.p/hw_vfio_pci-quirks.c.o -c ../../hw/vfio/pci-quirks.c
../../hw/vfio/pci-quirks.c: In function ‘vfio_pci_nvidia_v100_ram_init’:

Re: remove the nvlink2 pci_vfio subdriver v2

2021-05-04 Thread Daniel Vetter

On Tue, May 04, 2021 at 03:20:34PM +0200, Greg Kurz wrote:
> On Tue, 4 May 2021 14:59:07 +0200
> Greg Kroah-Hartman  wrote:
> 
> > On Tue, May 04, 2021 at 02:22:36PM +0200, Greg Kurz wrote:
> > > On Fri, 26 Mar 2021 07:13:09 +0100
> > > Christoph Hellwig  wrote:
> > > 
> > > > Hi all,
> > > > 
> > > > the nvlink2 vfio subdriver is a weird beast.  It supports a hardware
> > > > feature without any open source component - what would normally be
> > > > the normal open source userspace that we require for kernel drivers,
> > > > although in this particular case user space could of course be a
> > > > kernel driver in a VM.  It also happens to be a complete mess that
> > > > does not properly bind to PCI IDs, is hacked into the vfio_pci driver
> > > > and also pulles in over 1000 lines of code always build into powerpc
> > > > kernels that have Power NV support enabled.  Because of all these
> > > > issues and the lack of breaking userspace when it is removed I think
> > > > the best idea is to simply kill.
> > > > 
> > > > Changes since v1:
> > > >  - document the removed subtypes as reserved
> > > >  - add the ACK from Greg
> > > > 
> > > > Diffstat:
> > > >  arch/powerpc/platforms/powernv/npu-dma.c |  705 
> > > > ---
> > > >  b/arch/powerpc/include/asm/opal.h|3 
> > > >  b/arch/powerpc/include/asm/pci-bridge.h  |1 
> > > >  b/arch/powerpc/include/asm/pci.h |7 
> > > >  b/arch/powerpc/platforms/powernv/Makefile|2 
> > > >  b/arch/powerpc/platforms/powernv/opal-call.c |2 
> > > >  b/arch/powerpc/platforms/powernv/pci-ioda.c  |  185 ---
> > > >  b/arch/powerpc/platforms/powernv/pci.c   |   11 
> > > >  b/arch/powerpc/platforms/powernv/pci.h   |   17 
> > > >  b/arch/powerpc/platforms/pseries/pci.c   |   23 
> > > >  b/drivers/vfio/pci/Kconfig   |6 
> > > >  b/drivers/vfio/pci/Makefile  |1 
> > > >  b/drivers/vfio/pci/vfio_pci.c|   18 
> > > >  b/drivers/vfio/pci/vfio_pci_private.h|   14 
> > > >  b/include/uapi/linux/vfio.h  |   38 -
> > > 
> > > 
> > > Hi Christoph,
> > > 
> > > FYI, these uapi changes break build of QEMU.
> > 
> > What uapi changes?
> > 
> 
> All macros and structure definitions that are being removed
> from include/uapi/linux/vfio.h by patch 1.

Just my 2cents from drm (where we deprecate old gunk uapi quite often):
Imo it's best to keep the uapi headers as-is, but exchange the
documentation with a big "this is removed, never use again" warning:

- it occasionally serves as a good lesson for how to not do uapi (whatever
  the reasons really are in the specific case)

- it's good to know which uapi numbers (like parameter extensions or
  whatever they are in this case) are defacto reserved, because there are
  binaries (qemu in this) that have code acting on them out there.

The only exception where we completely nuke the structs and #defines is
when uapi has been only used by testcases. Which we know, since we defacto
limit our stable uapi guarantee to the canonical open userspace
drivers only (for at least the driver-specific stuff, the cross-driver
interfaces are hopeless).

Anyway feel free to ignore since this might be different than drivers/gpu.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1


Am 04.05.21 um 13:02 schrieb Christian Zigotzky:

Am 04.05.21 um 12:07 schrieb Christian Zigotzky:

Am 04.05.21 um 11:49 schrieb Christophe Leroy:



Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :

Am 04.05.21 um 11:11 schrieb Christophe Leroy:



Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :

Am 04.05.21 um 10:58 schrieb Christophe Leroy:



Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :

On 04 May 2021 at 09:47am, Christophe Leroy wrote:

Hi

Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :

Hi Christophe,

Thanks for your answer but I think I don't know how it works 
with the cherry-pick.


$ git bisect start


As you suspect the problem to be specific to powerpc, I can do

git bisect start -- arch/powerpc



$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c


You said that powerpc-5.13-1 is bad so you can narrow the 
search I think:


git bisect bad powerpc-5.13-1
git bisect good 887f3ceb51cd3~

I tried it but without any success.

git bisect bad powerpc-5.13-1

Output:
fatal: Needed a single revision
Bad rev input: powerpc-5.13-1


I don't understand, on my side it works. Maybe a difference 
between your version of git and mine.


In that case, just use the SHA corresponding to the merge:

git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

Christophe

Do you use a BookE machine?


No I don't unfortunately, and I have tried booting in QEMU a 
kernel built with your config, but it freezes before any output.

You can use my kernels and distributions.



Ok, I'll see if I can do something with them.

In the meantime, have you been able to bisect ?

Thanks
Christophe

I am bisecting currently.

$ git bisect start -- arch/powerpc
$ git bisect good 887f3ceb51cd3~
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
OK, there is another issue after the second bisecting step. The boot 
stops after loading the dtb and uImage file. I can't solve 2 issues 
with bisecting at the same time.

Xorg restarts again and again.

Here are some interesting error messages:

May 04 15:24:53 dc1.a-eon.tld kernel: lxsession[7255]: segfault (11) at 
80 nip ff6a770 lr ff6a760 code 1 in 
libglib-2.0.so.0.4800.2[feaf000+11f000]
May 04 15:24:53 dc1.a-eon.tld kernel: lxsession[7255]: code: 4bfc9401 
3920 91210054 8061005c 2f83 419c0014 3880 4bfc93e5
May 04 15:24:53 dc1.a-eon.tld kernel: lxsession[7255]: code: 3920 
9121005c 2f8f 419e0008 <93ef> 418e000c 81210040 913b


May 04 15:37:40 mintppc.a-eon.tld kernel: packagekitd[4290]: segfault 
(11) at 8 nip 92dbc8 lr 92dae8 code 1 in packagekitd[92+51000]
May 04 15:37:40 mintppc.a-eon.tld kernel: packagekitd[4290]: code: 
38800080 3be001f4 4cc63182 4802c8ad 4b64 6000 81210018 80be8048
May 04 15:37:40 mintppc.a-eon.tld kernel: packagekitd[4290]: code: 
7fa6eb78 38800010 807e801c 3be0 <80e90008> 4cc63182 4802c881 4b38

[PATCH 1/2] powerpc/64s: Fix crashes when toggling stf barrier

The STF (store-to-load forwarding) barrier mitigation can be
enabled/disabled at runtime via a debugfs file (stf_barrier), which
causes the kernel to patch itself to enable/disable the relevant
mitigations.

However depending on which mitigation we're using, it may not be safe to
do that patching while other CPUs are active. For example the following
crash:

  User access of kernel address (c0003fff5af0) - exploit attempt? (uid: 0)
  segfault (11) at c0003fff5af0 nip 7fff8ad12198 lr 7fff8ad121f8 code 1
  code: 40820128 e93c00d0 e9290058 7c292840 40810058 3860 4bfd9a81 e8410018
  code: 2c030006 41810154 3860ffb6 e9210098  7d295279 3940 
40820a3c

Shows that we returned to userspace without restoring the user r13
value, due to executing the partially patched STF exit code.

Fix it by doing the patching under stop machine. The CPUs that aren't
doing the patching will be spinning in the core of the stop machine
logic. That is currently sufficient for our purposes, because none of
the patching we do is to that code or anywhere in the vicinity.

Fixes: a048a07d7f45 ("powerpc/64s: Add support for a store forwarding barrier 
at kernel entry/exit")
Cc: sta...@vger.kernel.org # v4.17+
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/lib/feature-fixups.c | 19 +--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/lib/feature-fixups.c 
b/arch/powerpc/lib/feature-fixups.c
index 1fd31b4b0e13..8f8c8c98a6ac 100644
--- a/arch/powerpc/lib/feature-fixups.c
+++ b/arch/powerpc/lib/feature-fixups.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -227,11 +228,25 @@ static void do_stf_exit_barrier_fixups(enum 
stf_barrier_type types)
   : "unknown");
 }
 
-
-void do_stf_barrier_fixups(enum stf_barrier_type types)
+static int __do_stf_barrier_fixups(void *data)
 {
+   enum stf_barrier_type types = (enum stf_barrier_type)data;
+
do_stf_entry_barrier_fixups(types);
do_stf_exit_barrier_fixups(types);
+
+   return 0;
+}
+
+void do_stf_barrier_fixups(enum stf_barrier_type types)
+{
+   /*
+* The call to the fallback entry flush, and the fallback/sync-ori exit
+* flush can not be safely patched in/out while other CPUs are executing
+* them. So call __do_stf_barrier_fixups() on one CPU while all other 
CPUs
+* spin in the stop machine core with interrupts hard disabled.
+*/
+   stop_machine_cpuslocked(__do_stf_barrier_fixups, (void *)types, NULL);
 }
 
 void do_uaccess_flush_fixups(enum l1d_flush_type types)
-- 
2.25.1

[PATCH 2/2] powerpc/64s: Fix crashes when toggling entry flush barrier

The entry flush mitigation can be enabled/disabled at runtime via a
debugfs file (entry_flush), which causes the kernel to patch itself to
enable/disable the relevant mitigations.

However depending on which mitigation we're using, it may not be safe to
do that patching while other CPUs are active. For example the following
crash:

  sleeper[15639]: segfault (11) at c0004c20 nip c0004c20 lr 
c0004c20

Shows that we returned to userspace with a corrupted LR that points into
the kernel, due to executing the partially patched call to the fallback
entry flush (ie. we missed the LR restore).

Fix it by doing the patching under stop machine. The CPUs that aren't
doing the patching will be spinning in the core of the stop machine
logic. That is currently sufficient for our purposes, because none of
the patching we do is to that code or anywhere in the vicinity.

Fixes: f79643787e0a ("powerpc/64s: flush L1D on kernel entry")
Cc: sta...@vger.kernel.org # v5.10+
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/lib/feature-fixups.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/lib/feature-fixups.c 
b/arch/powerpc/lib/feature-fixups.c
index 8f8c8c98a6ac..679833564e19 100644
--- a/arch/powerpc/lib/feature-fixups.c
+++ b/arch/powerpc/lib/feature-fixups.c
@@ -299,8 +299,9 @@ void do_uaccess_flush_fixups(enum l1d_flush_type types)
: "unknown");
 }
 
-void do_entry_flush_fixups(enum l1d_flush_type types)
+static int __do_entry_flush_fixups(void *data)
 {
+   enum l1d_flush_type types = (enum l1d_flush_type)data;
unsigned int instrs[3], *dest;
long *start, *end;
int i;
@@ -369,6 +370,19 @@ void do_entry_flush_fixups(enum l1d_flush_type types)
: "ori type" :
(types &  L1D_FLUSH_MTTRIG) ? "mttrig type"
: "unknown");
+
+   return 0;
+}
+
+void do_entry_flush_fixups(enum l1d_flush_type types)
+{
+   /*
+* The call to the fallback flush can not be safely patched in/out while
+* other CPUs are executing it. So call __do_entry_flush_fixups() on one
+* CPU while all other CPUs spin in the stop machine core with 
interrupts
+* hard disabled.
+*/
+   stop_machine_cpuslocked(__do_entry_flush_fixups, (void *)types, NULL);
 }
 
 void do_rfi_flush_fixups(enum l1d_flush_type types)
-- 
2.25.1

Re: remove the nvlink2 pci_vfio subdriver v2

On Tue, 4 May 2021 14:59:07 +0200
Greg Kroah-Hartman  wrote:

> On Tue, May 04, 2021 at 02:22:36PM +0200, Greg Kurz wrote:
> > On Fri, 26 Mar 2021 07:13:09 +0100
> > Christoph Hellwig  wrote:
> > 
> > > Hi all,
> > > 
> > > the nvlink2 vfio subdriver is a weird beast.  It supports a hardware
> > > feature without any open source component - what would normally be
> > > the normal open source userspace that we require for kernel drivers,
> > > although in this particular case user space could of course be a
> > > kernel driver in a VM.  It also happens to be a complete mess that
> > > does not properly bind to PCI IDs, is hacked into the vfio_pci driver
> > > and also pulles in over 1000 lines of code always build into powerpc
> > > kernels that have Power NV support enabled.  Because of all these
> > > issues and the lack of breaking userspace when it is removed I think
> > > the best idea is to simply kill.
> > > 
> > > Changes since v1:
> > >  - document the removed subtypes as reserved
> > >  - add the ACK from Greg
> > > 
> > > Diffstat:
> > >  arch/powerpc/platforms/powernv/npu-dma.c |  705 
> > > ---
> > >  b/arch/powerpc/include/asm/opal.h|3 
> > >  b/arch/powerpc/include/asm/pci-bridge.h  |1 
> > >  b/arch/powerpc/include/asm/pci.h |7 
> > >  b/arch/powerpc/platforms/powernv/Makefile|2 
> > >  b/arch/powerpc/platforms/powernv/opal-call.c |2 
> > >  b/arch/powerpc/platforms/powernv/pci-ioda.c  |  185 ---
> > >  b/arch/powerpc/platforms/powernv/pci.c   |   11 
> > >  b/arch/powerpc/platforms/powernv/pci.h   |   17 
> > >  b/arch/powerpc/platforms/pseries/pci.c   |   23 
> > >  b/drivers/vfio/pci/Kconfig   |6 
> > >  b/drivers/vfio/pci/Makefile  |1 
> > >  b/drivers/vfio/pci/vfio_pci.c|   18 
> > >  b/drivers/vfio/pci/vfio_pci_private.h|   14 
> > >  b/include/uapi/linux/vfio.h  |   38 -
> > 
> > 
> > Hi Christoph,
> > 
> > FYI, these uapi changes break build of QEMU.
> 
> What uapi changes?
> 

All macros and structure definitions that are being removed
from include/uapi/linux/vfio.h by patch 1.

> What exactly breaks?
> 

These macros and types are used by the current QEMU code base.
Next time the QEMU source tree updates its copy of the kernel
headers, the compilation of affected code will fail.

> Why does QEMU require kernel driver stuff?
> 

Not sure to understand the question... is there a problem
with QEMU using an already published uapi ?

> thanks,
> 
> greg k-h

Re: remove the nvlink2 pci_vfio subdriver v2

2021-05-04 Thread Greg Kroah-Hartman

On Tue, May 04, 2021 at 03:20:34PM +0200, Greg Kurz wrote:
> On Tue, 4 May 2021 14:59:07 +0200
> Greg Kroah-Hartman  wrote:
> 
> > On Tue, May 04, 2021 at 02:22:36PM +0200, Greg Kurz wrote:
> > > On Fri, 26 Mar 2021 07:13:09 +0100
> > > Christoph Hellwig  wrote:
> > > 
> > > > Hi all,
> > > > 
> > > > the nvlink2 vfio subdriver is a weird beast.  It supports a hardware
> > > > feature without any open source component - what would normally be
> > > > the normal open source userspace that we require for kernel drivers,
> > > > although in this particular case user space could of course be a
> > > > kernel driver in a VM.  It also happens to be a complete mess that
> > > > does not properly bind to PCI IDs, is hacked into the vfio_pci driver
> > > > and also pulles in over 1000 lines of code always build into powerpc
> > > > kernels that have Power NV support enabled.  Because of all these
> > > > issues and the lack of breaking userspace when it is removed I think
> > > > the best idea is to simply kill.
> > > > 
> > > > Changes since v1:
> > > >  - document the removed subtypes as reserved
> > > >  - add the ACK from Greg
> > > > 
> > > > Diffstat:
> > > >  arch/powerpc/platforms/powernv/npu-dma.c |  705 
> > > > ---
> > > >  b/arch/powerpc/include/asm/opal.h|3 
> > > >  b/arch/powerpc/include/asm/pci-bridge.h  |1 
> > > >  b/arch/powerpc/include/asm/pci.h |7 
> > > >  b/arch/powerpc/platforms/powernv/Makefile|2 
> > > >  b/arch/powerpc/platforms/powernv/opal-call.c |2 
> > > >  b/arch/powerpc/platforms/powernv/pci-ioda.c  |  185 ---
> > > >  b/arch/powerpc/platforms/powernv/pci.c   |   11 
> > > >  b/arch/powerpc/platforms/powernv/pci.h   |   17 
> > > >  b/arch/powerpc/platforms/pseries/pci.c   |   23 
> > > >  b/drivers/vfio/pci/Kconfig   |6 
> > > >  b/drivers/vfio/pci/Makefile  |1 
> > > >  b/drivers/vfio/pci/vfio_pci.c|   18 
> > > >  b/drivers/vfio/pci/vfio_pci_private.h|   14 
> > > >  b/include/uapi/linux/vfio.h  |   38 -
> > > 
> > > 
> > > Hi Christoph,
> > > 
> > > FYI, these uapi changes break build of QEMU.
> > 
> > What uapi changes?
> > 
> 
> All macros and structure definitions that are being removed
> from include/uapi/linux/vfio.h by patch 1.
> 
> > What exactly breaks?
> > 
> 
> These macros and types are used by the current QEMU code base.
> Next time the QEMU source tree updates its copy of the kernel
> headers, the compilation of affected code will fail.

So does QEMU use this api that is being removed, or does it just have
some odd build artifacts of the uapi things?

What exactly is the error messages here?

And if we put the uapi .h file stuff back, is that sufficient for qemu
to work, as it should be checking at runtime what the kernel has / has
not anyway, right?

thanks,

greg k-h

Re: [PATCH] Raise the minimum GCC version to 5.2

2021-05-04 Thread Andy Shevchenko

On Mon, May 3, 2021 at 12:29 PM Arnd Bergmann  wrote:
>
> On Mon, May 3, 2021 at 9:35 AM Alexander Dahl  wrote:
> >
> > Desktops and servers are all nice, however I just want to make you
> > aware, there are embedded users forced to stick to older cross
> > toolchains for different reasons as well, e.g. in industrial
> > environment. :-)
> >
> > This is no show stopper for us, I just wanted to let you be aware.
>
> Can you be more specific about what scenarios you are thinking of,
> what the motivations are for using an old compiler with a new kernel
> on embedded systems, and what you think a realistic maximum
> time would be between compiler updates?
>
> One scenario that I've seen previously is where user space and
> kernel are built together as a source based distribution (OE, buildroot,
> openwrt, ...), and the compiler is picked to match the original sources
> of the user space because that is best tested, but the same compiler
> then gets used to build the kernel as well because that is the default
> in the build environment.
>
> There are two problems I see with this logic:
>
> - Running the latest kernel to avoid security problems is of course
>   a good idea, but if one runs that with ten year old user space that
>   is never updated, the system is likely to end up just as insecure.
>   Not all bugs are in the kernel.
>
> - The same logic that applies to ancient user space staying with
>   an ancient compiler (it's better tested in this combination) also
>   applies to the kernel: running the latest kernel on an old compiler
>   is something that few people test, and tends to run into more bugs
>   than using the compiler that other developers used to test that
>   kernel.

I understand that you are talking about embedded, but it you stuck
with a distro (esp. LTS one, like CentOS 7.x), you have gcc 4.8.5
there for everything, but they have got security updates. Seems if you
are with a distro you have to stick with its kernel with all pros and
cons of such an approach.


-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] Raise the minimum GCC version to 5.2

2021-05-04 Thread Andy Shevchenko

On Mon, May 3, 2021 at 9:17 AM Christophe Leroy
 wrote:
> Le 01/05/2021 à 17:15, Masahiro Yamada a écrit :
> > The current minimum GCC version is 4.9 except ARCH=arm64 requiring
> > GCC 5.1.
> >
> > When we discussed last time, we agreed to raise the minimum GCC version
> > to 5.1 globally. [1]
> >
> > I'd like to propose GCC 5.2 to clean up arch/powerpc/Kconfig as well.
>
> One point I missed when I saw your patch first time, but I realised during 
> the discussion:
>
> Up to 4.9, GCC was numbered with 3 digits, we had 4.8.0, 4.8.1, ... 4.8.5, 
> 4.9.0, 4.9.1,  4.9.4
>
> Then starting at 5, GCC switched to a 2 digits scheme, with 5.0, 5.1, 5.2, 
> ... 5.5
>
> So, that is not GCC 5.1 or 5.2 that you should target, but only GCC 5.
> Then it is up to the user to use the latest available version of GCC 5, which 
> is 5.5 at the time
> begin, just like the user would have selected 4.9.4 when 4.9 was the minimum 
> GCC version.

And we may end up in the case when gcc 5.x will be more buggy than
v4.9.y (as once proved by nice detective story where compiler bug
produces a file system corruption).

-- 
With Best Regards,
Andy Shevchenko

Re: remove the nvlink2 pci_vfio subdriver v2

2021-05-04 Thread Cornelia Huck

On Tue, 4 May 2021 15:00:39 +0200
Christoph Hellwig  wrote:

> On Tue, May 04, 2021 at 02:59:07PM +0200, Greg Kroah-Hartman wrote:
> > > Hi Christoph,
> > > 
> > > FYI, these uapi changes break build of QEMU.  
> > 
> > What uapi changes?
> > 
> > What exactly breaks?
> > 
> > Why does QEMU require kernel driver stuff?  
> 
> Looks like it pull in the uapi struct definitions unconditionally
> instead of having a local copy.  We could fix that by just putting
> them back, but to me this seems like a rather broken configuration
> in qemu when it pulls in headers from the running/installed kernel
> without any feature checks before using them.
> 

It is not pulling them from the installed kernel, but from a
development version to get new definitions. Removing things in the
kernel requires workarounds in QEMU until it can remove those things as
well. It is not a dumb update...

Re: remove the nvlink2 pci_vfio subdriver v2

2021-05-04 Thread Christoph Hellwig

On Tue, May 04, 2021 at 02:59:07PM +0200, Greg Kroah-Hartman wrote:
> > Hi Christoph,
> > 
> > FYI, these uapi changes break build of QEMU.
> 
> What uapi changes?
> 
> What exactly breaks?
> 
> Why does QEMU require kernel driver stuff?

Looks like it pull in the uapi struct definitions unconditionally
instead of having a local copy.  We could fix that by just putting
them back, but to me this seems like a rather broken configuration
in qemu when it pulls in headers from the running/installed kernel
without any feature checks before using them.

Re: remove the nvlink2 pci_vfio subdriver v2

2021-05-04 Thread Greg Kroah-Hartman

On Tue, May 04, 2021 at 02:22:36PM +0200, Greg Kurz wrote:
> On Fri, 26 Mar 2021 07:13:09 +0100
> Christoph Hellwig  wrote:
> 
> > Hi all,
> > 
> > the nvlink2 vfio subdriver is a weird beast.  It supports a hardware
> > feature without any open source component - what would normally be
> > the normal open source userspace that we require for kernel drivers,
> > although in this particular case user space could of course be a
> > kernel driver in a VM.  It also happens to be a complete mess that
> > does not properly bind to PCI IDs, is hacked into the vfio_pci driver
> > and also pulles in over 1000 lines of code always build into powerpc
> > kernels that have Power NV support enabled.  Because of all these
> > issues and the lack of breaking userspace when it is removed I think
> > the best idea is to simply kill.
> > 
> > Changes since v1:
> >  - document the removed subtypes as reserved
> >  - add the ACK from Greg
> > 
> > Diffstat:
> >  arch/powerpc/platforms/powernv/npu-dma.c |  705 
> > ---
> >  b/arch/powerpc/include/asm/opal.h|3 
> >  b/arch/powerpc/include/asm/pci-bridge.h  |1 
> >  b/arch/powerpc/include/asm/pci.h |7 
> >  b/arch/powerpc/platforms/powernv/Makefile|2 
> >  b/arch/powerpc/platforms/powernv/opal-call.c |2 
> >  b/arch/powerpc/platforms/powernv/pci-ioda.c  |  185 ---
> >  b/arch/powerpc/platforms/powernv/pci.c   |   11 
> >  b/arch/powerpc/platforms/powernv/pci.h   |   17 
> >  b/arch/powerpc/platforms/pseries/pci.c   |   23 
> >  b/drivers/vfio/pci/Kconfig   |6 
> >  b/drivers/vfio/pci/Makefile  |1 
> >  b/drivers/vfio/pci/vfio_pci.c|   18 
> >  b/drivers/vfio/pci/vfio_pci_private.h|   14 
> >  b/include/uapi/linux/vfio.h  |   38 -
> 
> 
> Hi Christoph,
> 
> FYI, these uapi changes break build of QEMU.

What uapi changes?

What exactly breaks?

Why does QEMU require kernel driver stuff?

thanks,

greg k-h

Re: [PATCH] powerpc/pseries/dlpar: use rtas_get_sensor()

2021-05-04 Thread Laurent Dufour


Le 04/05/2021 à 04:53, Nathan Lynch a écrit :

Instead of making bare calls to get-sensor-state, use
rtas_get_sensor(), which correctly handles busy and extended delay
statuses.


Reviewed-by: Laurent Dufour 


Fixes: ab519a011caa ("powerpc/pseries: Kernel DLPAR Infrastructure")
Signed-off-by: Nathan Lynch 
---
  arch/powerpc/platforms/pseries/dlpar.c | 9 +++--
  1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/dlpar.c 
b/arch/powerpc/platforms/pseries/dlpar.c
index 3ac70790ec7a..b1f01ac0c29e 100644
--- a/arch/powerpc/platforms/pseries/dlpar.c
+++ b/arch/powerpc/platforms/pseries/dlpar.c
@@ -289,8 +289,7 @@ int dlpar_acquire_drc(u32 drc_index)
  {
int dr_status, rc;
  
-	rc = rtas_call(rtas_token("get-sensor-state"), 2, 2, _status,

-  DR_ENTITY_SENSE, drc_index);
+   rc = rtas_get_sensor(DR_ENTITY_SENSE, drc_index, _status);
if (rc || dr_status != DR_ENTITY_UNUSABLE)
return -1;
  
@@ -311,8 +310,7 @@ int dlpar_release_drc(u32 drc_index)

  {
int dr_status, rc;
  
-	rc = rtas_call(rtas_token("get-sensor-state"), 2, 2, _status,

-  DR_ENTITY_SENSE, drc_index);
+   rc = rtas_get_sensor(DR_ENTITY_SENSE, drc_index, _status);
if (rc || dr_status != DR_ENTITY_PRESENT)
return -1;
  
@@ -333,8 +331,7 @@ int dlpar_unisolate_drc(u32 drc_index)

  {
int dr_status, rc;
  
-	rc = rtas_call(rtas_token("get-sensor-state"), 2, 2, _status,

-   DR_ENTITY_SENSE, drc_index);
+   rc = rtas_get_sensor(DR_ENTITY_SENSE, drc_index, _status);
if (rc || dr_status != DR_ENTITY_PRESENT)
return -1;

Re: remove the nvlink2 pci_vfio subdriver v2

On Fri, 26 Mar 2021 07:13:09 +0100
Christoph Hellwig  wrote:

> Hi all,
> 
> the nvlink2 vfio subdriver is a weird beast.  It supports a hardware
> feature without any open source component - what would normally be
> the normal open source userspace that we require for kernel drivers,
> although in this particular case user space could of course be a
> kernel driver in a VM.  It also happens to be a complete mess that
> does not properly bind to PCI IDs, is hacked into the vfio_pci driver
> and also pulles in over 1000 lines of code always build into powerpc
> kernels that have Power NV support enabled.  Because of all these
> issues and the lack of breaking userspace when it is removed I think
> the best idea is to simply kill.
> 
> Changes since v1:
>  - document the removed subtypes as reserved
>  - add the ACK from Greg
> 
> Diffstat:
>  arch/powerpc/platforms/powernv/npu-dma.c |  705 
> ---
>  b/arch/powerpc/include/asm/opal.h|3 
>  b/arch/powerpc/include/asm/pci-bridge.h  |1 
>  b/arch/powerpc/include/asm/pci.h |7 
>  b/arch/powerpc/platforms/powernv/Makefile|2 
>  b/arch/powerpc/platforms/powernv/opal-call.c |2 
>  b/arch/powerpc/platforms/powernv/pci-ioda.c  |  185 ---
>  b/arch/powerpc/platforms/powernv/pci.c   |   11 
>  b/arch/powerpc/platforms/powernv/pci.h   |   17 
>  b/arch/powerpc/platforms/pseries/pci.c   |   23 
>  b/drivers/vfio/pci/Kconfig   |6 
>  b/drivers/vfio/pci/Makefile  |1 
>  b/drivers/vfio/pci/vfio_pci.c|   18 
>  b/drivers/vfio/pci/vfio_pci_private.h|   14 
>  b/include/uapi/linux/vfio.h  |   38 -


Hi Christoph,

FYI, these uapi changes break build of QEMU.

I guess QEMU people should take some action before this percolates
to the QEMU source tree.

Cc'ing relevant QEMU lists to bring the discussion there.

Cheers,

--
Greg

>  drivers/vfio/pci/vfio_pci_nvlink2.c  |  490 --
>  16 files changed, 12 insertions(+), 1511 deletions(-)

Re: [PATCH] Raise the minimum GCC version to 5.2





Le 04/05/2021 à 14:17, Michal Suchánek a écrit :

On Tue, May 04, 2021 at 02:09:24PM +0200, Miguel Ojeda wrote:

On Tue, May 4, 2021 at 11:22 AM Michal Suchánek  wrote:


Except it makes answering the question "Is this bug we see on this
ancient system still present in upstream?" needlessly more difficult to
answer.


Can you please provide some details? If you are talking about testing
a new kernel image in the ancient system "as-is", why wouldn't you
build it in a newer system? If you are talking about  particular
problems about bisecting (kernel, compiler) pairs etc., details would
also be welcome.


Yes, bisecting comes to mind. If you need to switch the userspace as
well the bisection results are not that solid. You may not be even able
to bisect because the workload does not exist on a new system at all.
Crafting a minimal test case that can be forward-ported to a new system
is not always trivial - if you understood the problem to that extent you
might not even need to bisect it in the first place.



But you don't need to switch the userspace or the complete build tools to build a kernel with a 
newer toolchain.


All you have to do is take one from 
https://mirrors.edge.kernel.org/pub/tools/crosstool/

I'm doing everything under CentOS 6, and using one of those tools allows me to build latest kernel 
without breaking anything else.

Re: [PATCH] Raise the minimum GCC version to 5.2

2021-05-04 Thread Michal Suchánek

On Tue, May 04, 2021 at 02:09:24PM +0200, Miguel Ojeda wrote:
> On Tue, May 4, 2021 at 11:22 AM Michal Suchánek  wrote:
> >
> > Except it makes answering the question "Is this bug we see on this
> > ancient system still present in upstream?" needlessly more difficult to
> > answer.
> 
> Can you please provide some details? If you are talking about testing
> a new kernel image in the ancient system "as-is", why wouldn't you
> build it in a newer system? If you are talking about  particular
> problems about bisecting (kernel, compiler) pairs etc., details would
> also be welcome.

Yes, bisecting comes to mind. If you need to switch the userspace as
well the bisection results are not that solid. You may not be even able
to bisect because the workload does not exist on a new system at all.
Crafting a minimal test case that can be forward-ported to a new system
is not always trivial - if you understood the problem to that extent you
might not even need to bisect it in the first place.

Thanks

Michal

Re: [PATCH v2] powerpc/64: BE option to use ELFv2 ABI for big endian kernels

Segher Boessenkool  writes:
> On Mon, May 03, 2021 at 10:51:41AM +1000, Nicholas Piggin wrote:
>> Excerpts from Segher Boessenkool's message of May 3, 2021 3:55 am:
>> > On Wed, Apr 29, 2020 at 10:57:16AM +1000, Nicholas Piggin wrote:
>> >> Excerpts from Segher Boessenkool's message of April 29, 2020 9:40 am:
>> >> I blame toolchain for -mabi=elfv2 ! And also some blame on ABI document 
>> >> which is called ELF V2 ABI rather than ELF ABI V2 which would have been 
>> >> unambiguous.
>> > 
>> > At least ELFv2 ABI is correct.  "ELF ABI v2" is not.
>> > 
>> >> I can go through and change all my stuff and config options to ELF_ABI_v2.
>> > 
>> > Please don't.  It is wrong.
>> 
>> Then I'm not sure what the point of your previous mail was, what did I 
>> miss?
>
> I asked if you could make it clearer to people who do not know what this
> is whether they want to use it.  Or that was my intention, anyhow :-/
>
>> > Both the original PowerPC ELF ABI and the
>> > ELFv2 one have versions themselves.  Also, the base ELF standard has a
>> > version, and is set up so there can be incompatible versions even!  Of
>> > course it still is version 1 to this day, but :-)
>> 
>> The point was for people who don't know ELFv2 has a specific meaning for 
>> powerpc,
>
> It does not have *any* meaning outside of Power.  But people who do not
> know what it is can assume the wrong things about it.  It isn't a great
> name because of that :-(
>
> (It's not as bad as the MIPS ABIs -- an older one is called "new" :-) )
>
>> then ELF ABIv2 is more explanatory about it being an abi change
>> rather than base elf change, even if it's not the "correct" name.
>
> I very much disagree.  "ELF ABIv2" is completely meaningless.

Except:

$ readelf -h /bin/true
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class: ELF64
  Data:  2's complement, little endian
  Version:   1 (current)
  OS/ABI:UNIX - System V
  ABI Version:   0
  Type:  DYN (Shared object file)
  Machine:   PowerPC64
  Version:   0x1
  Entry point address:   0x1990
  Start of program headers:  64 (bytes into file)
  Start of section headers:  66176 (bytes into file)
  Flags: 0x2, abiv2
  ^

:)

cheers

Re: [PATCH] Raise the minimum GCC version to 5.2

2021-05-04 Thread Miguel Ojeda

On Tue, May 4, 2021 at 11:22 AM Michal Suchánek  wrote:
>
> Except it makes answering the question "Is this bug we see on this
> ancient system still present in upstream?" needlessly more difficult to
> answer.

Can you please provide some details? If you are talking about testing
a new kernel image in the ancient system "as-is", why wouldn't you
build it in a newer system? If you are talking about  particular
problems about bisecting (kernel, compiler) pairs etc., details would
also be welcome.

> Sure, throwing out old compiler versions that are known to cause
> problems makes sense. Updating to latest just because much less so.

I definitely did not argue for "latest compiler" or "updating just because".

> One of the selling point of C in general and gcc in particular is
> stability. If we need the latest compiler we can as well rewrite the
> kernel in Rust which has a required update cycle of a few months.

Rust does not have a "required update cycle" and it does not break old
code unless really required, just like C and common compilers.

Concerning GCC, they patch releases for ~2.5 years, sure, but for many
projects that is not nearly enough. So you still need custom support,
which is anyway what most people care about.

> Because some mainline kernel features rely on bleeding edge tools I end
> up building mainline with current tools anyway but if you do not need
> BTF or whatever other latest gimmick older toolchains should do.

It would be better to hear concrete arguments about why "older
toolchains should do", rather than calling things a gimmick.

Cheers,
Miguel

Re: [PATCH] Raise the minimum GCC version to 5.2

2021-05-04 Thread Arnd Bergmann

On Tue, May 4, 2021 at 7:31 AM Alexander Dahl  wrote:
> Am Mon, May 03, 2021 at 11:25:21AM +0200 schrieb Arnd Bergmann:
> > On Mon, May 3, 2021 at 9:35 AM Alexander Dahl  wrote:
> > >
> > > Desktops and servers are all nice, however I just want to make you
> > > aware, there are embedded users forced to stick to older cross
> > > toolchains for different reasons as well, e.g. in industrial
> > > environment. :-)
> > >
> > > This is no show stopper for us, I just wanted to let you be aware.
> >
> > Can you be more specific about what scenarios you are thinking of,
> > what the motivations are for using an old compiler with a new kernel
> > on embedded systems, and what you think a realistic maximum
> > time would be between compiler updates?
>
> One reason might be certification. For certain industrial applications
> like support for complex field bus protocols, you need to get your
> devices tested by an external partner running extensive test suites.
> This is time consuming and expensive.
>
> Changing the toolchain of your system then, would be a massive change
> which would require recertification, while you could argue just
> updating a single component like the kernel and building everything
> again, does not require the whole testing process again.
>
> Thin ice, I know.

As Christophe said, I don't think this is a valid example. I agree that
if rebuilding everything with a new toolchain requires certification, you
shouldn't rebuild everything.

If replacing the kernel does not require recertification for your
specific system, that is fine, but that does not mean the new kernel
should be built with an outdated toolchain. If the certification
allows replacing linux-3.18 with linux-5.10 but doesn't allow building
the kernel with a different toolchain compared to the rest, then
the point of the certification is rather questionable.

Do you know specific certifications that would require you to
do this?

> One problem we actually ran into in BSPs like that (we build with
> ptxdist, however build system doesn't matter here, it could as well
> have been buildroot etc.) was things* failing to build with newer
> compilers, things we could not or did not want to fix, so staying with
> an older toolchain was the obvious choice.
>
> *Things as in bootloaders for an armv5 platform.
...
>
> What we actually did: building recent userspace and kernel with older
> toolchains, because bootloader.

It sounds like you are trying to make an argument in favour of
deprecating old toolchains *earlier* in new kernels ;-)

If we simply made it impossible to have users build kernels with
the same old toolchain that is needed for building the old bootloader
or the old user space, it sounds like more people would do the
right thing and build the updated kernels with a better tested
toolchain, or update their bootloader as well. The only downside
is that some users would choose to remain on the older kernels,
so it shouldn't be too aggressive either.

 Arnd

Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1


Am 04.05.21 um 12:07 schrieb Christian Zigotzky:

Am 04.05.21 um 11:49 schrieb Christophe Leroy:



Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :

Am 04.05.21 um 11:11 schrieb Christophe Leroy:



Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :

Am 04.05.21 um 10:58 schrieb Christophe Leroy:



Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :

On 04 May 2021 at 09:47am, Christophe Leroy wrote:

Hi

Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :

Hi Christophe,

Thanks for your answer but I think I don't know how it works 
with the cherry-pick.


$ git bisect start


As you suspect the problem to be specific to powerpc, I can do

git bisect start -- arch/powerpc



$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c


You said that powerpc-5.13-1 is bad so you can narrow the 
search I think:


git bisect bad powerpc-5.13-1
git bisect good 887f3ceb51cd3~

I tried it but without any success.

git bisect bad powerpc-5.13-1

Output:
fatal: Needed a single revision
Bad rev input: powerpc-5.13-1


I don't understand, on my side it works. Maybe a difference 
between your version of git and mine.


In that case, just use the SHA corresponding to the merge:

git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

Christophe

Do you use a BookE machine?


No I don't unfortunately, and I have tried booting in QEMU a kernel 
built with your config, but it freezes before any output.

You can use my kernels and distributions.



Ok, I'll see if I can do something with them.

In the meantime, have you been able to bisect ?

Thanks
Christophe

I am bisecting currently.

$ git bisect start -- arch/powerpc
$ git bisect good 887f3ceb51cd3~
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
OK, there is another issue after the second bisecting step. The boot 
stops after loading the dtb and uImage file. I can't solve 2 issues with 
bisecting at the same time.

Re: [PATCH 4/4] powerpc/pseries: warn if recursing into the hcall tracing code

Excerpts from Naveen N. Rao's message of May 4, 2021 8:25 pm:
> Nicholas Piggin wrote:
>> Excerpts from Naveen N. Rao's message of April 27, 2021 11:59 pm:
>>> Nicholas Piggin wrote:
 + *
 + * H_CONFER from spin locks must be treated separately though and use 
 _notrace
 + * plpar_hcall variants, see yield_to_preempted().
   */
  static DEFINE_PER_CPU(unsigned int, hcall_trace_depth);
 
 @@ -1843,7 +1846,7 @@ notrace void __trace_hcall_entry(unsigned long 
 opcode, unsigned long *args)
 
depth = this_cpu_ptr(_trace_depth);
 
 -  if (*depth)
 +  if (WARN_ON_ONCE(*depth))
goto out;
>>> 
>>> I don't think this will be helpful. The hcall trace depth tracking is 
>>> for the tracepoint and I suspect that this warning will be triggered 
>>> quite easily. Since we have recursion protection, I don't think we 
>>> should warn here.
>> 
>> What would trigger recursion?
> 
> The trace code that this protects: trace_hcall_entry(). The tracing code 
> itself can end up doing a hcall as we see in the first patch in this 
> series:
>   plpar_hcall_norets_trace+0x34/0x8c (unreliable)
>   __pv_queued_spin_lock_slowpath+0x684/0x710
>   trace_clock_global+0x148/0x150
>   ring_buffer_lock_reserve+0x12c/0x630
>   trace_event_buffer_lock_reserve+0x80/0x220
>   trace_event_buffer_reserve+0x7c/0xd0
>   trace_event_raw_event_hcall_entry+0x68/0x150
>   __trace_hcall_entry+0x160/0x180
> 
> 
> There is also a comment aroung hcall_trace_depth that mentions this:
> 
>   /*
>* Since the tracing code might execute hcalls we need to guard against
>* recursion. One example of this are spinlocks calling H_YIELD on
>* shared processor partitions.
>*/

Right but since fixing those, my thought is we better not cause more
any recursion, so we should fix anything that does.

Thanks,
Nick

Re: [PATCH 1/2] powerpc/asm-offset: Remove unused items related to paca





Le 04/05/2021 à 12:14, Nicholas Piggin a écrit :

Excerpts from Christophe Leroy's message of May 4, 2021 2:46 am:

PACA_SIZE, PACACONTEXTID, PACALOWSLICESPSIZE, PACAHIGHSLICEPSIZE,
PACA_SLB_ADDR_LIMIT, MMUPSIZEDEFSIZE, PACASLBCACHE, PACASLBCACHEPTR,
PACASTABRR, PACAVMALLOCSLLP, MMUPSIZESLLP, PACACONTEXTSLLP,
PACALPPACAPTR, LPPACA_DTLIDX and PACA_DTL_RIDX are not used anymore
by ASM code.


Reviewed-by: Nicholas Piggin 

Also I think SIGSEGV, NMI_MASK, THREAD_DBCR0, KUAP?, TI_FLAGS,
TI_PREEMPT, [ID]CACHEL1*, STACK_REGS_KUAP, EXC_LVL_SIZE, KVM_NEED_FLUSH,
KVM_FWNMI, VCPU_DEC, VCPU_SPMC, HSTATE_XICS_PHYS, HSTATE_SAVED_XIRR,
PPC_DBELL_MSGTYPE I think. While we're cleaning it up.


Yes, thanks for checking.

I think we can safely remove KUAP.

But we can't remove EXC_LVL_SIZE, it is used in kernel/head_booke.h which is probably included in 
head_44x.S and head_fsl_booke.S


Christophe

Re: [PATCH v3] powerpc/64: Option to use ELFv2 ABI for big-endian kernels

Excerpts from Michal Suchánek's message of May 4, 2021 12:38 am:
> On Mon, May 03, 2021 at 01:37:57PM +0200, Andreas Schwab wrote:
>> Should this add a tag to the module vermagic?

Good question.

> 
> Would the modues link even if the vermagic was not changed?
> 
> I suppose something like this might do it.

Yeah I don't know how robust the loader would be to a mismatch. We could 
add this patch.

Thanks,
Nick

> 
> Thanks
> 
> Michal
> 
> diff --git a/arch/powerpc/include/asm/vermagic.h 
> b/arch/powerpc/include/asm/vermagic.h
> index b054a8576e5d..3fdaacd7a743 100644
> --- a/arch/powerpc/include/asm/vermagic.h
> +++ b/arch/powerpc/include/asm/vermagic.h
> @@ -14,7 +14,14 @@
>  #define MODULE_ARCH_VERMAGIC_RELOCATABLE ""
>  #endif
>  
> +
> +#ifdef CONFIG_PPC64_BUILD_BIG_ENDIAN_ELF_V2_ABI
> +#define MODULE_ARCH_VERMAGIC_ELF_V2_ABI  "abi-elfv2 "
> +#else
> +#define MODULE_ARCH_VERMAGIC_ELF_V2_ABI  ""
> +#endif
> +
>  #define MODULE_ARCH_VERMAGIC \
> - MODULE_ARCH_VERMAGIC_FTRACE MODULE_ARCH_VERMAGIC_RELOCATABLE
> + MODULE_ARCH_VERMAGIC_FTRACE MODULE_ARCH_VERMAGIC_RELOCATABLE 
> MODULE_ARCH_VERMAGIC_ELF_V2_ABI
>  
>  #endif /* _ASM_VERMAGIC_H */
>

Re: [PATCH 4/4] powerpc/pseries: warn if recursing into the hcall tracing code

2021-05-04 Thread Naveen N. Rao


Nicholas Piggin wrote:

Excerpts from Naveen N. Rao's message of April 27, 2021 11:59 pm:

Nicholas Piggin wrote:

+ *
+ * H_CONFER from spin locks must be treated separately though and use _notrace
+ * plpar_hcall variants, see yield_to_preempted().
  */
 static DEFINE_PER_CPU(unsigned int, hcall_trace_depth);

@@ -1843,7 +1846,7 @@ notrace void __trace_hcall_entry(unsigned long opcode, 
unsigned long *args)

depth = this_cpu_ptr(_trace_depth);

-   if (*depth)
+   if (WARN_ON_ONCE(*depth))
goto out;


I don't think this will be helpful. The hcall trace depth tracking is 
for the tracepoint and I suspect that this warning will be triggered 
quite easily. Since we have recursion protection, I don't think we 
should warn here.


What would trigger recursion?


The trace code that this protects: trace_hcall_entry(). The tracing code 
itself can end up doing a hcall as we see in the first patch in this 
series:

 plpar_hcall_norets_trace+0x34/0x8c (unreliable)
 __pv_queued_spin_lock_slowpath+0x684/0x710
 trace_clock_global+0x148/0x150
 ring_buffer_lock_reserve+0x12c/0x630
 trace_event_buffer_lock_reserve+0x80/0x220
 trace_event_buffer_reserve+0x7c/0xd0
 trace_event_raw_event_hcall_entry+0x68/0x150
 __trace_hcall_entry+0x160/0x180


There is also a comment aroung hcall_trace_depth that mentions this:

 /*
  * Since the tracing code might execute hcalls we need to guard against
  * recursion. One example of this are spinlocks calling H_YIELD on
  * shared processor partitions.
  */


Thanks,
Naveen

Re: [PATCH 2/2] powerpc/paca: Remove mm_ctx_id and mm_ctx_slb_addr_limit

Excerpts from Christophe Leroy's message of May 4, 2021 2:46 am:
> mm_ctx_id and mm_ctx_slb_addr_limit are not used anymore.
> 
> Remove them.
> 
> Signed-off-by: Christophe Leroy 

Reviewed-by: Nicholas Piggin 

> ---
>  arch/powerpc/include/asm/paca.h | 2 --
>  arch/powerpc/kernel/paca.c  | 2 --
>  2 files changed, 4 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
> index ec18ac818e3a..ecc8d792a431 100644
> --- a/arch/powerpc/include/asm/paca.h
> +++ b/arch/powerpc/include/asm/paca.h
> @@ -149,11 +149,9 @@ struct paca_struct {
>  #endif /* CONFIG_PPC_BOOK3E */
>  
>  #ifdef CONFIG_PPC_BOOK3S
> - mm_context_id_t mm_ctx_id;
>  #ifdef CONFIG_PPC_MM_SLICES
>   unsigned char mm_ctx_low_slices_psize[BITS_PER_LONG / BITS_PER_BYTE];
>   unsigned char mm_ctx_high_slices_psize[SLICE_ARRAY_SIZE];
> - unsigned long mm_ctx_slb_addr_limit;
>  #else
>   u16 mm_ctx_user_psize;
>   u16 mm_ctx_sllp;
> diff --git a/arch/powerpc/kernel/paca.c b/arch/powerpc/kernel/paca.c
> index 7f5aae3c387d..9bd30cac852b 100644
> --- a/arch/powerpc/kernel/paca.c
> +++ b/arch/powerpc/kernel/paca.c
> @@ -346,10 +346,8 @@ void copy_mm_to_paca(struct mm_struct *mm)
>  #ifdef CONFIG_PPC_BOOK3S
>   mm_context_t *context = >context;
>  
> - get_paca()->mm_ctx_id = context->id;
>  #ifdef CONFIG_PPC_MM_SLICES
>   VM_BUG_ON(!mm_ctx_slb_addr_limit(context));
> - get_paca()->mm_ctx_slb_addr_limit = mm_ctx_slb_addr_limit(context);
>   memcpy(_paca()->mm_ctx_low_slices_psize, mm_ctx_low_slices(context),
>  LOW_SLICE_ARRAY_SZ);
>   memcpy(_paca()->mm_ctx_high_slices_psize, 
> mm_ctx_high_slices(context),
> -- 
> 2.25.0
> 
>

Re: [PATCH 1/2] powerpc/asm-offset: Remove unused items related to paca

Excerpts from Christophe Leroy's message of May 4, 2021 2:46 am:
> PACA_SIZE, PACACONTEXTID, PACALOWSLICESPSIZE, PACAHIGHSLICEPSIZE,
> PACA_SLB_ADDR_LIMIT, MMUPSIZEDEFSIZE, PACASLBCACHE, PACASLBCACHEPTR,
> PACASTABRR, PACAVMALLOCSLLP, MMUPSIZESLLP, PACACONTEXTSLLP,
> PACALPPACAPTR, LPPACA_DTLIDX and PACA_DTL_RIDX are not used anymore
> by ASM code.

Reviewed-by: Nicholas Piggin 

Also I think SIGSEGV, NMI_MASK, THREAD_DBCR0, KUAP?, TI_FLAGS,
TI_PREEMPT, [ID]CACHEL1*, STACK_REGS_KUAP, EXC_LVL_SIZE, KVM_NEED_FLUSH, 
KVM_FWNMI, VCPU_DEC, VCPU_SPMC, HSTATE_XICS_PHYS, HSTATE_SAVED_XIRR,
PPC_DBELL_MSGTYPE I think. While we're cleaning it up.

> 
> Remove them.
> 
> Signed-off-by: Christophe Leroy 
> ---
>  arch/powerpc/kernel/asm-offsets.c | 24 
>  1 file changed, 24 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/asm-offsets.c 
> b/arch/powerpc/kernel/asm-offsets.c
> index 28af4efb4587..419ab4a89114 100644
> --- a/arch/powerpc/kernel/asm-offsets.c
> +++ b/arch/powerpc/kernel/asm-offsets.c
> @@ -197,7 +197,6 @@ int main(void)
>   OFFSET(ICACHEL1LOGBLOCKSIZE, ppc64_caches, l1i.log_block_size);
>   OFFSET(ICACHEL1BLOCKSPERPAGE, ppc64_caches, l1i.blocks_per_page);
>   /* paca */
> - DEFINE(PACA_SIZE, sizeof(struct paca_struct));
>   OFFSET(PACAPACAINDEX, paca_struct, paca_index);
>   OFFSET(PACAPROCSTART, paca_struct, cpu_start);
>   OFFSET(PACAKSAVE, paca_struct, kstack);
> @@ -212,15 +211,6 @@ int main(void)
>   OFFSET(PACAIRQSOFTMASK, paca_struct, irq_soft_mask);
>   OFFSET(PACAIRQHAPPENED, paca_struct, irq_happened);
>   OFFSET(PACA_FTRACE_ENABLED, paca_struct, ftrace_enabled);
> -#ifdef CONFIG_PPC_BOOK3S
> - OFFSET(PACACONTEXTID, paca_struct, mm_ctx_id);
> -#ifdef CONFIG_PPC_MM_SLICES
> - OFFSET(PACALOWSLICESPSIZE, paca_struct, mm_ctx_low_slices_psize);
> - OFFSET(PACAHIGHSLICEPSIZE, paca_struct, mm_ctx_high_slices_psize);
> - OFFSET(PACA_SLB_ADDR_LIMIT, paca_struct, mm_ctx_slb_addr_limit);
> - DEFINE(MMUPSIZEDEFSIZE, sizeof(struct mmu_psize_def));
> -#endif /* CONFIG_PPC_MM_SLICES */
> -#endif
>  
>  #ifdef CONFIG_PPC_BOOK3E
>   OFFSET(PACAPGD, paca_struct, pgd);
> @@ -241,21 +231,9 @@ int main(void)
>  #endif /* CONFIG_PPC_BOOK3E */
>  
>  #ifdef CONFIG_PPC_BOOK3S_64
> - OFFSET(PACASLBCACHE, paca_struct, slb_cache);
> - OFFSET(PACASLBCACHEPTR, paca_struct, slb_cache_ptr);
> - OFFSET(PACASTABRR, paca_struct, stab_rr);
> - OFFSET(PACAVMALLOCSLLP, paca_struct, vmalloc_sllp);
> -#ifdef CONFIG_PPC_MM_SLICES
> - OFFSET(MMUPSIZESLLP, mmu_psize_def, sllp);
> -#else
> - OFFSET(PACACONTEXTSLLP, paca_struct, mm_ctx_sllp);
> -#endif /* CONFIG_PPC_MM_SLICES */
>   OFFSET(PACA_EXGEN, paca_struct, exgen);
>   OFFSET(PACA_EXMC, paca_struct, exmc);
>   OFFSET(PACA_EXNMI, paca_struct, exnmi);
> -#ifdef CONFIG_PPC_PSERIES
> - OFFSET(PACALPPACAPTR, paca_struct, lppaca_ptr);
> -#endif
>   OFFSET(PACA_SLBSHADOWPTR, paca_struct, slb_shadow_ptr);
>   OFFSET(SLBSHADOW_STACKVSID, slb_shadow, save_area[SLB_NUM_BOLTED - 
> 1].vsid);
>   OFFSET(SLBSHADOW_STACKESID, slb_shadow, save_area[SLB_NUM_BOLTED - 
> 1].esid);
> @@ -264,9 +242,7 @@ int main(void)
>  #ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
>   OFFSET(PACA_PMCINUSE, paca_struct, pmcregs_in_use);
>  #endif
> - OFFSET(LPPACA_DTLIDX, lppaca, dtl_idx);
>   OFFSET(LPPACA_YIELDCOUNT, lppaca, yield_count);
> - OFFSET(PACA_DTL_RIDX, paca_struct, dtl_ridx);
>  #endif /* CONFIG_PPC_BOOK3S_64 */
>   OFFSET(PACAEMERGSP, paca_struct, emergency_sp);
>  #ifdef CONFIG_PPC_BOOK3S_64
> -- 
> 2.25.0
> 
>

Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1


Am 04.05.21 um 11:49 schrieb Christophe Leroy:



Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :

Am 04.05.21 um 11:11 schrieb Christophe Leroy:



Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :

Am 04.05.21 um 10:58 schrieb Christophe Leroy:



Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :

On 04 May 2021 at 09:47am, Christophe Leroy wrote:

Hi

Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :

Hi Christophe,

Thanks for your answer but I think I don't know how it works 
with the cherry-pick.


$ git bisect start


As you suspect the problem to be specific to powerpc, I can do

git bisect start -- arch/powerpc



$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c


You said that powerpc-5.13-1 is bad so you can narrow the search 
I think:


git bisect bad powerpc-5.13-1
git bisect good 887f3ceb51cd3~

I tried it but without any success.

git bisect bad powerpc-5.13-1

Output:
fatal: Needed a single revision
Bad rev input: powerpc-5.13-1


I don't understand, on my side it works. Maybe a difference 
between your version of git and mine.


In that case, just use the SHA corresponding to the merge:

git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

Christophe

Do you use a BookE machine?


No I don't unfortunately, and I have tried booting in QEMU a kernel 
built with your config, but it freezes before any output.

You can use my kernels and distributions.



Ok, I'll see if I can do something with them.

In the meantime, have you been able to bisect ?

Thanks
Christophe

I am bisecting currently.

$ git bisect start -- arch/powerpc
$ git bisect good 887f3ceb51cd3~
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1





Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :

Am 04.05.21 um 11:11 schrieb Christophe Leroy:



Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :

Am 04.05.21 um 10:58 schrieb Christophe Leroy:



Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :

On 04 May 2021 at 09:47am, Christophe Leroy wrote:

Hi

Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :

Hi Christophe,

Thanks for your answer but I think I don't know how it works with the 
cherry-pick.

$ git bisect start


As you suspect the problem to be specific to powerpc, I can do

git bisect start -- arch/powerpc



$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c


You said that powerpc-5.13-1 is bad so you can narrow the search I think:

git bisect bad powerpc-5.13-1
git bisect good 887f3ceb51cd3~

I tried it but without any success.

git bisect bad powerpc-5.13-1

Output:
fatal: Needed a single revision
Bad rev input: powerpc-5.13-1


I don't understand, on my side it works. Maybe a difference between your 
version of git and mine.

In that case, just use the SHA corresponding to the merge:

git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

Christophe

Do you use a BookE machine?


No I don't unfortunately, and I have tried booting in QEMU a kernel built with your config, but it 
freezes before any output.

You can use my kernels and distributions.



Ok, I'll see if I can do something with them.

In the meantime, have you been able to bisect ?

Thanks
Christophe

Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1


Am 04.05.21 um 11:11 schrieb Christophe Leroy:



Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :

Am 04.05.21 um 10:58 schrieb Christophe Leroy:



Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :

On 04 May 2021 at 09:47am, Christophe Leroy wrote:

Hi

Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :

Hi Christophe,

Thanks for your answer but I think I don't know how it works with 
the cherry-pick.


$ git bisect start


As you suspect the problem to be specific to powerpc, I can do

git bisect start -- arch/powerpc



$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c


You said that powerpc-5.13-1 is bad so you can narrow the search I 
think:


git bisect bad powerpc-5.13-1
git bisect good 887f3ceb51cd3~

I tried it but without any success.

git bisect bad powerpc-5.13-1

Output:
fatal: Needed a single revision
Bad rev input: powerpc-5.13-1


I don't understand, on my side it works. Maybe a difference between 
your version of git and mine.


In that case, just use the SHA corresponding to the merge:

git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

Christophe

Do you use a BookE machine?


No I don't unfortunately, and I have tried booting in QEMU a kernel 
built with your config, but it freezes before any output.

You can use my kernels and distributions.

Download Fedora 28 PPC64: http://www.xenosoft.de/fedora28-2.img.tar.gz
Download size: 4.1 GB
MD5 checksum: 1784ca69651531522161498720a89414

Default username and password:
Username: amigaone
Password: amigaone
Root Password: amigaone

You can start the MATE desktop with "startx".

Download MintPPC (Debian Sid) PPC32: 
http://www.xenosoft.de/MintPPC32-X5000.tar.gz

MD5 checksum: b31c1c1ca1fcf5d4cdf110c4bce11654

The password for both 'root' and 'mintppc' is 'mintppc'.

Download kernel 5.12.0 for the AmigaOne X5000 and for the virtual e5500 
QEMU machine without the bad commit: 
http://www.xenosoft.de/linux-image-5.12-X1000_X5000.tar.gz
Download git kernel for the AmigaOne X5000 and for the virtual e5500 
QEMU machine with the bad commit: 
http://www.xenosoft.de/linux-image-5.13-alpha3-X1000_X5000.tar.gz


QEMU command with KVM on the X5000: qemu-system-ppc64 -M ppce500 -cpu 
e5500 -enable-kvm -m 1024 -kernel uImage -drive 
format=raw,file=MintPPC32-X5000.img,index=0,if=virtio -netdev 
user,id=mynet0 -device e1000,netdev=mynet0 -append "rw root=/dev/vda" 
-device virtio-vga -device virtio-mouse-pci -device virtio-keyboard-pci 
-device pci-ohci,id=newusb -device usb-audio,bus=newusb.0 -smp 4


QEMU command for Fedora 28 without KVM and with VNC connect: 
qemu-system-ppc64 -M ppce500 -cpu e5500 -m 1024 -kernel uImage -drive 
format=raw,file=fedora28-2.img,index=0,if=virtio -netdev user,id=mynet0 
-device virtio-net-pci,netdev=mynet0 -append "rw root=/dev/vda" -device 
virtio-vga -usb -device usb-ehci,id=ehci -device usb-tablet -device 
virtio-keyboard-pci -smp 4 -vnc :1


QEMU command for MintPPC without KVM and with VNC connect: 
qemu-system-ppc64 -M ppce500 -cpu e5500 -m 1024 -kernel uImage -drive 
format=raw,file=MintPPC32-X5000.img,index=0,if=virtio -netdev 
user,id=mynet0 -device virtio-net-pci,netdev=mynet0 -append "rw 
root=/dev/vda" -device virtio-vga -usb -device usb-ehci,id=ehci -device 
usb-tablet -device virtio-keyboard-pci -smp 4 -vnc :1

Re: [PATCH] Raise the minimum GCC version to 5.2

2021-05-04 Thread Michal Suchánek

On Tue, May 04, 2021 at 10:38:32AM +0200, Miguel Ojeda wrote:
> On Tue, May 4, 2021 at 9:57 AM Ben Dooks  wrote:
> >
> > Some of us are a bit stuck as either customer refuses to upgrade
> > their build infrastructure or has paid for some old but safety
> > blessed version of gcc. These often lag years behind the recent
> > gcc releases :(
> 
> In those scenarios, why do you need to build mainline? Aren't your
> customers using longterm or frozen kernels? If they are paying for
> certified GCC images, aren't they already paying for supported kernel
> images from some vendor too?
> 
> I understand where you are coming from -- I have also dealt with
> projects/machines running ancient, unsupported software/toolchains for
> various reasons; but nobody expected upstream (and in particular the
> mainline kernel source) to support them. In the cases I experienced,
> those use cases require not touching anything at all, and when the
> time came of doing so, everything would be updated at once,
> re-certified/validated as needed and frozen again.

Except it makes answering the question "Is this bug we see on this
ancient system still present in upstream?" needlessly more difficult to
answer.

Sure, throwing out old compiler versions that are known to cause
problems makes sense. Updating to latest just because much less so.

One of the selling point of C in general and gcc in particular is
stability. If we need the latest compiler we can as well rewrite the
kernel in Rust which has a required update cycle of a few months.

Because some mainline kernel features rely on bleeding edge tools I end
up building mainline with current tools anyway but if you do not need
BTF or whatever other latest gimmick older toolchains should do.

Thanks

Michal

[PATCH v4] pseries/drmem: update LMBs after LPM

2021-05-04 Thread Laurent Dufour

After a LPM, the device tree node ibm,dynamic-reconfiguration-memory may be
updated by the hypervisor in the case the NUMA topology of the LPAR's
memory is updated.

This is caught by the kernel, but the memory's node is updated because
there is no way to move a memory block between nodes.

If later a memory block is added or removed, drmem_update_dt() is called
and it is overwriting the DT node to match the added or removed LMB. But
the LMB's associativity node has not been updated after the DT node update
and thus the node is overwritten by the Linux's topology instead of the
hypervisor one.

Introduce a hook called when the ibm,dynamic-reconfiguration-memory node is
updated to force an update of the LMB's associativity. However, ignore the
call to that hook when the update has been triggered by drmem_update_dt().
Because, in that case, the LMB tree has been used to set the DT property
and thus it doesn't need to be updated back. Since drmem_update_dt() is
called under the protection of the device_hotplug_lock and the hook is
called in the same context, use a simple boolean variable to detect that
call.

Cc: Aneesh Kumar K.V 
Cc: Tyrel Datwyler 
Signed-off-by: Laurent Dufour 
---

V4:
 - Prevent the LMB to be updated back in the case the request came from the
 LMB tree's update.
V3:
 - Check rd->dn->name instead of rd->dn->full_name
V2:
 - Take Tyrel's idea to rely on OF_RECONFIG_UPDATE_PROPERTY instead of
 introducing a new hook mechanism.
---
 arch/powerpc/include/asm/drmem.h  |  1 +
 arch/powerpc/mm/drmem.c   | 46 +++
 .../platforms/pseries/hotplug-memory.c|  4 ++
 3 files changed, 51 insertions(+)

diff --git a/arch/powerpc/include/asm/drmem.h b/arch/powerpc/include/asm/drmem.h
index bf2402fed3e0..4265d5e95c2c 100644
--- a/arch/powerpc/include/asm/drmem.h
+++ b/arch/powerpc/include/asm/drmem.h
@@ -111,6 +111,7 @@ int drmem_update_dt(void);
 int __init
 walk_drmem_lmbs_early(unsigned long node, void *data,
  int (*func)(struct drmem_lmb *, const __be32 **, void *));
+void drmem_update_lmbs(struct property *prop);
 #endif
 
 static inline void invalidate_lmb_associativity_index(struct drmem_lmb *lmb)
diff --git a/arch/powerpc/mm/drmem.c b/arch/powerpc/mm/drmem.c
index 9af3832c9d8d..22197b18d85e 100644
--- a/arch/powerpc/mm/drmem.c
+++ b/arch/powerpc/mm/drmem.c
@@ -18,6 +18,7 @@ static int n_root_addr_cells, n_root_size_cells;
 
 static struct drmem_lmb_info __drmem_info;
 struct drmem_lmb_info *drmem_info = &__drmem_info;
+static bool in_drmem_update;
 
 u64 drmem_lmb_memory_max(void)
 {
@@ -178,6 +179,11 @@ int drmem_update_dt(void)
if (!memory)
return -1;
 
+   /*
+* Set in_drmem_update to prevent the notifier callback to process the
+* DT property back since the change is coming from the LMB tree.
+*/
+   in_drmem_update = true;
prop = of_find_property(memory, "ibm,dynamic-memory", NULL);
if (prop) {
rc = drmem_update_dt_v1(memory, prop);
@@ -186,6 +192,7 @@ int drmem_update_dt(void)
if (prop)
rc = drmem_update_dt_v2(memory, prop);
}
+   in_drmem_update = false;
 
of_node_put(memory);
return rc;
@@ -307,6 +314,45 @@ int __init walk_drmem_lmbs_early(unsigned long node, void 
*data,
return ret;
 }
 
+/*
+ * Update the LMB associativity index.
+ */
+static int update_lmb(struct drmem_lmb *updated_lmb,
+ __maybe_unused const __be32 **usm,
+ __maybe_unused void *data)
+{
+   struct drmem_lmb *lmb;
+
+   for_each_drmem_lmb(lmb) {
+   if (lmb->drc_index != updated_lmb->drc_index)
+   continue;
+
+   lmb->aa_index = updated_lmb->aa_index;
+   break;
+   }
+   return 0;
+}
+
+/*
+ * Update the LMB associativity index.
+ *
+ * This needs to be called when the hypervisor is updating the
+ * dynamic-reconfiguration-memory node property.
+ */
+void drmem_update_lmbs(struct property *prop)
+{
+   /*
+* Don't update the LMBs if triggered by the update done in
+* drmem_update_dt(), the LMB values have been used to the update the DT
+* property in that case.
+*/
+   if (in_drmem_update)
+   return;
+   if (!strcmp(prop->name, "ibm,dynamic-memory"))
+   __walk_drmem_v1_lmbs(prop->value, NULL, NULL, update_lmb);
+   else if (!strcmp(prop->name, "ibm,dynamic-memory-v2"))
+   __walk_drmem_v2_lmbs(prop->value, NULL, NULL, update_lmb);
+}
 #endif
 
 static int init_drmem_lmb_size(struct device_node *dn)
diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c 
b/arch/powerpc/platforms/pseries/hotplug-memory.c
index 8377f1f7c78e..672ffbee2e78 100644
--- a/arch/powerpc/platforms/pseries/hotplug-memory.c
+++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
@@ -949,6 +949,10 @@ static int

Re: [PATCH 4/4] powerpc/powernv: Remove POWER9 PVR version check for entry and uaccess flushes

Excerpts from Joel Stanley's message of May 4, 2021 10:51 am:
> On Mon, 3 May 2021 at 13:04, Nicholas Piggin  wrote:
>>
>> These aren't necessarily POWER9 only, and it's not to say some new
>> vulnerability may not get discovered on other processors for which
>> we would like the flexibility of having the workaround enabled by
>> firmware.
>>
>> Remove the restriction that they only apply to POWER9.
> 
> I was wondering how these worked which led me to reviewing your patch.
> From what I could see, these are enabled by default (SEC_FTR_DEFAULT
> in arch/powerpc/include/asm/security_features.h), so unless all
> non-POWER9 machines have set the "please don't" bit in their firmware
> this patch will enable the feature for those machines. Is that what
> you wanted?

Yes. POWER7/8 should be affected (it's similar mechanism that requires
the meltdown RFI flush, which those processors need).

POWER10 we haven't released a bare metal firmware with the right bits
yet. Not urgent at the moment but wouldn't hurt to specify them and
add the Linux code for them.

Thanks,
Nick

> 
>>
>> Signed-off-by: Nicholas Piggin 
>> ---
>>  arch/powerpc/platforms/powernv/setup.c | 9 -
>>  1 file changed, 9 deletions(-)
>>
>> diff --git a/arch/powerpc/platforms/powernv/setup.c 
>> b/arch/powerpc/platforms/powernv/setup.c
>> index a8db3f153063..6ec67223f8c7 100644
>> --- a/arch/powerpc/platforms/powernv/setup.c
>> +++ b/arch/powerpc/platforms/powernv/setup.c
>> @@ -122,15 +122,6 @@ static void pnv_setup_security_mitigations(void)
>> type = L1D_FLUSH_ORI;
>> }
>>
>> -   /*
>> -* If we are non-Power9 bare metal, we don't need to flush on kernel
>> -* entry or after user access: they fix a P9 specific vulnerability.
>> -*/
>> -   if (!pvr_version_is(PVR_POWER9)) {
>> -   security_ftr_clear(SEC_FTR_L1D_FLUSH_ENTRY);
>> -   security_ftr_clear(SEC_FTR_L1D_FLUSH_UACCESS);
>> -   }
>> -
>> enable = security_ftr_enabled(SEC_FTR_FAVOUR_SECURITY) && \
>>  (security_ftr_enabled(SEC_FTR_L1D_FLUSH_PR)   || \
>>   security_ftr_enabled(SEC_FTR_L1D_FLUSH_HV));
>> --
>> 2.23.0
>>
>

Re: [PATCH v2] powerpc/64: BE option to use ELFv2 ABI for big endian kernels

Excerpts from Michal Suchánek's message of May 4, 2021 6:17 am:
> On Mon, May 03, 2021 at 11:34:25AM +0200, Michal Suchánek wrote:
>> On Mon, May 03, 2021 at 09:11:16AM +0200, Michal Suchánek wrote:
>> > On Mon, May 03, 2021 at 10:58:33AM +1000, Nicholas Piggin wrote:
>> > > Excerpts from Michal Suchánek's message of May 3, 2021 2:57 am:
>> > > > On Tue, Apr 28, 2020 at 09:25:17PM +1000, Nicholas Piggin wrote:
>> > > >> Provide an option to use ELFv2 ABI for big endian builds. This works 
>> > > >> on
>> > > >> GCC and clang (since 2014). It is less well tested and supported by 
>> > > >> the
>> > > >> GNU toolchain, but it can give some useful advantages of the ELFv2 ABI
>> > > >> for BE (e.g., less stack usage). Some distros even build BE ELFv2
>> > > >> userspace.
>> > > > 
>> > > > Fixes BTFID failure on BE for me and the ELF ABIv2 kernel boots.
>> > > 
>> > > What's the BTFID failure? Anything we can do to fix it on the v1 ABI or 
>> > > at least make it depend on BUILD_ELF_V2?
>> > 
>> > Looks like symbols are prefixed with a dot in ABIv1 and BTFID tool is
>> > not aware of that. It can be disabled on ABIv1 easily.
>> > 
>> > Thanks
>> > 
>> > Michal
>> > 
>> > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
>> > index 678c13967580..e703c26e9b80 100644
>> > --- a/lib/Kconfig.debug
>> > +++ b/lib/Kconfig.debug
>> > @@ -305,6 +305,7 @@ config DEBUG_INFO_BTF
>> >bool "Generate BTF typeinfo"
>> >depends on !DEBUG_INFO_SPLIT && !DEBUG_INFO_REDUCED
>> >depends on !GCC_PLUGIN_RANDSTRUCT || COMPILE_TEST
>> > +  depends on !PPC64 || BUILD_ELF_V2
>> >help
>> >  Generate deduplicated BTF type information from DWARF debug info.
>> >  Turning this on expects presence of pahole tool, which will convert
>> > 
>> > > 
>> > > > 
>> > > > Tested-by: Michal Suchánek 
>> > > > 
>> > > > Also can we enable mprofile on BE now?
>> > > > 
>> > > > I don't see anything endian-specific in the mprofile code at a glance
>> > > > but don't have any idea how to test it.
>> > > 
>> > > AFAIK it's just a different ABI for the _mcount call so just running
>> > > some ftrace and ftrace with call graph should test it reasonably well.
>> 
>> It does not crash and burn but there are some regressions from LE to BE
>> on the ftrace kernel selftest:
>> 
>> --- ftraceLE.txt 2021-05-03 11:19:14.83000 +0200
>> +++ ftraceBE.txt 2021-05-03 11:27:24.77000 +0200
>> @@ -7,8 +7,8 @@
>>  [n] Change the ringbuffer size  [PASS]
>>  [n] Snapshot and tracing setting[PASS]
>>  [n] trace_pipe and trace_marker [PASS]
>> -[n] Test ftrace direct functions against tracers[UNRESOLVED]
>> -[n] Test ftrace direct functions against kprobes[UNRESOLVED]
>> +[n] Test ftrace direct functions against tracers[FAIL]
>> +[n] Test ftrace direct functions against kprobes[FAIL]
>>  [n] Generic dynamic event - add/remove kprobe events[PASS]
>>  [n] Generic dynamic event - add/remove synthetic events [PASS]
>>  [n] Generic dynamic event - selective clear (compatibility) [PASS]
>> @@ -16,10 +16,10 @@
>>  [n] event tracing - enable/disable with event level files   [PASS]
>>  [n] event tracing - restricts events based on pid notrace filtering [PASS]
>>  [n] event tracing - restricts events based on pid   [PASS]
>> -[n] event tracing - enable/disable with subsystem level files   [PASS]
>> +[n] event tracing - enable/disable with subsystem level files   [FAIL]
>>  [n] event tracing - enable/disable with top level files [PASS]
>> -[n] Test trace_printk from module   [UNRESOLVED]
>> -[n] ftrace - function graph filters with stack tracer   [PASS]
>> +[n] Test trace_printk from module   [FAIL]
>> +[n] ftrace - function graph filters with stack tracer   [FAIL]
>>  [n] ftrace - function graph filters [PASS]
>>  [n] ftrace - function trace with cpumask[PASS]
>>  [n] ftrace - test for function event triggers   [PASS]
>> @@ -27,7 +27,7 @@
>>  [n] ftrace - function pid notrace filters   [PASS]
>>  [n] ftrace - function pid filters   [PASS]
>>  [n] ftrace - stacktrace filter command  [PASS]
>> -[n] ftrace - function trace on module   [UNRESOLVED]
>> +[n] ftrace - function trace on module   [FAIL]
>>  [n] ftrace - function profiler with function tracing[PASS]
>>  [n] ftrace - function profiling [PASS]
>>  [n] ftrace - test reading of set_ftrace_filter  [PASS]
>> @@ -44,10 +44,10 @@
>>  [n] Kprobe event argument syntax[PASS]
>>  [n] Kprobe dynamic event with arguments [PASS]
>>  [n] Kprobes event arguments with types  [PASS]
>> -[n] Kprobe event user-memory access [UNSUPPORTED]
>> +[n] Kprobe event user-memory access [FAIL]
>>  [n] Kprobe event auto/manual naming [PASS]
>>  [n] Kprobe dynamic event with function tracer   [PASS]
>> -[n] Kprobe dynamic event - probing module   [UNRESOLVED]
>> +[n] Kprobe dynamic event - probing module   [FAIL]
>>  [n] Create/delete multiprobe on kprobe event[PASS]
>>  [n] Kprobe event parser error log

Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1





Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :

Am 04.05.21 um 10:58 schrieb Christophe Leroy:



Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :

On 04 May 2021 at 09:47am, Christophe Leroy wrote:

Hi

Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :

Hi Christophe,

Thanks for your answer but I think I don't know how it works with the 
cherry-pick.

$ git bisect start


As you suspect the problem to be specific to powerpc, I can do

git bisect start -- arch/powerpc



$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c


You said that powerpc-5.13-1 is bad so you can narrow the search I think:

git bisect bad powerpc-5.13-1
git bisect good 887f3ceb51cd3~

I tried it but without any success.

git bisect bad powerpc-5.13-1

Output:
fatal: Needed a single revision
Bad rev input: powerpc-5.13-1


I don't understand, on my side it works. Maybe a difference between your 
version of git and mine.

In that case, just use the SHA corresponding to the merge:

git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

Christophe

Do you use a BookE machine?


No I don't unfortunately, and I have tried booting in QEMU a kernel built with your config, but it 
freezes before any output.

Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1


Am 04.05.21 um 10:58 schrieb Christophe Leroy:



Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :

On 04 May 2021 at 09:47am, Christophe Leroy wrote:

Hi

Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :

Hi Christophe,

Thanks for your answer but I think I don't know how it works with 
the cherry-pick.


$ git bisect start


As you suspect the problem to be specific to powerpc, I can do

git bisect start -- arch/powerpc



$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c


You said that powerpc-5.13-1 is bad so you can narrow the search I 
think:


git bisect bad powerpc-5.13-1
git bisect good 887f3ceb51cd3~

I tried it but without any success.

git bisect bad powerpc-5.13-1

Output:
fatal: Needed a single revision
Bad rev input: powerpc-5.13-1


I don't understand, on my side it works. Maybe a difference between 
your version of git and mine.


In that case, just use the SHA corresponding to the merge:

git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

Christophe

Do you use a BookE machine?

Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1





Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :

On 04 May 2021 at 09:47am, Christophe Leroy wrote:

Hi

Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :

Hi Christophe,

Thanks for your answer but I think I don't know how it works with the 
cherry-pick.

$ git bisect start


As you suspect the problem to be specific to powerpc, I can do

git bisect start -- arch/powerpc



$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c


You said that powerpc-5.13-1 is bad so you can narrow the search I think:

git bisect bad powerpc-5.13-1
git bisect good 887f3ceb51cd3~

I tried it but without any success.

git bisect bad powerpc-5.13-1

Output:
fatal: Needed a single revision
Bad rev input: powerpc-5.13-1


I don't understand, on my side it works. Maybe a difference between your 
version of git and mine.

In that case, just use the SHA corresponding to the merge:

git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

Christophe

Re: [PATCH] Raise the minimum GCC version to 5.2

2021-05-04 Thread Ben Dooks


On 02/05/2021 03:41, Joe Perches wrote:

On Sat, 2021-05-01 at 17:52 +0200, Miguel Ojeda wrote:

On Sat, May 1, 2021 at 5:17 PM Masahiro Yamada  wrote:


More cleanups will be possible as follow-up patches, but this one must
be agreed and applied to the mainline first.


+1 This will allow me to remove the __has_attribute hack in
include/linux/compiler_attributes.h.


Why not raise the minimum gcc compiler version even higher?

https://gcc.gnu.org/releases.html


Some of us are a bit stuck as either customer refuses to upgrade
their build infrastructure or has paid for some old but safety
blessed version of gcc. These often lag years behind the recent
gcc releases :(


--
Ben Dooks   http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius

https://www.codethink.co.uk/privacy.html

Re: [PATCH] Raise the minimum GCC version to 5.2

2021-05-04 Thread Miguel Ojeda

On Tue, May 4, 2021 at 9:57 AM Ben Dooks  wrote:
>
> Some of us are a bit stuck as either customer refuses to upgrade
> their build infrastructure or has paid for some old but safety
> blessed version of gcc. These often lag years behind the recent
> gcc releases :(

In those scenarios, why do you need to build mainline? Aren't your
customers using longterm or frozen kernels? If they are paying for
certified GCC images, aren't they already paying for supported kernel
images from some vendor too?

I understand where you are coming from -- I have also dealt with
projects/machines running ancient, unsupported software/toolchains for
various reasons; but nobody expected upstream (and in particular the
mainline kernel source) to support them. In the cases I experienced,
those use cases require not touching anything at all, and when the
time came of doing so, everything would be updated at once,
re-certified/validated as needed and frozen again.

Cheers,
Miguel

Re: [PATCH v3 1/2] KVM: PPC: Book3S HV: Sanitise vcpu registers in nested path

Excerpts from Paul Mackerras's message of May 4, 2021 5:36 pm:
> On Tue, May 04, 2021 at 03:26:24PM +1000, Nicholas Piggin wrote:
>> Excerpts from Paul Mackerras's message of May 4, 2021 2:28 pm:
>> > On Sat, May 01, 2021 at 11:58:36AM +1000, Nicholas Piggin wrote:
>> >> Excerpts from Fabiano Rosas's message of April 16, 2021 9:09 am:
>> >> > As one of the arguments of the H_ENTER_NESTED hypercall, the nested
>> >> > hypervisor (L1) prepares a structure containing the values of various
>> >> > hypervisor-privileged registers with which it wants the nested guest
>> >> > (L2) to run. Since the nested HV runs in supervisor mode it needs the
>> >> > host to write to these registers.
>> >> > 
>> >> > To stop a nested HV manipulating this mechanism and using a nested
>> >> > guest as a proxy to access a facility that has been made unavailable
>> >> > to it, we have a routine that sanitises the values of the HV registers
>> >> > before copying them into the nested guest's vcpu struct.
>> >> > 
>> >> > However, when coming out of the guest the values are copied as they
>> >> > were back into L1 memory, which means that any sanitisation we did
>> >> > during guest entry will be exposed to L1 after H_ENTER_NESTED returns.
>> >> > 
>> >> > This patch alters this sanitisation to have effect on the vcpu->arch
>> >> > registers directly before entering and after exiting the guest,
>> >> > leaving the structure that is copied back into L1 unchanged (except
>> >> > when we really want L1 to access the value, e.g the Cause bits of
>> >> > HFSCR).
>> >> > 
>> >> > Signed-off-by: Fabiano Rosas 
>> >> > ---
>> >> >  arch/powerpc/kvm/book3s_hv_nested.c | 55 ++---
>> >> >  1 file changed, 34 insertions(+), 21 deletions(-)
>> >> > 
>> >> > diff --git a/arch/powerpc/kvm/book3s_hv_nested.c 
>> >> > b/arch/powerpc/kvm/book3s_hv_nested.c
>> >> > index 0cd0e7aad588..270552dd42c5 100644
>> >> > --- a/arch/powerpc/kvm/book3s_hv_nested.c
>> >> > +++ b/arch/powerpc/kvm/book3s_hv_nested.c
>> >> > @@ -102,8 +102,17 @@ static void save_hv_return_state(struct kvm_vcpu 
>> >> > *vcpu, int trap,
>> >> >  {
>> >> > struct kvmppc_vcore *vc = vcpu->arch.vcore;
>> >> >  
>> >> > +   /*
>> >> > +* When loading the hypervisor-privileged registers to run L2,
>> >> > +* we might have used bits from L1 state to restrict what the
>> >> > +* L2 state is allowed to be. Since L1 is not allowed to read
>> >> > +* the HV registers, do not include these modifications in the
>> >> > +* return state.
>> >> > +*/
>> >> > +   hr->hfscr = ((~HFSCR_INTR_CAUSE & hr->hfscr) |
>> >> > +(HFSCR_INTR_CAUSE & vcpu->arch.hfscr));
>> >> > +
>> >> > hr->dpdes = vc->dpdes;
>> >> > -   hr->hfscr = vcpu->arch.hfscr;
>> >> > hr->purr = vcpu->arch.purr;
>> >> > hr->spurr = vcpu->arch.spurr;
>> >> > hr->ic = vcpu->arch.ic;
>> >> 
>> >> Do we still have the problem here that hfac interrupts due to bits cleared
>> >> by the hfscr sanitisation would have the cause bits returned to the L1,
>> >> so in theory it could probe hfscr directly that way? I don't see a good
>> >> solution to this except either have the L0 intercept these faults and do
>> >> "something" transparent, or return error from H_ENTER_NESTED (which would
>> >> also allow trivial probing of the facilities).
>> > 
>> > It seems to me that there are various specific reasons why L0 would
>> > clear HFSCR bits, and if we think about the specific reasons, what we
>> > should do becomes clear.  (I say "L0" but in fact the same reasoning
>> > applies to any hypervisor that lets its guest do hypervisor-ish
>> > things.)
>> > 
>> > 1. Emulating a version of the architecture which doesn't have the
>> > feature in question - in that case the bit should appear to L1 as a
>> > reserved bit in HFSCR (i.e. always read 0), the associated facility
>> > code should never appear in the top 8 bits of any HFSCR value that L1
>> > sees, and any HFU interrupt received by L0 for the facility should be
>> > changed into an illegal instruction interrupt (or HEAI) forwarded to
>> > L1.  In this case the real HFSCR should always have the enable bit for
>> > the facility set to 0.
>> > 
>> > 2. Lazy save/restore of the state associated with a facility - in this
>> > case, while the system is in the "lazy" state (i.e. the state is not
>> > that of the currently running guest), the real HFSCR bit for the
>> > facility should be 0.  On an HFU interrupt for the facility, L0 looks
>> > at L1's HFSCR value: if it's 0, forward the HFU interrupt to L1; if
>> > it's 1, load up the facility state, set the facility's bit in HFSCR,
>> > and resume the guest.
>> > 
>> > 3. Emulating a facility in software - in this case, the real HFSCR
>> > bit for the facility would always be 0.  On an HFU interrupt, L0 reads
>> > the instruction and emulates it, then resumes the guest.
>> > 
>> > One thing this all makes clear is

Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1


On 04 May 2021 at 09:47am, Christophe Leroy wrote:

Hi

Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :

Hi Christophe,

Thanks for your answer but I think I don't know how it works with the 
cherry-pick.


$ git bisect start


As you suspect the problem to be specific to powerpc, I can do

git bisect start -- arch/powerpc



$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c


You said that powerpc-5.13-1 is bad so you can narrow the search I think:

git bisect bad powerpc-5.13-1
git bisect good 887f3ceb51cd3~

I tried it but without any success.

git bisect bad powerpc-5.13-1

Output:
fatal: Needed a single revision
Bad rev input: powerpc-5.13-1

Maybe we should look in the PowerPC updates directly. The CPUs of the 
AmigaOne X5000 and virtual e5500 QEMU machine belong to BookE cpu 
family. The AmigaOne X1000 isn't affected by this issue because the PA6T 
belongs to the Book3S cpu family. [1]


I found this in the PowerPC updates 5.13-1:  - Convert 64-bit BookE to 
do interrupt entry/exit in C.


Maybe we should look more in the modified BookE files:

arch/powerpc/kernel/head_booke.h [2]
arch/powerpc/kernel/head_fsl_booke.S [3]

Please check the BookE commits in the PowerPC updates 5.13-1. You don't 
need an AmigaOne X5000 for testing because the virtual e5500 QEMU 
machine is also affected.


Thanks,
Christian

[1] https://www.kernel.org/doc/Documentation/powerpc/cpu_families.txt
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/arch/powerpc/kernel/head_booke.h?id=c70a4be130de333ea079c59da41cc959712bb01c
[3] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/arch/powerpc/kernel/head_fsl_booke.S?id=c70a4be130de333ea079c59da41cc959712bb01c








Bisecting: 2462 revisions left to test after this (roughly 11 steps)
[47a6959fa331fe892a4fc3b48ca08e92045c6bda] netfilter: allow to turn 
off xtables compat layer


$ git cherry-pick 525642624783
error: could not apply 525642624783... powerpc/signal32: Fix 
erroneous SIGSEGV on RT signal return

hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add ' or 'git rm '
hint: and commit the result with 'git commit'

How can I fix this error?


This problably means that the step is at a commit which is prior to 
the first bad commit you identified at previous step. If you narrow 
the bisect as explained above, it shouldn't happen unless git decides 
it needs to descend a branch to a merge point. In that case just do 
'git cherry-pick --abort" and go without the fix.


Note that once you have cherry picked the fix and tested the result, 
you have to apply the result to HEAD~ (the commit before the 
cherry-pick).

- git bisect good HEAD~
- git bisect bad HEAD~

Christophe

Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1


Hi

Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :

Hi Christophe,

Thanks for your answer but I think I don't know how it works with the 
cherry-pick.

$ git bisect start


As you suspect the problem to be specific to powerpc, I can do

git bisect start -- arch/powerpc



$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c


You said that powerpc-5.13-1 is bad so you can narrow the search I think:

git bisect bad powerpc-5.13-1
git bisect good 887f3ceb51cd3~




Bisecting: 2462 revisions left to test after this (roughly 11 steps)
[47a6959fa331fe892a4fc3b48ca08e92045c6bda] netfilter: allow to turn off xtables 
compat layer

$ git cherry-pick 525642624783
error: could not apply 525642624783... powerpc/signal32: Fix erroneous SIGSEGV 
on RT signal return
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add ' or 'git rm '
hint: and commit the result with 'git commit'

How can I fix this error?


This problably means that the step is at a commit which is prior to the first bad commit you 
identified at previous step. If you narrow the bisect as explained above, it shouldn't happen unless 
git decides it needs to descend a branch to a merge point. In that case just do 'git cherry-pick 
--abort" and go without the fix.


Note that once you have cherry picked the fix and tested the result, you have to apply the result to 
HEAD~ (the commit before the cherry-pick).

- git bisect good HEAD~
- git bisect bad HEAD~

Christophe

[PATCH] powerpc/pmu: Make the generic compat PMU use the architected events

2021-05-04 Thread Paul Mackerras

This changes generic-compat-pmu.c so that it only uses architected
events defined in Power ISA v3.0B, rather than event encodings which,
while common to all the IBM Power Systems implementations, are
nevertheless implementation-specific rather than architected.  The
intention is that any CPU implementation designed to conform to Power
ISA v3.0B or later can use generic-compat-pmu.c.

In addition to the existing events for cycles and instructions, this
adds several other architected events, including alternative encodings
for some events.  In order to make it possible to measure cycles and
instructions at the same time as each other, we set the CC5-6RUN bit
in MMCR0, which makes PMC5 and PMC6 count instructions and cycles
regardless of the run bit, so their events are now PM_CYC and
PM_INST_CMPL rather than PM_RUN_CYC and PM_RUN_INST_CMPL (the latter
are still available via other event codes).

Note that POWER9 has an erratum where one architected event
(PM_FLOP_CMPL, floating-point operations completed, code 0x100f4) does
not work correctly.  Given that there is a specific PMU driver for P9
which will be used in preference to generic-compat-pmu.c, that is not
a real problem.

Signed-off-by: Paul Mackerras 
---
 arch/powerpc/perf/generic-compat-pmu.c | 170 +++--
 1 file changed, 134 insertions(+), 36 deletions(-)

diff --git a/arch/powerpc/perf/generic-compat-pmu.c 
b/arch/powerpc/perf/generic-compat-pmu.c
index eb8a6aaf4cc1..695975227e60 100644
--- a/arch/powerpc/perf/generic-compat-pmu.c
+++ b/arch/powerpc/perf/generic-compat-pmu.c
@@ -14,45 +14,119 @@
  *
  *2824201612 8 4   
  0
  * | - - - - | - - - - | - - - - | - - - - | - - - - | - - - - | - - - - | - - 
- - |
- * [ pmc ]   [unit ]   [ ]   m   [pmcxsel  
  ]
- * | |
- * | *- mark
- * |
- * |
- * *- combine
- *
- * Below uses IBM bit numbering.
- *
- * MMCR1[x:y] = unit(PMCxUNIT)
- * MMCR1[24]   = pmc1combine[0]
- * MMCR1[25]   = pmc1combine[1]
- * MMCR1[26]   = pmc2combine[0]
- * MMCR1[27]   = pmc2combine[1]
- * MMCR1[28]   = pmc3combine[0]
- * MMCR1[29]   = pmc3combine[1]
- * MMCR1[30]   = pmc4combine[0]
- * MMCR1[31]   = pmc4combine[1]
- *
+ * [ pmc ]   [pmcxsel  
  ]
  */
 
 /*
- * Some power9 event codes.
+ * Event codes defined in ISA v3.0B
  */
 #define EVENT(_name, _code)_name = _code,
 
 enum {
-EVENT(PM_CYC,  0x0001e)
-EVENT(PM_INST_CMPL,0x2)
+   /* Cycles, alternate code */
+   EVENT(PM_CYC_ALT,   0x100f0)
+   /* One or more instructions completed in a cycle */
+   EVENT(PM_CYC_INST_CMPL, 0x100f2)
+   /* Floating-point instruction completed */
+   EVENT(PM_FLOP_CMPL, 0x100f4)
+   /* Instruction ERAT/L1-TLB miss */
+   EVENT(PM_L1_ITLB_MISS,  0x100f6)
+   /* All instructions completed and none available */
+   EVENT(PM_NO_INST_AVAIL, 0x100f8)
+   /* A load-type instruction completed (ISA v3.0+) */
+   EVENT(PM_LD_CMPL,   0x100fc)
+   /* Instruction completed, alternate code (ISA v3.0+) */
+   EVENT(PM_INST_CMPL_ALT, 0x100fe)
+   /* A store-type instruction completed */
+   EVENT(PM_ST_CMPL,   0x200f0)
+   /* Instruction Dispatched */
+   EVENT(PM_INST_DISP, 0x200f2)
+   /* Run_cycles */
+   EVENT(PM_RUN_CYC,   0x200f4)
+   /* Data ERAT/L1-TLB miss/reload */
+   EVENT(PM_L1_DTLB_RELOAD,0x200f6)
+   /* Taken branch completed */
+   EVENT(PM_BR_TAKEN_CMPL, 0x200fa)
+   /* Demand iCache Miss */
+   EVENT(PM_L1_ICACHE_MISS,0x200fc)
+   /* L1 Dcache reload from memory */
+   EVENT(PM_L1_RELOAD_FROM_MEM,0x200fe)
+   /* L1 Dcache store miss */
+   EVENT(PM_ST_MISS_L1,0x300f0)
+   /* Alternate code for PM_INST_DISP */
+   EVENT(PM_INST_DISP_ALT, 0x300f2)
+   /* Branch direction or target mispredicted */
+   EVENT(PM_BR_MISPREDICT, 0x300f6)
+   /* Data TLB miss/reload */
+   EVENT(PM_DTLB_MISS, 0x300fc)
+   /* Demand LD - L3 Miss (not L2 hit and not L3 hit) */
+   EVENT(PM_DATA_FROM_L3MISS,  0x300fe)
+   /* L1 Dcache load miss */
+   EVENT(PM_LD_MISS_L1,0x400f0)
+   /* Cycle when instruction(s) dispatched */
+   EVENT(PM_CYC_INST_DISP,

Re: [PATCH v3 1/2] KVM: PPC: Book3S HV: Sanitise vcpu registers in nested path

2021-05-04 Thread Paul Mackerras

On Tue, May 04, 2021 at 03:26:24PM +1000, Nicholas Piggin wrote:
> Excerpts from Paul Mackerras's message of May 4, 2021 2:28 pm:
> > On Sat, May 01, 2021 at 11:58:36AM +1000, Nicholas Piggin wrote:
> >> Excerpts from Fabiano Rosas's message of April 16, 2021 9:09 am:
> >> > As one of the arguments of the H_ENTER_NESTED hypercall, the nested
> >> > hypervisor (L1) prepares a structure containing the values of various
> >> > hypervisor-privileged registers with which it wants the nested guest
> >> > (L2) to run. Since the nested HV runs in supervisor mode it needs the
> >> > host to write to these registers.
> >> > 
> >> > To stop a nested HV manipulating this mechanism and using a nested
> >> > guest as a proxy to access a facility that has been made unavailable
> >> > to it, we have a routine that sanitises the values of the HV registers
> >> > before copying them into the nested guest's vcpu struct.
> >> > 
> >> > However, when coming out of the guest the values are copied as they
> >> > were back into L1 memory, which means that any sanitisation we did
> >> > during guest entry will be exposed to L1 after H_ENTER_NESTED returns.
> >> > 
> >> > This patch alters this sanitisation to have effect on the vcpu->arch
> >> > registers directly before entering and after exiting the guest,
> >> > leaving the structure that is copied back into L1 unchanged (except
> >> > when we really want L1 to access the value, e.g the Cause bits of
> >> > HFSCR).
> >> > 
> >> > Signed-off-by: Fabiano Rosas 
> >> > ---
> >> >  arch/powerpc/kvm/book3s_hv_nested.c | 55 ++---
> >> >  1 file changed, 34 insertions(+), 21 deletions(-)
> >> > 
> >> > diff --git a/arch/powerpc/kvm/book3s_hv_nested.c 
> >> > b/arch/powerpc/kvm/book3s_hv_nested.c
> >> > index 0cd0e7aad588..270552dd42c5 100644
> >> > --- a/arch/powerpc/kvm/book3s_hv_nested.c
> >> > +++ b/arch/powerpc/kvm/book3s_hv_nested.c
> >> > @@ -102,8 +102,17 @@ static void save_hv_return_state(struct kvm_vcpu 
> >> > *vcpu, int trap,
> >> >  {
> >> >  struct kvmppc_vcore *vc = vcpu->arch.vcore;
> >> >  
> >> > +/*
> >> > + * When loading the hypervisor-privileged registers to run L2,
> >> > + * we might have used bits from L1 state to restrict what the
> >> > + * L2 state is allowed to be. Since L1 is not allowed to read
> >> > + * the HV registers, do not include these modifications in the
> >> > + * return state.
> >> > + */
> >> > +hr->hfscr = ((~HFSCR_INTR_CAUSE & hr->hfscr) |
> >> > + (HFSCR_INTR_CAUSE & vcpu->arch.hfscr));
> >> > +
> >> >  hr->dpdes = vc->dpdes;
> >> > -hr->hfscr = vcpu->arch.hfscr;
> >> >  hr->purr = vcpu->arch.purr;
> >> >  hr->spurr = vcpu->arch.spurr;
> >> >  hr->ic = vcpu->arch.ic;
> >> 
> >> Do we still have the problem here that hfac interrupts due to bits cleared
> >> by the hfscr sanitisation would have the cause bits returned to the L1,
> >> so in theory it could probe hfscr directly that way? I don't see a good
> >> solution to this except either have the L0 intercept these faults and do
> >> "something" transparent, or return error from H_ENTER_NESTED (which would
> >> also allow trivial probing of the facilities).
> > 
> > It seems to me that there are various specific reasons why L0 would
> > clear HFSCR bits, and if we think about the specific reasons, what we
> > should do becomes clear.  (I say "L0" but in fact the same reasoning
> > applies to any hypervisor that lets its guest do hypervisor-ish
> > things.)
> > 
> > 1. Emulating a version of the architecture which doesn't have the
> > feature in question - in that case the bit should appear to L1 as a
> > reserved bit in HFSCR (i.e. always read 0), the associated facility
> > code should never appear in the top 8 bits of any HFSCR value that L1
> > sees, and any HFU interrupt received by L0 for the facility should be
> > changed into an illegal instruction interrupt (or HEAI) forwarded to
> > L1.  In this case the real HFSCR should always have the enable bit for
> > the facility set to 0.
> > 
> > 2. Lazy save/restore of the state associated with a facility - in this
> > case, while the system is in the "lazy" state (i.e. the state is not
> > that of the currently running guest), the real HFSCR bit for the
> > facility should be 0.  On an HFU interrupt for the facility, L0 looks
> > at L1's HFSCR value: if it's 0, forward the HFU interrupt to L1; if
> > it's 1, load up the facility state, set the facility's bit in HFSCR,
> > and resume the guest.
> > 
> > 3. Emulating a facility in software - in this case, the real HFSCR
> > bit for the facility would always be 0.  On an HFU interrupt, L0 reads
> > the instruction and emulates it, then resumes the guest.
> > 
> > One thing this all makes clear is that the IC field of the "virtual"
> > HFSCR value seen by L1 should only ever be changed when L0 forwards a
> > HFU interrupt to L1.
> > 
>

Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1


Hi Christophe,

Thanks for your answer but I think I don't know how it works with the 
cherry-pick.


$ git bisect start
$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

Bisecting: 2462 revisions left to test after this (roughly 11 steps)
[47a6959fa331fe892a4fc3b48ca08e92045c6bda] netfilter: allow to turn off 
xtables compat layer


$ git cherry-pick 525642624783
error: could not apply 525642624783... powerpc/signal32: Fix erroneous 
SIGSEGV on RT signal return

hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add ' or 'git rm '
hint: and commit the result with 'git commit'

How can I fix this error?

Thanks,
Christian

On 04 May 2021 at 06:56 am, Christophe Leroy wrote:



Le 04/05/2021 à 00:25, Christian Zigotzky a écrit :

Hello,

Xorg always restarts again and again after the the PowerPC updates 
5.13-1 [1] on my FSL P5040 Cyrus+ board (A-EON AmigaOne X5000) [2]. 
Xorg doesn't start anymore in a virtual e5500 QEMU machine [3].


I bisected today [4].

Result: powerpc/signal32: Convert do_setcontext[_tm]() to user access 
block (887f3ceb51cd34109ac17bfc98695162e299e657) [5] is the first bad 
commit.


Please find attached the kernel config.

Please check the first bad commit.


I'm not sure you can conclude anything here. There is a problem in 
that commit, but it is fixed by 525642624783 ("powerpc/signal32: Fix 
erroneous SIGSEGV on RT signal return") which is the last commit of 
powerpc-5.13-1.


So any bisect from there will for sure point to 887f3ceb51cd 
("powerpc/signal32: Convert do_setcontext[_tm]() to user access 
block") but that's unconclusive. If the problem is still there at the 
HEAD of powerpc-5.13-1, the problem is likely somewhere else.


I think you need to do the bisect again with a cherry-pick of 
525642624783 at each step.


Thanks
Christophe




Thanks,
Christian

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c70a4be130de333ea079c59da41cc959712bb01c 


[2] http://wiki.amiga.org/index.php?title=X5000
[3] qemu-system-ppc64 -M ppce500 -cpu e5500 -m 1024 -kernel uImage 
-drive format=raw,file=fedora28-2.img,index=0,if=virtio -netdev 
user,id=mynet0 -device virtio-net-pci,netdev=mynet0 -append "rw 
root=/dev/vda" -device virtio-vga -usb -device usb-ehci,id=ehci 
-device usb-tablet -device virtio-keyboard-pci -smp 4 -vnc :1
[4] 
https://forum.hyperion-entertainment.com/viewtopic.php?p=53101#p53101
[5] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=887f3ceb51cd34109ac17bfc98695162e299e657

Re: [PATCH v3] pseries/drmem: update LMBs after LPM

2021-05-04 Thread Laurent Dufour


Le 03/05/2021 à 22:44, Tyrel Datwyler a écrit :

On 5/3/21 10:28 AM, Laurent Dufour wrote:

Le 01/05/2021 à 01:58, Tyrel Datwyler a écrit :

On 4/30/21 9:13 AM, Laurent Dufour wrote:

Le 29/04/2021 à 21:12, Tyrel Datwyler a écrit :

On 4/29/21 3:27 AM, Aneesh Kumar K.V wrote:

Laurent Dufour  writes:



Snip



As of today I don't have a problem with your patch. This was more of me pointing
out things that I think are currently wrong with our memory hotplug
implementation, and that we need to take a long hard look at it down the road.


I do agree, there is a lot of odd things there to address in this area.
If you're ok with that patch, do you mind to add a reviewed-by?



Can you send a v4 with the fix for the duplicate update included?


Of course !
I wrote it last week, but let in the to-be-sent list, my mistake.

Re: [PATCH] Raise the minimum GCC version to 5.2