On Tue, 2021-07-20 at 10:34 +0200, Niklas Schnelle wrote:
> On Mon, 2021-07-19 at 14:11 +0200, Niklas Schnelle wrote:
> > The helper function pci_dev_is_added() from drivers/pci/pci.h is used in
> > PCI arch code of both s390 and powerpc leading to awkward relative
> > includes. Move it to the
The helper function pci_dev_is_added() from drivers/pci/pci.h is used in
PCI arch code of both s390 and powerpc leading to awkward relative
includes. Move it to the global include/linux/pci.h and get rid of these
includes just for that one function.
Signed-off-by: Niklas Schnelle
---
Since v1:
-
On Mon, 2021-07-19 at 14:11 +0200, Niklas Schnelle wrote:
> The helper function pci_dev_is_added() from drivers/pci/pci.h is used in
> PCI arch code of both s390 and powerpc leading to awkward relative
> includes. Move it to the global include/linux/pci.h and get rid of these
> includes just for
On Mon, Jul 19 2021 at 15:06, Cédric Le Goater wrote:
> There is no need to use the lockup detector ("noirqdebug") for IPIs.
> The ipistorm benchmark measures a ~10% improvement on high systems
> when this flag is set.
>
> Cc: Thomas Gleixner
> Signed-off-by: Cédric Le Goater
Reviewed-by:
On 20/07/2021 15:38, Leonardo Brás wrote:
Hello Fred, thanks for this feedback!
Sorry if I miss anything, this snippet was written for v1 over an year
ago, and I have not taken a look at it ever since.
On Mon, 2021-07-19 at 15:53 +0200, Frederic Barrat wrote:
On 16/07/2021 10:27,
On 2021-07-20 13:35, Will Deacon wrote:
Hi folks,
Jonathan reports [1] that commit c742199a014d ("mm/pgtable: add stubs
for {pmd/pub}_{set/clear}_huge") breaks the boot on arm64 when huge
mappings are used to map the kernel linear map but the VA size is
configured such that PUDs are folded.
On Tue, 20 Jul 2021 at 14:35, Will Deacon wrote:
>
> Hi folks,
>
> Jonathan reports [1] that commit c742199a014d ("mm/pgtable: add stubs
> for {pmd/pub}_{set/clear}_huge") breaks the boot on arm64 when huge
> mappings are used to map the kernel linear map but the VA size is
> configured such that
Hi Niklas,
I love your patch! Yet something to improve:
[auto build test ERROR on pci/next]
[also build test ERROR on powerpc/next s390/features pm/linux-next v5.14-rc2
next-20210720]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest
The XIVE interrupt controller on P10 can automatically save and
restore the state of the interrupt registers under the internal NVP
structure representing the VCPU. This saves a costly store/load in
guest entries and exits.
Thanks,
C.
Cédric Le Goater (2):
KVM: PPC: Book3S HV: XIVE: Add a
On Tue, 2021-07-20 at 11:58 +0200, Niklas Schnelle wrote:
> The helper function pci_dev_is_added() from drivers/pci/pci.h is used in
> PCI arch code of both s390 and powerpc leading to awkward relative
> includes. Move it to the global include/linux/pci.h and get rid of these
> includes just for
On 20/07/21 7:02 pm, kajoljain wrote:
On 7/20/21 11:04 AM, Pratik R. Sampat wrote:
Adds a generic interface to represent the energy and frequency related
PAPR attributes on the system using the new H_CALL
"H_GET_ENERGY_SCALE_INFO".
H_GET_EM_PARMS H_CALL was previously responsible for
Hi folks,
Jonathan reports [1] that commit c742199a014d ("mm/pgtable: add stubs
for {pmd/pub}_{set/clear}_huge") breaks the boot on arm64 when huge
mappings are used to map the kernel linear map but the VA size is
configured such that PUDs are folded. This is because the non-functional
On 7/20/21 11:04 AM, Pratik R. Sampat wrote:
> Adds a generic interface to represent the energy and frequency related
> PAPR attributes on the system using the new H_CALL
> "H_GET_ENERGY_SCALE_INFO".
>
> H_GET_EM_PARMS H_CALL was previously responsible for exporting this
> information in the
From: Jonathan Marek
This reverts commit c742199a014de23ee92055c2473d91fe5561ffdf.
c742199a014d ("mm/pgtable: add stubs for {pmd/pub}_{set/clear}_huge")
breaks arm64 in at least two ways for configurations where PUD or PMD
folding occur:
1. We no longer install huge-vmap mappings and
This reverts commit a6a8f7c4aa7eb50304b5c4e68eccd24313f3a785.
Commit c742199a014d ("mm/pgtable: add stubs for
{pmd/pub}_{set/clear}_huge") breaks the boot for arm64 when block
mappings are used to create the linear map, as this relies on a working
implementation of pXd_set_huge() even if the
On P10, the feature doing an automatic "save & restore" of a VCPU
interrupt context is set by default in OPAL. When a VP context is
pulled out, the state of the interrupt registers are saved by the XIVE
interrupt controller under the internal NVP structure representing the
VP. This saves a costly
Use it to hold platform specific features. P9 DD2 introduced
single-escalation support. P10 will add others.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/kvm/book3s_xive.h| 9 -
arch/powerpc/kvm/book3s_xive.c| 19 ++-
If an interrupt is taken in kernel mode, always use SIAR for it rather than
looking at regs_sipr. This prevents samples piling up around interrupt
enable (hard enable or interrupt replay via soft enable) in PMUs / modes
where the PR sample indication is not in synch with SIAR.
This results in
On 16/07/2021 10:27, Leonardo Bras wrote:
Code used to create a ddw property that was previously scattered in
enable_ddw() is now gathered in ddw_property_create(), which deals with
allocation and filling the property, letting it ready for
of_property_add(), which now occurs in sequence.
On 16/07/2021 10:27, Leonardo Bras wrote:
At the moment pseries stores information about created directly mapped
DDW window in DIRECT64_PROPNAME.
With the objective of implementing indirect DMA mapping with DDW, it's
necessary to have another propriety name to make sure kexec'ing into older
Will Deacon a écrit :
This reverts commit a6a8f7c4aa7eb50304b5c4e68eccd24313f3a785.
Commit c742199a014d ("mm/pgtable: add stubs for
{pmd/pub}_{set/clear}_huge") breaks the boot for arm64 when block
mappings are used to create the linear map, as this relies on a working
implementation of
On 16/07/2021 10:27, Leonardo Bras wrote:
Add a new helper _iommu_table_setparms(), and use it in
iommu_table_setparms() and iommu_table_setparms_lpar() to avoid duplicated
code.
Also, setting tbl->it_ops was happening outsite iommu_table_setparms*(),
so move it to the new helper. Since we
On 16/07/2021 10:27, Leonardo Bras wrote:
Update remove_dma_window() so it can be used to remove DDW with a given
property name.
This enables the creation of new property names for DDW, so we can
have different usage for it, like indirect mapping.
Signed-off-by: Leonardo Bras
Reviewed-by:
The helper function pci_dev_is_added() from drivers/pci/pci.h is used in
PCI arch code of both s390 and powerpc leading to awkward relative
includes. Move it to the global include/linux/pci.h and get rid of these
includes just for that one function.
Signed-off-by: Niklas Schnelle
---
Since v1
On 16/07/2021 10:27, Leonardo Bras wrote:
enable_ddw() currently returns the address of the DMA window, which is
considered invalid if has the value 0x00.
Also, it only considers valid an address returned from find_existing_ddw
if it's not 0x00.
Changing this behavior makes sense, given the
On 16/07/2021 10:27, Leonardo Bras wrote:
A previous change introduced the usage of DDW as a bigger indirect DMA
mapping when the DDW available size does not map the whole partition.
As most of the code that manipulates direct mappings was reused for
indirect mappings, it's necessary to
On 16/07/2021 10:27, Leonardo Bras wrote:
So far it's assumed possible to map the guest RAM 1:1 to the bus, which
works with a small number of devices. SRIOV changes it as the user can
configure hundreds VFs and since phyp preallocates TCEs and does not
allow IOMMU pages bigger than 64K, it
Will Deacon a écrit :
Hi folks,
Jonathan reports [1] that commit c742199a014d ("mm/pgtable: add stubs
for {pmd/pub}_{set/clear}_huge") breaks the boot on arm64 when huge
mappings are used to map the kernel linear map but the VA size is
configured such that PUDs are folded. This is because the
https://bugzilla.kernel.org/show_bug.cgi?id=213803
Bug ID: 213803
Summary: G5 kernel build (v5.14-rc2) fails at linking stage -
ld: arch/powerpc/mm/pgtable.o: in function
`.__ptep_set_access_flags':
On 21/07/2021 04:12, Frederic Barrat wrote:
On 16/07/2021 10:27, Leonardo Bras wrote:
So far it's assumed possible to map the guest RAM 1:1 to the bus, which
works with a small number of devices. SRIOV changes it as the user can
configure hundreds VFs and since phyp preallocates TCEs and
On Tue, Jul 13, 2021 at 09:35:22PM +0200, Uwe Kleine-König wrote:
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also
Running perf fuzzer showed below in dmesg logs:
"Can't find PMC that caused IRQ"
This means a PMU exception happened, but none of the PMC's (Performance
Monitor Counter) were found to be overflown. There are some corner cases
that clears the PMCs after PMI gets masked. In such cases, the perf
Running perf fuzzer testsuite popped up below messages
in the dmesg logs:
"Can't find PMC that caused IRQ"
This means a PMU exception happened, but none of the PMC's (Performance
Monitor Counter) were found to be overflown. Perf interrupt handler checks
the PMC's to see which PMC has overflown
- Add kernel_fpu_begin & kernel_fpu_end API as x86
- Add logic similar to x86 to ensure fpu
begin/end call correctness
- Add kernel_fpu_enabled to know if FPU is enabled
v2:
- Added asm/fpu/api.h powerpc variant with kernel_fpu_begin/end()
and kernel_fpu_enabled() declarations
- Updated
Use kernel_fpu_begin & kernel_fpu_end for PPC
Depends on "ppc/fpu: Add generic FPU api similar to x86"
v2:
- Got rid of macro switch for PPC as header file with same
name as x86 is added by previous patch in the series
Signed-off-by: Anson Jacob
CC: Christoph Hellwig
CC: Rodrigo Siqueira
This is an attempt to have generic FPU enable/disable
calls similar to x86.
So that we can simplify gpu/drm/amd/display/dc/os_types.h
Also adds FPU correctness logic seen in x86.
v2:
- Added asm/fpu/api.h powerpc variant with kernel_fpu_begin/end()
and kernel_fpu_enabled() declarations
-
On 21/07/21 11:18 am, Athira Rajeev wrote:
Running perf fuzzer showed below in dmesg logs:
"Can't find PMC that caused IRQ"
This means a PMU exception happened, but none of the PMC's (Performance
Monitor Counter) were found to be overflown. There are some corner cases
that clears the PMCs
> On 20-Jul-2021, at 7:45 PM, Nicholas Piggin wrote:
>
> If an interrupt is taken in kernel mode, always use SIAR for it rather than
> looking at regs_sipr. This prevents samples piling up around interrupt
> enable (hard enable or interrupt replay via soft enable) in PMUs / modes
> where the
On Mon, Jul 19, 2021 at 03:52:10PM -0400, Anson Jacob wrote:
> - Add kernel_fpu_begin & kernel_fpu_end API as x86
> - Add logic similar to x86 to ensure fpu
> begin/end call correctness
> - Add kernel_fpu_enabled to know if FPU is enabled
>
> Signed-off-by: Anson Jacob
All the x86 FPU support
> #define DC_FP_END() kernel_fpu_end()
> #elif defined(CONFIG_PPC64)
> #include
> +#define DC_FP_START() kernel_fpu_begin()
> +#define DC_FP_END() kernel_fpu_end()
> #endif
Please use the same header as x86 in your first patch and then kill
this ifdefered and the DC_FP_START/DC_FP_END
While you already CCed a bunch of people stuff like that needs to go to
the appropriate mailing list and not just amd-gfx.
Especially LKML so that other core devs can take a look as well.
Regards,
Christian.
Am 19.07.21 um 21:52 schrieb Anson Jacob:
This is an attempt to have generic FPU
Hi Parth,
Sorry for the late review.
On Tue, Jun 15, 2021 at 12:38:04PM +0530, Parth Shah wrote:
> On POWER10 systems, the "ibm,thread-groups" property "2" indicates the cpus
> in thread-group share both L2 and L3 caches. Hence, use cache_property = 2
> itself to find both the L2 and L3 cache
42 matches
Mail list logo
