patch-2.6.21-rt8 works for ppc arch?

ction 'local_irq_restore' All the failure makes me doubt the correctness of the PREEMPT_RT patch in 2.6.21 for ppc arch. Has anyone made a RT patch work for ppc arch in 2.6.21? In other words, is 2.6.21 a good candidate to test a PREEMPT_RT patch for ppc arch? I understand that ppc arch wi

State of PREEMPT_RT in PPC arch

ivial. The other is to back port an existing and working RT patch to the ppc arch of 2.6.21, which, at least for now, seems quite difficult and may not be merited for future. I'm soliciting comments from the community. Thanks in advance for sharing your though

Re: State of PREEMPT_RT in PPC arch

ted to active developers. Is there a place that users or not-so-active developers can post technical questions and get some relatively quick answers or comments? I think there used to be such a mailing list but I couldn't remember it. -Ryan. _

Re: State of PREEMPT_RT in PPC arch

Hi Wolfram, On Fri, Feb 19, 2010 at 12:54 AM, Wolfram Sang wrote: > > The list was apropriate. As all people are busy by default, getting no > response > is not that exceptional. If you need a fast response, you should consider > commercial support. I appreciate your c

Re: [PATCH] arch/powerpc: advertise ISA2.07, HTM, DSCR, EBB and ISEL bits in HWCAP2

Nishanth Aravamudan wrote on 05/03/2013 06:40:19 PM: > Nishanth Aravamudan > 05/03/2013 06:40 PM > > To > > Benjamin Herrenschmidt > > cc > > Michael Neuling , Michael R Meissner/ > Cambridge/IBM@IBMUS, Steve Munroe/Rochester/IBM@IBMUS, Peter > Berg

Re: [PATCH v2 1/4] powerpc/cputable: reserve bits in HWCAP2 for new features

_07 0x8000 #define PPC_FEATURE2_HAS_HTM0x4000 #define PPC_FEATURE2_HAS_DSC0x2000 #define PPC_FEATURE2_HAS_EBB0x1000 #define PPC_FEATURE2_HAS_ISEL 0x0800 #define PPC_FEATURE2_HAS_TAR0x0400 Notice that I changed DSCR to DSC. The 'R' wasn

Re: [PATCH v2 1/4] powerpc/cputable: reserve bits in HWCAP2 for new features

Benjamin Herrenschmidt wrote on 05/06/2013 04:41:01 PM: > Benjamin Herrenschmidt > 05/06/2013 04:41 PM > > To > > Ryan Arnold/Rochester/IBM@IBMUS > > cc > > Nishanth Aravamudan , linuxppc- > d...@lists.ozlabs.org, mich...@ellerman.id.au, Michael R Meissne

Re: [PATCH] arch/powerpc: advertise ISA2.07, HTM, DSCR, EBB and ISEL bits in HWCAP2

Benjamin Herrenschmidt wrote on 05/06/2013 04:37:08 PM: > Benjamin Herrenschmidt > 05/06/2013 04:37 PM > > To > > Ryan Arnold/Rochester/IBM@IBMUS > > cc > > Nishanth Aravamudan , linuxppc- > d...@lists.ozlabs.org, Michael R Meissner/Cambridge/IBM@IBMUS,

Re: SIGSTKSZ/MINSIGSTKSZ too small on 64bit

Alan Modra wrote on 07/26/2013 12:05:28 AM: > Alan Modra > 07/26/2013 12:05 AM > > To > > Anton Blanchard , > > cc > > Michael Neuling , Ryan Arnold/Rochester/ > IBM@IBMUS, linuxppc-dev@lists.ozlabs.org > > Subject > > Re: SIGSTKSZ/MINSIGSTKSZ too

[PATCH 2/3] CXL: Snoop control

Add mode to opal call. SNOOP control turns CAPP unit snooping on/off. This is needed for the following reset patch, which turns snoops off in the CAPP recovery path. Signed-off-by: Ryan Grimm --- arch/powerpc/include/asm/opal.h | 12 arch/powerpc/include/asm/pnv-pci.h

[PATCH 1/3] CXL: Add image control to sysfs

image load. A power cycle is required to load the image. Value of 1 means PERST will cause image load. sysfs updates the cxl struct in the driver then calls cxl_update_image_control to write the vals in the VSEC. Signed-off-by: Ryan Grimm --- Documentation/ABI/testing/sysfs-class-cxl | 15 ++

[PATCH 3/3] CXL: Add reset to sysfs

be used by hand for debugging purposes. Signed-off-by: Ryan Grimm --- Documentation/ABI/testing/sysfs-class-cxl | 6 + drivers/misc/cxl/cxl.h| 1 + drivers/misc/cxl/pci.c| 38 +-- drivers/misc/cxl/sysfs.c

Re: [PATCH 1/3] CXL: Add image control to sysfs

Ian, Thanks for reviewing! On 01/14/2015 11:41 PM, Ian Munsie wrote: Excerpts from Ryan Grimm's message of 2015-01-15 13:56:39 +1100: Add reset_loads_image and reset_image_select to sysfs. reset_image_select identifies which image will be loaded to the card on the next PERST. Valid en

Re: [PATCH 2/3] CXL: Snoop control

On 01/15/2015 12:16 AM, Ian Munsie wrote: Excerpts from Ryan Grimm's message of 2015-01-15 13:56:40 +1100: Add mode to opal call. SNOOP control turns CAPP unit snooping on/off. This is needed for the following reset patch, which turns snoops off in the CAPP recovery path. Looking at pa

Re: [PATCH 3/3] CXL: Add reset to sysfs

On 01/15/2015 12:42 AM, Ian Munsie wrote: Excerpts from Ryan Grimm's message of 2015-01-15 13:56:41 +1100: This allows an image to be downloaded to the flash without rebooting the machine. The driver perform a PERST, which results in FPGA image downloaded to flash and the CAPP unit e

[PATCH 1/3] CXL: Add image control to sysfs

to the pcie slot is required to load the image. "user" loads the user provided image and "factory" loads the factory image upon PERST. sysfs updates the cxl struct in the driver then calls cxl_update_image_control to write the vals in the VSEC. Signed-off-by: Ryan Grimm --- Doc

[PATCH 2/3] CXL: Enable CAPP recovery

Turning snoops on is the last step in CAPP recovery. Sapphire is expected to have reinitialized the PHB and done the previous recovery steps. Add mode argument to opal call to do this. Driver can turn snoops off although it does not currently. Signed-off-by: Ryan Grimm --- arch/powerpc

[PATCH 3/3] CXL: Add ability to reset the card

ays are preserved which then can be read through debugfs. PERST also triggers CAPP recovery. An HMI comes in, which is handled by EEH. EEH unbinds the driver, calls into Sapphire to reinitialize the PHB, then rebinds the driver. Signed-off-by: Ryan Grimm --- Documentation/ABI/testing/sysfs-cla

Re: [PATCH 1/3] CXL: Add image control to sysfs

On 01/15/2015 11:15 PM, Ian Munsie wrote: Hi Ryan, Excerpts from Ryan Grimm's message of 2015-01-16 09:27:15 +1100: reset_image_select identifies whether a PERST will cause the image to be s/reset_image_select/load_image_on_perst/ Ah, thanks, fixed. +What: /sys/clas

Re: [PATCH 3/3] CXL: Add ability to reset the card

On 01/15/2015 11:27 PM, Ian Munsie wrote: Hi Ryan, Excerpts from Ryan Grimm's message of 2015-01-16 09:27:17 +1100: Adds reset to sysfs which will PERST the card. If load_image_on_perst is set to "user" or "factory", the PERST will cause that image to be loaded. load

[PATCH 1/4] CXL: Use image state defaults for reloading FPGA

Select defaults such that a PERST causes flash image reload. Select which image based on what the card is set up to load. CXL_VSEC_PERST_LOADS_IMAGE selects whether PERST assertion causes flash image load. CXL_VSEC_PERST_SELECT_USER selects which image is loaded on the next PERST. cxl_update_im

[PATCH 2/4] CXL: Add image control to sysfs

load_image_on_perst identifies whether a PERST will cause the image to be flashed to the card. And if so, which image. Valid entries are: "none", "user" and "factory". A value of "none" means PERST will not cause the image to be flashed. A power cycle to the pcie slot is required to load the im

[PATCH 3/4] CXL: Enable CAPP recovery

Turning snoops on is the last step in CAPP recovery. Sapphire is expected to have reinitialized the PHB and done the previous recovery steps. Add mode argument to opal call to do this. Driver can turn snoops off although it does not currently. Signed-off-by: Ryan Grimm --- arch/powerpc

[PATCH 4/4] CXL: Add ability to reset the card

ays are preserved which then can be read through debugfs. PERST also triggers CAPP recovery. An HMI comes in, which is handled by EEH. EEH unbinds the driver, calls into Sapphire to reinitialize the PHB, then rebinds the driver. Signed-off-by: Ryan Grimm --- Documentation/ABI/testing/sysfs-class

Re: [PATCH 1/4] CXL: Use image state defaults for reloading FPGA

On 01/19/2015 12:03 AM, Ian Munsie wrote: Acked-by: Ian Munsie Looks like you forgot your Signed-off-by line - mpe, do you want Ryan to resend the whole patch (maybe with the below explanation included), or just reply with a Signed-off-by? OK resending. -Ryan This would also be good to

[PATCH 1/4] CXL: Use image state defaults for reloading FPGA

. cxl_update_image_control writes these bits into the VSEC. Signed-off-by: Ryan Grimm --- Please consider this patch for stable. Without these defaults, the card could get in a bad state and require a power cycle to the box. drivers/misc/cxl/cxl.h | 1 + drivers/misc/cxl/pci.c | 42

[PATCH 2/4] CXL: Add image control to sysfs

to the pcie slot is required to load the image. "user" loads the user provided image and "factory" loads the factory image upon PERST. sysfs updates the cxl struct in the driver then calls cxl_update_image_control to write the vals in the VSEC. Signed-off-by: Rya

[PATCH 4/4] CXL: Add ability to reset the card

ays are preserved which then can be read through debugfs. PERST also triggers CAPP recovery. An HMI comes in, which is handled by EEH. EEH unbinds the driver, calls into Sapphire to reinitialize the PHB, then rebinds the driver. Signed-off-by: Ryan Grimm --- Documentation/ABI/testing/sysfs-class

[PATCH 3/4] CXL: Enable CAPP recovery

Turning snoops on is the last step in CAPP recovery. Sapphire is expected to have reinitialized the PHB and done the previous recovery steps. Add mode argument to opal call to do this. Driver can turn snoops off although it does not currently. Signed-off-by: Ryan Grimm --- arch/powerpc

Re: [PATCH] CXL: Fix device_node reference counting

better than the current patch. See as a comparison pcibios_get_phb_of_node(). We could almost use that instead, except it's not exported for modules and I'm not sure if that even works with __weak functions? Ryan - do you want to respin this, or would you rather I take it?

[PATCH] CXL: Fix device_node reference counting

] [c0009258] syscall_exit+0x0/0x98 We are missing a call to of_node_get. pnv_pci_to_phb_node should call of_node_get otherwise np's reference count isn't incremented and it might go away. Rename pnv_pci_to_phb_node to pnv_pci_get_phb_node so it's clear it calls of_node_get. Signed-off

Re: [PATCH v4 4/8] KVM: PPC: Ultravisor: Use UV_WRITE_PATE ucall to register a PATE

gt; > Both partition tables will have PATE entries for HV and normal > > virtual > > Can you expand novel acronyms on their first usage please, ie. PATE. > Agreed. This confused me a while ago. It is "Partition Table Entry", correct? > > machines. > >

About zImage, vmlinux and yaboot on IBM Power

Hello, I have some question about zImage, vmlinux and yaboot on IBM Power: 1) vmlinux is wrapped into zImage if zImage is used. 2) If yaboot is used, no zImage is needed, just vmlinux/initrd. Are there words right? thanks, ___ Linuxppc-dev maili

What does rmo/tce stand for in powerpc?

Hi, In kernel source comments, I saw the words: '' alloc_top is set to the top of RMO, eventually shrink down if the TCEs overlap '' I wonder what does RMO mean, and TCE? thanks, ___ L

Re: What does rmo/tce stand for in powerpc?

2011/11/2 Nishanth Aravamudan > Hi Ryan, > > On 01.11.2011 [14:25:43 +0800], Ryan Wang wrote: > > Hi, > > > > In kernel source comments, I saw the words: > > '' > > > > alloc_top is set to the top of RMO, eventually shrink down if t

Re: What does rmo/tce stand for in powerpc?

2011/11/3 Scott Wood > On 11/02/2011 06:17 AM, Ryan Wang wrote: > > > > > > 2011/11/2 Nishanth Aravamudan mailto:n...@us.ibm.com>> > > > > Hi Ryan, > > > > On 01.11.2011 [14:25:43 +0800], Ryan Wang wrote: > > > Hi, &g

Re: [PATCH 2/6] powerpc: Add enable_ppr kernel parameter to enable PPR save/restore

under a certain priority when it is, in-fact, not. I don't care for this option. We'll be hitting code paths that are ineffective and unnecessary. Ryan S. Arnold Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

3.4-rc3 compile failed on IBM Power6

# gcc --version gcc (GCC) 4.4.6 20110731 (Red Hat 4.4.6-3) Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. platform: pSeries model: I

Re: Extending virtio_console to support multiple ports

On Thu, 2009-08-27 at 12:22 +0530, Amit Shah wrote: > On (Thu) Aug 27 2009 [15:04:45], Michael Ellerman wrote: > Ryan you called his code "pure legacy baggage" if you > > don't ;) > > > > http://git.kernel.org/?p=linux/kernel/git/to

Program Priority Registers per ISA 2.06

s and we'll supply this when the userspace patch is submitted to GLIBC. We can present that data here in the meantime if requested. Regards, Ryan S. Arnold IBM Linux Technology Center Linux Toolchain development ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev

[RFC] Moving toward smarter disabling of FPRs, VRs, and VSRs in the MSR

benchmark this to verify the expense of the interrupt->enable. As it presently works this stands in the way of using VMX or VSX for optimized string routines in GLIBC. Regards, Ryan S. Arnold IBM Linux Technology Center Linux Toolchain Development ___

Re: [RFC] Moving toward smarter disabling of FPRs, VRs, and VSRs in the MSR

it, i.e. if the size and alignment of the data are in a sweet spot as indicated by profiling data. Regards, Ryan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [RFC] Moving toward smarter disabling of FPRs, VRs, and VSRs in the MSR

rofiling... We can do some VMX testing on existing POWER6 machines. The VSX instruction set hasn't been fully implemented in GCC yet so we'll need to wait a bit for that. Does anyone have an idea for a good VMX/Altivec benchmark? Ryan ___ Li

[PATCH v1 7/8] arm64: hugetlb: Convert set_huge_pte_at() to take vma

Separate commits update the other arches and core code, before the actual bug is fixed in arm64. No behavioral changes intended. Signed-off-by: Ryan Roberts --- arch/arm64/include/asm/hugetlb.h | 2 +- arch/arm64/mm/hugetlbpage.c | 5 +++-- 2 files changed, 4 insertions(+), 3 deletions(-) diff

[PATCH v1 1/8] parisc: hugetlb: Convert set_huge_pte_at() to take vma

Separate commits update the other arches and core code, before the actual bug is fixed in arm64. No behavioral changes intended. Signed-off-by: Ryan Roberts --- arch/parisc/include/asm/hugetlb.h | 2 +- arch/parisc/mm/hugetlbpage.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) di

[PATCH v1 3/8] riscv: hugetlb: Convert set_huge_pte_at() to take vma

Separate commits update the other arches and core code, before the actual bug is fixed in arm64. No behavioral changes intended. Signed-off-by: Ryan Roberts --- arch/riscv/include/asm/hugetlb.h | 2 +- arch/riscv/mm/hugetlbpage.c | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff

[PATCH v1 8/8] arm64: hugetlb: Fix set_huge_pte_at() to work with all swap entries

hat added the uffd poison feature, since that is what exposed the problem, as well as the original change that broke the interface. Hopefully this is valuable for people doing bisect. Signed-off-by: Ryan Roberts Fixes: 18f3962953e4 ("mm: hugetlb: kill set_huge_swap_pte_at()") Fixes: 8a1

[PATCH v1 6/8] mm: hugetlb: Convert set_huge_pte_at() to take vma

core mm. Separate commits update the arches, before the actual bug is fixed in arm64. No behavioral changes intended. Signed-off-by: Ryan Roberts --- include/asm-generic/hugetlb.h | 6 +++--- include/linux/hugetlb.h | 6 +++--- mm/damon/vaddr.c | 2 +- mm/h

[PATCH v1 2/8] powerpc: hugetlb: Convert set_huge_pte_at() to take vma

Separate commits update the other arches and core code, before the actual bug is fixed in arm64. No behavioral changes intended. Signed-off-by: Ryan Roberts --- arch/powerpc/include/asm/nohash/32/hugetlb-8xx.h | 3 ++- arch/powerpc/mm/book3s64/hugetlbpage.c | 2 +- arch/powerpc/mm/

[PATCH v1 4/8] s390: hugetlb: Convert set_huge_pte_at() to take vma

Separate commits update the other arches and core code, before the actual bug is fixed in arm64. No behavioral changes intended. Signed-off-by: Ryan Roberts --- arch/s390/include/asm/hugetlb.h | 8 +--- arch/s390/mm/hugetlbpage.c | 8 +++- 2 files changed, 12 insertions(+), 4 deletions(

[PATCH v1 5/8] sparc: hugetlb: Convert set_huge_pte_at() to take vma

Separate commits update the other arches and core code, before the actual bug is fixed in arm64. No behavioral changes intended. Signed-off-by: Ryan Roberts --- arch/sparc/include/asm/hugetlb.h | 8 +--- arch/sparc/mm/hugetlbpage.c | 8 +++- 2 files changed, 12 insertions(+), 4 d

[PATCH v1 0/8] Fix set_huge_pte_at() panic on arm64

, where I observe the uffd poison test is fixed, and there are no other regressions. Patches --- patches 1-7: Convert core mm and arches to pass vma instead of mm patch: 8: Fixes the arm64 bug Patches based on v6.6-rc2. Thanks, Ryan Ryan Roberts (8): parisc: hugetlb: Convert set_huge_pte

Re: [PATCH v1 0/8] Fix set_huge_pte_at() panic on arm64

On 21/09/2023 17:30, Andrew Morton wrote: > On Thu, 21 Sep 2023 17:19:59 +0100 Ryan Roberts wrote: > >> Hi All, >> >> This series fixes a bug in arm64's implementation of set_huge_pte_at(), which >> can result in an unprivileged user causing a kernel panic

Re: [PATCH v1 2/8] powerpc: hugetlb: Convert set_huge_pte_at() to take vma

On 22/09/2023 07:44, Christophe Leroy wrote: > > > Le 21/09/2023 à 20:43, Christophe Leroy a écrit : >> >> >> Le 21/09/2023 à 18:20, Ryan Roberts a écrit : >>> In order to fix a bug, arm64 needs access to the vma inside it's >>> implementation of

Re: [PATCH v1 2/8] powerpc: hugetlb: Convert set_huge_pte_at() to take vma

On 22/09/2023 07:56, Christophe Leroy wrote: > > > Le 21/09/2023 à 18:20, Ryan Roberts a écrit : >> In order to fix a bug, arm64 needs access to the vma inside it's >> implementation of set_huge_pte_at(). Provide for this by converting the >> mm parameter to be

Re: [PATCH v1 8/8] arm64: hugetlb: Fix set_huge_pte_at() to work with all swap entries

On 22/09/2023 03:54, Qi Zheng wrote: > Hi Ryan, > > On 2023/9/22 00:20, Ryan Roberts wrote: >> When called with a swap entry that does not embed a PFN (e.g. >> PTE_MARKER_POISONED or PTE_MARKER_UFFD_WP), the previous implementation >> of set_huge_pte_at() would eithe

Re: [PATCH v1 0/8] Fix set_huge_pte_at() panic on arm64

On 21/09/2023 18:38, Catalin Marinas wrote: > On Thu, Sep 21, 2023 at 05:35:54PM +0100, Ryan Roberts wrote: >> On 21/09/2023 17:30, Andrew Morton wrote: >>> On Thu, 21 Sep 2023 17:19:59 +0100 Ryan Roberts >>> wrote: >>>> Ryan Roberts (8): >>>>

Re: [PATCH v1 3/8] riscv: hugetlb: Convert set_huge_pte_at() to take vma

On 22/09/2023 08:54, Alexandre Ghiti wrote: > Hi Ryan, > > On 21/09/2023 18:20, Ryan Roberts wrote: >> In order to fix a bug, arm64 needs access to the vma inside it's >> implementation of set_huge_pte_at(). Provide for this by converting the >> mm parameter to be

Re: [PATCH v1 2/8] powerpc: hugetlb: Convert set_huge_pte_at() to take vma

On 22/09/2023 09:10, Christophe Leroy wrote: > > > Le 22/09/2023 à 09:33, Ryan Roberts a écrit : >> On 22/09/2023 07:56, Christophe Leroy wrote: >>> >>> >>> Le 21/09/2023 à 18:20, Ryan Roberts a écrit : >>>> In order to fix a bug, arm64 need

Re: [PATCH v1 8/8] arm64: hugetlb: Fix set_huge_pte_at() to work with all swap entries

On 22/09/2023 08:54, Qi Zheng wrote: > Hi Ryan, > > On 2023/9/22 15:40, Ryan Roberts wrote: >> On 22/09/2023 03:54, Qi Zheng wrote: >>> Hi Ryan, >>> >>> On 2023/9/22 00:20, Ryan Roberts wrote: >>>> When called with a swap entry that

Re: [PATCH v1 2/8] powerpc: hugetlb: Convert set_huge_pte_at() to take vma

On 22/09/2023 10:14, Christophe Leroy wrote: > > > Le 22/09/2023 à 10:41, Ryan Roberts a écrit : >> On 22/09/2023 09:10, Christophe Leroy wrote: >>> >>> >>>> I'm happy to take your proposed approach if that's your preference. Another >&g

[PATCH v2 0/2] Fix set_huge_pte_at() panic on arm64

es to single patch - Simplify powerpc so that is doesn't require __set_huge_page_at() - Added Reviewed-bys [1] https://lore.kernel.org/linux-arm-kernel/20230921162007.1630149-1-ryan.robe...@arm.com/ Thanks, Ryan Ryan Roberts (2): mm: hugetlb: Add huge page size param to set_huge_pte_a

[PATCH v2 1/2] mm: hugetlb: Add huge page size param to set_huge_pte_at()

modifications to the core mm as well as all arches that implement this function (arm64, parisc, powerpc, riscv, s390, sparc). The actual arm64 bug will be fixed in a separate commit. No behavioral changes intended. Signed-off-by: Ryan Roberts Cc: # 6.5+ --- arch/arm64/include/asm/hugetlb.h

[PATCH v2 2/2] arm64: hugetlb: Fix set_huge_pte_at() to work with all swap entries

ied the set_huge_pte_at() interface to pass the huge page size in the previous patch, we can trivially fix this issue. Signed-off-by: Ryan Roberts Fixes: 8a13897fb0da ("mm: userfaultfd: support UFFDIO_POISON for hugetlbfs") Cc: # 6.5+ --- arch/arm64/mm/hugetlbpage.c | 17 +++--

Re: [PATCH v2 1/2] mm: hugetlb: Add huge page size param to set_huge_pte_at()

On 22/09/2023 14:33, Alexandre Ghiti wrote: > On 22/09/2023 13:58, Ryan Roberts wrote: >> In order to fix a bug, arm64 needs to be told the size of the huge page >> for which the pte is being set in set_huge_pte_at(). Provide for this by >> adding an `unsigned long sz` para

Re: [PATCH v2 2/2] arm64: hugetlb: Fix set_huge_pte_at() to work with all swap entries

On 22/09/2023 17:14, Will Deacon wrote: > On Fri, Sep 22, 2023 at 12:58:04PM +0100, Ryan Roberts wrote: >> When called with a swap entry that does not embed a PFN (e.g. >> PTE_MARKER_POISONED or PTE_MARKER_UFFD_WP), the previous implementation >> of set_huge_pte_at() would ei

Re: [PATCH v6 4/9] mm: thp: Introduce anon_orders and anon_always_mask sysfs files

On 29/09/2023 23:55, Andrew Morton wrote: > On Fri, 29 Sep 2023 12:44:15 +0100 Ryan Roberts wrote: > >> In preparation for adding support for anonymous large folios that are >> smaller than the PMD-size, introduce 2 new sysfs files that will be used >> to control th

Re: [RFC PATCH v11 12/29] KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory

> +static struct folio *kvm_gmem_get_folio(struct file *file, pgoff_t index) > +{ > + struct folio *folio; > + > + /* TODO: Support huge pages. */ > + folio = filemap_grab_folio(file->f_mapping, index); > + if (!folio) > + return NULL; In Linux 6.4, filemap_grab_folio()

Re: [PATCH RFC 06/12] mm/gup: Drop folio_fast_pin_allowed() in hugepd processing

On 23/11/2023 17:22, Peter Xu wrote: > On Thu, Nov 23, 2023 at 03:47:49PM +, Matthew Wilcox wrote: >> It looks like ARM (in the person of Ryan) are going to add support for >> something equivalent to hugepd. > > If it's about arm's cont_pte, then it looks ide

Re: [PATCH RFC 06/12] mm/gup: Drop folio_fast_pin_allowed() in hugepd processing

On 23/11/2023 19:46, Peter Xu wrote: > On Thu, Nov 23, 2023 at 07:11:19PM +0000, Ryan Roberts wrote: >> Hi, >> >> I'm not sure I've 100% understood the crossover between this series and my >> work >> to support arm64's contpte mappings generally f

Re: [PATCH RFC 06/12] mm/gup: Drop folio_fast_pin_allowed() in hugepd processing

On 03/12/2023 13:33, Christophe Leroy wrote: > > > Le 30/11/2023 à 22:30, Peter Xu a écrit : >> On Fri, Nov 24, 2023 at 11:07:51AM -0500, Peter Xu wrote: >>> On Fri, Nov 24, 2023 at 09:06:01AM +, Ryan Roberts wrote: >>>> I don't have any micro-

Re: [PATCH RFC 06/12] mm/gup: Drop folio_fast_pin_allowed() in hugepd processing

On 04/12/2023 11:25, Christophe Leroy wrote: > > > Le 04/12/2023 à 12:11, Ryan Roberts a écrit : >> On 03/12/2023 13:33, Christophe Leroy wrote: >>> >>> >>> Le 30/11/2023 à 22:30, Peter Xu a écrit : >>>> On Fri, Nov 24, 2023 at 11:07:51AM -

Re: [PATCH RFC 06/12] mm/gup: Drop folio_fast_pin_allowed() in hugepd processing

On 04/12/2023 11:57, Christophe Leroy wrote: > > > Le 04/12/2023 à 12:46, Ryan Roberts a écrit : >> On 04/12/2023 11:25, Christophe Leroy wrote: >>> >>> >>> Le 04/12/2023 à 12:11, Ryan Roberts a écrit : >>>> On 03/12/2023 13:33, Christoph

Re: [PATCH v2 06/13] mm/gup: Drop folio_fast_pin_allowed() in hugepd processing

uld start to follow Ryan's > generic work for ARM contig: > > https://lore.kernel.org/all/20231218105100.172635-1-ryan.robe...@arm.com/ > > Specifically the arch implementation: > > https://lore.kernel.org/linux-mm/20231218105100.172635-15-ryan.robe...@arm.com/ >

Re: [PATCH v1 01/11] arm/pgtable: define PFN_PTE_SHIFT on arm and arm64

On 22/01/2024 19:41, David Hildenbrand wrote: > We want to make use of pte_next_pfn() outside of set_ptes(). Let's > simpliy define PFN_PTE_SHIFT, required by pte_next_pfn(). > > Signed-off-by: David Hildenbrand > --- > arch/arm/include/asm/pgtable.h | 2 ++ > arch/arm64/include/asm/pgtable.h

Re: [PATCH v1 07/11] mm/memory: factor out copying the actual PTE in copy_present_pte()

On 22/01/2024 19:41, David Hildenbrand wrote: > Let's prepare for further changes. > > Signed-off-by: David Hildenbrand Reviewed-by: Ryan Roberts > --- > mm/memory.c | 60 - > 1 file changed, 32 insertions(+), 28

Re: [PATCH v1 08/11] mm/memory: pass PTE to copy_present_pte()

On 22/01/2024 19:41, David Hildenbrand wrote: > We already read it, let's just forward it. > > This patch is based on work by Ryan Roberts. > > Signed-off-by: David Hildenbrand Reviewed-by: Ryan Roberts > --- > mm/memory.c | 7 +++ > 1 file changed,

Re: [PATCH v1 01/11] arm/pgtable: define PFN_PTE_SHIFT on arm and arm64

On 23/01/2024 10:48, David Hildenbrand wrote: > On 23.01.24 11:34, Ryan Roberts wrote: >> On 22/01/2024 19:41, David Hildenbrand wrote: >>> We want to make use of pte_next_pfn() outside of set_ptes(). Let's >>> simpliy define PFN_PTE_SHIFT, required by pte_next_pfn

Re: [PATCH v1 01/11] arm/pgtable: define PFN_PTE_SHIFT on arm and arm64

On 23/01/2024 11:02, David Hildenbrand wrote: > On 23.01.24 11:48, David Hildenbrand wrote: >> On 23.01.24 11:34, Ryan Roberts wrote: >>> On 22/01/2024 19:41, David Hildenbrand wrote: >>>> We want to make use of pte_next_pfn() outside of set_ptes(). Let'

Re: [PATCH v1 01/11] arm/pgtable: define PFN_PTE_SHIFT on arm and arm64

On 23/01/2024 11:31, David Hildenbrand wrote: >>> If high bits are used for something else, then we might produce a garbage PTE on overflow, but that shouldn't really matter I concluded for folio_pte_batch() purposes, we'd not detect "belongs to this folio batch" either wa

Re: [PATCH v1 01/11] arm/pgtable: define PFN_PTE_SHIFT on arm and arm64

On 23/01/2024 11:33, David Hildenbrand wrote: > On 23.01.24 12:17, Ryan Roberts wrote: >> On 23/01/2024 11:02, David Hildenbrand wrote: >>> On 23.01.24 11:48, David Hildenbrand wrote: >>>> On 23.01.24 11:34, Ryan Roberts wrote: >>>>> On 22/01/2024 19:4

Re: [PATCH v1 09/11] mm/memory: optimize fork() with PTE-mapped THP

ome other > PTE bits. This patch is based on work by Ryan Roberts. > > Use __always_inline for __copy_present_ptes() and keep the handling for > single PTEs completely separate from the multi-PTE case: we really want > the compiler to optimize for the single-PTE case with small f

Re: [PATCH v1 10/11] mm/memory: ignore dirty/accessed/soft-dirty bits in folio_pte_batch()

On 22/01/2024 19:41, David Hildenbrand wrote: > Let's ignore these bits: they are irrelevant for fork, and will likely > be irrelevant for upcoming users such as page unmapping. > > Signed-off-by: David Hildenbrand > --- > mm/memory.c | 10 -- > 1 file changed, 8 insertions(+), 2 deletio

Re: [PATCH v1 09/11] mm/memory: optimize fork() with PTE-mapped THP

On 23/01/2024 12:19, David Hildenbrand wrote: > [...] > >> >> I wrote some documentation for this (based on Matthew's docs for set_ptes() >> in >> my version. Perhaps it makes sense to add it here, given this is overridable >> by >> the arch. >> >> /** >>   * wrprotect_ptes - Write protect a con

Re: [PATCH v1 11/11] mm/memory: ignore writable bit in folio_pte_batch()

Signed-off-by: David Hildenbrand Reviewed-by: Ryan Roberts > --- > mm/memory.c | 26 +- > 1 file changed, 21 insertions(+), 5 deletions(-) > > diff --git a/mm/memory.c b/mm/memory.c > index 341b2be845b6e..a26fd0669016b 100644 > --- a/mm/memory.c > ++

Re: [PATCH v1 10/11] mm/memory: ignore dirty/accessed/soft-dirty bits in folio_pte_batch()

On 23/01/2024 13:06, David Hildenbrand wrote: > On 23.01.24 13:25, Ryan Roberts wrote: >> On 22/01/2024 19:41, David Hildenbrand wrote: >>> Let's ignore these bits: they are irrelevant for fork, and will likely >>> be irrelevant for upcoming users such as page

Re: [PATCH v1 10/11] mm/memory: ignore dirty/accessed/soft-dirty bits in folio_pte_batch()

On 23/01/2024 14:13, David Hildenbrand wrote: >>> Although now I'm wondering if there is a race here... What happens if a >>> page in >>> the parent becomes dirty after you have checked it but before you write >>> protect >>> it? Isn't that already a problem with the current non-batched version?

Re: [PATCH v1 01/11] arm/pgtable: define PFN_PTE_SHIFT on arm and arm64

On 23/01/2024 15:01, Matthew Wilcox wrote: > On Tue, Jan 23, 2024 at 10:34:21AM +0000, Ryan Roberts wrote: >>> +#define PFN_PTE_SHIFT PAGE_SHIFT >> >> I think this is buggy. And so is the arm64 implementation of set_ptes(). It >> works fine for 48-bit

Re: [PATCH v1 00/11] mm/memory: optimize fork() with PTE-mapped THP

On 22/01/2024 19:41, David Hildenbrand wrote: > Now that the rmap overhaul[1] is upstream that provides a clean interface > for rmap batching, let's implement PTE batching during fork when processing > PTE-mapped THPs. > > This series is partially based on Ryan's previous work[2] to implement > co

Re: [PATCH v1 00/11] mm/memory: optimize fork() with PTE-mapped THP

On 23/01/2024 19:33, David Hildenbrand wrote: > On 23.01.24 20:15, Ryan Roberts wrote: >> On 22/01/2024 19:41, David Hildenbrand wrote: >>> Now that the rmap overhaul[1] is upstream that provides a clean interface >>> for rmap batching, let's implement PTE batc

Re: [PATCH v1 00/11] mm/memory: optimize fork() with PTE-mapped THP

On 23/01/2024 20:14, David Hildenbrand wrote: > On 23.01.24 20:43, Ryan Roberts wrote: >> On 23/01/2024 19:33, David Hildenbrand wrote: >>> On 23.01.24 20:15, Ryan Roberts wrote: >>>> On 22/01/2024 19:41, David Hildenbrand wrote: >>>>> Now that the

Re: [PATCH v2 13/15] mm/memory: optimize fork() with PTE-mapped THP

ted > PTE bits. This patch is based on work by Ryan Roberts. > > Use __always_inline for __copy_present_ptes() and keep the handling for > single PTEs completely separate from the multi-PTE case: we really want > the compiler to optimize for the single-PTE case with small f

Re: [PATCH v2 14/15] mm/memory: ignore dirty/accessed/soft-dirty bits in folio_pte_batch()

any meaning in > the src vma, and similarly won't have any in the copied dst vma. > > For now, we won't bother with the uffd-wp bit. > > Signed-off-by: David Hildenbrand Reviewed-by: Ryan Roberts > --- > mm/memory.c | 36 +++-

Re: [PATCH v1 1/9] mm/memory: factor out zapping of present pte into zap_present_pte()

On 29/01/2024 14:32, David Hildenbrand wrote: > Let's prepare for further changes by factoring out processing of present > PTEs. > > Signed-off-by: David Hildenbrand > --- > mm/memory.c | 92 ++--- > 1 file changed, 52 insertions(+), 40 deletions(-

Re: [PATCH v1 2/9] mm/memory: handle !page case in zap_present_pte() separately

by a single "!page" one. > > Signed-off-by: David Hildenbrand Reviewed-by: Ryan Roberts > --- > mm/memory.c | 20 ++-- > 1 file changed, 10 insertions(+), 10 deletions(-) > > diff --git a/mm/memory.c b/mm/memory.c > index 50a6c79c78fc..69502cd

Re: [PATCH v1 3/9] mm/memory: further separate anon and pagecache folio handling in zap_present_pte()

On 29/01/2024 14:32, David Hildenbrand wrote: > We don't need up-to-date accessed-dirty information for anon folios and can > simply work with the ptent we already have. Also, we know the RSS counter > we want to update. > > We can safely move arch_check_zapped_pte() + tlb_remove_tlb_entry() + > z

Re: [PATCH v1 5/9] mm/mmu_gather: pass "delay_rmap" instead of encoded page to __tlb_remove_page_size()

ly for batching of > multiple pages of the same folio, specifying that the next encoded page > pointer in an array is actually "nr_pages". So pass page + delay_rmap flag > instead of an encoded page, to handle the encoding internally. > > Signed-off-by: David Hildenbrand R

Re: [PATCH v1 3/9] mm/memory: further separate anon and pagecache folio handling in zap_present_pte()

On 30/01/2024 08:37, David Hildenbrand wrote: > On 30.01.24 09:31, Ryan Roberts wrote: >> On 29/01/2024 14:32, David Hildenbrand wrote: >>> We don't need up-to-date accessed-dirty information for anon folios and can >>> simply work with the ptent we already hav

Re: [PATCH v1 1/9] mm/memory: factor out zapping of present pte into zap_present_pte()

On 30/01/2024 08:41, David Hildenbrand wrote: > On 30.01.24 09:13, Ryan Roberts wrote: >> On 29/01/2024 14:32, David Hildenbrand wrote: >>> Let's prepare for further changes by factoring out processing of present >>> PTEs. >>> >>> Signed-off-by:

Re: [PATCH v1 4/9] mm/memory: factor out zapping folio pte into zap_present_folio_pte()

On 29/01/2024 14:32, David Hildenbrand wrote: > Let's prepare for further changes by factoring it out into a separate > function. > > Signed-off-by: David Hildenbrand Reviewed-by: Ryan Roberts > --- > mm/memory.c | 53

  1   2   3   >