Hi,
On Fri, Jan 15, 2016 at 07:18:37PM +, Geoff Levand wrote:
> This reverts commit b08d4640a3dca68670fc5af2fe9205b395a02388.
>
> Add back the setup_mm_for_reboot() needed for kexec.
My pagetable rework series [1,2] adds cpu_install_idmap() [3], which
supersedes setup_mm_for_reboot, and diff
[Adding Marc as this touches KVM code]
On Fri, Jan 15, 2016 at 07:18:37PM +, Geoff Levand wrote:
> We currently have macros defining flags for the arm64 sctlr registers in both
> kvm_arm.h and sysreg.h. To clean things up and simplify move the definitions
> of the SCTLR_EL2 flags from kvm_arm
On Fri, Jan 15, 2016 at 07:18:38PM +, Geoff Levand wrote:
> From: AKASHI Takahiro
>
> This patch adds arch specific descriptions about kdump usage on arm64
> to kdump.txt.
>
> Signed-off-by: AKASHI Takahiro
> ---
> Documentation/kdump/kdump.txt | 23 ++-
> 1 file change
s produces build warnings when only
> asm/page.h is included by asm code.
>
> Signed-off-by: James Morse
> Acked-by: Pavel Machek
> Signed-off-by: Geoff Levand
This is sensible even in isolation, so FWIW:
Acked-by: Mark Rutland
I note that for the !__ASSEMBLY__ portion we use cu
On Mon, Jan 18, 2016 at 07:26:04PM +0900, AKASHI Takahiro wrote:
> On 01/16/2016 05:16 AM, Mark Rutland wrote:
> >On Fri, Jan 15, 2016 at 07:18:38PM +, Geoff Levand wrote:
> >>From: AKASHI Takahiro
> >>
> >>This patch adds arch specific descriptions about k
On Tue, Jan 19, 2016 at 02:31:05PM +0900, AKASHI Takahiro wrote:
> On 01/18/2016 08:29 PM, Mark Rutland wrote:
> >On Mon, Jan 18, 2016 at 07:26:04PM +0900, AKASHI Takahiro wrote:
> >>On 01/16/2016 05:16 AM, Mark Rutland wrote:
> >>>On Fri, Jan 15, 2016 at 07:18:
On Tue, Jan 19, 2016 at 09:43:32AM +0800, Dave Young wrote:
> On 01/18/16 at 07:26pm, AKASHI Takahiro wrote:
> > On 01/16/2016 05:16 AM, Mark Rutland wrote:
> > >On Fri, Jan 15, 2016 at 07:18:38PM +, Geoff Levand wrote:
> > >>From: AKASHI Takahiro
> > &g
On Tue, Jan 19, 2016 at 08:28:48PM +0800, Dave Young wrote:
> On 01/19/16 at 02:35pm, AKASHI Takahiro wrote:
> > On 01/19/2016 10:43 AM, Dave Young wrote:
> > >On 01/18/16 at 07:26pm, AKASHI Takahiro wrote:
> > >>On 01/16/2016 05:16 AM, Mark Rutland wrote:
> > &
On Tue, Jan 19, 2016 at 09:45:53PM +0800, Dave Young wrote:
> On 01/19/16 at 12:51pm, Mark Rutland wrote:
> > On Tue, Jan 19, 2016 at 08:28:48PM +0800, Dave Young wrote:
> > > On 01/19/16 at 02:35pm, AKASHI Takahiro wrote:
> > > > On 01/19/2016 10:43 AM, Dave Y
On Tue, Jan 19, 2016 at 09:52:33PM +0800, Dave Young wrote:
> On 01/19/16 at 12:17pm, Mark Rutland wrote:
> > On Tue, Jan 19, 2016 at 09:43:32AM +0800, Dave Young wrote:
> > > On 01/18/16 at 07:26pm, AKASHI Takahiro wrote:
> > > > On 01/16/2016 05:16 AM, Mark Rutland
On Wed, Jan 20, 2016 at 10:49:46AM +0800, Dave Young wrote:
> On 01/19/16 at 02:01pm, Mark Rutland wrote:
> > On Tue, Jan 19, 2016 at 09:45:53PM +0800, Dave Young wrote:
> > > On 01/19/16 at 12:51pm, Mark Rutland wrote:
> > > > On Tue, Jan 19, 2016 at 08:2
On Wed, Jan 20, 2016 at 03:07:53PM +0900, AKASHI Takahiro wrote:
> On 01/20/2016 11:49 AM, Dave Young wrote:
> >On 01/19/16 at 02:01pm, Mark Rutland wrote:
> >>On Tue, Jan 19, 2016 at 09:45:53PM +0800, Dave Young wrote:
> >>>On 01/19/16 at 12:51pm, Mark Rutland wrote:
On Wed, Jan 20, 2016 at 02:38:56PM +0800, Dave Young wrote:
> Maybe I did not say it clearly, I prefer kexec syscall/tool to modifiy dtb
> or uefi-memmap so that we do not need any extra kernel cmdline.
I am strongly opposed to modifying the FW-provided memroy map
information, for the reasons I ex
On Wed, Jan 20, 2016 at 02:25:07PM +0900, AKASHI Takahiro wrote:
> On 01/19/2016 11:01 PM, Mark Rutland wrote:
> >For NUMA topology in !ACPI kernels, we might need to also retain and
> >parse memory nodes, but only for toplogy information. The kernel would
> >still only use m
58PM +0000, Mark Rutland wrote:
> On Wed, Jan 20, 2016 at 02:25:07PM +0900, AKASHI Takahiro wrote:
> > On 01/19/2016 11:01 PM, Mark Rutland wrote:
> > >For NUMA topology in !ACPI kernels, we might need to also retain and
> > >parse memory nodes, but only for toplogy informati
On Wed, Jan 20, 2016 at 03:59:08PM +0100, Ard Biesheuvel wrote:
> On 20 January 2016 at 13:36, Mark Rutland wrote:
> > Ard, Ganapatrao, the below is something we need to consider for the
> > combination of the NUMA & kexec approaches. It only becomes a problem
> > if/w
On Thu, Jan 21, 2016 at 03:53:42PM +0900, AKASHI Takahiro wrote:
> On 01/20/2016 08:49 PM, Mark Rutland wrote:
> >On Wed, Jan 20, 2016 at 03:07:53PM +0900, AKASHI Takahiro wrote:
> >>On 01/20/2016 11:49 AM, Dave Young wrote:
> >>>On 01/19/16 at 02:01pm, Mark Rutla
On Wed, Jan 20, 2016 at 10:56:21AM +0800, Dave Young wrote:
> On 01/19/16 at 04:15pm, Geoff Levand wrote:
> > On Tue, 2016-01-19 at 20:32 +0800, Dave Young wrote:
> > > Geoff, another question about kexec-tools part is, can the kexec
> > > -tools code
> > > been written in kernel? We have the infra
On Thu, Jan 21, 2016 at 02:43:15PM +0900, AKASHI Takahiro wrote:
> On 01/20/2016 11:59 PM, Ard Biesheuvel wrote:
> >On 20 January 2016 at 13:36, Mark Rutland wrote:
> >>Ard, Ganapatrao, the below is something we need to consider for the
> >>combination of the NUMA
On Fri, Jan 22, 2016 at 03:23:14PM +0900, AKASHI Takahiro wrote:
> On 01/21/2016 09:02 PM, Mark Rutland wrote:
> >On Thu, Jan 21, 2016 at 03:53:42PM +0900, AKASHI Takahiro wrote:
> >>On 01/20/2016 08:49 PM, Mark Rutland wrote:
> >>>On Wed, Jan 20, 2016 at 03:07:53P
On Thu, Mar 31, 2016 at 09:12:32AM +0100, Marc Zyngier wrote:
> On 31/03/16 08:57, AKASHI Takahiro wrote:
> > On Mon, Mar 21, 2016 at 01:29:28PM +, James Morse wrote:
> >> On 18/03/16 18:08, James Morse wrote:
> >>> On 14/03/16 17:48, Geoff Levand wrote:
> +/* just in case */
> >>>
On Fri, Apr 01, 2016 at 05:45:09PM +0900, AKASHI Takahiro wrote:
> On Thu, Mar 31, 2016 at 11:10:38AM +0100, Mark Rutland wrote:
> > On Thu, Mar 31, 2016 at 09:12:32AM +0100, Marc Zyngier wrote:
> > > On 31/03/16 08:57, AKASHI Takahiro wrote:
> > > > On Mon, Mar 21, 2
On Fri, Apr 29, 2016 at 08:36:43PM +0530, Pratyush Anand wrote:
> > + phys_addr_t vmcore_base = paddr_vmcoreinfo_note();
> > + return sprintf(buf, "%pa %x\n", &vmcore_base,
>
> Why do we pass &vmcore_base? Shouldn't it be vmcore_base?
The %pa* printk format specifiers take the value b
Hi,
Apologies for the delay on this.
On Tue, Jul 12, 2016 at 02:05:14PM +0900, AKASHI Takahiro wrote:
> From: James Morse
>
> Add documentation for
> linux,crashkernel-base and crashkernel-size,
> linux,usable-memory-range, and
> linux,elfcorehdr
> used by arm64 kexec/kdump to
On Tue, Jul 12, 2016 at 04:24:10PM +0200, Arnd Bergmann wrote:
> On Tuesday, July 12, 2016 10:18:11 AM CEST Vivek Goyal wrote:
> > >
> > > On Open Firmware, the DT is extracted from running firmware and copied
> > > into dynamically allocated data structures. After a kexec, the runtime
> > > inter
On Wed, Jul 13, 2016 at 10:36:14AM +0800, Dave Young wrote:
> But consider we can kexec to a different kernel and a different initrd so
> there
> will be use cases to pass a total different dtb as well.
It depends on what you mean by "a different kernel", and what this
implies for the DTB.
I exp
On Wed, Jul 13, 2016 at 10:01:33AM +0200, Arnd Bergmann wrote:
> On Wednesday, July 13, 2016 10:36:14 AM CEST Dave Young wrote:
> > On 07/12/16 at 03:50pm, Mark Rutland wrote:
> > > On Tue, Jul 12, 2016 at 04:24:10PM +0200, Arnd Bergmann wrote:
> > > > On Tuesday,
On Thu, Jul 14, 2016 at 02:38:06AM +0900, AKASHI Takahiro wrote:
> Apologies for the slow response. I'm attending LinuxCon this week.
>
> On Wed, Jul 13, 2016 at 10:34:47AM +0100, Mark Rutland wrote:
> > On Wed, Jul 13, 2016 at 10:36:14AM +0800, Dave Young wrote:
> > &
On Wed, Jul 13, 2016 at 09:57:28PM +0200, Arnd Bergmann wrote:
> On Wednesday, July 13, 2016 6:58:32 PM CEST Mark Rutland wrote:
> >
> > > we may want to remove unnecessary devices and even add a dedicated
> > > storage device for storing a core dump image.
> >
On Fri, Jul 15, 2016 at 09:09:55AM -0400, Vivek Goyal wrote:
> On Tue, Jul 12, 2016 at 10:42:01AM +0900, AKASHI Takahiro wrote:
>
> [..]
> > -SYSCALL_DEFINE5(kexec_file_load, int, kernel_fd, int, initrd_fd,
> > +SYSCALL_DEFINE6(kexec_file_load, int, kernel_fd, int, initrd_fd,
> > unsig
On Fri, Jul 15, 2016 at 09:26:10AM -0400, Vivek Goyal wrote:
> On Fri, Jul 15, 2016 at 09:31:02AM +0200, Arnd Bergmann wrote:
> > On Thursday, July 14, 2016 10:44:14 PM CEST Thiago Jung Bauermann wrote:
> > > Am Donnerstag, 14 Juli 2016, 10:29:11 schrieb Arnd Bergmann:
> >
> > > >
> > > > Right,
On Fri, Jul 15, 2016 at 12:29:09PM -0300, Thiago Jung Bauermann wrote:
> Am Freitag, 15 Juli 2016, 14:33:47 schrieb Mark Rutland:
> > On Fri, Jul 15, 2016 at 09:26:10AM -0400, Vivek Goyal wrote:
> > > I don't know anything about DTB. So here comes a very basic questio
On Mon, Jul 18, 2016 at 10:30:24AM +0800, Dave Young wrote:
> On 07/15/16 at 02:19pm, Mark Rutland wrote:
> > On Fri, Jul 15, 2016 at 09:09:55AM -0400, Vivek Goyal wrote:
> > > On Tue, Jul 12, 2016 at 10:42:01AM +0900, AKASHI Takahiro wrote:
> > >
> >
On Tue, Jul 19, 2016 at 08:55:56AM +0800, Dave Young wrote:
> On 07/18/16 at 11:07am, Mark Rutland wrote:
> > On Mon, Jul 18, 2016 at 10:30:24AM +0800, Dave Young wrote:
> > > I do not think it is worth to add another syscall for extra fds.
> > > We have open(2) as an ex
On Tue, Jul 19, 2016 at 08:24:06AM -0400, Vivek Goyal wrote:
> On Tue, Jul 19, 2016 at 11:52:00AM +0100, Mark Rutland wrote:
> > Regardless, this extended syscall changes some underlying assumptions
> > made with the development of kexec_file_load, and I think treating this
> &g
On Tue, Jul 19, 2016 at 08:48:57AM -0400, Mark Salter wrote:
> On Tue, 2016-07-19 at 18:41 +0800, Dennis Chen wrote:
> > On Tue, Jul 19, 2016 at 07:28:16PM +0900, AKASHI Takahiro wrote:
> > > On Tue, Jul 19, 2016 at 05:39:07PM +0800, Dennis Chen wrote:
> > > > On Tue, Jul 12, 2016 at 02:05:07PM +09
Hi,
On Tue, Jul 19, 2016 at 11:28:13PM +, Geoff Levand wrote:
> +/**
> + * struct arm64_image_header - arm64 kernel image header.
> + *
> + * @pe_sig: Optional PE format 'MZ' signature.
> + * @branch_code: Reserved for instructions to branch to stext.
> + * @text_offset: The image load offset
On Wed, Jul 20, 2016 at 12:19:21PM -0700, Geoff Levand wrote:
> > > +static uint64_t read_sink(const char *command_line)
> > > +{
> > > +> > > > uint64_t v;
> > > +> > > > const char *p;
> > > +
> > > +> > > > if (arm64_opts.port)
> > > +> > > > > > return arm64_opts.port;
>
On Fri, Jul 22, 2016 at 09:38:42AM +0530, Pratyush Anand wrote:
> On 21/07/2016:02:49:36 PM, Geoff Levand wrote:
> > On Thu, 2016-07-21 at 11:50 +0100, Robin Murphy wrote:
> > > The Exynos UART (drivers/tty/serial/samsung.c) is one which comes to
> > > mind as definitely existing, and on arm64 syst
On Thu, Aug 11, 2016 at 08:03:56PM -0300, Thiago Jung Bauermann wrote:
> This patch series is from AKASHI Takahiro. I will use it in my next
> version of the kexec_file_load implementation for powerpc, so I am
> rebasing it on top of v4.8-rc1.
[...]
> Original cover letter:
>
> Device tree blob
Hi Rob,
Reviving an old thread -- "rock" and "hard place" come to mind.
On Fri, Aug 19, 2016 at 08:26:41AM -0500, Rob Herring wrote:
> On Tue, Aug 09, 2016 at 10:57:47AM +0900, AKASHI Takahiro wrote:
> > From: James Morse
> > +linux,usable-memory-range
> > +-
> > +
> > +
On Mon, Oct 03, 2016 at 06:11:40PM +0530, Manish Jaggi wrote:
> On 10/03/2016 04:34 PM, AKASHI Takahiro wrote:
> > On Mon, Oct 03, 2016 at 01:24:34PM +0530, Manish Jaggi wrote:
> >> Observations:
> >> 1.1. Dump capture kernel shows different memory map.
> >>
t;
> With a few more acks I think this should be ready to go. More testing is
> always appreciated though.
I've given the whole series a go with kasan, kexec, and hibernate (using
test_resume with the disk target), and everything looks happy. So FWIW,
for the series:
Reviewed-by: Mark
On Wed, Dec 14, 2016 at 11:16:07AM +, James Morse wrote:
> Hi Pratyush,
> On 14/12/16 09:38, Pratyush Anand wrote:
> > On Saturday 26 November 2016 12:00 AM, James Morse wrote:
> >> On 22/11/16 04:32, Pratyush Anand wrote:
> >>> +/*
> >>> + *disable_dcache: Disable D-cache and flush RAM loc
On Wed, Dec 14, 2016 at 11:16:17AM +, James Morse wrote:
> Hi Pratyush,
>
> On 14/12/16 10:12, Pratyush Anand wrote:
> > On Wednesday 14 December 2016 03:08 PM, Pratyush Anand wrote:
> >>> I would go as far as to generate the page tables at 'kexec -l' time,
> >>> and only if
> >>
> >> Ok..So y
Hi,
On Wed, Dec 14, 2016 at 05:51:05PM +0530, Pratyush Anand wrote:
>
> On Wednesday 14 December 2016 05:07 PM, Mark Rutland wrote:
> >I see in an earlier message that the need for sha256 was being discussed
> >in another thread. Do either of you happen to have a pointer to th
Hi,
As a general note, I must apologise for my minimial review of the series
until this point. Judging by the way the DT parts are organised. I'm
very concerned with the way the DT parts are organised, and clearly I
did not communicate my concerns and suggestions effectively in prior
rounds of rev
erved area, and
> the elfcorehdr's location within it.
>
> Signed-off-by: James Morse
> [takahiro.aka...@linaro.org: added "linux,crashkernel-base" and "-size" ]
> Signed-off-by: AKASHI Takahiro
> Cc: devicet...@vger.kernel.org
> Cc: Rob Herr
On Fri, Jan 13, 2017 at 06:13:49PM +0900, AKASHI Takahiro wrote:
> On Thu, Jan 12, 2017 at 03:39:45PM +0000, Mark Rutland wrote:
> > On Wed, Dec 28, 2016 at 01:37:34PM +0900, AKASHI Takahiro wrote:
> > > +linux,crashkernel-base
> > &
On Fri, Jan 13, 2017 at 05:16:18PM +0900, AKASHI Takahiro wrote:
> On Thu, Jan 12, 2017 at 03:09:26PM +0000, Mark Rutland wrote:
> > > +static int __init export_crashkernel(void)
> > > + /* Add /chosen/linux,crashkernel-* properties */
> > > + of_remove_proper
On Mon, Jan 16, 2017 at 05:25:07PM +0900, AKASHI Takahiro wrote:
> On Fri, Jan 13, 2017 at 11:17:56AM +0000, Mark Rutland wrote:
> > On Fri, Jan 13, 2017 at 06:13:49PM +0900, AKASHI Takahiro wrote:
> > > On Thu, Jan 12, 2017 at 03:39:45PM +, Mark Rutland wrote:
> > &g
On Tue, Jan 17, 2017 at 05:20:44PM +0900, AKASHI Takahiro wrote:
> On Fri, Jan 13, 2017 at 11:39:15AM +0000, Mark Rutland wrote:
> > Great! I think it would be better to follow the approach of
> > mark_rodata_ro(), rather than opening up set_memory_*(), but otherwise,
> > it
On Thu, Jan 19, 2017 at 06:49:42PM +0900, AKASHI Takahiro wrote:
> On Tue, Jan 17, 2017 at 11:54:42AM +0000, Mark Rutland wrote:
> > On Tue, Jan 17, 2017 at 05:20:44PM +0900, AKASHI Takahiro wrote:
> > > On Fri, Jan 13, 2017 at 11:39:15AM +, Mark Rutland wrote:
> > >
On Mon, Jan 23, 2017 at 06:51:46PM +0900, AKASHI Takahiro wrote:
> Mark,
>
> On Thu, Jan 19, 2017 at 11:28:50AM +0000, Mark Rutland wrote:
> > On Thu, Jan 19, 2017 at 06:49:42PM +0900, AKASHI Takahiro wrote:
> > > On Tue, Jan 17, 2017 at 11:54:42AM +, Mark Rutland wr
On Sat, Jan 28, 2017 at 02:15:16AM +0900, AKASHI Takahiro wrote:
> On Fri, Jan 27, 2017 at 11:19:32AM +, James Morse wrote:
> > Hi Akashi,
> >
> > On 26/01/17 11:28, AKASHI Takahiro wrote:
> > > On Wed, Jan 25, 2017 at 05:37:38PM +, James Morse wrote:
> > >> On 24/01/17 08:49, AKASHI Takahi
On Sat, Jan 28, 2017 at 12:42:20AM +0900, AKASHI Takahiro wrote:
> On Fri, Jan 27, 2017 at 01:59:05PM +, James Morse wrote:
> > On 24/01/17 08:49, AKASHI Takahiro wrote:
> > > + /*
> > > + * While crash dump kernel memory is contained in a single memblock
> > > + * for now, it should appear i
us from making unnecessary assignments to the size field, and
makes it clear that reg.size has definitely been initialised, regardless
of what of_scan_flat_dt() happens to do.
With that:
Acked-by: Mark Rutland
Thanks,
Mark.
> +
> + of_scan_flat_dt(early_init_dt_scan_usablemem,
t's
probably OK. However, it would also be nicer to log the base as an
address.
Could we dump this as we do for the kernel memory layout? e.g.
pr_info("crashkernel reserved: 0x%016lx - 0x%016lx (%lld MB)\n",
crash_base, crash_base + crash_size, crash_size >> 20);
With those:
Acked-by: Mark Rutland
Thanks,
Mark.
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Hi,
On Wed, Feb 01, 2017 at 09:46:23PM +0900, AKASHI Takahiro wrote:
> A new function, remove_pgd_mapping(), is added.
> It allows us to unmap a specific portion of kernel mapping later as far as
> the mapping is made using create_pgd_mapping() and unless we try to free
> a sub-set of memory range
On Wed, Feb 01, 2017 at 09:46:24PM +0900, AKASHI Takahiro wrote:
> arch_kexec_protect_crashkres() and arch_kexec_unprotect_crashkres()
> are meant to be called around kexec_load() in order to protect
> the memory allocated for crash dump kernel once after it's loaded.
>
> The protection is impleme
On Wed, Feb 01, 2017 at 06:00:08PM +, Mark Rutland wrote:
> On Wed, Feb 01, 2017 at 09:46:24PM +0900, AKASHI Takahiro wrote:
> > arch_kexec_protect_crashkres() and arch_kexec_unprotect_crashkres()
> > are meant to be called around kexec_load() in order to protect
> > the
On Wed, Feb 01, 2017 at 09:46:28PM +0900, AKASHI Takahiro wrote:
> Add arch-specific functions to provide a dump file, /proc/vmcore.
>
> This file is in ELF format and its ELF header needs to be prepared by
> userspace tools, like kexec-tools, in adance. The primary kernel is
> responsible to allo
Hi,
On Thu, Feb 02, 2017 at 07:31:30PM +0900, AKASHI Takahiro wrote:
> On Wed, Feb 01, 2017 at 06:00:08PM +0000, Mark Rutland wrote:
> > On Wed, Feb 01, 2017 at 09:46:24PM +0900, AKASHI Takahiro wrote:
> > > arch_kexec_protect_crashkres() and arch_kexec_unprotect_crashkres()
>
On Thu, Feb 02, 2017 at 01:52:36PM +0900, AKASHI Takahiro wrote:
> On Wed, Feb 01, 2017 at 03:26:09PM +0000, Mark Rutland wrote:
> > On Wed, Feb 01, 2017 at 09:46:22PM +0900, AKASHI Takahiro wrote:
> > > + pr_info("Reserving %lldMB of memory at %lldMB for crashkernel\n"
On Thu, Feb 02, 2017 at 07:21:32PM +0900, AKASHI Takahiro wrote:
> On Wed, Feb 01, 2017 at 04:03:54PM +0000, Mark Rutland wrote:
> > Hi,
> >
> > On Wed, Feb 01, 2017 at 09:46:23PM +0900, AKASHI Takahiro wrote:
> > > A new function, remove_pgd_mapping(), is added.
Hi,
On Thu, Feb 02, 2017 at 10:45:58AM +, James Morse wrote:
> On 01/02/17 18:25, Mark Rutland wrote:
> > On Wed, Feb 01, 2017 at 06:00:08PM +0000, Mark Rutland wrote:
> >> On Wed, Feb 01, 2017 at 09:46:24PM +0900, AKASHI Takahiro wrote:
> >>> arch
On Thu, Feb 02, 2017 at 07:39:06PM +0900, AKASHI Takahiro wrote:
> Mark,
>
> On Wed, Feb 01, 2017 at 06:25:06PM +0000, Mark Rutland wrote:
> > On Wed, Feb 01, 2017 at 06:00:08PM +0000, Mark Rutland wrote:
> > > On Wed, Feb 01, 2017 at 09:46:24PM +090
On Thu, Feb 02, 2017 at 03:24:09PM +0900, AKASHI Takahiro wrote:
> On Wed, Feb 01, 2017 at 07:21:22PM +0000, Mark Rutland wrote:
> > On Wed, Feb 01, 2017 at 09:46:28PM +0900, AKASHI Takahiro wrote:
> > > Add arch-specific functions to provide a dump file, /proc/vmcore.
> >
On Thu, Feb 02, 2017 at 12:03:20PM +, Mark Rutland wrote:
> On Thu, Feb 02, 2017 at 03:24:09PM +0900, AKASHI Takahiro wrote:
> > On Wed, Feb 01, 2017 at 07:21:22PM +0000, Mark Rutland wrote:
> > > On Wed, Feb 01, 2017 at 09:46:28PM +0900, AKA
On Thu, Feb 02, 2017 at 11:01:03PM +0900, AKASHI Takahiro wrote:
> On Thu, Feb 02, 2017 at 11:44:38AM +0000, Mark Rutland wrote:
> > On Thu, Feb 02, 2017 at 07:21:32PM +0900, AKASHI Takahiro wrote:
> > > On Wed, Feb 01, 2017 at 04:03:54PM +, Mark Rutland wrote:
> > >
On Thu, Feb 02, 2017 at 11:36:04PM +0900, AKASHI Takahiro wrote:
> On Thu, Feb 02, 2017 at 11:16:37AM +0000, Mark Rutland wrote:
> > On Thu, Feb 02, 2017 at 07:31:30PM +0900, AKASHI Takahiro wrote:
> > > On Wed, Feb 01, 2017 at 06:00:08PM +, Mark Rutland wrote:
> > >
Hi,
On Fri, Feb 03, 2017 at 10:45:39AM +0900, AKASHI Takahiro wrote:
> On Thu, Feb 02, 2017 at 11:54:25AM +0000, Mark Rutland wrote:
> > On Thu, Feb 02, 2017 at 07:39:06PM +0900, AKASHI Takahiro wrote:
> > > On Wed, Feb 01, 2017 at 06:25:06PM +, Mark Rutland wrote:
>
Hi,
On Fri, Feb 03, 2017 at 03:13:18PM +0900, AKASHI Takahiro wrote:
> On Thu, Feb 02, 2017 at 11:55:54PM +0900, AKASHI Takahiro wrote:
> > On Thu, Feb 02, 2017 at 02:35:35PM +0000, Mark Rutland wrote:
> > > I think that if we only allow ourselves to make PTEs invalid, we d
On Fri, Mar 17, 2017 at 02:02:53PM +, David Woodhouse wrote:
> On Fri, 2017-03-17 at 11:43 +, David Woodhouse wrote:
> >
> > Is this one going to be be my fault too?
>
> Looks like it isn't my fault. In ipi_cpu_crash_stop() we don't modify
> the online mask. Which is reasonable enough if
On Fri, Mar 17, 2017 at 02:02:53PM +, David Woodhouse wrote:
> On Fri, 2017-03-17 at 11:43 +, David Woodhouse wrote:
> >
> > Is this one going to be be my fault too?
>
> Looks like it isn't my fault. In ipi_cpu_crash_stop() we don't modify
> the online mask. Which is reasonable enough if
On Fri, Mar 17, 2017 at 03:47:08PM +, David Woodhouse wrote:
> On Fri, 2017-03-17 at 15:33 +0000, Mark Rutland wrote:
> No, in this case the CPUs *were* offlined correctly, or at least "as
> designed", by smp_send_crash_stop(). And if that hadn't worked, as
> verifi
On Thu, Aug 24, 2017 at 05:18:05PM +0900, AKASHI Takahiro wrote:
> This is a basic purgtory, or a kind of glue code between the two kernel,
> for arm64. We will later add a feature of verifying a digest check against
> loaded memory segments.
>
> arch_kexec_apply_relocations_add() is responsible f
On Thu, Aug 24, 2017 at 05:18:06PM +0900, AKASHI Takahiro wrote:
> Most of sha256 code is based on crypto/sha256-glue.c, particularly using
> non-neon version.
>
> Please note that we won't be able to re-use lib/mem*.S for purgatory
> because unaligned memory access is not allowed in purgatory whe
On Thu, Aug 24, 2017 at 05:18:07PM +0900, AKASHI Takahiro wrote:
> load_other_segments() sets up and adds all the memory segments necessary
> other than kernel, including initrd, device-tree blob and purgatory.
> Most of the code was borrowed from kexec-tools' counterpart.
>
> In addition, arch_ke
On Thu, Aug 24, 2017 at 05:18:10PM +0900, AKASHI Takahiro wrote:
> The "Image" binary will be loaded at the offset of TEXT_OFFSET from
> the start of system memory. TEXT_OFFSET is basically determined from
> the header of the image.
What's the policy for the binary types kexec_file_load() will loa
On Thu, Aug 24, 2017 at 05:18:11PM +0900, AKASHI Takahiro wrote:
> The first PT_LOAD segment, which is assumed to be "text" code, in vmlinux
> will be loaded at the offset of TEXT_OFFSET from the begining of system
> memory. The other PT_LOAD segments are placed relative to the first one.
I really
On Fri, Aug 25, 2017 at 10:00:59AM +0900, AKASHI Takahiro wrote:
> On Thu, Aug 24, 2017 at 05:56:17PM +0100, Mark Rutland wrote:
> > On Thu, Aug 24, 2017 at 05:18:05PM +0900, AKASHI Takahiro wrote:
> > > This is a basic purgtory, or a kind of glue code between the two kernel,
&
On Fri, Aug 25, 2017 at 10:21:06AM +0900, AKASHI Takahiro wrote:
> On Thu, Aug 24, 2017 at 06:04:40PM +0100, Mark Rutland wrote:
> > On Thu, Aug 24, 2017 at 05:18:06PM +0900, AKASHI Takahiro wrote:
> > > Most of sha256 code is based on crypto/sha256-glue.c, particularly us
On Thu, Aug 24, 2017 at 06:30:50PM +0100, Mark Rutland wrote:
> On Thu, Aug 24, 2017 at 05:18:11PM +0900, AKASHI Takahiro wrote:
> > The first PT_LOAD segment, which is assumed to be "text" code, in vmlinux
> > will be loaded at the offset of TEXT_OFFSET from the begining
On Tue, Mar 13, 2018 at 07:22:03PM +0900, AKASHI Takahiro wrote:
> On Mon, Mar 12, 2018 at 08:58:00PM +, Ard Biesheuvel wrote:
> > On 12 March 2018 at 20:14, Bhupesh Sharma wrote:
> More importantly, neither arm64 _kexec_ supports kaslr.
The below is just considering this, and ignoring kdump
On Tue, Mar 13, 2018 at 08:07:49PM +0900, AKASHI Takahiro wrote:
> On Tue, Mar 13, 2018 at 10:47:15AM +0000, Mark Rutland wrote:
> > On Tue, Mar 13, 2018 at 07:22:03PM +0900, AKASHI Takahiro wrote:
> > > On Mon, Mar 12, 2018 at 08:58:00PM +, Ard Biesheuvel wrote:
> > &g
On Wed, Mar 14, 2018 at 11:10:53AM +0900, AKASHI Takahiro wrote:
> If kaslr-seed has a critical value in terms of security, is kexec-tools
> a right place? It is exposed to user space albeit for a short time of period.
The kernel zeroes the seed in the DT at boot time, so the current seed
isn't vi
On Sun, Apr 15, 2018 at 01:44:16AM +0530, Bhupesh Sharma wrote:
> 4. Accordingly, I wanted to get opinions on whether arm64 timer count is a
> good
> entropy source on platforms which indeed support EFI_RNG_PROTOCOL?
On its own, the timer is not a good entropy source.
If we have the EFI_RNG_PROT
On Fri, Sep 28, 2018 at 03:48:32PM +0900, AKASHI Takahiro wrote:
> Those image head's flags will be used later by kexec_file loader.
>
> Signed-off-by: AKASHI Takahiro
> Cc: Catalin Marinas
> Cc: Will Deacon
> Acked-by: James Morse
> ---
> arch/arm64/include/asm/boot.h | 15 +++
>
On Tue, Oct 02, 2018 at 04:59:40PM +0900, AKASHI Takahiro wrote:
> Hi Mark,
>
> On Mon, Oct 01, 2018 at 01:52:26PM +0100, Mark Rutland wrote:
> > On Fri, Sep 28, 2018 at 03:48:32PM +0900, AKASHI Takahiro wrote:
> > > Those image head's flags will be us
On Fri, Sep 28, 2018 at 03:48:36PM +0900, AKASHI Takahiro wrote:
> This patch provides kexec_file_ops for "Image"-format kernel. In this
> implementation, a binary is always loaded with a fixed offset identified
> in text_offset field of its header.
>
> Regarding signature verification for trusted
On Wed, Oct 10, 2018 at 03:52:37PM +0900, AKASHI Takahiro wrote:
> Mark,
>
> On Tue, Oct 09, 2018 at 04:28:00PM +0100, Mark Rutland wrote:
> > On Fri, Sep 28, 2018 at 03:48:36PM +0900, AKASHI Takahiro wrote:
> > > This patch provides kexec_file_ops for "
On Wed, Jul 31, 2019 at 11:38:57AM -0400, Pavel Tatashin wrote:
> +/*
> + * The following code is adoped from "Bare-metal Boot Code for ARMv8-A
> + * Processors Version 1.0, 5.3.1 Cleaning and invalidating the caches".
> + * http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0527a
> + *
Hi Pavel,
Generally, the cover letter should state up-front what the goal is (or
what problem you're trying to solve). It would be really helpful to have
that so that we understand what you're trying to achieve, and why.
Messing with the MMU is often fraught with danger (and very painful to
debug
On Wed, Jul 31, 2019 at 12:40:51PM -0400, Pavel Tatashin wrote:
> On Wed, Jul 31, 2019 at 12:33 PM Mark Rutland wrote:
> >
> > Hi Pavel,
> >
> > Generally, the cover letter should state up-front what the goal is (or
> > what problem you're trying to solv
On Fri, Aug 16, 2019 at 10:46:17PM -0400, Pavel Tatashin wrote:
> create_safe_exec_page() is going to be split into two parts in preparation
> of moving page table handling code out of hibernate.c
>
> Remove allocator parameter, and rename dst to page. Also, remove the
> goto's, as we can return d
On Fri, Aug 16, 2019 at 10:46:18PM -0400, Pavel Tatashin wrote:
> trans_table_create_copy() and trans_table_map_page() are going to be
> the basis for public interface of new subsystem that handles page
> tables for cases which are between kernels: kexec, and hibernate.
While the architecture uses
On Mon, Aug 19, 2019 at 12:33:31PM -0400, Pavel Tatashin wrote:
> On Mon, Aug 19, 2019 at 11:58 AM Mark Rutland wrote:
> > On Fri, Aug 16, 2019 at 10:46:18PM -0400, Pavel Tatashin wrote:
> > > trans_table_create_copy() and trans_table_map_page() are going to be
> >
7;vabits_actual' value would be 48 for arm64 hardware
> which don't support LVA-8.2 extension (even when CONFIG_ARM64_VA_BITS_52
> is enabled), VA_BITS would still be set to a value 52. Hence this change
> would be safe in all possible VA address space combinations.
>
> Cc: J
config")].
>
> This patch enables config KEXEC_FILE by default in the
> arm64 defconfig, so that user-space tools like kexec-tools
> can use the same as the default interface for kexec/kdump
> on arm64.
>
> Cc: AKASHI Takahiro
> Cc: Catalin Marinas
> Cc: Jame
1 - 100 of 171 matches
Mail list logo
