Re: [PATCH v2 4/9] mm: vmalloc: Remove global vmap_area_root rb-tree

2023-09-07 Thread Baoquan He
On 09/07/23 at 10:17am, Baoquan He wrote: > Add Kazu and Lianbo to CC, and kexec mailing list > > On 08/29/23 at 10:11am, Uladzislau Rezki (Sony) wrote: > > Store allocated objects in a separate nodes. A va->va_start > > address is converted into a correct node where it should > > be placed and re

Re: [PATCH v2 4/9] mm: vmalloc: Remove global vmap_area_root rb-tree

2023-09-07 Thread Uladzislau Rezki
On Thu, Sep 07, 2023 at 10:17:39AM +0800, Baoquan He wrote: > Add Kazu and Lianbo to CC, and kexec mailing list > > On 08/29/23 at 10:11am, Uladzislau Rezki (Sony) wrote: > > Store allocated objects in a separate nodes. A va->va_start > > address is converted into a correct node where it should >

Re: [PATCH v2 4/9] mm: vmalloc: Remove global vmap_area_root rb-tree

2023-09-07 Thread Uladzislau Rezki
On Thu, Sep 07, 2023 at 05:38:07PM +0800, Baoquan He wrote: > On 09/07/23 at 10:17am, Baoquan He wrote: > > Add Kazu and Lianbo to CC, and kexec mailing list > > > > On 08/29/23 at 10:11am, Uladzislau Rezki (Sony) wrote: > > > Store allocated objects in a separate nodes. A va->va_start > > > addre

Re: [PATCH v2 4/9] mm: vmalloc: Remove global vmap_area_root rb-tree

2023-09-07 Thread Baoquan He
On 09/07/23 at 11:39am, Uladzislau Rezki wrote: > On Thu, Sep 07, 2023 at 10:17:39AM +0800, Baoquan He wrote: > > Add Kazu and Lianbo to CC, and kexec mailing list > > > > On 08/29/23 at 10:11am, Uladzislau Rezki (Sony) wrote: > > > Store allocated objects in a separate nodes. A va->va_start > > >

Re: [PATCH 3/3] /dev/mem: Do not map unaccepted memory

2023-09-07 Thread Kirill A. Shutemov
On Wed, Sep 06, 2023 at 10:39:02AM +0300, Adrian Hunter wrote: > Support for unaccepted memory was added recently, refer commit > dcdfdd40fa82 ("mm: Add support for unaccepted memory"), whereby > a virtual machine may need to accept memory before it can be used. > > Do not map unaccepted memory be

Re: [PATCH 0/3] Do not map unaccepted memory

2023-09-07 Thread Kirill A. Shutemov
On Wed, Sep 06, 2023 at 10:38:59AM +0300, Adrian Hunter wrote: > Hi > > Support for unaccepted memory was added recently, refer commit > dcdfdd40fa82 ("mm: Add support for unaccepted memory"), whereby > a virtual machine may need to accept memory before it can be used. > > Plug a few gaps where R

[PATCH V1 0/3] riscv: kexec: cleanup and fixups

2023-09-07 Thread Song Shuai
Hi, I had posted 2 patches [1][2] for riscv/kexec, but there was no "effective" response to them until now, so I merged them in this series with the 3rd fixup. Anyway, this series contains a cleanup for riscv_kexec_relocate() and two fixups for KEXEC_FILE and had passed the basic kexec test in my

[PATCH V1 1/3] riscv: kexec: Cleanup riscv_kexec_relocate

2023-09-07 Thread Song Shuai
For readability and simplicity, cleanup the riscv_kexec_relocate code: - Re-sort the first 4 `mv` instructions against `riscv_kexec_method()` - Eliminate registers for debugging (s9,s10,s11) and storing const-value (s5,s6) - Replace `jalr` with `jr` for no-link jump I tested this on Qemu virt mac

[PATCH V1 3/3] riscv: kexec: Remove -fPIE for PURGATORY_CFLAGS

2023-09-07 Thread Song Shuai
With CONFIG_RELOCATABLE enabled, KBUILD_CFLAGS had a -fPIE option and then the purgatory/string.o was built to reference _ctype symbol via R_RISCV_GOT_HI20 relocations which can't be handled by purgatory. As a consequence, the kernel failed kexec_load_file() with: [ 880.386562] kexec_image: The

[PATCH V1 2/3] riscv: kexec: Align the kexeced kernel entry

2023-09-07 Thread Song Shuai
The current riscv boot protocol requires 2MB alignment for RV64 and 4MB alignment for RV32. In KEXEC_FILE path, the elf_find_pbase() function should align the kexeced kernel entry according to the requirement, otherwise the kexeced kernel would silently BUG at the setup_vm(). Fixes: 8acea455fafa

Re: [PATCH 3/3] /dev/mem: Do not map unaccepted memory

2023-09-07 Thread Dave Hansen
On 9/6/23 00:39, Adrian Hunter wrote: > Support for unaccepted memory was added recently, refer commit > dcdfdd40fa82 ("mm: Add support for unaccepted memory"), whereby > a virtual machine may need to accept memory before it can be used. > > Do not map unaccepted memory because it can cause the gu

Re: [PATCH 3/3] /dev/mem: Do not map unaccepted memory

2023-09-07 Thread Kirill A. Shutemov
On Thu, Sep 07, 2023 at 07:15:21AM -0700, Dave Hansen wrote: > On 9/6/23 00:39, Adrian Hunter wrote: > > Support for unaccepted memory was added recently, refer commit > > dcdfdd40fa82 ("mm: Add support for unaccepted memory"), whereby > > a virtual machine may need to accept memory before it can b

Re: [PATCH 3/3] /dev/mem: Do not map unaccepted memory

2023-09-07 Thread Dave Hansen
On 9/7/23 07:25, Kirill A. Shutemov wrote: > On Thu, Sep 07, 2023 at 07:15:21AM -0700, Dave Hansen wrote: >> On 9/6/23 00:39, Adrian Hunter wrote: >>> Support for unaccepted memory was added recently, refer commit >>> dcdfdd40fa82 ("mm: Add support for unaccepted memory"), whereby >>> a virtual mac

Re: [PATCH 3/3] /dev/mem: Do not map unaccepted memory

2023-09-07 Thread Dave Hansen
On 9/7/23 07:46, Dave Hansen wrote: > Can a line of code in this patch even run in the face of IO_STRICT_DEVMEM=y? Gah, I meant plain old STRICT_DEVMEM=y. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 2/3] proc/kcore: Do not map unaccepted memory

2023-09-07 Thread Dave Hansen
On 9/6/23 00:39, Adrian Hunter wrote: > +static bool pfn_is_unaccepted_memory(unsigned long pfn) > +{ > + phys_addr_t paddr = pfn << PAGE_SHIFT; > + > + return range_contains_unaccepted_memory(paddr, paddr + PAGE_SIZE); > +} Please just add this as an inline helper to common code rather th

Re: [PATCH 1/3] proc/vmcore: Do not map unaccepted memory

2023-09-07 Thread Dave Hansen
On 9/6/23 00:39, Adrian Hunter wrote: > @@ -559,7 +567,8 @@ static int vmcore_remap_oldmem_pfn(struct vm_area_struct > *vma, >* pages without a reason. >*/ > idx = srcu_read_lock(&vmcore_cb_srcu); > - if (!list_empty(&vmcore_cb_list)) > + if (!list_empty(&vmcore_cb_li

Re: [PATCH 2/3] proc/kcore: Do not map unaccepted memory

2023-09-07 Thread Dave Hansen
On 9/6/23 00:39, Adrian Hunter wrote: > Do not map unaccepted memory because it can cause the guest to fail. > > For /proc/kcore, which is read-only and does not support mmap, this means a > read of unaccepted memory will return zeros. I'm confused by this changelog and subject. What is getting

Re: [PATCH 1/3] proc/vmcore: Do not map unaccepted memory

2023-09-07 Thread Adrian Hunter
On 7/09/23 18:39, Dave Hansen wrote: > On 9/6/23 00:39, Adrian Hunter wrote: >> @@ -559,7 +567,8 @@ static int vmcore_remap_oldmem_pfn(struct vm_area_struct >> *vma, >> * pages without a reason. >> */ >> idx = srcu_read_lock(&vmcore_cb_srcu); >> -if (!list_empty(&vmcore_cb_lis

Re: [PATCH 1/3] proc/vmcore: Do not map unaccepted memory

2023-09-07 Thread Dave Hansen
On 9/7/23 08:44, Adrian Hunter wrote: > On 7/09/23 18:39, Dave Hansen wrote: >> On 9/6/23 00:39, Adrian Hunter wrote: >>> @@ -559,7 +567,8 @@ static int vmcore_remap_oldmem_pfn(struct >>> vm_area_struct *vma, >>> * pages without a reason. >>> */ >>> idx = srcu_read_lock(&vmcore_cb_sr

Re: [RFC] IMA Log Snapshotting Design Proposal - network bandwidth

2023-09-07 Thread Paul Moore
On Wed, Sep 6, 2023 at 4:21 PM Ken Goldman wrote: > On 9/1/2023 5:20 PM, Tushar Sugandhi wrote: > > On 8/30/23 11:06, Ken Goldman wrote: > >> On 8/1/2023 3:12 PM, Sush Shringarputale wrote: > >>> In addition, a large IMA log can add pressure on the network > >>> bandwidth when > >>> the attestatio

Re: [RFC] IMA Log Snapshotting Design Proposal - aggregate

2023-09-07 Thread Paul Moore
On Wed, Sep 6, 2023 at 4:49 PM Ken Goldman wrote: > On 9/1/2023 6:06 PM, Tushar Sugandhi wrote: > > On 8/30/23 11:12, Ken Goldman wrote: > >> On 8/1/2023 3:12 PM, Sush Shringarputale wrote: > >>> - A user-mode process will trigger the snapshot by opening a file in > >>> SysFS > >>>say /sys/ker

Re: [PATCH v7 0/4] kexec: Fix kexec_file_load for llvm16 with PGO

2023-09-07 Thread Song Liu
Hi Ricardo and folks, On Fri, May 19, 2023 at 7:48 AM Ricardo Ribalda wrote: > > When upreving llvm I realised that kexec stopped working on my test > platform. > > The reason seems to be that due to PGO there are multiple .text sections > on the purgatory, and kexec does not supports that. > > S

Re: [PATCH v2 4/9] mm: vmalloc: Remove global vmap_area_root rb-tree

2023-09-07 Thread 萩尾 一仁
On 2023/09/07 18:58, Baoquan He wrote: > On 09/07/23 at 11:39am, Uladzislau Rezki wrote: >> On Thu, Sep 07, 2023 at 10:17:39AM +0800, Baoquan He wrote: >>> Add Kazu and Lianbo to CC, and kexec mailing list >>> >>> On 08/29/23 at 10:11am, Uladzislau Rezki (Sony) wrote: Store allocated objects i

Re: [PATCH v2 4/9] mm: vmalloc: Remove global vmap_area_root rb-tree

2023-09-07 Thread Baoquan He
On 09/08/23 at 01:51am, HAGIO KAZUHITO(萩尾 一仁) wrote: > On 2023/09/07 18:58, Baoquan He wrote: > > On 09/07/23 at 11:39am, Uladzislau Rezki wrote: > >> On Thu, Sep 07, 2023 at 10:17:39AM +0800, Baoquan He wrote: > >>> Add Kazu and Lianbo to CC, and kexec mailing list > >>> > >>> On 08/29/23 at 10:11

Re: [PATCH v2 4/9] mm: vmalloc: Remove global vmap_area_root rb-tree

2023-09-07 Thread 萩尾 一仁
On 2023/09/08 13:43, Baoquan He wrote: > On 09/08/23 at 01:51am, HAGIO KAZUHITO(萩尾 一仁) wrote: >> On 2023/09/07 18:58, Baoquan He wrote: >>> On 09/07/23 at 11:39am, Uladzislau Rezki wrote: On Thu, Sep 07, 2023 at 10:17:39AM +0800, Baoquan He wrote: > Add Kazu and Lianbo to CC, and kexec mai

Re: [PATCH v2 1/3] powerpc/fadump: make is_fadump_active() visible for exporting vmcore

2023-09-07 Thread Hari Bathini
Thanks, Baoquan. On 07/09/23 11:12 am, Baoquan He wrote: On 09/06/23 at 12:06am, Hari Bathini wrote: Include asm/fadump.h in asm/kexec.h to make it visible while exporting vmcore. Also, update is_fadump_active() to return boolean instead of integer for better readability. The change will be use

Re: [PATCH v2 4/9] mm: vmalloc: Remove global vmap_area_root rb-tree

2023-09-07 Thread Baoquan He
On 09/08/23 at 05:01am, HAGIO KAZUHITO(萩尾 一仁) wrote: > On 2023/09/08 13:43, Baoquan He wrote: > > On 09/08/23 at 01:51am, HAGIO KAZUHITO(萩尾 一仁) wrote: > >> On 2023/09/07 18:58, Baoquan He wrote: > >>> On 09/07/23 at 11:39am, Uladzislau Rezki wrote: > On Thu, Sep 07, 2023 at 10:17:39AM +0800, B