> +
> +/*
> + * Use kernel_fpu_begin/end() if you intend to use FPU in kernel context. It
> + * disables preemption so be careful if you intend to use it for long periods
> + * of time.
> + * TODO: If you intend to use the FPU in irq/softirq you need to check first
> with
> + * irq_fpu_usable() if
On Wed, Jul 21, 2021 at 08:29:43AM +0200, Christian K??nig wrote:
> Looks good in general, but question is what about other architectures like
> ARM?
DRM_AMD_DC_DCN currently requires X86 || PPC64.
Maybe a good think would be to add a new KERNEL_FPU_API Kconfig symbol,
selected by x86 and powerpc
Am 21.07.21 um 06:48 schrieb Anson Jacob:
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
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 aft
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 an
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
inte
> 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 P
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
CC
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
- Updat
- 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 kernel
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 do
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':
/usr/src/linux-s
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 re
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
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 renam
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 ha
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
k
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: A
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 ne
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.
This
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
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 pXd_se
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 (an
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 bett
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 th
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 export
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 'f
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 ++-
arch/powerpc/kvm/book3s_xive_nati
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 s
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 lp
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. This
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
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 silently
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 corre
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
pud_set_hug
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: Thomas
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 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, Leonardo
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 glob
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 th
41 matches
Mail list logo
