Re: [PATCH] arch: pgtable: define MAX_POSSIBLE_PHYSMEM_BITS where needed
On Fri, Nov 13, 2020 at 03:59:32PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Stefan Agner reported a bug when using zsram on 32-bit Arm machines
> with RAM above the 4GB address boundary:
>
> Unable to handle kernel NULL pointer dereference at virtual address
> pgd = a27bd01c
> [] *pgd=236a0003, *pmd=1ffa64003
> Internal error: Oops: 207 [#1] SMP ARM
> Modules linked in: mdio_bcm_unimac(+) brcmfmac cfg80211 brcmutil
> raspberrypi_hwmon hci_uart crc32_arm_ce bcm2711_thermal phy_generic genet
> CPU: 0 PID: 123 Comm: mkfs.ext4 Not tainted 5.9.6 #1
> Hardware name: BCM2711
> PC is at zs_map_object+0x94/0x338
> LR is at zram_bvec_rw.constprop.0+0x330/0xa64
> pc : []lr : []psr: 6013
> sp : e376bbe0 ip : fp : c1e2921c
> r10: 0002 r9 : c1dda730 r8 :
> r7 : e8ff7a00 r6 : r5 : 02f9ffa0 r4 : e371
> r3 : 000fdffe r2 : c1e0ce80 r1 : ebf979a0 r0 :
> Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
> Control: 30c5383d Table: 235c2a80 DAC: fffd
> Process mkfs.ext4 (pid: 123, stack limit = 0x495a22e6)
> Stack: (0xe376bbe0 to 0xe376c000)
>
> As it turns out, zsram needs to know the maximum memory size, which
> is defined in MAX_PHYSMEM_BITS when CONFIG_SPARSEMEM is set, or in
> MAX_POSSIBLE_PHYSMEM_BITS on the x86 architecture.
>
> The same problem will be hit on all 32-bit architectures that have a
> physical address space larger than 4GB and happen to not enable sparsemem
> and include asm/sparsemem.h from asm/pgtable.h.
>
> After the initial discussion, I suggested just always defining
> MAX_POSSIBLE_PHYSMEM_BITS whenever CONFIG_PHYS_ADDR_T_64BIT is
> set, or provoking a build error otherwise. This addresses all
> configurations that can currently have this runtime bug, but
> leaves all other configurations unchanged.
>
> I looked up the possible number of bits in source code and
> datasheets, here is what I found:
>
> - on ARC, CONFIG_ARC_HAS_PAE40 controls whether 32 or 40 bits are used
> - on ARM, CONFIG_LPAE enables 40 bit addressing, without it we never
>support more than 32 bits, even though supersections in theory allow
>up to 40 bits as well.
> - on MIPS, some MIPS32r1 or later chips support 36 bits, and MIPS32r5
>XPA supports up to 60 bits in theory, but 40 bits are more than
>anyone will ever ship
> - On PowerPC, there are three different implementations of 36 bit
>addressing, but 32-bit is used without CONFIG_PTE_64BIT
> - On RISC-V, the normal page table format can support 34 bit
>addressing. There is no highmem support on RISC-V, so anything
>above 2GB is unused, but it might be useful to eventually support
>CONFIG_ZRAM for high pages.
>
> Fixes: 61989a80fb3a ("staging: zsmalloc: zsmalloc memory allocation library")
> Fixes: 02390b87a945 ("mm/zsmalloc: Prepare to variable MAX_PHYSMEM_BITS")
> Cc: Stefan Agner
> Cc: Mike Rapoport
> Cc: Kirill A. Shutemov
> Cc: Nitin Gupta
> Cc: Minchan Kim
> Cc: Vineet Gupta
> Cc: linux-snps-...@lists.infradead.org
> Cc: Russell King
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: Thomas Bogendoerfer
> Cc: linux-m...@vger.kernel.org
> Cc: Michael Ellerman
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: Paul Walmsley
> Cc: Palmer Dabbelt
> Cc: Albert Ou
> Cc: linux-ri...@lists.infradead.org
> Link:
> https://lore.kernel.org/linux-mm/bdfa44bf1c570b05d6c70898e2bbb0acf234ecdf.1604762181.git.ste...@agner.ch/
> Signed-off-by: Arnd Bergmann
Acked-by: Mike Rapoport
> ---
> If everyone is happy with this version, I would suggest merging this as
> a bugfix through my asm-generic tree for linux-5.10. I originally
> said I'd send individual patches for each architecture tree, but
> I now think this is easier and better documents what is going on.
> ---
> arch/arc/include/asm/pgtable.h | 2 ++
> arch/arm/include/asm/pgtable-2level.h| 2 ++
> arch/arm/include/asm/pgtable-3level.h| 2 ++
> arch/mips/include/asm/pgtable-32.h | 3 +++
> arch/powerpc/include/asm/book3s/32/pgtable.h | 2 ++
> arch/powerpc/include/asm/nohash/32/pgtable.h | 2 ++
> arch/riscv/include/asm/pgtable-32.h | 2 ++
> include/linux/pgtable.h | 13 +
> 8 files changed, 28 insertions(+)
>
> diff --git a/arch/arc/include/asm/pgtable.h b/arch/arc/include/asm/pgtable.h
> index f1ed17edb085..163641726a2b 100644
> --- a/arch/arc/include/asm/pgtable.h
> +++ b/arch/arc/include/asm/pgtable.h
> @@ -134,8 +134,10 @@
>
> #ifdef CONFIG_ARC_HAS_PAE40
> #define PTE_BITS_NON_RWX_IN_PD1 (0xff | PAGE_MASK |
> _PAGE_CACHEABLE)
> +#define MAX_POSSIBLE_PHYSMEM_BITS 40
> #else
> #define PTE_BITS_NON_RWX_IN_PD1 (PAGE_MASK | _PAGE_CACHEABLE)
> +#define MAX_POSSIBLE_PHYSMEM_BITS 32
> #endif
>
> /**
Re: [PATCH v4] PCI: Unify ECAM constants in native PCI Express drivers
On 20-10-04 19:53:06, Florian Fainelli wrote: Hi Florian, Sorry for taking a long time to get back to you. [...] > This appears to be correct, so: > > Acked-by: Florian Fainelli Thank you! > however, I would have defined a couple of additional helper macros and do: > > idx = PCIE_ECAM_BUS(bus->number) | PCIE_ECAM_DEV(devfn) | > PCIE_ECAM_FUN(devfn); > > for clarity. > [...] > For instance, adding these two: > > #define PCIE_ECAM_DEV(x) (((x) & 0x1f) << PCIE_ECAM_DEV_SHIFT) > #define PCIE_ECAM_FUN(x) (((x) & 0x7) << PCIE_ECAM_FUN_SHIFT) > > may be clearer for use in drivers like pcie-brcmstb.c that used to treat the > device function in terms of device and function (though it was called slot > there). Regarding the suggestion above - it has been like that initially, albeit Bjorn suggested that there is no need to reply on the macros that use PCI_SLOT() and PCI_FUNC() macros, see: https://lore.kernel.org/linux-pci/20200922232715.GA2238688@bjorn-Precision-5520/ I would be happy to put the macros back if there is a value in having the extra macros added - perhaps for clarify, as you suggest. Krzysztof
Re: [PATCH net-next 04/12] ibmvnic: Introduce xmit_more support using batched subCRQ hcalls
On Thu, 12 Nov 2020 13:09:59 -0600 Thomas Falcon wrote:
> Include support for the xmit_more feature utilizing the
> H_SEND_SUB_CRQ_INDIRECT hypervisor call which allows the sending
> of multiple subordinate Command Response Queue descriptors in one
> hypervisor call via a DMA-mapped buffer. This update reduces hypervisor
> calls and thus hypervisor call overhead per TX descriptor.
>
> Signed-off-by: Thomas Falcon
The common bug with xmit_more is not flushing the already queued
notifications when there is a drop. Any time you drop a skb you need
to check it's not an skb that was the end of an xmit_more train and
if so flush notifications (or just always flush on error).
Looking at the driver e.g. this starting goto:
if (ibmvnic_xmit_workarounds(skb, netdev)) {
tx_dropped++;
tx_send_failed++;
ret = NETDEV_TX_OK;
goto out;
}
Does not seem to hit any flush on its way out AFAICS.
Re: [PATCH net-next 01/12] ibmvnic: Ensure that subCRQ entry reads are ordered
On Thu, 12 Nov 2020 13:09:56 -0600 Thomas Falcon wrote: > Ensure that received Subordinate Command-Response Queue > entries are properly read in order by the driver. > > Signed-off-by: Thomas Falcon Are you sure this is not a bug fix?
Re: [PATCH net-next 02/12] ibmvnic: Introduce indirect subordinate Command Response Queue buffer
On Thu, 12 Nov 2020 13:09:57 -0600 Thomas Falcon wrote:
> This patch introduces the infrastructure to send batched subordinate
> Command Response Queue descriptors, which are used by the ibmvnic
> driver to send TX frame and RX buffer descriptors.
>
> Signed-off-by: Thomas Falcon
> @@ -2957,6 +2963,19 @@ static struct ibmvnic_sub_crq_queue
> *init_sub_crq_queue(struct ibmvnic_adapter
>
> scrq->adapter = adapter;
> scrq->size = 4 * PAGE_SIZE / sizeof(*scrq->msgs);
> + scrq->ind_buf.index = 0;
> +
> + scrq->ind_buf.indir_arr =
> + dma_alloc_coherent(dev,
> +IBMVNIC_IND_ARR_SZ,
> +&scrq->ind_buf.indir_dma,
> +GFP_KERNEL);
> +
> + if (!scrq->ind_buf.indir_arr) {
> + dev_err(dev, "Couldn't allocate indirect scrq buffer\n");
This warning/error is not necessary, memory allocation will trigger an
OOM message already.
> + goto reg_failed;
Don't you have to do something like
rc = plpar_hcall_norets(H_FREE_SUB_CRQ,
adapter->vdev->unit_address,
scrq->crq_num);
?
> + }
> +
> spin_lock_init(&scrq->lock);
>
Re: [PATCH v2 05/19] powerpc: interrupt handler wrapper functions
Hi Nicholas,
I love your patch! Perhaps something to improve:
[auto build test WARNING on powerpc/next]
[also build test WARNING on v5.10-rc3 next-20201113]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Nicholas-Piggin/powerpc-interrupt-wrappers/2020-183954
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-randconfig-r035-2020 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
a719eef73ec447b2c5fc8b70f69564a2e0f78e1e)
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://github.com/0day-ci/linux/commit/36805b0ebcf1760588efad86b8b5db5344329148
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Nicholas-Piggin/powerpc-interrupt-wrappers/2020-183954
git checkout 36805b0ebcf1760588efad86b8b5db5344329148
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> arch/powerpc/kernel/traps.c:1950:30: warning: no previous prototype for
>> function 'performance_monitor_exception_nmi' [-Wmissing-prototypes]
DEFINE_INTERRUPT_HANDLER_NMI(performance_monitor_exception_nmi)
^
arch/powerpc/kernel/traps.c:1950:1: note: declare 'static' if the function
is not intended to be used outside of this translation unit
DEFINE_INTERRUPT_HANDLER_NMI(performance_monitor_exception_nmi)
^
arch/powerpc/include/asm/interrupt.h:146:19: note: expanded from macro
'DEFINE_INTERRUPT_HANDLER_NMI'
__visible noinstr long func(struct pt_regs *regs) \
^
>> arch/powerpc/kernel/traps.c:1963:32: warning: no previous prototype for
>> function 'performance_monitor_exception_async' [-Wmissing-prototypes]
DEFINE_INTERRUPT_HANDLER_ASYNC(performance_monitor_exception_async)
^
arch/powerpc/kernel/traps.c:1963:1: note: declare 'static' if the function
is not intended to be used outside of this translation unit
DEFINE_INTERRUPT_HANDLER_ASYNC(performance_monitor_exception_async)
^
arch/powerpc/include/asm/interrupt.h:118:19: note: expanded from macro
'DEFINE_INTERRUPT_HANDLER_ASYNC'
__visible noinstr void func(struct pt_regs *regs) \
^
2 warnings generated.
vim +/performance_monitor_exception_nmi +1950 arch/powerpc/kernel/traps.c
1949
> 1950 DEFINE_INTERRUPT_HANDLER_NMI(performance_monitor_exception_nmi)
1951 {
1952 nmi_enter();
1953
1954 __this_cpu_inc(irq_stat.pmu_irqs);
1955
1956 perf_irq(regs);
1957
1958 nmi_exit();
1959
1960 return 0;
1961 }
1962
> 1963 DEFINE_INTERRUPT_HANDLER_ASYNC(performance_monitor_exception_async)
1964 {
1965 irq_enter();
1966
1967 __this_cpu_inc(irq_stat.pmu_irqs);
1968
1969 perf_irq(regs);
1970
1971 irq_exit();
1972 }
1973
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH v2 03/19] powerpc: bad_page_fault, do_break get registers from regs
Hi, Quoting Nicholas Piggin : This also moves the 32s DABR match to C. I'm still not happy with that. What about the following instead ? diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S index 8cdc8bcde703..6253c4acb46d 100644 --- a/arch/powerpc/kernel/entry_32.S +++ b/arch/powerpc/kernel/entry_32.S @@ -657,10 +657,6 @@ ppc_swapcontext: .globl handle_page_fault handle_page_fault: addir3,r1,STACK_FRAME_OVERHEAD -#ifdef CONFIG_PPC_BOOK3S_32 - andis. r0,r5,DSISR_DABRMATCH@h - bne-handle_dabr_fault -#endif bl do_page_fault cmpwi r3,0 beq+ret_from_except @@ -674,17 +670,6 @@ handle_page_fault: bl bad_page_fault b ret_from_except_full -#ifdef CONFIG_PPC_BOOK3S_32 - /* We have a data breakpoint exception - handle it */ -handle_dabr_fault: - SAVE_NVGPRS(r1) - lwz r0,_TRAP(r1) - clrrwi r0,r0,1 - stw r0,_TRAP(r1) - bl do_break - b ret_from_except_full -#endif - /* * This routine switches between two different tasks. The process * state of one is saved on its kernel stack. Then the state diff --git a/arch/powerpc/kernel/head_book3s_32.S b/arch/powerpc/kernel/head_book3s_32.S index 9381aa867591..5cc71482b35f 100644 --- a/arch/powerpc/kernel/head_book3s_32.S +++ b/arch/powerpc/kernel/head_book3s_32.S @@ -684,7 +684,10 @@ handle_page_fault_tramp_1: lwz r5, _DSISR(r11) /* fall through */ handle_page_fault_tramp_2: + andis. r0, r5, DSISR_DABRMATCH@h + bne-1f EXC_XFER_LITE(0x300, handle_page_fault) +1: EXC_XFER_STD(0x300, do_break) #ifdef CONFIG_VMAP_STACK .macro save_regs_threadthread --- Christophe Similar to the previous patch this makes interrupt handler function types more regular so they can be wrapped with the next patch. bad_page_fault and do_break are not performance critical. Signed-off-by: Nicholas Piggin --- arch/powerpc/include/asm/bug.h | 2 +- arch/powerpc/include/asm/debug.h | 3 +-- arch/powerpc/kernel/entry_32.S | 14 -- arch/powerpc/kernel/exceptions-64e.S | 3 +-- arch/powerpc/kernel/exceptions-64s.S | 3 +-- arch/powerpc/kernel/head_8xx.S | 5 ++--- arch/powerpc/kernel/process.c | 7 +++ arch/powerpc/kernel/traps.c| 2 +- arch/powerpc/mm/book3s64/hash_utils.c | 4 ++-- arch/powerpc/mm/book3s64/slb.c | 2 +- arch/powerpc/mm/fault.c| 14 +++--- arch/powerpc/platforms/8xx/machine_check.c | 2 +- 12 files changed, 25 insertions(+), 36 deletions(-) diff --git a/arch/powerpc/include/asm/bug.h b/arch/powerpc/include/asm/bug.h index 897bad6b6bbb..49162faba33f 100644 --- a/arch/powerpc/include/asm/bug.h +++ b/arch/powerpc/include/asm/bug.h @@ -113,7 +113,7 @@ struct pt_regs; long do_page_fault(struct pt_regs *); long hash__do_page_fault(struct pt_regs *); -extern void bad_page_fault(struct pt_regs *, unsigned long, int); +void bad_page_fault(struct pt_regs *, int); extern void _exception(int, struct pt_regs *, int, unsigned long); extern void _exception_pkey(struct pt_regs *, unsigned long, int); extern void die(const char *, struct pt_regs *, long); diff --git a/arch/powerpc/include/asm/debug.h b/arch/powerpc/include/asm/debug.h index ec57daf87f40..0550eceab3ca 100644 --- a/arch/powerpc/include/asm/debug.h +++ b/arch/powerpc/include/asm/debug.h @@ -52,8 +52,7 @@ extern void do_send_trap(struct pt_regs *regs, unsigned long address, unsigned long error_code, int brkpt); #else -extern void do_break(struct pt_regs *regs, unsigned long address, -unsigned long error_code); +void do_break(struct pt_regs *regs); #endif #endif /* _ASM_POWERPC_DEBUG_H */ diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S index 8cdc8bcde703..eb97df234a0c 100644 --- a/arch/powerpc/kernel/entry_32.S +++ b/arch/powerpc/kernel/entry_32.S @@ -657,10 +657,6 @@ ppc_swapcontext: .globl handle_page_fault handle_page_fault: addir3,r1,STACK_FRAME_OVERHEAD -#ifdef CONFIG_PPC_BOOK3S_32 - andis. r0,r5,DSISR_DABRMATCH@h - bne-handle_dabr_fault -#endif bl do_page_fault cmpwi r3,0 beq+ret_from_except @@ -668,19 +664,17 @@ handle_page_fault: lwz r0,_TRAP(r1) clrrwi r0,r0,1 stw r0,_TRAP(r1) - mr r5,r3 + mr r4,r3 /* err arg for bad_page_fault */ addir3,r1,STACK_FRAME_OVERHEAD - lwz r4,_DAR(r1) +#ifdef CONFIG_PPC_BOOK3S_32 + blt handle_dabr_fault +#endif bl bad_page_fault b ret_from_except_full #ifdef CONFIG_PPC_BOOK3S_32 /* We have a data breakpoint exception - handle it */ handle_dabr_fault: - SAVE_NVGPRS(r1) - lwz
Re: [PATCH] arch: pgtable: define MAX_POSSIBLE_PHYSMEM_BITS where needed
On 2020-11-13 15:59, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Stefan Agner reported a bug when using zsram on 32-bit Arm machines
> with RAM above the 4GB address boundary:
>
> Unable to handle kernel NULL pointer dereference at virtual address
> pgd = a27bd01c
> [] *pgd=236a0003, *pmd=1ffa64003
> Internal error: Oops: 207 [#1] SMP ARM
> Modules linked in: mdio_bcm_unimac(+) brcmfmac cfg80211 brcmutil
> raspberrypi_hwmon hci_uart crc32_arm_ce bcm2711_thermal phy_generic
> genet
> CPU: 0 PID: 123 Comm: mkfs.ext4 Not tainted 5.9.6 #1
> Hardware name: BCM2711
> PC is at zs_map_object+0x94/0x338
> LR is at zram_bvec_rw.constprop.0+0x330/0xa64
> pc : []lr : []psr: 6013
> sp : e376bbe0 ip : fp : c1e2921c
> r10: 0002 r9 : c1dda730 r8 :
> r7 : e8ff7a00 r6 : r5 : 02f9ffa0 r4 : e371
> r3 : 000fdffe r2 : c1e0ce80 r1 : ebf979a0 r0 :
> Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
> Control: 30c5383d Table: 235c2a80 DAC: fffd
> Process mkfs.ext4 (pid: 123, stack limit = 0x495a22e6)
> Stack: (0xe376bbe0 to 0xe376c000)
>
> As it turns out, zsram needs to know the maximum memory size, which
> is defined in MAX_PHYSMEM_BITS when CONFIG_SPARSEMEM is set, or in
> MAX_POSSIBLE_PHYSMEM_BITS on the x86 architecture.
>
> The same problem will be hit on all 32-bit architectures that have a
> physical address space larger than 4GB and happen to not enable sparsemem
> and include asm/sparsemem.h from asm/pgtable.h.
>
> After the initial discussion, I suggested just always defining
> MAX_POSSIBLE_PHYSMEM_BITS whenever CONFIG_PHYS_ADDR_T_64BIT is
> set, or provoking a build error otherwise. This addresses all
> configurations that can currently have this runtime bug, but
> leaves all other configurations unchanged.
>
> I looked up the possible number of bits in source code and
> datasheets, here is what I found:
>
> - on ARC, CONFIG_ARC_HAS_PAE40 controls whether 32 or 40 bits are used
> - on ARM, CONFIG_LPAE enables 40 bit addressing, without it we never
>support more than 32 bits, even though supersections in theory allow
>up to 40 bits as well.
> - on MIPS, some MIPS32r1 or later chips support 36 bits, and MIPS32r5
>XPA supports up to 60 bits in theory, but 40 bits are more than
>anyone will ever ship
> - On PowerPC, there are three different implementations of 36 bit
>addressing, but 32-bit is used without CONFIG_PTE_64BIT
> - On RISC-V, the normal page table format can support 34 bit
>addressing. There is no highmem support on RISC-V, so anything
>above 2GB is unused, but it might be useful to eventually support
>CONFIG_ZRAM for high pages.
>
> Fixes: 61989a80fb3a ("staging: zsmalloc: zsmalloc memory allocation library")
> Fixes: 02390b87a945 ("mm/zsmalloc: Prepare to variable MAX_PHYSMEM_BITS")
> Cc: Stefan Agner
> Cc: Mike Rapoport
> Cc: Kirill A. Shutemov
> Cc: Nitin Gupta
> Cc: Minchan Kim
> Cc: Vineet Gupta
> Cc: linux-snps-...@lists.infradead.org
> Cc: Russell King
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: Thomas Bogendoerfer
> Cc: linux-m...@vger.kernel.org
> Cc: Michael Ellerman
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: Paul Walmsley
> Cc: Palmer Dabbelt
> Cc: Albert Ou
> Cc: linux-ri...@lists.infradead.org
> Link:
> https://lore.kernel.org/linux-mm/bdfa44bf1c570b05d6c70898e2bbb0acf234ecdf.1604762181.git.ste...@agner.ch/
> Signed-off-by: Arnd Bergmann
> ---
> If everyone is happy with this version, I would suggest merging this as
> a bugfix through my asm-generic tree for linux-5.10. I originally
> said I'd send individual patches for each architecture tree, but
> I now think this is easier and better documents what is going on.
> ---
> arch/arc/include/asm/pgtable.h | 2 ++
> arch/arm/include/asm/pgtable-2level.h| 2 ++
> arch/arm/include/asm/pgtable-3level.h| 2 ++
Tested, it fixed the issue on my test system, thanks!
For ARM:
Reviewed-by: Stefan Agner
Tested-by: Stefan Agner
--
Stefan
> arch/mips/include/asm/pgtable-32.h | 3 +++
> arch/powerpc/include/asm/book3s/32/pgtable.h | 2 ++
> arch/powerpc/include/asm/nohash/32/pgtable.h | 2 ++
> arch/riscv/include/asm/pgtable-32.h | 2 ++
> include/linux/pgtable.h | 13 +
> 8 files changed, 28 insertions(+)
>
> diff --git a/arch/arc/include/asm/pgtable.h b/arch/arc/include/asm/pgtable.h
> index f1ed17edb085..163641726a2b 100644
> --- a/arch/arc/include/asm/pgtable.h
> +++ b/arch/arc/include/asm/pgtable.h
> @@ -134,8 +134,10 @@
>
> #ifdef CONFIG_ARC_HAS_PAE40
> #define PTE_BITS_NON_RWX_IN_PD1 (0xff | PAGE_MASK |
> _PAGE_CACHEABLE)
> +#define MAX_POSSIBLE_PHYSMEM_BITS 40
> #else
> #define PTE_BITS_NON_RWX_IN_PD1 (PAGE_MASK | _PAGE_CACHEABLE)
> +#define MAX_POSSIBLE_PHYSMEM_BITS 32
> #endif
Re: [PATCH kernel v4 2/2] powerpc/dma: Fallback to dma_ops when persistent memory present
On Thu, Oct 29, 2020 at 12:52:41PM +1100, Alexey Kardashevskiy wrote: > +EXPORT_SYMBOL_GPL(arch_dma_map_page_direct); I've dropped the unused exports and applied the series to dma-mapping-for-next.
[PATCH] powerpc/64s: Fix KVM system reset handling when CONFIG_PPC_PSERIES=y
pseries guest kernels have a FWNMI handler for SRESET and MCE NMIs,
which is basically the same as the regular handlers for those
interrupts.
The system reset FWNMI handler did not have a KVM guest test in it,
although it probably should have because the guest can itself run
guests.
Commit 4f50541f6703b ("powerpc/64s/exception: Move all interrupt
handlers to new style code gen macros") convert the handler faithfully
to avoid a KVM test with a "clever" trick to modify the IKVM_REAL
setting to 0 when the fwnmi handler is to be generated (PPC_PSERIES=y).
This worked when the KVM test was generated in the interrupt entry
handlers, but a later patch moved the KVM test to the common handler,
and the common handler macro is expanded below the fwnmi entry. This
prevents the KVM test from being generated even for the 0x100 entry
point as well.
The result is NMI IPIs in the host kernel when a guest is running will
use gest registers. This goes particularly badly when an HPT guest is
running and the MMU is set to guest mode.
Remove this trickery and just generate the test always.
Fixes: 9600f261acaaa ("powerpc/64s/exception: Move KVM test to common code")
Signed-off-by: Nicholas Piggin
---
arch/powerpc/kernel/exceptions-64s.S | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/powerpc/kernel/exceptions-64s.S
b/arch/powerpc/kernel/exceptions-64s.S
index f7d748b88705..07d64883c0b5 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -1000,8 +1000,6 @@ TRAMP_REAL_BEGIN(system_reset_idle_wake)
* Vectors for the FWNMI option. Share common code.
*/
TRAMP_REAL_BEGIN(system_reset_fwnmi)
- /* XXX: fwnmi guest could run a nested/PR guest, so why no test? */
- __IKVM_REAL(system_reset)=0
GEN_INT_ENTRY system_reset, virt=0
#endif /* CONFIG_PPC_PSERIES */
--
2.23.0
Re: Error: invalid switch -me200
Le 14/11/2020 à 01:20, Segher Boessenkool a écrit : On Fri, Nov 13, 2020 at 12:14:18PM -0800, Nick Desaulniers wrote: Error: invalid switch -me200 Error: unrecognized option -me200 251 cpu-as-$(CONFIG_E200) += -Wa,-me200 Are those all broken configs, or is Kconfig messed up such that randconfig can select these when it should not? Hmmm, looks like this flag does not exist in mainline binutils? There is a thread in 2010 about this that Segher commented on: https://lore.kernel.org/linuxppc-dev/9859e645-954d-4d07-8003-ffcd2391a...@kernel.crashing.org/ Guess this config should be eliminated? The help text for this config options says that e200 is used in 55xx, and there *is* an -me5500 GAS flag (which probably does this same thing, too). But is any of this tested, or useful, or wanted? Maybe Christophe knows, cc:ed. I don't have much clue on this. But I see on wikipedia that e5500 is a 64 bits powerpc (https://en.wikipedia.org/wiki/PowerPC_e5500) What I see is that NXP seems to provide a GCC version that includes aditionnal cpu (e200z0 e200z2 e200z3 e200z4 e200z6 e200z7): valid arguments to '-mcpu=' are: 401 403 405 405fp 440 440fp 464 464fp 476 476fp 505 601 602 603 603e 604 604e 620 630 740 7400 7450 750 801 821 823 8540 8548 860 970 G3 G4 G5 a2 cell e200z0 e200z2 e200z3 e200z4 e200z6 e200z7 e300c2 e300c3 e500mc e500mc64 e5500 e6500 ec603e native power3 power4 power5 power5+ power6 power6x power7 power8 powerpc powerpc64 powerpc64le rs64 titan " https://community.nxp.com/t5/MPC5xxx/GCC-generating-not-implemented-instructions/m-p/845049 Apparently based on binutils 2.28 https://www.nxp.com/docs/en/release-note/S32DS-POWER-v1-2-RN.pdf But that's not exactly -me200 though. Now, I can't see any defconfig that selects CONFIG_E200, so is that worth keeping it in the kernel at all ? Christophe
