On 12/26/18 at 11:24am, Dave Young wrote:
> > >> +
> > >> +KERNEL_IMAGE_SIZE
> > >> +=
> > >> +The size of 'KERNEL_IMAGE_SIZE', currently unused.
> > >
> > > So remove?
> > >
> >
> &g
Add Kazu and Dave in cc
On 12/20/18 at 01:40pm, Lianbo Jiang wrote:
> This patchset did two things:
> a. add a new document for vmcoreinfo
>
> This document lists some variables that export to vmcoreinfo, and briefly
> describles what these variables indicate. It should be instructive for
> many
> >> +
> >> +KERNEL_IMAGE_SIZE
> >> +=
> >> +The size of 'KERNEL_IMAGE_SIZE', currently unused.
> >
> > So remove?
> >
>
> I'm not sure whether it should be removed, so i keep it.
Just remove it. It was added by Baoquan for KASLR issues, later
makedumpfile reverted the userspac
> >> +init_uts_ns
> >> +===
> >> +This is the UTS namespace, which is used to isolate two specific elements
> >> +of the system that relate to the uname system call. The UTS namespace is
> >> +named after the data structure used to store information returned by the
> >> +uname system call.
logically offline memory (pages kept fake offline while
> onlining a section via online_page_callback) would under some condicions
> result in a kernel panic when dumping them.
>
> Cc: Andrew Morton
> Cc: Dave Young
> Cc: "Kirill A. Shutemov"
> Cc: Baoquan He
> Cc: O
ferent opinion :)
>
> Cc: Andrew Morton
> Cc: Dave Young
> Cc: "Kirill A. Shutemov"
> Cc: Baoquan He
> Cc: Omar Sandoval
> Cc: Arnd Bergmann
> Cc: Matthew Wilcox
> Cc: Michal Hocko
> Cc: "Michael S. Tsirkin"
> Signed-off-by: David Hi
Hi,
On 02/13/18 at 04:22pm, Gioh Kim wrote:
> Jumping between the system kernel and the dump-capture kernel
> has been supported for long time but there is no description
> how to use it. This patch adds the description how to use kexec tool
> to jump to the dump-capture kernel and jump back to the
On 05/26/17 at 12:17pm, Xunlei Pang wrote:
> On 04/19/2017 at 05:21 AM, Tom Lendacky wrote:
> > Provide support so that kexec can be used to boot a kernel when SME is
> > enabled.
> >
> > Support is needed to allocate pages for kexec without encryption. This
> > is needed in order to be able to re
Ccing Xunlei he is reading the patches see what need to be done for
kdump. There should still be several places to handle to make kdump work.
On 05/18/17 at 07:01pm, Borislav Petkov wrote:
> On Tue, Apr 18, 2017 at 04:22:12PM -0500, Tom Lendacky wrote:
> > Add sysfs support for SME so that user-sp
Add Takahiro and Pratyush, they should be able to review the arm64 part.
On 05/18/17 at 11:03am, Bharat Bhushan wrote:
> This patch have minor updates in Documentation for arm64i as
> relocatable kernel.
> Also this patch updates documentation for using uncompressed
> image "Image" which is used f
On 04/27/17 at 08:52am, Dave Hansen wrote:
> On 04/27/2017 12:25 AM, Dave Young wrote:
> > On 04/21/17 at 02:55pm, Dave Hansen wrote:
> >> On 04/18/2017 02:22 PM, Tom Lendacky wrote:
> >>> Add sysfs support for SME so that user-space utilities (kdump, etc.) can
&g
On 04/21/17 at 02:55pm, Dave Hansen wrote:
> On 04/18/2017 02:22 PM, Tom Lendacky wrote:
> > Add sysfs support for SME so that user-space utilities (kdump, etc.) can
> > determine if SME is active.
> >
> > A new directory will be created:
> > /sys/kernel/mm/sme/
> >
> > And two entries within t
On 03/06/17 at 11:58am, Tom Lendacky wrote:
> On 3/1/2017 3:25 AM, Dave Young wrote:
> > Hi Tom,
>
> Hi Dave,
>
> >
> > On 02/17/17 at 10:43am, Tom Lendacky wrote:
> > > On 2/17/2017 9:57 AM, Konrad Rzeszutek Wilk wrote:
> > > > On Thu, F
50,13 +251,13 @@ static int __init get_setup_data_total_num(u64 pa_data,
> int *nr)
> *nr = 0;
> while (pa_data) {
> *nr += 1;
> - data = ioremap_cache(pa_data, sizeof(*data));
> + data = memremap(pa_data, sizeof(*data), MEMREMAP_
On 02/16/17 at 09:47am, Tom Lendacky wrote:
> Use memremap() to map the setup data. This simplifies the code and will
> make the appropriate decision as to whether a RAM remapping can be done
> or if a fallback to ioremap_cache() is needed (which includes checking
> PageHighMem).
>
> Signed-off-b
On 02/16/17 at 09:45am, Tom Lendacky wrote:
[snip]
> + * This function determines if an address should be mapped encrypted.
> + * Boot setup data, EFI data and E820 areas are checked in making this
> + * determination.
> + */
> +static bool memremap_should_map_encrypted(resource_size_t phys_addr,
>
Hi Tom,
On 02/17/17 at 10:43am, Tom Lendacky wrote:
> On 2/17/2017 9:57 AM, Konrad Rzeszutek Wilk wrote:
> > On Thu, Feb 16, 2017 at 09:47:55AM -0600, Tom Lendacky wrote:
> > > Provide support so that kexec can be used to boot a kernel when SME is
> > > enabled.
> >
> > Is the point of kexec and
Add kexec list..
On 03/01/17 at 05:25pm, Dave Young wrote:
> Hi Tom,
>
> On 02/17/17 at 10:43am, Tom Lendacky wrote:
> > On 2/17/2017 9:57 AM, Konrad Rzeszutek Wilk wrote:
> > > On Thu, Feb 16, 2017 at 09:47:55AM -0600, Tom Lendacky wrote:
> > > > Provide
Hi Tom,
On 02/16/17 at 09:41am, Tom Lendacky wrote:
> This RFC patch series provides support for AMD's new Secure Memory
> Encryption (SME) feature.
>
> SME can be used to mark individual pages of memory as encrypted through the
> page tables. A page of memory that is marked encrypted will be aut
On 08/17/16 at 07:36pm, Joe Perches wrote:
> On Thu, 2016-08-18 at 10:31 +0800, Zhou Wenjian wrote:
> > nr_cpus can help to save memory. So we should remind user of it.
>
> trivia:
> > diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
> []
> > @@ -390,9 +390,11 @@ Notes on
On 08/10/16 at 02:22pm, Zhou Wenjian wrote:
> multi-cpu support is useful to improve the performance of kdump in
> some cases. So add the description of enable multi-cpu support in
> dump-capture kernel.
>
> Signed-off-by: Zhou Wenjian
> Acked-by: Baoquan He
> ---
> Documentation/kdump/kdump.tx
On 05/11/16 at 10:32am, Russell King - ARM Linux wrote:
> On Wed, May 11, 2016 at 05:13:38PM +0800, Dave Young wrote:
> > On 05/11/16 at 09:52am, Russell King - ARM Linux wrote:
> > > I think you're confusing things. DT doesn't contain the boot alias
> > >
On 05/11/16 at 09:52am, Russell King - ARM Linux wrote:
> On Wed, May 11, 2016 at 04:29:23PM +0800, Dave Young wrote:
> > Hi, Russell
> >
> > On 04/28/16 at 10:26am, Russell King - ARM Linux wrote:
> > > These changes are required for TI Keystone2 kexec to be funct
Hi, Russell
On 04/28/16 at 10:26am, Russell King - ARM Linux wrote:
> These changes are required for TI Keystone2 kexec to be functional. TI
> Keystone2 has the run-time view of physical memory above 4GiB, but with
> a boot time alias below 4GiB which can only be used during the early
> boot.
>
crash_size, SECTION_SIZE);
> + if (start != crash_base) {
> + pr_err("crashkernel reservation failed - memory is in
> use.\n");
> + return;
> + }
> +
On 04/01/16 at 02:25pm, Russell King - ARM Linux wrote:
[snip]
> Well, if we want to remove it, we then need to sort out a method of
> specifying a limit on the address - where platforms physical memory
> bridges the 4GB CPU-accessible limit, the crashkernel region must be
> allocated below that
Hi, Russell
A long standing issue, but nobody tried to do it. Thank you for bringing up.
On 03/29/16 at 11:10am, Russell King wrote:
> When the kernel crashkernel parameter is specified with just a size, we
> are supposed to allocate a region from RAM to store the crashkernel.
> However, ARM mere
27 matches
Mail list logo
