On Tue, Dec 18, 2018 at 11:16:50AM +0100, Sebastian Ott wrote:
> Set the flag to skip scanning for VFs after SRIOV enablement.
> VF creation will be triggered by the hotplug code.
>
> Signed-off-by: Sebastian Ott
Looks good,
Reviewed-by: Christoph Hellwig
On Tue, Dec 18, 2018 at 11:16:49AM +0100, Sebastian Ott wrote:
> Provide a flag to skip scanning for new VFs after SRIOV enablement.
> This can be set by implementations for which the VFs are already
> reported by other means.
>
> Signed-off-by: Sebastian Ott
Looks good,
Reviewed-by: Christoph
This patch implements CONFIG_DEBUG_VIRTUAL to warn about
incorrect use of virt_to_phys() and page_to_phys()
Below is the result of test_debug_virtual:
[1.438746] WARNING: CPU: 0 PID: 1 at ./arch/powerpc/include/asm/io.h:808
test_debug_virtual_init+0x3c/0xd4
[1.448156] CPU: 0 PID: 1
On 12/19/2018 06:57 AM, Christophe Leroy wrote:
Le 19/12/2018 à 01:26, Michael Ellerman a écrit :
Michael Ellerman writes:
Christophe Leroy writes:
This patch implements CONFIG_DEBUG_VIRTUAL to warn about
incorrect use of virt_to_phys() and page_to_phys()
This commit is breaking my
Le 19/12/2018 à 01:26, Michael Ellerman a écrit :
Michael Ellerman writes:
Christophe Leroy writes:
This patch implements CONFIG_DEBUG_VIRTUAL to warn about
incorrect use of virt_to_phys() and page_to_phys()
This commit is breaking my p5020ds booting a 32-bit kernel with:
smp:
On 19/12/2018 11:17, Michael Ellerman wrote:
> Alexey Kardashevskiy writes:
>> diff --git a/arch/powerpc/platforms/powernv/npu-dma.c
>> b/arch/powerpc/platforms/powernv/npu-dma.c
>> index dc629ee..3468eaa 100644
>> --- a/arch/powerpc/platforms/powernv/npu-dma.c
>> +++
On Tue, 2018-12-18 at 09:17 -0800, Christoph Hellwig wrote:
> This series seems to miss patches 1 and 2.
Odd, I got them...
Ben.
On Wed, Dec 19, 2018 at 08:50:57AM +0530, Aneesh Kumar K.V wrote:
> That was done considering that ptep_modify_prot_start/commit was defined
> in asm-generic/pgtable.h. I was trying to make sure I didn't break
> anything with the patch. Also s390 do have that EXPORT_SYMBOL() for the
> same.
On 19/12/2018 10:35, Michael Ellerman wrote:
> Alexey Kardashevskiy writes:
>
>> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
>> b/arch/powerpc/platforms/powernv/pci-ioda.c
>> index b86a6e0..1168b185 100644
>> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
>> +++
On 14/12/18 2:41 PM, Anju T Sudhakar wrote:
Add PMU functions to support trace-imc.
Reviewed-by: Madhavan Srinivasan
Signed-off-by: Anju T Sudhakar
---
arch/powerpc/perf/imc-pmu.c | 175
1 file changed, 175 insertions(+)
diff --git
On 14/12/18 2:41 PM, Anju T Sudhakar wrote:
Patch detects trace-imc events, does memory initilizations for each online
cpu, and registers cpuhotplug call-backs.
Reviewed-by: Madhavan Srinivasan
Signed-off-by: Anju T Sudhakar
---
arch/powerpc/perf/imc-pmu.c | 91
On 14/12/18 2:41 PM, Anju T Sudhakar wrote:
LDBAR holds the memory address allocated for each cpu. For thread-imc
the mode bit (i.e bit 1) of LDBAR is set to accumulation.
Currently, ldbar is loaded with per cpu memory address and mode set to
accumulation at boot time.
To enable trace-imc,
On 14/12/18 2:41 PM, Anju T Sudhakar wrote:
Add the macros needed for IMC (In-Memory Collection Counters) trace-mode
and data structure to hold the trace-imc record data.
Also, add the new type "OPAL_IMC_COUNTERS_TRACE" in 'opal-api.h', since
there is a new switch case added in the opal-calls
On 18/12/18 11:50 AM, Anju T Sudhakar wrote:
The data structure (i.e struct imc_mem_info) to hold the memory address
information for nest imc units is allocated based on the number of nodes
in the system.
nest_imc_event_init() traverse this struct array to calculate the memory
base address
On 08/10/2018 21:18, Michael Ellerman wrote:
> Serhii Popovych writes:
>> Alexey Kardashevskiy wrote:
>>> As a part of cleanup, the SPAPR TCE IOMMU subdriver releases preregistered
>>> memory. If there is a bug in memory release, the loop in
>>> tce_iommu_release() becomes infinite; this
Christophe Leroy writes:
> If the device tree doesn't reside in the memory which is declared
> inside it, it has to be moved as well as this memory will not be
> mapped by the kernel.
I worry this will break some obscure platform, but I'll merge it anyway
and we'll see :)
cheers
> diff --git
On 19/12/2018 09:37, Alex Williamson wrote:
> On Thu, 13 Dec 2018 17:17:34 +1100
> Alexey Kardashevskiy wrote:
>
>> POWER9 Witherspoon machines come with 4 or 6 V100 GPUs which are not
>> pluggable PCIe devices but still have PCIe links which are used
>> for config space and MMIO. In addition
THP pages can get split during different code paths. An incremented reference
count do imply we will not split the compound page. But the pmd entry can be
converted to level 4 pte entries. Keep the code simpler by allowing large
IOMMU page size only if the guest ram is backed by hugetlb pages.
Current code doesn't do page migration if the page allocated is a compound page.
With HugeTLB migration support, we can end up allocating hugetlb pages from
CMA region. Also THP pages can be allocated from CMA region. This patch updates
the code to handle compound pages correctly.
This use the
This helper does a get_user_pages_fast and if it find pages in the CMA area
it will try to migrate them before taking page reference. This makes sure that
we don't keep non-movable pages (due to page reference count) in the CMA area.
Not able to move pages out of CMA area result in CMA allocation
ppc64 use CMA area for the allocation of guest page table (hash page table). We
won't
be able to start guest if we fail to allocate hash page table. We have observed
hash table allocation failure because we failed to migrate pages out of CMA
region
because they were pinned. This happen when we
Christoph Hellwig writes:
> On Tue, Dec 18, 2018 at 03:11:37PM +0530, Aneesh Kumar K.V wrote:
>> +EXPORT_SYMBOL(huge_ptep_modify_prot_start);
>
> The only user of this function is the one you added in the last patch
> in mm/hugetlb.c, so there is no need to export this function.
>
>> +
>> +void
Christoph Hellwig writes:
> This series seems to miss patches 1 and 2.
https://lore.kernel.org/linuxppc-dev/20181218094137.13732-2-aneesh.ku...@linux.ibm.com/
https://lore.kernel.org/linuxppc-dev/20181218094137.13732-3-aneesh.ku...@linux.ibm.com/
-aneesh
Michael Ellerman writes:
> Christophe Leroy writes:
>
>> This patch implements CONFIG_DEBUG_VIRTUAL to warn about
>> incorrect use of virt_to_phys() and page_to_phys()
>
> This commit is breaking my p5020ds booting a 32-bit kernel with:
>
> smp: Bringing up secondary CPUs ...
> __ioremap():
Hi Mathieu,
Mathieu Malaterre writes:
> In commit a225f1567405 ("powerpc/ptrace: replace ptrace_report_syscall()
> with a tracehook call") an empty body if(); was added.
>
> Replace ; with {} to remove a warning (treated as error) reported by gcc
> using W=1:
>
> arch/powerpc/kernel/ptrace.c:
Alexey Kardashevskiy writes:
> diff --git a/arch/powerpc/platforms/powernv/npu-dma.c
> b/arch/powerpc/platforms/powernv/npu-dma.c
> index dc629ee..3468eaa 100644
> --- a/arch/powerpc/platforms/powernv/npu-dma.c
> +++ b/arch/powerpc/platforms/powernv/npu-dma.c
> @@ -372,8 +358,263 @@ struct npu {
Rob Herring writes:
> On Mon, Dec 17, 2018 at 1:56 AM wrote:
>>
>> From: Frank Rowand
>>
>> Non-overlay dynamic devicetree node removal may leave the node in
>> the phandle cache. Subsequent calls to of_find_node_by_phandle()
>> will incorrectly find the stale entry. This bug exposed the
Rob Herring writes:
> On Tue, Dec 18, 2018 at 2:33 PM Frank Rowand wrote:
>>
>> On 12/18/18 12:09 PM, Frank Rowand wrote:
>> > On 12/18/18 12:01 PM, Rob Herring wrote:
>> >> On Tue, Dec 18, 2018 at 12:57 PM Frank Rowand
>> >> wrote:
>> >>>
>> >>> On 12/17/18 2:52 AM, Michael Ellerman wrote:
>>
Alexey Kardashevskiy writes:
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
> b/arch/powerpc/platforms/powernv/pci-ioda.c
> index b86a6e0..1168b185 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -2735,12 +2733,68 @@
Alexey Kardashevskiy writes:
> diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
> index f0dc680..cbcc615 100644
> --- a/arch/powerpc/kernel/iommu.c
> +++ b/arch/powerpc/kernel/iommu.c
> @@ -993,15 +994,19 @@ int iommu_tce_check_gpa(unsigned long page_shift,
> unsigned long
On Thu, 13 Dec 2018 17:17:34 +1100
Alexey Kardashevskiy wrote:
> POWER9 Witherspoon machines come with 4 or 6 V100 GPUs which are not
> pluggable PCIe devices but still have PCIe links which are used
> for config space and MMIO. In addition to that the GPUs have 6 NVLinks
> which are connected
This patch implements Audio Mixer CPU DAI driver for NXP iMX8 SOCs.
The Audio Mixer is a on-chip functional module that allows mixing of
two audio streams into a single audio stream.
Audio Mixer datasheet is available here:
https://www.nxp.com/docs/en/reference-manual/IMX8DQXPRM.pdf
On Tue, Dec 18, 2018 at 2:33 PM Frank Rowand wrote:
>
> On 12/18/18 12:09 PM, Frank Rowand wrote:
> > On 12/18/18 12:01 PM, Rob Herring wrote:
> >> On Tue, Dec 18, 2018 at 12:57 PM Frank Rowand
> >> wrote:
> >>>
> >>> On 12/17/18 2:52 AM, Michael Ellerman wrote:
> Hi Frank,
>
>
In commit a225f1567405 ("powerpc/ptrace: replace ptrace_report_syscall()
with a tracehook call") an empty body if(); was added.
Replace ; with {} to remove a warning (treated as error) reported by gcc
using W=1:
arch/powerpc/kernel/ptrace.c: In function ‘do_syscall_trace_enter’:
On 12/18/18 12:09 PM, Frank Rowand wrote:
> On 12/18/18 12:01 PM, Rob Herring wrote:
>> On Tue, Dec 18, 2018 at 12:57 PM Frank Rowand wrote:
>>>
>>> On 12/17/18 2:52 AM, Michael Ellerman wrote:
Hi Frank,
frowand.l...@gmail.com writes:
> From: Frank Rowand
>
>
On 12/18/18 12:01 PM, Rob Herring wrote:
> On Tue, Dec 18, 2018 at 12:57 PM Frank Rowand wrote:
>>
>> On 12/17/18 2:52 AM, Michael Ellerman wrote:
>>> Hi Frank,
>>>
>>> frowand.l...@gmail.com writes:
From: Frank Rowand
Non-overlay dynamic devicetree node removal may leave the node
On Tue, Dec 18, 2018 at 12:57 PM Frank Rowand wrote:
>
> On 12/17/18 2:52 AM, Michael Ellerman wrote:
> > Hi Frank,
> >
> > frowand.l...@gmail.com writes:
> >> From: Frank Rowand
> >>
> >> Non-overlay dynamic devicetree node removal may leave the node in
> >> the phandle cache. Subsequent calls
On 12/18/18 11:40 AM, frowand.l...@gmail.com wrote:
> From: Frank Rowand
>
> Non-overlay dynamic devicetree node removal may leave the node in
> the phandle cache. Subsequent calls to of_find_node_by_phandle()
> will incorrectly find the stale entry. Remove the node from the
> cache.
>
> Add
On 12/18/18 11:40 AM, frowand.l...@gmail.com wrote:
> From: Frank Rowand
>
> The phandle cache contains struct device_node pointers. The refcount
> of the pointers was not incremented while in the cache, allowing use
> after free error after kfree() of the node. Add the proper increment
> and
From: Frank Rowand
Non-overlay dynamic devicetree node removal may leave the node in
the phandle cache. Subsequent calls to of_find_node_by_phandle()
will incorrectly find the stale entry. This bug exposed the foloowing
phandle cache refcount bug.
The refcount of phandle_cache entries is not
From: Frank Rowand
The phandle cache contains struct device_node pointers. The refcount
of the pointers was not incremented while in the cache, allowing use
after free error after kfree() of the node. Add the proper increment
and decrement of the use count.
Fixes: 0b3ce78e90fc ("of: cache
From: Frank Rowand
Non-overlay dynamic devicetree node removal may leave the node in
the phandle cache. Subsequent calls to of_find_node_by_phandle()
will incorrectly find the stale entry. Remove the node from the
cache.
Add paranoia checks in of_find_node_by_phandle() as a second level
of
On 12/17/18 2:52 AM, Michael Ellerman wrote:
> Hi Frank,
>
> frowand.l...@gmail.com writes:
>> From: Frank Rowand
>>
>> Non-overlay dynamic devicetree node removal may leave the node in
>> the phandle cache. Subsequent calls to of_find_node_by_phandle()
>> will incorrectly find the stale entry.
Le 18/12/2018 à 18:04, Jonathan Neuschäfer a écrit :
On Tue, Dec 18, 2018 at 04:04:42PM +0100, Christophe Leroy wrote:
Stupid of me. In fact at the time being, BATS cover both RO and RW data
areas, so it can definitly not be mapped with PAGE_KERNEL_ROX.
In fact, as I have CONFIG_BDI_SWITCH in
On Tue, Dec 18, 2018 at 03:11:37PM +0530, Aneesh Kumar K.V wrote:
> +EXPORT_SYMBOL(huge_ptep_modify_prot_start);
The only user of this function is the one you added in the last patch
in mm/hugetlb.c, so there is no need to export this function.
> +
> +void huge_ptep_modify_prot_commit(struct
On Wed, Dec 05, 2018 at 08:39:29AM +0530, Aneesh Kumar K.V wrote:
> +pte_t ptep_modify_prot_start(struct vm_area_struct *vma, unsigned long addr,
> + pte_t *ptep)
> +{
> + unsigned long pte_val;
> +
> + /*
> + * Clear the _PAGE_PRESENT so that no hardware
This series seems to miss patches 1 and 2.
On Tue, Dec 18, 2018 at 04:04:42PM +0100, Christophe Leroy wrote:
> Stupid of me. In fact at the time being, BATS cover both RO and RW data
> areas, so it can definitly not be mapped with PAGE_KERNEL_ROX.
>
> In fact, as I have CONFIG_BDI_SWITCH in my setup, PAGE_KERNEL_TEXT is
> PAGE_KERNEL_X on
Hi Christophe,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on v4.20-rc7 next-20181218]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
On Mon, Dec 17, 2018 at 1:56 AM wrote:
>
> From: Frank Rowand
>
> Non-overlay dynamic devicetree node removal may leave the node in
> the phandle cache. Subsequent calls to of_find_node_by_phandle()
> will incorrectly find the stale entry. This bug exposed the foloowing
> phandle cache
Le 18/12/2018 à 15:55, Christophe Leroy a écrit :
Le 18/12/2018 à 15:15, Christophe Leroy a écrit :
Le 18/12/2018 à 15:07, Jonathan Neuschäfer a écrit :
On Tue, Dec 18, 2018 at 09:18:42AM +, Christophe Leroy wrote:
The only difference I see then are the flags. Everything else is
Le 18/12/2018 à 15:15, Christophe Leroy a écrit :
Le 18/12/2018 à 15:07, Jonathan Neuschäfer a écrit :
On Tue, Dec 18, 2018 at 09:18:42AM +, Christophe Leroy wrote:
The only difference I see then are the flags. Everything else is seems
identical.
I know you tried already, but would
On Fri 07-12-18 15:12:26, Andrew Morton wrote:
> On Wed, 21 Nov 2018 14:52:56 +0530 "Aneesh Kumar K.V"
> wrote:
>
> > Subject: [PATCH V4 0/3] * mm/kvm/vfio/ppc64: Migrate compound pages out of
> > CMA region
>
> Asterisk in title is strange?
>
> > ppc64 use CMA area for the allocation of
Le 18/12/2018 à 15:07, Jonathan Neuschäfer a écrit :
On Tue, Dec 18, 2018 at 09:18:42AM +, Christophe Leroy wrote:
The only difference I see then are the flags. Everything else is seems
identical.
I know you tried already, but would you mind trying once more with the
following change ?
On 12/13/2018 9:34 AM, Christophe Leroy wrote:
> [2.364486] WARNING: CPU: 0 PID: 60 at ./arch/powerpc/include/asm/io.h:837
> dma_nommu_map_page+0x44/0xd4
> [2.373579] CPU: 0 PID: 60 Comm: cryptomgr_test Tainted: GW
> 4.20.0-rc5-00560-g6bfb52e23a00-dirty #531
> [
On Tue, Dec 18, 2018 at 09:18:42AM +, Christophe Leroy wrote:
> The only difference I see then are the flags. Everything else is seems
> identical.
>
> I know you tried already, but would you mind trying once more with the
> following change ?
>
[...]
> - setbat(idx, PAGE_OFFSET
Christophe Leroy writes:
> This patch implements CONFIG_DEBUG_VIRTUAL to warn about
> incorrect use of virt_to_phys() and page_to_phys()
This commit is breaking my p5020ds booting a 32-bit kernel with:
smp: Bringing up secondary CPUs ...
__ioremap(): phys addr 0x7fef5000 is RAM lr
"Aneesh Kumar K.V" writes:
> This helper does a get_user_pages_fast and if it find pages in the CMA area
> it will try to migrate them before taking page reference. This makes sure that
> we don't keep non-movable pages (due to page reference count) in the CMA area.
> Not able to move pages out
Hi Dmitry,
"Dmitry V. Levin" writes:
> syscall_get_error() is required to be implemented on this
> architecture in addition to already implemented syscall_get_nr(),
> syscall_get_arguments(), syscall_get_return_value(), and
> syscall_get_arch() functions in order to extend the generic
> ptrace
Set the flag to skip scanning for VFs after SRIOV enablement.
VF creation will be triggered by the hotplug code.
Signed-off-by: Sebastian Ott
---
arch/s390/pci/pci.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c
index 9f6f392a4461..4266a4de3160
Provide a flag to skip scanning for new VFs after SRIOV enablement.
This can be set by implementations for which the VFs are already
reported by other means.
Signed-off-by: Sebastian Ott
---
drivers/pci/iov.c | 48
include/linux/pci.h | 1 +
2
From: Stephen Rothwell
This replaces all open encodings in tools with NUMA_NO_NODE.
Also linux/numa.h is now needed for the perf build.
Signed-off-by: Anshuman Khandual
Signed-off-by: Stephen Rothwell
---
tools/include/linux/numa.h | 16
tools/perf/bench/numa.c| 6
At present there are multiple places where invalid node number is encoded
as -1. Even though implicitly understood it is always better to have macros
in there. Replace these open encodings for an invalid node number with the
global macro NUMA_NO_NODE. This helps remove NUMA related assumptions
Changes in V3:
- Dropped all references to NUMA_NO_NODE as per Lubomir Rinetl
- Split the patch into two creating a new one specifically for tools
- Folded Stephen's linux-next build fix into the second patch
Changes in V2: (https://patchwork.kernel.org/patch/10698089/)
- Added inclusion of
NestMMU requires us to mark the pte invalid and flush the tlb when we do a
RW upgrade of pte. We fixed a variant of this in the fault path in commit
Fixes: bd5050e38aec ("powerpc/mm/radix: Change pte relax sequence to handle
nest MMU hang")
Signed-off-by: Aneesh Kumar K.V
---
Architectures like ppc64 requires to do a conditional tlb flush based on the old
and new value of pte. Follow the regular pte change protection sequence for
hugetlb too. This allow the architectures to override the update sequence.
Signed-off-by: Aneesh Kumar K.V
---
include/linux/hugetlb.h |
NestMMU requires us to mark the pte invalid and flush the tlb when we do a
RW upgrade of pte. We fixed a variant of this in the fault path in commit
Fixes: bd5050e38aec ("powerpc/mm/radix: Change pte relax sequence to handle
nest MMU hang")
Do the same for mprotect upgrades.
Hugetlb is handled
Architectures like ppc64 requires to do a conditional tlb flush based on the old
and new value of pte. Enable that by passing old pte value as the arg.
Signed-off-by: Aneesh Kumar K.V
---
arch/s390/include/asm/pgtable.h | 3 ++-
arch/s390/mm/pgtable.c | 2 +-
Some architecture may want to call flush_tlb_range from these helpers.
Signed-off-by: Aneesh Kumar K.V
---
arch/s390/include/asm/pgtable.h | 4 ++--
arch/s390/mm/pgtable.c| 6 --
arch/x86/include/asm/paravirt.h | 11 ++-
We can upgrade pte access (R -> RW transition) via mprotect. We need
to make sure we follow the recommended pte update sequence as outlined in
commit bd5050e38aec ("powerpc/mm/radix: Change pte relax sequence to handle
nest MMU hang")
for such updates. This patch series do that.
Changes from V3:
On 12/18/2018 03:05 AM, Jonathan Neuschäfer wrote:
On Mon, Dec 17, 2018 at 10:29:18AM +0100, Christophe Leroy wrote:
With patches 1-3:
[0.00] setbat(0, c000, , 0100, 311)
[0.00] setbat(2, c100, 0100, 0080, 311)
[0.00] setbat(4, d000,
71 matches
Mail list logo
