* Re: [01/32] net: pasemi: set a 64-bit DMA mask on the DMA device
From: Michael Ellerman @ 2019-02-22 9:47 UTC (permalink / raw)
To: Christoph Hellwig, Benjamin Herrenschmidt, Paul Mackerras,
Olof Johansson
Cc: iommu, linuxppc-dev, linux-kernel, Christian Zigotzky
In-Reply-To: <20190213070133.11259-2-hch@lst.de>
On Wed, 2019-02-13 at 07:01:02 UTC, Christoph Hellwig wrote:
> The pasemi driver never set a DMA mask, and given that the powerpc
> DMA mapping routines never check it this worked ok so far. But the
> generic dma-direct code which I plan to switch on for powerpc checks
> the DMA mask and fails unsupported mapping requests, so we need to
> make sure the proper 64-bit mask is set.
>
> Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> Tested-by: Christian Zigotzky <chzigotzky@xenosoft.de>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/74ebe3e733b791f37415b3a1b917ee50
cheers
^ permalink raw reply
* Re: [v2, 1/2] powerpc/64s: Fix logic when handling unknown CPU features
From: Michael Ellerman @ 2019-02-22 9:47 UTC (permalink / raw)
To: Andrew Donnellan, linuxppc-dev; +Cc: syzkaller, dvyukov, npiggin
In-Reply-To: <20190211002002.26038-1-andrew.donnellan@au1.ibm.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1599 bytes --]
On Mon, 2019-02-11 at 00:20:01 UTC, Andrew Donnellan wrote:
> From: Michael Ellerman <mpe@ellerman.id.au>
>
> In cpufeatures_process_feature(), if a provided CPU feature is unknown and
> enable_unknown is false, we erroneously print that the feature is being
> enabled and return true, even though no feature has been enabled, and
> may also set feature bits based on the last entry in the match table.
>
> Fix this so that we only set feature bits from the match table if we have
> actually enabled a feature from that table, and when failing to enable an
> unknown feature, always print the "not enabling" message and return false.
>
> Coincidentally, some older gccs (<GCC 7), when invoked with
> -fsanitize-coverage=trace-pc, cause a spurious uninitialised variable
> warning in this function:
>
> arch/powerpc/kernel/dt_cpu_ftrs.c: In function ‘cpufeatures_process_feature’:
> arch/powerpc/kernel/dt_cpu_ftrs.c:686:7: warning: ‘m’ may be used uninitialized in this function [-Wmaybe-uninitialized]
> if (m->cpu_ftr_bit_mask)
>
> An upcoming patch will enable support for kcov, which requires this option.
> This patch avoids the warning.
>
> Fixes: 5a61ef74f269 ("powerpc/64s: Support new device tree binding for discovering CPU features")
> Reported-by: Segher Boessenkool <segher@kernel.crashing.org>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> [ajd: add commit message]
> Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/8cfaf106918a8c13abb24c641556172a
cheers
^ permalink raw reply
* Re: tools/selftest/vm: allow choosing mem size and page size in map_hugetlb
From: Michael Ellerman @ 2019-02-22 9:47 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras,
Shuah Khan
Cc: linuxppc-dev, linux-kernel, linux-kselftest
In-Reply-To: <59dbb1bc305068dd0fe8e2d5a75c4213e0134549.1549638049.git.christophe.leroy@c-s.fr>
On Fri, 2019-02-08 at 15:02:55 UTC, Christophe Leroy wrote:
> map_hugetlb maps 256Mbytes of memory with default hugepage size.
>
> This patch allows the user to pass the size and page shift as an
> argument in order to use different size and page size.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/fa7b9a805c797b729022029aaa3a2b7c
cheers
^ permalink raw reply
* Re: powerpc: fix 32-bit KVM-PR lockup and panic with MacOS guest
From: Michael Ellerman @ 2019-02-22 9:47 UTC (permalink / raw)
To: Mark Cave-Ayland, benh, paulus, npiggin, christophe.leroy,
linuxppc-dev, linux-kernel, kvm-ppc
In-Reply-To: <20190208143319.11980-1-mark.cave-ayland@ilande.co.uk>
On Fri, 2019-02-08 at 14:33:19 UTC, Mark Cave-Ayland wrote:
> Commit 8792468da5e1 "powerpc: Add the ability to save FPU without giving it up"
> unexpectedly removed the MSR_FE0 and MSR_FE1 bits from the bitmask used to
> update the MSR of the previous thread in __giveup_fpu() causing a KVM-PR MacOS
> guest to lockup and panic the kernel.
>
> Reinstate these bits to the MSR bitmask to enable MacOS guests to run under
> 32-bit KVM-PR once again without issue.
>
> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/fe1ef6bcdb4fca33434256a802a3ed6a
cheers
^ permalink raw reply
* Re: powerpc: Make PPC_64K_PAGES depend on only 44x or PPC_BOOK3S_64
From: Michael Ellerman @ 2019-02-22 9:47 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: oss, aneesh.kumar
In-Reply-To: <20190208123416.1051-1-mpe@ellerman.id.au>
On Fri, 2019-02-08 at 12:34:16 UTC, Michael Ellerman wrote:
> In commit 7820856a4fcd ("powerpc/mm/book3e/64: Remove unsupported
> 64Kpage size from 64bit booke") we dropped the 64K page size support
> from the 64-bit nohash (Book3E) code.
>
> But we didn't update the dependencies of the PPC_64K_PAGES option,
> meaning a randconfig can still trigger this code and cause a build
> breakage, eg:
> arch/powerpc/include/asm/nohash/64/pgtable.h:14:2: error: #error "Page size not supported"
> arch/powerpc/include/asm/nohash/mmu-book3e.h:275:2: error: #error Unsupported page size
>
> So remove PPC_BOOK3E_64 from the dependencies. This also means we
> don't need to worry about PPC_FSL_BOOK3E, because that was just trying
> to prevent the PPC_BOOK3E_64=y && PPC_FSL_BOOK3E=y case.
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Applied to powerpc next.
https://git.kernel.org/powerpc/c/bba436309d579f306419e0bffe8a28a5
cheers
^ permalink raw reply
* Re: powerpc/44x: Force PCI on for CURRITUCK
From: Michael Ellerman @ 2019-02-22 9:47 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: bhelgaas, rdunlap, geert, hch
In-Reply-To: <20190207024935.30456-1-mpe@ellerman.id.au>
On Thu, 2019-02-07 at 02:49:35 UTC, Michael Ellerman wrote:
> The recent rework of PCI kconfig symbols exposed an existing bug in
> the CURRITUCK kconfig logic.
>
> It selects PPC4xx_PCI_EXPRESS which depends on PCI, but PCI is user
> selectable and might be disabled, leading to a warning:
>
> WARNING: unmet direct dependencies detected for PPC4xx_PCI_EXPRESS
> Depends on [n]: PCI [=n] && 4xx [=y]
> Selected by [y]:
> - CURRITUCK [=y] && PPC_47x [=y]
>
> Prior to commit eb01d42a7778 ("PCI: consolidate PCI config entry in
> drivers/pci") PCI was enabled by default for currituck_defconfig so we
> didn't see the warning. The bad logic was still there, it just
> required someone disabling PCI in their .config to hit it.
>
> Fix it by forcing PCI on for CURRITUCK, which seems was always the
> expectation anyway.
>
> Fixes: eb01d42a7778 ("PCI: consolidate PCI config entry in drivers/pci")
> Reported-by: Randy Dunlap <rdunlap@infradead.org>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
Applied to powerpc next.
https://git.kernel.org/powerpc/c/aa7150ba378650d0e9d84b8e4d805946
cheers
^ permalink raw reply
* Re: powerpc/powernv/npu: Remove redundant change_pte() hook
From: Michael Ellerman @ 2019-02-22 9:47 UTC (permalink / raw)
To: Peter Xu, linux-kernel
Cc: Andrea Arcangeli, Alexey Kardashevskiy, Alistair Popple,
Jason Wang, Mark Hairgrove, peterx, Jerome Glisse, Paul Mackerras,
linuxppc-dev, David Gibson
In-Reply-To: <20190131103022.10218-1-peterx@redhat.com>
On Thu, 2019-01-31 at 10:30:22 UTC, Peter Xu wrote:
> The change_pte() notifier was designed to use as a quick path to
> update secondary MMU PTEs on write permission changes or PFN changes.
> For KVM, it could reduce the vm-exits when vcpu faults on the pages
> that was touched up by KSM. It's not used to do cache invalidations,
> for example, if we see the notifier will be called before the real PTE
> update after all (please see set_pte_at_notify that set_pte_at was
> called later).
>
> All the necessary cache invalidation should all be done in
> invalidate_range() already.
>
> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> CC: Paul Mackerras <paulus@samba.org>
> CC: Michael Ellerman <mpe@ellerman.id.au>
> CC: Alistair Popple <alistair@popple.id.au>
> CC: Alexey Kardashevskiy <aik@ozlabs.ru>
> CC: Mark Hairgrove <mhairgrove@nvidia.com>
> CC: Balbir Singh <bsingharora@gmail.com>
> CC: David Gibson <david@gibson.dropbear.id.au>
> CC: Andrea Arcangeli <aarcange@redhat.com>
> CC: Jerome Glisse <jglisse@redhat.com>
> CC: Jason Wang <jasowang@redhat.com>
> CC: linuxppc-dev@lists.ozlabs.org
> CC: linux-kernel@vger.kernel.org
> Signed-off-by: Peter Xu <peterx@redhat.com>
> Reviewed-by: Andrea Arcangeli <aarcange@redhat.com>
> Reviewed-by: Alistair Popple <alistair@popple.id.au>
> Reviewed-by: Balbir Singh <bsingharora@gmail.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/1b58a975be36994a572ae3b3fb3e0232
cheers
^ permalink raw reply
* Re: [v2] powerpc/32: Fix CONFIG_VIRT_CPU_ACCOUNTING_NATIVE for 40x/booke
From: Michael Ellerman @ 2019-02-22 9:47 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <da718ce0da4303de0197b46570680843a188f216.1548851096.git.christophe.leroy@c-s.fr>
On Thu, 2019-01-31 at 10:10:31 UTC, Christophe Leroy wrote:
> 40x/booke have another path to reach 3f from transfer_to_handler,
> make sure it also calls ACCOUNT_CPU_USER_ENTRY() when
> CONFIG_VIRT_CPU_ACCOUNTING_NATIVE is selected.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/6b9166f0786e6f24da9fb198bcf70ce1
cheers
^ permalink raw reply
* Re: [10/10] powerpc/book3s32: Reorder _PAGE_XXX flags to simplify TLB handling
From: Michael Ellerman @ 2019-02-22 9:47 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras,
joakim.tjernlund
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <a96a221fb2ce681076b86c27d28ba4ec6b9bbb8d.1548419273.git.christophe.leroy@c-s.fr>
On Fri, 2019-01-25 at 12:34:20 UTC, Christophe Leroy wrote:
> For pages without _PAGE_USER, PP field is 00
> For pages with _PAGE_USER, PP field is 10 for RW and 11 for RO.
>
> This patch sets _PAGE_USER to 0x002 and _PAGE_RW to 0x001
> is order to simplify TLB handling by reducing amount of shifts.
>
> The location of _PAGE_PRESENT and _PAGE_HASHPTE doesn't matter
> as they are only SW related flags.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/78ca1108b10927b3d068c8da91352b0f
cheers
^ permalink raw reply
* Re: powerpc/83xx: Also save/restore SPRG4-7 during suspend
From: Michael Ellerman @ 2019-02-22 9:47 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras,
Scott Wood
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <5a09a970ce5f7998719f0b4cd8af22cc7dd09ef0.1548371001.git.christophe.leroy@c-s.fr>
On Fri, 2019-01-25 at 12:03:55 UTC, Christophe Leroy wrote:
> The 83xx has 8 SPRG registers and uses at least SPRG4
> for DTLB handling LRU.
>
> Fixes: 2319f1239592 ("powerpc/mm: e300c2/c3/c4 TLB errata workaround")
> Cc: stable@vger.kernel.org
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/36da5ff0bea2dc67298150ead8d84715
cheers
^ permalink raw reply
* Re: powerpc/traps: fix recoverability of machine check handling on book3s/32
From: Michael Ellerman @ 2019-02-22 9:47 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras,
Nicholas Piggin
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1c804764d38fb084b420b12ca13e8c1b2dea075e.1548166189.git.christophe.leroy@c-s.fr>
On Tue, 2019-01-22 at 14:11:24 UTC, Christophe Leroy wrote:
> Looks like book3s/32 doesn't set RI on machine check, so
> checking RI before calling die() will always be fatal
> allthought this is not an issue in most cases.
>
> Fixes: b96672dd840f ("powerpc: Machine check interrupt is a non-maskable interrupt")
> Fixes: daf00ae71dad ("powerpc/traps: restore recoverability of machine_check interrupts")
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> Cc: stable@vger.kernel.org
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/0bbea75c476b77fa7d7811d6be911cc7
cheers
^ permalink raw reply
* Re: powerpc/selftest: fix type of mftb() in null_syscall
From: Michael Ellerman @ 2019-02-22 9:47 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel, linux-kselftest
In-Reply-To: <3c3638c1ece313ad3fa0a850f9a98a635ebe688a.1548165236.git.christophe.leroy@c-s.fr>
On Tue, 2019-01-22 at 13:54:57 UTC, Christophe Leroy wrote:
> All callers of mftb() expect 'unsigned long', and the function itself
> only returns lower part of the TB so it really is 'unsigned long'
> not 'unsigned long long'
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/beb4f4722cf60d9f0803054dec4eb502
cheers
^ permalink raw reply
* Re: powerpc/32: Remove unneccessary MSR[RI] clearing for 8xx
From: Michael Ellerman @ 2019-02-22 9:47 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <8e8b5c4c5a7b7af2615e9e3d8395adc37765b3ed.1548120584.git.christophe.leroy@c-s.fr>
On Tue, 2019-01-22 at 13:52:04 UTC, Christophe Leroy wrote:
> MSR[RI] has already been cleared a few lines above.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/ab44840df1dcd1a10c514aa2938c47f5
cheers
^ permalink raw reply
* Re: powerpc/64: Make sys_switch_endian() traceable
From: Michael Ellerman @ 2019-02-22 9:47 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
In-Reply-To: <20190115063736.3679-1-mpe@ellerman.id.au>
On Tue, 2019-01-15 at 06:37:36 UTC, Michael Ellerman wrote:
> We weren't using SYSCALL_DEFINE for sys_switch_endian(), which means
> it wasn't able to be traced by CONFIG_FTRACE_SYSCALLS.
>
> By using the macro we create the right metadata and the syscall is
> visible. eg:
>
> # cd /sys/kernel/debug/tracing
> # echo 1 | tee events/syscalls/sys_*_switch_endian/enable
> # ~/switch_endian_test
> # cat trace
> ...
> switch_endian_t-3604 [009] .... 315.175164: sys_switch_endian()
> switch_endian_t-3604 [009] .... 315.175167: sys_switch_endian -> 0x5555aaaa5555aaaa
> switch_endian_t-3604 [009] .... 315.175169: sys_switch_endian()
> switch_endian_t-3604 [009] .... 315.175169: sys_switch_endian -> 0x5555aaaa5555aaaa
>
> Fixes: 529d235a0e19 ("powerpc: Add a proper syscall for switching endianness")
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Applied to powerpc next.
https://git.kernel.org/powerpc/c/81dac817786263bb44cd5a200a07eff3
cheers
^ permalink raw reply
* Re: powerpc/setup: display reason for not booting
From: Michael Ellerman @ 2019-02-22 9:47 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <8e172be53248cbc3297b345ae2ce7ddda6d5f0c5.1545070330.git.christophe.leroy@c-s.fr>
On Tue, 2018-12-18 at 06:53:41 UTC, Christophe Leroy wrote:
> When no machine description matches, display it clearly
> before looping forever.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/e995265252fad3cf10cec6821ff0870c
cheers
^ permalink raw reply
* Re: [v2] powerpc/8xx: hide itlbie and dtlbie symbols
From: Michael Ellerman @ 2019-02-22 9:47 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <998f5532a4ec358acdbeb4238182f416304b3293.1544687473.git.christophe.leroy@c-s.fr>
On Thu, 2018-12-13 at 08:08:11 UTC, Christophe Leroy wrote:
> When disassembling InstructionTLBError we get the following messy code:
>
> c000138c: 7d 84 63 78 mr r4,r12
> c0001390: 75 25 58 00 andis. r5,r9,22528
> c0001394: 75 2a 40 00 andis. r10,r9,16384
> c0001398: 41 a2 00 08 beq c00013a0 <itlbie>
> c000139c: 7c 00 22 64 tlbie r4,r0
>
> c00013a0 <itlbie>:
> c00013a0: 39 40 04 01 li r10,1025
> c00013a4: 91 4b 00 b0 stw r10,176(r11)
> c00013a8: 39 40 10 32 li r10,4146
> c00013ac: 48 00 cc 59 bl c000e004 <transfer_to_handler>
>
> For a cleaner code dump, this patch replaces itlbie and dtlbie
> symbols by local symbols.
>
> c000138c: 7d 84 63 78 mr r4,r12
> c0001390: 75 25 58 00 andis. r5,r9,22528
> c0001394: 75 2a 40 00 andis. r10,r9,16384
> c0001398: 41 a2 00 08 beq c00013a0 <InstructionTLBError+0xa0>
> c000139c: 7c 00 22 64 tlbie r4,r0
> c00013a0: 39 40 04 01 li r10,1025
> c00013a4: 91 4b 00 b0 stw r10,176(r11)
> c00013a8: 39 40 10 32 li r10,4146
> c00013ac: 48 00 cc 59 bl c000e004 <transfer_to_handler>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/32ceaa6e128556ec67151a16d7c2c045
cheers
^ permalink raw reply
* Re: powerpc/pseries: export timebase register sample in lparcfg
From: Michael Ellerman @ 2019-02-22 9:47 UTC (permalink / raw)
To: Tyrel Datwyler; +Cc: brking, linuxppc-dev, Tyrel Datwyler, puvichakravarthy
In-Reply-To: <1544312907-17555-1-git-send-email-tyreld@linux.vnet.ibm.com>
On Sat, 2018-12-08 at 23:48:27 UTC, Tyrel Datwyler wrote:
> The Processor Utilzation of Resource Registers (PURR) provide an estimate of
> resources used by a cpu thread. Section 7.6 in Book III of the ISA outlines
> how to calculate the percentage of shared resources for threads using the
> ratio of the PURR delta and Timebase Register delta for a sampled period.
>
> This calculation is currently done erroneously by the lparstat tool from the
> powerpc-utils package. This patch exports the current timebase value after
> we sample the PURRs and exposes it to userspace accounting tools via
> /proc/ppc64/lparcfg.
>
> Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/9f3ba362d84786af8e1ab36a32fb3378
cheers
^ permalink raw reply
* Re: [1/3] powerpc/smp: Fix NMI IPI timeout
From: Michael Ellerman @ 2019-02-22 9:47 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Paul Mackerras, Nicholas Piggin
In-Reply-To: <20181126020107.17250-2-npiggin@gmail.com>
On Mon, 2018-11-26 at 02:01:05 UTC, Nicholas Piggin wrote:
> The NMI IPI timeout logic is broken, if __smp_send_nmi_ipi times out
> on the first condition, delay_us will be zero which will send it into
> the second spin loop with no timeout so it will spin forever.
>
> Fixes: 5b73151fff63 ("powerpc: NMI IPI make NMI IPIs fully sychronous")
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/1b5fc84aba170bdfe3533396ca9662ce
cheers
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Book3S HV: Fix build failure without IOMMU support
From: Paul Mackerras @ 2019-02-22 9:41 UTC (permalink / raw)
To: Jordan Niethe; +Cc: linuxppc-dev, kvm-ppc
In-Reply-To: <20190221032848.22590-1-jniethe5@gmail.com>
On Thu, Feb 21, 2019 at 02:28:48PM +1100, Jordan Niethe wrote:
> Currently trying to build without IOMMU support will fail:
>
> (.text+0x1380): undefined reference to `kvmppc_h_get_tce'
> (.text+0x1384): undefined reference to `kvmppc_rm_h_put_tce'
> (.text+0x149c): undefined reference to `kvmppc_rm_h_stuff_tce'
> (.text+0x14a0): undefined reference to `kvmppc_rm_h_put_tce_indirect'
>
> This happens because turning off IOMMU support will prevent
> book3s_64_vio_hv.c from being built because it is only built when
> SPAPR_TCE_IOMMU is set, which depends on IOMMU support.
>
> Fix it using ifdefs for the undefined references.
>
> Fixes: 76d837a4c0f9 ("KVM: PPC: Book3S PR: Don't include SPAPR TCE code on non-pseries platforms")
> Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
Thanks, applied to my kvm-ppc-next tree.
Paul.
^ permalink raw reply
* Re: [PATCH kernel] KVM: PPC: Improve KVM reference counting
From: Paul Mackerras @ 2019-02-22 9:41 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: linuxppc-dev, kvm-ppc, David Gibson
In-Reply-To: <20190221034414.41777-1-aik@ozlabs.ru>
On Thu, Feb 21, 2019 at 02:44:14PM +1100, Alexey Kardashevskiy wrote:
> The anon fd's ops releases the KVM reference in the release hook.
> However we reference the KVM object after we create the fd so there is
> small window when the release function can be called and
> dereferenced the KVM object which potentially may free it.
>
> It is not a problem at the moment as the file is created and KVM is
> referenced under the KVM lock and the release function obtains the same
> lock before dereferencing the KVM (although the lock is not held when
> calling kvm_put_kvm()) but it is a fragile against future changes.
>
> This references the KVM object before creating a file.
>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Thanks, applied to my kvm-ppc-next tree.
Paul.
^ permalink raw reply
* Re: [PATCH kernel] KVM: PPC: Release all hardware TCE tables attached to a group
From: Paul Mackerras @ 2019-02-22 9:39 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: Paul E . McKenney, linuxppc-dev, kvm-ppc, David Gibson
In-Reply-To: <20190212043745.18290-1-aik@ozlabs.ru>
On Tue, Feb 12, 2019 at 03:37:45PM +1100, Alexey Kardashevskiy wrote:
> The SPAPR TCE KVM device references all hardware IOMMU tables assigned to
> some IOMMU group to ensure that in-kernel KVM acceleration of H_PUT_TCE
> can work. The tables are references when an IOMMU group gets registered
> with the VFIO KVM device by the KVM_DEV_VFIO_GROUP_ADD ioctl;
> KVM_DEV_VFIO_GROUP_DEL calls into the dereferencing code
> in kvm_spapr_tce_release_iommu_group() which walks through the list of
> LIOBNs, finds a matching IOMMU table and calls kref_put() when found.
>
> However that code stops after the very first successful derefencing
> leaving other tables referenced till the SPAPR TCE KVM device is destroyed
> which normally happens on guest reboot or termination so if we do hotplug
> and unplug in a loop, we are leaking IOMMU tables here.
>
> This removes a premature return to let kvm_spapr_tce_release_iommu_group()
> find and dereference all attached tables.
>
> Fixes: 121f80ba68f "KVM: PPC: VFIO: Add in-kernel acceleration for VFIO"
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Thanks, applied to my kvm-ppc-next tree.
Paul.
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Book3S HV: Optimise mmio emulation for devices on FAST_MMIO_BUS
From: Paul Mackerras @ 2019-02-22 9:39 UTC (permalink / raw)
To: Suraj Jitindar Singh; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <20190207045650.18322-1-sjitindarsingh@gmail.com>
On Thu, Feb 07, 2019 at 03:56:50PM +1100, Suraj Jitindar Singh wrote:
> Devices on the KVM_FAST_MMIO_BUS by definition have length zero and are
> thus used for notification purposes rather than data transfer. For
> example eventfd for virtio devices.
>
> This means that when emulating mmio instructions which target devices on
> this bus we can immediately handle them and return without needing to load
> the instruction from guest memory.
>
> For now we restrict this to stores as this is the only use case at
> present.
>
> For a normal guest the effect is negligible, however for a nested guest
> we save on the order of 5us per access.
>
> Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
Thanks, applied to my kvm-ppc-next tree.
Paul.
^ permalink raw reply
* Re: [PATCH v2] KVM: PPC: Book3S: Add KVM stat largepages_[2M/1G]
From: Paul Mackerras @ 2019-02-22 9:40 UTC (permalink / raw)
To: Suraj Jitindar Singh; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <20190219035345.26239-1-sjitindarsingh@gmail.com>
On Tue, Feb 19, 2019 at 02:53:45PM +1100, Suraj Jitindar Singh wrote:
> This adds an entry to the kvm_stats_debugfs directory which provides the
> number of large (2M or 1G) pages which have been used to setup the guest
> mappings.
>
> Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
Thanks, applied to my kvm-ppc-next tree.
Paul.
^ permalink raw reply
* RE: [PATCH] soc: fsl: guts: make fsl_guts_get_svr() static
From: Y.b. Lu @ 2019-02-22 8:07 UTC (permalink / raw)
To: Horia Geanta, Leo Li
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190221103731.28978-1-horia.geanta@nxp.com>
> -----Original Message-----
> From: Horia Geantă <horia.geanta@nxp.com>
> Sent: Thursday, February 21, 2019 6:38 PM
> To: Leo Li <leoyang.li@nxp.com>
> Cc: Y.b. Lu <yangbo.lu@nxp.com>; linuxppc-dev@lists.ozlabs.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org
> Subject: [PATCH] soc: fsl: guts: make fsl_guts_get_svr() static
>
> The export of fsl_guts_get_svr() is a left-over, it's currently used only internally
> and users needing SoC information should use the generic soc_device
> infrastructure.
>
[Y.b. Lu] Acked-by: Yangbo Lu <yangbo.lu@nxp.com>
> Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
> ---
> drivers/soc/fsl/guts.c | 3 +--
> include/linux/fsl/guts.h | 2 --
> 2 files changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c index
> 4f9655087bd7..63f6df86f9e5 100644
> --- a/drivers/soc/fsl/guts.c
> +++ b/drivers/soc/fsl/guts.c
> @@ -115,7 +115,7 @@ static const struct fsl_soc_die_attr
> *fsl_soc_die_match(
> return NULL;
> }
>
> -u32 fsl_guts_get_svr(void)
> +static u32 fsl_guts_get_svr(void)
> {
> u32 svr = 0;
>
> @@ -129,7 +129,6 @@ u32 fsl_guts_get_svr(void)
>
> return svr;
> }
> -EXPORT_SYMBOL(fsl_guts_get_svr);
>
> static int fsl_guts_probe(struct platform_device *pdev) { diff --git
> a/include/linux/fsl/guts.h b/include/linux/fsl/guts.h index
> 941b11811f85..1fc0edd71c52 100644
> --- a/include/linux/fsl/guts.h
> +++ b/include/linux/fsl/guts.h
> @@ -135,8 +135,6 @@ struct ccsr_guts {
> u32 srds2cr1; /* 0x.0f44 - SerDes2 Control Register 0 */
> } __attribute__ ((packed));
>
> -u32 fsl_guts_get_svr(void);
> -
> /* Alternate function signal multiplex control */ #define
> MPC85xx_PMUXCR_QE(x) (0x8000 >> (x))
>
> --
> 2.16.2
^ permalink raw reply
* Re: linux-next: build failure after merge of the powerpc tree
From: Christophe Leroy @ 2019-02-22 7:37 UTC (permalink / raw)
To: Stephen Rothwell, Michael Ellerman, PowerPC
Cc: Linux Next Mailing List, Linux Kernel Mailing List
In-Reply-To: <20190222181403.4ce373bd@canb.auug.org.au>
Le 22/02/2019 à 08:14, Stephen Rothwell a écrit :
> Hi all,
>
> After merging the powerpc tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> make[4]: *** No rule to make target 'arch/powerpc/mm/ptdump/core.o', needed by 'arch/powerpc/mm/ptdump/built-in.a'.
>
> Caused by commit
>
> 5df1cfa43394 ("powerpc: Move page table dump files in a dedicated subdirectory")
>
> I have reverted that commit for today.
>
In the Makefile, replace core.o by ptdump.o (or rename the file ptdump.c
to core.c). Michael, what was your intention ?
Christophe
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox