Re: [PATCH v6 00/14] x86: Trenchboot secure dynamic launch Linux kernel support

2023-05-10 Thread Bagas Sanjaya
On Thu, May 04, 2023 at 02:50:09PM +, Ross Philipson wrote: > This patchset provides detailed documentation of DRTM, the approach used for > adding the capbility, and relevant API/ABI documentation. In addition to the > documentation the patch set introduces Intel TXT support as the first platf

Re: [PATCH v6 02/14] Documentation/x86: Secure Launch kernel documentation

2023-05-10 Thread Bagas Sanjaya
e SL stub. > + - SL stub fixes up the world on the BSP. > + - For TXT, SL stub wakes the APs, fixes up their worlds. > + - For TXT, APs are left halted waiting for an NMI to wake them. > + - SL stub jumps to startup_32. > + - SL main does validation of buffers and memory locations.

Re: [PATCH v6 00/14] x86: Trenchboot secure dynamic launch Linux kernel support

2023-05-06 Thread Bagas Sanjaya
On 5/5/23 22:45, Ross Philipson wrote: > Sorry about that. In the future I will include a base-commit field. It is > based off of torvolds/master as of 5/1/2023. The branch where the patches > came from is now pushed to the TrenchBoot repository here: > > https://github.com/TrenchBoot/linux/tree

Re: [PATCH v5 3/3] kexec: Introduce sysctl parameters kexec_load_limit_*

2023-01-05 Thread Bagas Sanjaya
On Wed, Dec 21, 2022 at 08:45:59PM +0100, Ricardo Ribalda wrote: > += = > +-1 Unlimited calls to kexec. This is the default setting. > +N Number of calls left. > += = > + > +k

Re: [PATCH V2 2/2] Documentation: kdump: describe VMCOREINFO export for RISCV64

2022-10-21 Thread Bagas Sanjaya
LES_END : Kernel module space. > + * VMALLOC_START ~ VMALLOC_END : vmalloc() / ioremap() space. > + * VMEMMAP_START ~ VMEMMAP_END : vmemmap region, used for struct page array. > + * KASAN_SHADOW_START ~ KASAN_SHADOW_END : kasan shadow space. > + * KERNEL_LINK_ADDR ~ ADDRESS_SPACE_END :

Re: [PATCH V4 2/2] Documentation: kdump: describe VMCOREINFO export for RISCV64

2022-10-19 Thread Bagas Sanjaya
MODULES_VADDR ~ MODULES_END, > VMALLOC_START ~ VMALLOC_END, > VMEMMAP_START ~ VMEMMAP_END, > > Document these RISCV64 exports above. > > Signed-off-by: Xianting Tian Hi Xianting, Seems like you forgot to keep carrying my Reviewed-by from v3 [1]. Anyway, here it

Re: [PATCH V2 2/2] Documentation: kdump: describe VMCOREINFO export for RISCV64

2022-10-18 Thread Bagas Sanjaya
On 10/18/22 13:06, Xianting Tian wrote: > > 在 2022/10/18 上午11:19, Bagas Sanjaya 写道: >> On Fri, Oct 14, 2022 at 09:41:39PM +0800, Xianting Tian wrote: >>> The following interrelated definitions and ranges are needed by the kdump >>> crash tool, they are exported by &

Re: [PATCH 2/2] Documentation: kdump: describe VMCOREINFO export for RISCV64

2022-10-14 Thread Bagas Sanjaya
On Fri, Oct 14, 2022 at 03:48:10PM +0800, Xianting Tian wrote: > The following interrelated definitions and ranges are needed by the kdump > crash tool, they are exported by "arch/riscv/kernel/crash_core.c": > VA_BITS, > PAGE_OFFSET, > phys_ram_base, > MODULES_VADDR ~ MODULES_END, >

Re: [PATCH 2/2] Documentation: kdump: describe VMCOREINFO export for RISCV64

2022-10-14 Thread Bagas Sanjaya
On 10/14/22 20:10, Conor Dooley wrote: > Without whitespace highlighting, your change threw me for a sec.. But > yeah, having the overline is inconsistent with other headings in the > doc. > > What I wanted to ask about was the linelength as I don't know anything > about rst. Is it possible to avo

Re: [PATCH V6 6/6] Documentation: kdump: describe VMCOREINFO export for RISCV64

2022-08-11 Thread Bagas Sanjaya
On 8/11/22 14:41, Xianting Tian wrote: > The following interrelated definitions and ranges are needed by the kdump > crash tool, they are exported by "arch/riscv/kernel/crash_core.c": > VA_BITS, PAGE_OFFSET, phys_ram_base > MODULES_VADDR ~ MODULES_END, > VMALLOC_START ~ VMALLOC_END, >

Re: [PATCH V5 5/6] riscv: crash_core: Export kernel vm layout, phys_ram_base

2022-08-10 Thread Bagas Sanjaya
On Tue, Aug 02, 2022 at 08:18:17PM +0800, Xianting Tian wrote: > These infos are needed by the kdump crash tool. Since these values change > from time to time, it is preferable to export them via vmcoreinfo than to > change the crash's code frequently. > I have to agree with Conor.Dooley, that th