Hello Michael,
On 01/08/24 08:04, Michael Ellerman wrote:
Sourabh Jain writes:
The following errors are observed when kexec is done with SMT=off on
powerpc.
[ 358.458385] Removing IBM Power 842 compression device
[ 374.795734] kexec_core: Starting new kernel
[ 374.795748] kexec: Waking off
From: "Mike Rapoport (Microsoft)"
NUMA emulation can be now enabled on arm64 and riscv in addition to x86.
Move description of numa=fake parameters from x86 documentation of
admin-guide/kernel-parameters.txt
Suggested-by: Zi Yan
Signed-off-by: Mike Rapoport (Microsoft)
---
Documentation/admi
From: "Mike Rapoport (Microsoft)"
The x86 implementation of range-to-target_node lookup (i.e.
phys_to_target_node() and memory_add_physaddr_to_nid()) relies on
numa_memblks.
Since numa_memblks are now part of the generic code, move these
functions from x86 to mm/numa_memblks.c and select
CONFIG_
From: "Mike Rapoport (Microsoft)"
Until now arch_numa was directly translating firmware NUMA information
to memblock.
Using numa_memblks as an intermediate step has a few advantages:
* alignment with more battle tested x86 implementation
* availability of NUMA emulation
* maintaining node inform
From: "Mike Rapoport (Microsoft)"
Currently of_numa_parse_memory_nodes() returns 0 if no "memory" node in
device tree contains "numa-node-id" property. This makes of_numa_init()
to return "success" despite no NUMA nodes were actually parsed and set
up.
arch_numa workarounds this by returning an
From: "Mike Rapoport (Microsoft)"
numa_cleanup_meminfo() moves blocks outside system RAM to
numa_reserved_meminfo and it uses 0 and PFN_PHYS(max_pfn) to determine
the memory boundaries.
Replace the memory range boundaries with more portable
memblock_start_of_DRAM() and memblock_end_of_DRAM().
S
From: "Mike Rapoport (Microsoft)"
Make functions and variables that are exclusively used by numa_memblks
static.
Move numa_nodemask_from_meminfo() before its callers to avoid forward
declaration.
Signed-off-by: Mike Rapoport (Microsoft)
Tested-by: Zi Yan # for x86_64 and arm64
---
include/li
From: "Mike Rapoport (Microsoft)"
Move most of x86::numa_init() to numa_memblks so that the latter will be
more self-contained.
With this numa_memblk data structures should not be exposed to the
architecture specific code.
Signed-off-by: Mike Rapoport (Microsoft)
Tested-by: Zi Yan # for x86_6
From: "Mike Rapoport (Microsoft)"
Move numa_emulation codfrom arch/x86 to mm/numa_emulation.c
This code will be later reused by arch_numa.
No functional changes.
Signed-off-by: Mike Rapoport (Microsoft)
Tested-by: Zi Yan # for x86_64 and arm64
---
arch/x86/Kconfig | 8 -
From: "Mike Rapoport (Microsoft)"
Move code dealing with numa_distance array from arch/x86 to
mm/numa_memblks.c
This code will be later reused by arch_numa.
No functional changes.
Signed-off-by: Mike Rapoport (Microsoft)
Tested-by: Zi Yan # for x86_64 and arm64
---
arch/x86/include/asm/numa
From: "Mike Rapoport (Microsoft)"
Move code dealing with numa_memblks from arch/x86 to mm/ and add Kconfig
options to let x86 select it in its Kconfig.
This code will be later reused by arch_numa.
No functional changes.
Signed-off-by: Mike Rapoport (Microsoft)
Tested-by: Zi Yan # for x86_64
From: "Mike Rapoport (Microsoft)"
CPU id cannot be negative.
Making it unsigned also aligns with declarations in
include/asm-generic/numa.h used by arm64 and riscv and allows sharing
numa emulation code with these architectures.
Signed-off-by: Mike Rapoport (Microsoft)
Reviewed-by: Jonathan Ca
From: "Mike Rapoport (Microsoft)"
This is required to make numa emulation code architecture independent so
that it can be moved to generic code in following commits.
Signed-off-by: Mike Rapoport (Microsoft)
Reviewed-by: Jonathan Cameron
Tested-by: Zi Yan # for x86_64 and arm64
---
arch/x86/i
From: "Mike Rapoport (Microsoft)"
This is required to make numa emulation code architecture independent so
that it can be moved to generic code in following commits.
Signed-off-by: Mike Rapoport (Microsoft)
Reviewed-by: Jonathan Cameron
Tested-by: Zi Yan # for x86_64 and arm64
---
arch/x86/i
From: "Mike Rapoport (Microsoft)"
By the time numa_emulation() is called, all physical memory is already
mapped in the direct map and there is no need to define limits for
memblock allocation.
Replace memblock_phys_alloc_range() with memblock_alloc().
Signed-off-by: Mike Rapoport (Microsoft)
R
From: "Mike Rapoport (Microsoft)"
The definitions of FAKE_NODE_MIN_SIZE and FAKE_NODE_MIN_HASH_MASK are
only used by numa emulation code, make them local to
arch/x86/mm/numa_emulation.c
Signed-off-by: Mike Rapoport (Microsoft)
Reviewed-by: Jonathan Cameron
Tested-by: Zi Yan # for x86_64 and a
From: "Mike Rapoport (Microsoft)"
Instead of looping over numa_meminfo array to detect node's start and
end addresses use get_pfn_range_for_init().
This is shorter and make it easier to lift numa_memblks to generic code.
Signed-off-by: Mike Rapoport (Microsoft)
Tested-by: Zi Yan # for x86_64
From: "Mike Rapoport (Microsoft)"
Allocation of numa_distance uses memblock_phys_alloc_range() to limit
allocation to be below the last mapped page.
But NUMA initializaition runs after the direct map is populated and
there is also code in setup_arch() that adjusts memblock limit to
reflect how m
From: "Mike Rapoport (Microsoft)"
Architectures that support NUMA duplicate the code that allocates
NODE_DATA on the node-local memory with slight variations in reporting
of the addresses where the memory was allocated.
Use x86 version as the basis for the generic alloc_node_data() function
and
From: "Mike Rapoport (Microsoft)"
Every architecture that supports NUMA defines node_data in the same way:
struct pglist_data *node_data[MAX_NUMNODES];
No reason to keep multiple copies of this definition and its forward
declarations, especially when such forward declaration is the only
From: "Mike Rapoport (Microsoft)"
There are no users of HAVE_ARCH_NODEDATA_EXTENSION left, so
arch_alloc_nodedata() and arch_refresh_nodedata() are not needed
anymore.
Replace the call to arch_alloc_nodedata() in free_area_init() with
memblock_alloc(), remove arch_refresh_nodedata() and cleanup
From: "Mike Rapoport (Microsoft)"
Commit f8f9f21c7848 ("MIPS: Fix build error for loongson64 and
sgi-ip27") added HAVE_ARCH_NODEDATA_EXTENSION to loongson64 to silence a
compilation error that happened because loongson64 didn't define array
of pg_data_t as node_data like most other architectures
From: "Mike Rapoport (Microsoft)"
Make definition of node_data match other architectures.
This will allow pulling declaration of node_data to the generic mm code in
the following commit.
Signed-off-by: Mike Rapoport (Microsoft)
Reviewed-by: Jiaxun Yang
Reviewed-by: David Hildenbrand
Reviewed-
From: "Mike Rapoport (Microsoft)"
Commit f8f9f21c7848 ("MIPS: Fix build error for loongson64 and
sgi-ip27") added HAVE_ARCH_NODEDATA_EXTENSION to sgi-ip27 to silence a
compilation error that happened because sgi-ip27 didn't define array of
pg_data_t as node_data like most other architectures did.
From: "Mike Rapoport (Microsoft)"
For SGI IP27 machines node_possible_map is statically set to
NODE_MASK_ALL and it is not updated during NUMA initialization.
Ensure that it only contains nodes present in the system.
Signed-off-by: Mike Rapoport (Microsoft)
---
arch/mips/sgi-ip27/ip27-smp.c |
From: "Mike Rapoport (Microsoft)"
sgi-ip27 is the only system that defines NODE_DATA() differently than
the rest of NUMA machines.
Add node_data array of struct pglist pointers that will point to
__node_data[node]->pglist and redefine NODE_DATA() to use node_data
array.
This will allow pulling
From: "Mike Rapoport (Microsoft)"
The stub functions in kernel/numa.c belong to mm/ rather than to kernel/
Signed-off-by: Mike Rapoport (Microsoft)
Acked-by: David Hildenbrand
Reviewed-by: Jonathan Cameron
Tested-by: Zi Yan # for x86_64 and arm64
---
kernel/Makefile | 1 -
mm/Makefile
From: "Mike Rapoport (Microsoft)"
Hi,
Following the discussion about handling of CXL fixed memory windows on
arm64 [1] I decided to bite the bullet and move numa_memblks from x86 to
the generic code so they will be available on arm64/riscv and maybe on
loongarch sometime later.
While it could b
On 31-07-24, 13:12, Rob Herring (Arm) wrote:
> Use of_property_present() to test for property presence rather than
> of_(find|get)_property(). This is part of a larger effort to remove
> callers of of_find_property() and similar functions. of_find_property()
> leaks the DT struct property and data
Hi all,
After merging the dma-mapping tree, today's linux-next qemu boot test
(powerpc_pseries_le_defconfig boot) produced this warning:
ipr: IBM Power RAID SCSI Device Driver version: 2.6.4 (March 14, 2017)
ibmvscsi 7103: SRP_VERSION: 16.a
ibmvscsi 7103: Maximum ID: 64 Maximum LUN: 32 Ma
P2020RDB contains multiple peripherals, which isn't added to
devicetree:
- Switch: Microchip VSC7385
- PMIC: Renesas ZL2006
- Temperature sensor: Analog Devices ADT7461
- Two eeproms: 24C256 and 24C01
- GPIO expander: NXP PCA9557
- reset gpios of Ethernet PHYs
This commit adds it.
Som
On Thu, Aug 1, 2024 at 3:13 AM Rob Herring (Arm) wrote:
>
> Use of_property_present() to test for property presence rather than
> of_(find|get)_property(). This is part of a larger effort to remove
> callers of of_find_property() and similar functions. of_find_property()
> leaks the DT struct prop
Sourabh Jain writes:
> The following errors are observed when kexec is done with SMT=off on
> powerpc.
>
> [ 358.458385] Removing IBM Power 842 compression device
> [ 374.795734] kexec_core: Starting new kernel
> [ 374.795748] kexec: Waking offline cpu 1.
> [ 374.875695] crash hp: kexec_tryloc
On Tue, Jul 30, 2024 at 05:34:50PM +0200, Christoph Hellwig wrote:
> On Mon, Jul 29, 2024 at 07:12:08PM -0700, Nathan Chancellor wrote:
> > > | ~~ ^~~~
> > >include/linux/dma-mapping.h:77:40: note: expanded from macro
> > > 'DMA_BI
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski :
On Tue, 30 Jul 2024 08:31:33 +0200 you wrote:
> Received frame from QMC contains the CRC.
> Upper layers don't need this CRC and tcpdump mentioned trailing junk
> data due to this CRC presence.
>
> As some other HDLC driv
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski :
On Tue, 30 Jul 2024 08:31:04 +0200 you wrote:
> The carrier_lock spinlock protects the carrier detection. While it is
> hold, framer_get_status() is called witch in turn takes a mutex.
> This is not correct and can lead to
From: Krishna Kumar
[ Upstream commit 335e35b748527f0c06ded9eebb65387f60647fda ]
The hotplug driver for powerpc (pci/hotplug/pnv_php.c) causes a kernel
crash when we try to hot-unplug/disable the PCIe switch/bridge from
the PHB.
The crash occurs because although the MSI data structure has been
From: Krishna Kumar
[ Upstream commit 335e35b748527f0c06ded9eebb65387f60647fda ]
The hotplug driver for powerpc (pci/hotplug/pnv_php.c) causes a kernel
crash when we try to hot-unplug/disable the PCIe switch/bridge from
the PHB.
The crash occurs because although the MSI data structure has been
From: Krishna Kumar
[ Upstream commit 335e35b748527f0c06ded9eebb65387f60647fda ]
The hotplug driver for powerpc (pci/hotplug/pnv_php.c) causes a kernel
crash when we try to hot-unplug/disable the PCIe switch/bridge from
the PHB.
The crash occurs because although the MSI data structure has been
From: Krishna Kumar
[ Upstream commit 335e35b748527f0c06ded9eebb65387f60647fda ]
The hotplug driver for powerpc (pci/hotplug/pnv_php.c) causes a kernel
crash when we try to hot-unplug/disable the PCIe switch/bridge from
the PHB.
The crash occurs because although the MSI data structure has been
From: Krishna Kumar
[ Upstream commit 335e35b748527f0c06ded9eebb65387f60647fda ]
The hotplug driver for powerpc (pci/hotplug/pnv_php.c) causes a kernel
crash when we try to hot-unplug/disable the PCIe switch/bridge from
the PHB.
The crash occurs because although the MSI data structure has been
From: Krishna Kumar
[ Upstream commit 335e35b748527f0c06ded9eebb65387f60647fda ]
The hotplug driver for powerpc (pci/hotplug/pnv_php.c) causes a kernel
crash when we try to hot-unplug/disable the PCIe switch/bridge from
the PHB.
The crash occurs because although the MSI data structure has been
From: Krishna Kumar
[ Upstream commit 335e35b748527f0c06ded9eebb65387f60647fda ]
The hotplug driver for powerpc (pci/hotplug/pnv_php.c) causes a kernel
crash when we try to hot-unplug/disable the PCIe switch/bridge from
the PHB.
The crash occurs because although the MSI data structure has been
From: Nathan Lynch
[ Upstream commit 0974d03eb479384466d828d65637814bee6b26d7 ]
Smatch warns:
arch/powerpc/kernel/rtas.c:1932 __do_sys_rtas() warn: potential
spectre issue 'args.args' [r] (local cap)
The 'nargs' and 'nret' locals come directly from a user-supplied
buffer and are used as in
Hi Guenter,
Thanks for this report. I'm afk this week, i"ll have a look at it in more
détails next week.
But to be sûre, does that Oops match the bisected commit ? Because pmd_leaf()
for e500 doesn't exist yet so pmd_write() shouldnt be called.
I did validate all my changes with mpc8544 on qemu
On Wed, Jul 31, 2024 at 11:04:20AM -0400, Frank Li wrote:
> Convert dt-binding rcpm from txt to yaml format.
> Add fsl,ls1028a-rcpm compatible string.
>
> Additional changes:
> - Add missed compatible string fsl,-rcpm.
> - Remove map fsl,-rcpm to fsl,qoriq-rcpm-.
>
> Signed-off-by: Frank Li
> --
On Mon Jul 29, 2024 at 4:29 PM EEST, Stefan Berger wrote:
> Commit d2add27cf2b8 ("tpm: Add NULL primary creation") introduced
> CONFIG_TCG_TPM2_HMAC. When this option is enabled on ppc64 then the
> following message appears in the kernel log due to a missing call to
> tpm2_sessions_init().
>
> [
On Wed, Jul 31, 2024, Alex Bennée wrote:
> Sean Christopherson writes:
>
> > Put the page reference acquired by gfn_to_pfn_prot() if
> > kvm_vm_ioctl_mte_copy_tags() runs into ZONE_DEVICE memory. KVM's less-
> > than-stellar heuristics for dealing with pfn-mapped memory means that KVM
> > can ge
On Wed, Jul 31, 2024 at 04:44:49PM -0300, Arnaldo Carvalho de Melo wrote:
> On Fri, Jul 26, 2024 at 11:08:55AM -0300, Arnaldo Carvalho de Melo wrote:
> > On Tue, Jul 23, 2024 at 09:02:23AM -0700, Ian Rogers wrote:
> > > On Mon, Jul 22, 2024 at 10:27 PM Kajol Jain wrote:
> > > >
> > > > Update JSON
On Fri, Jul 26, 2024 at 11:08:55AM -0300, Arnaldo Carvalho de Melo wrote:
> On Tue, Jul 23, 2024 at 09:02:23AM -0700, Ian Rogers wrote:
> > On Mon, Jul 22, 2024 at 10:27 PM Kajol Jain wrote:
> > >
> > > Update JSON/events for power10 platform with additional events.
> > > Also move PM_VECTOR_LD_CM
Use of_property_present() to test for property presence rather than
of_get_property(). This is part of a larger effort to remove callers
of of_get_property() and similar functions. of_get_property() leaks
the DT property data pointer which is a problem for dynamically
allocated nodes which may be f
Use of_property_present() to test for property presence rather than
of_(find|get)_property(). This is part of a larger effort to remove
callers of of_find_property() and similar functions. of_find_property()
leaks the DT struct property and data pointers which is a problem for
dynamically allocated
On Mon, Jul 29, 2024 at 01:51:26PM +0300, Baruch Siach wrote:
> diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c
> index 410a7b40e496..ded3d841c88c 100644
> --- a/kernel/dma/pool.c
> +++ b/kernel/dma/pool.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
>
> static stru
On Mon, Jul 29, 2024 at 01:51:25PM +0300, Baruch Siach wrote:
> From: Catalin Marinas
>
> Hardware DMA limit might not be power of 2. When RAM range starts above
> 0, say 4GB, DMA limit of 30 bits should end at 5GB. A single high bit
> can not encode this limit.
>
> Use direct phys_addr_t limit
On 7/31/24 08:36, LEROY Christophe wrote:
Hi Guenter,
Thanks for this report. I'm afk this week, i"ll have a look at it in more
détails next week.
But to be sûre, does that Oops match the bisected commit ? Because pmd_leaf()
for e500 doesn't exist yet so pmd_write() shouldnt be called.
I did
Sean Christopherson writes:
> Put the page reference acquired by gfn_to_pfn_prot() if
> kvm_vm_ioctl_mte_copy_tags() runs into ZONE_DEVICE memory. KVM's less-
> than-stellar heuristics for dealing with pfn-mapped memory means that KVM
> can get a page reference to ZONE_DEVICE memory.
>
> Fixes:
On Wed, Jul 31, 2024 at 11:04:20AM -0400, Frank Li wrote:
> Convert dt-binding rcpm from txt to yaml format.
> Add fsl,ls1028a-rcpm compatible string.
>
> Additional changes:
> - Add missed compatible string fsl,-rcpm.
> - Remove map fsl,-rcpm to fsl,qoriq-rcpm-.
>
> Signed-off-by: Frank Li
> --
Convert dt-binding rcpm from txt to yaml format.
Add fsl,ls1028a-rcpm compatible string.
Additional changes:
- Add missed compatible string fsl,-rcpm.
- Remove map fsl,-rcpm to fsl,qoriq-rcpm-.
Signed-off-by: Frank Li
---
Change from v1 to v2
- add missed compatible string
- Remove compatible st
On Wed, 31 Jul 2024 10:29:49 +0800, Yue Haibing wrote:
> The variable savedbitclkrate is assigned and never used, so can be removed.
>
> sound/soc/fsl/lpc3xxx-i2s.c:42:13: warning: variable ‘savedbitclkrate’ set
> but not used [-Wunused-but-set-variable]
>
>
Applied to
https://git.kernel.o
On Thu, 25 Jul 2024 16:54:52 +0800, Shengjiu Wang wrote:
> There are some register difference for i.MX8 and i.MX9
> REG_MICFIL_FIFO_CTRL definition is updated.
> REG_MICFIL_FSYNC_CTRL, REG_MICFIL_VERID, REG_MICFIL_PARAM are added from
> i.MX9
>
> Shengjiu Wang (2):
> ASoC: fsl_micfil: Expand the
nel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20240731/202407312114.ee900833-oliver.s...@intel.com
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Replace FB_BLANK_ constants with their counterparts from the
backlight subsystem. The values are identical, so there's no
change in functionality or semantics.
Signed-off-by: Thomas Zimmermann
---
drivers/macintosh/via-pmu-backlight.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -
Commit a1cacb8a8e70 ("backlight: Add BACKLIGHT_POWER_ constants for
power states") introduced dedicated constants for backlight power states.
Convert PowerPC code to the new constants.
The new constants replace the fbdev constants. This is part of a larger
effort to make kernel subsystems more ind
Replace FB_BLANK_ constants with their counterparts from the
backlight subsystem. The values are identical, so there's no
change in functionality or semantics.
Signed-off-by: Thomas Zimmermann
---
arch/powerpc/kernel/traps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arc
On 15.07.24 21:21, Peter Xu wrote:
Introduce arch_check_zapped_pud() to sanity check shadow stack on PUD zaps.
It has the same logic of the PMD helper.
One thing to mention is, it might be a good idea to use page_table_check in
the future for trapping wrong setups of shadow stack pgtable entries
On 15.07.24 21:21, Peter Xu wrote:
In 2013, commit 72403b4a0fbd ("mm: numa: return the number of base pages
altered by protection changes") introduced "numa_huge_pte_updates" vmstat
entry, trying to capture how many huge ptes (in reality, PMD thps at that
time) are marked by NUMA balancing.
This
On 15.07.24 21:21, Peter Xu wrote:
An entry should be reported as PUD leaf even if it's PROT_NONE, in which
case PRESENT bit isn't there. I hit bad pud without this when testing dax
1G on zapping a PROT_NONE PUD.
Subject s/cares/care/
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
On 15.07.24 21:21, Peter Xu wrote:
Currently the dax fault handler dumps the vma range when dynamic debugging
enabled. That's mostly not useful. Dump the (aligned) address instead
with the order info.
Signed-off-by: Peter Xu
---
drivers/dax/device.c | 6 +++---
1 file changed, 3 insertions
On Wed, Jul 31 2024 at 08:31, Nysal Jan K. A. wrote:
> If the user has decided to offline certain cores, enabling SMT should
> not online CPUs in those cores. This patch fixes the issue and changes
> the behaviour as described, by introducing an arch specific function
> topology_is_core_online(). I
On 7/30/24 21:15, Sean Christopherson wrote:
Does it make sense to move RET_PF_* to common code, and avoid a bool
argument here?
After this series, probably? Especially if/when we make "struct kvm_page_fault"
a common structure and converge all arch code. In this series, definitely not,
as it
On 7/30/24 22:00, Sean Christopherson wrote:
The probability of guest_memfd not having struct page for mapped pfns is likely
very low, but at the same time, providing a pfn+page pair doesn't cost us much.
And if it turns out that not having struct page is nonsensical, deferring the
kvm_gmem_get_p
On 7/30/24 22:15, Sean Christopherson wrote:
On Tue, Jul 30, 2024, Paolo Bonzini wrote:
On 7/27/24 01:51, Sean Christopherson wrote:
Add a kvm_follow_pfn() wrapper, kvm_lookup_pfn(), to allow looking up a
gfn=>pfn mapping without the caller getting a reference to any underlying
page. The API w
On 7/30/24 22:21, Sean Christopherson wrote:
On Tue, Jul 30, 2024, Paolo Bonzini wrote:
On 7/27/24 01:52, Sean Christopherson wrote:
Now that KVM no longer relies on an ugly heuristic to find its struct page
references, i.e. now that KVM can't get false positives on VM_MIXEDMAP
pfns, remove KVM
…
> hold, framer_get_status() is called witch in turn takes a mutex.
…
which?
Regards,
Markus
On Tue, Jul 30, 2024 at 08:31:04AM +0200, Herve Codina wrote:
> The carrier_lock spinlock protects the carrier detection. While it is
> hold, framer_get_status() is called witch in turn takes a mutex.
> This is not correct and can lead to a deadlock.
>
> A run with PROVE_LOCKING enabled detected t
On Tue, Jul 30, 2024 at 08:31:33AM +0200, Herve Codina wrote:
> Received frame from QMC contains the CRC.
> Upper layers don't need this CRC and tcpdump mentioned trailing junk
> data due to this CRC presence.
>
> As some other HDLC driver, simply discard this CRC.
It might be nice to specificall
On Wed, Jul 31, 2024 at 4:39 AM Yue Haibing wrote:
>
> The variable savedbitclkrate is assigned and never used, so can be removed.
>
> sound/soc/fsl/lpc3xxx-i2s.c:42:13: warning: variable ‘savedbitclkrate’ set
> but not used [-Wunused-but-set-variable]
>
> Fixes: 0959de657a10 ("ASoC: fsl: Add i2s
On Fri, Jul 26, 2024 at 04:52:06PM GMT, Sean Christopherson wrote:
> Mark pages accessed before dropping mmu_lock when faulting in guest memory
> so that RISC-V can convert to kvm_release_faultin_page() without tripping
> its lockdep assertion on mmu_lock being held. Marking pages accessed
> outsi
On Fri, Jul 26, 2024 at 04:52:05PM GMT, Sean Christopherson wrote:
> Don't mark pages dirty if KVM bails from the page fault handler without
> installing a stage-2 mapping, i.e. if the page is guaranteed to not be
> written by the guest.
>
> In addition to being a (very) minor fix, this paves the
On Fri, Jul 26, 2024 at 04:52:07PM GMT, Sean Christopherson wrote:
> Convert RISC-V to __kvm_faultin_pfn()+kvm_release_faultin_page(), which
> are new APIs to consolidate arch code and provide consistent behavior
> across all KVM architectures.
>
> Signed-off-by: Sean Christopherson
> ---
> arch
Enable kfence on book3s64 hash only when early init is enabled.
This is because, kfence could cause the kernel linear map to be mapped
at PAGE_SIZE level instead of 16M (which I guess we don't want).
Also currently there is no way to -
1. Make multiple page size entries for the SLB used for kernel
Both radix and hash on book3s requires to detect if kfence
early init is enabled or not. Hash needs to disable kfence
if early init is not enabled because with kfence the linear map is
mapped using PAGE_SIZE rather than 16M mapping.
We don't support multiple page sizes for slb entry used for kernel
Now that linear map functionality of debug_pagealloc is made generic,
enable kfence to use this generic infrastructure.
1. Define kfence related linear map variables.
- u8 *linear_map_kf_hash_slots;
- unsigned long linear_map_kf_hash_count;
- DEFINE_RAW_SPINLOCK(linear_map_kf_hash_lock);
Make size of the linear map to be allocated in RMA region to be of
ppc64_rma_size / 4. If debug_pagealloc requires more memory than that
then do not allocate any memory and disable debug_pagealloc.
Signed-off-by: Ritesh Harjani (IBM)
---
arch/powerpc/mm/book3s64/hash_utils.c | 15 ++-
Currently kernel_map_linear_page() function assumes to be working on
linear_map_hash_slots array. But since in later patches we need a
separate linear map array for kfence, hence make
kernel_map_linear_page() take a linear map array and lock in it's
function argument.
This is needed to separate ou
This refactors hash__kernel_map_pages() function to call
hash_debug_pagealloc_map_pages(). This will come useful when we will add
kfence support.
No functionality changes in this patch.
Signed-off-by: Ritesh Harjani (IBM)
---
arch/powerpc/mm/book3s64/hash_utils.c | 9 -
1 file changed,
This adds hash_debug_pagealloc_alloc_slots() function instead of open
coding that in htab_initialize(). This is required since we will be
separating the kfence functionality to not depend upon debug_pagealloc.
Now that everything required for debug_pagealloc is under a #ifdef
config. Bring in line
This adds hash_debug_pagealloc_add_slot() function instead of open
coding that in htab_bolt_mapping(). This is required since we will be
separating kfence functionality to not depend upon debug_pagealloc.
No functionality change in this patch.
Signed-off-by: Ritesh Harjani (IBM)
---
arch/powerp
This just brings all linear map related handling at one place instead of
having those functions scattered in hash_utils file.
Makes it easy for review.
No functionality changes in this patch.
Signed-off-by: Ritesh Harjani (IBM)
---
arch/powerpc/mm/book3s64/hash_utils.c | 164 +--
Kfence on book3s Hash on pseries is anyways broken. It fails to boot
due to RMA size limitation. That is because, kfence with Hash uses
debug_pagealloc infrastructure. debug_pagealloc allocates linear map
for entire dram size instead of just kfence relevant objects.
This means for 16TB of DRAM it w
Kfence on book3s64 Hash is broken. Kfence depends upon debug_pagealloc
infrastructure on Hash. debug_pagealloc allocates a linear map based on the size
of the DRAM i.e. 1 byte for every 64k page. That means for a 16TB DRAM, it will
need 256MB memory for linear map. Memory for linear map on pseries
91 matches
Mail list logo
