From: panand@redhat.com (Pratyush Anand)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v24 5/9] arm64: kdump: add kdump support
Date: Tue, 23 Aug 2016 16:53:44 +0530 [thread overview]
Message-ID: <20160823112343.GC13501@localhost.localdomain> (raw)
In-Reply-To: <20160823003815.GL20080@linaro.org>
On 23/08/2016:09:38:16 AM, AKASHI Takahiro wrote:
> On Mon, Aug 22, 2016 at 02:47:30PM +0100, James Morse wrote:
> > On 22/08/16 02:29, AKASHI Takahiro wrote:
> > > On Fri, Aug 19, 2016 at 04:52:17PM +0530, Pratyush Anand wrote:
> > >> It will help kexec-tools to prevent copying of any unnecessary data. I
> > >> think, then you also need to change phys_offset calculation in kexec-tools. That
> > >> should be start of either of first "reserved" or "System RAM" block.
> > >
> > > Good point, but I'm not sure this is always true.
> >
> > > Is there any system whose ACPI memory is *not* part of DRAM
> >
> > From the spec, it looks like this is allowed.
> >
> > What do you mean by 'DRAM'? Any ACPI region will be in the UEFI memory map, so
> > the question is what is its type and memory attributes?
>
> Yes.
>
> > The UEFI spec[0] says ACPI regions can have a type of EfiACPIReclaimMemory or
> > EfiACPIMemoryNVS, the memory attributes aren't specified, so are chosen by the
> > firmware.
> >
> > It is possible these regions have to be mapped non-cacheable, page 40 has a
> > couple of:
> > > If no information about the table location exists in the UEFI memory map or
> > ACPI memory
> > > descriptors, the table is assumed to be non-cached.
> >
> > reserve_regions() in drivers/firmware/efi/arm-init.c will add any entry in the
> > memory map that has a 'WB' attribute to the memblock.memory list (via
> > early_init_dt_add_memory_arch()), it will also mark as no-map regions that have
> > this attribute and aren't in the is_reserve_region() list.
> >
> > If these ACPI regions have the 'WB' attribute, we add them as memory and mark
> > them nomap. These show up as either a hole, or 'reserved' in /proc/iomem.
> > If they don't have the 'WB' attribute, then then they are left out of memblock
> > and aren't part of DRAM, I don't think these will show up in /proc/iomem at all.
>
> Let's say,
> 0x1000-0x1fff: reserved (SRAM for UEFI, WB)
> 0x80000000-0xffffffff: System RAM (DRAM)
May be slightly more complicated:
0x80000000-0x80001fff: System RAM (DRAM) for UEFI, WB
0x80002000-0xffffffff: System RAM (DRAM)
Kernel will have phys_offset 0x80000000, however kexec-tools will calculate it
as 0x80002000.
>
> If, as Pratyush suggested, "reserved" resources are added to phys_offset
> calculation, the kernel linear mapping area starts at PAGE_OFFSET, but
> there is no actual mapping around PAGE_OFFSET.
> It won't hurt anything, but looks funny.
> So we'd better not include "reserved" in phys_offset calculation anyway.
> -> Pratyush
My only concern is that, then we will have different values of phys_offset in
kernel and kexec-tools, which might lead to further confusion.
~Pratyush
next prev parent reply other threads:[~2016-08-23 11:23 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-09 1:52 [PATCH v24 0/9] arm64: add kdump support AKASHI Takahiro
2016-08-09 1:52 ` [PATCH v24 1/9] arm64: kdump: reserve memory for crash dump kernel AKASHI Takahiro
2016-08-09 1:55 ` [PATCH v24 2/9] memblock: add memblock_cap_memory_range() AKASHI Takahiro
2016-08-10 16:26 ` James Morse
2016-08-09 1:56 ` [PATCH v24 3/9] arm64: limit memory regions based on DT property, usable-memory-range AKASHI Takahiro
2016-08-09 1:56 ` [PATCH v24 4/9] arm64: kdump: implement machine_crash_shutdown() AKASHI Takahiro
2016-08-09 1:56 ` [PATCH v24 5/9] arm64: kdump: add kdump support AKASHI Takahiro
2016-08-10 16:38 ` James Morse
2016-08-10 18:18 ` Pratyush Anand
2016-08-11 10:03 ` Pratyush Anand
2016-08-16 10:13 ` James Morse
2016-08-17 15:33 ` [PATCH] fixup! " James Morse
2016-08-18 7:32 ` AKASHI Takahiro
2016-08-19 8:00 ` Pratyush Anand
2016-08-19 13:34 ` James Morse
2016-08-19 15:19 ` Pratyush Anand
2016-08-18 7:15 ` [PATCH v24 5/9] " AKASHI Takahiro
2016-08-18 7:19 ` Dave Young
2016-08-19 1:26 ` AKASHI Takahiro
2016-08-19 11:22 ` Pratyush Anand
2016-08-22 1:29 ` AKASHI Takahiro
2016-08-22 7:07 ` Pratyush Anand
2016-08-22 13:47 ` James Morse
2016-08-23 0:38 ` AKASHI Takahiro
2016-08-23 11:23 ` Pratyush Anand [this message]
2016-08-24 8:04 ` Dave Young
2016-08-24 10:25 ` James Morse
2016-08-25 1:04 ` Dave Young
2016-08-19 13:28 ` James Morse
2016-08-22 1:23 ` AKASHI Takahiro
2016-08-24 14:44 ` Ard Biesheuvel
2016-08-26 6:22 ` AKASHI Takahiro
2016-08-09 1:56 ` [PATCH v24 6/9] arm64: kdump: add VMCOREINFO's for user-space coredump tools AKASHI Takahiro
2016-08-09 1:56 ` [PATCH v24 7/9] arm64: kdump: enable kdump in the arm64 defconfig AKASHI Takahiro
2016-08-09 1:56 ` [PATCH v24 8/9] arm64: kdump: update a kernel doc AKASHI Takahiro
2016-08-09 1:57 ` [PATCH v24 9/9] Documentation: dt: chosen properties for arm64 kdump AKASHI Takahiro
2016-08-19 13:26 ` Rob Herring
2016-08-22 4:28 ` AKASHI Takahiro
2016-08-30 16:34 ` Rob Herring
2016-08-30 23:45 ` AKASHI Takahiro
2016-08-31 5:02 ` AKASHI Takahiro
2016-09-02 10:11 ` AKASHI Takahiro
2016-09-27 23:39 ` Mark Rutland
2016-08-09 2:04 ` [PATCH v24 0/9] arm64: add kdump support AKASHI Takahiro
2016-08-31 3:41 ` Manish Jaggi
2016-08-31 5:31 ` AKASHI Takahiro
2016-09-02 12:53 ` Manish Jaggi
2016-09-05 8:15 ` AKASHI Takahiro
2016-09-05 12:42 ` Manish Jaggi
2016-09-06 15:33 ` Marc Zyngier
2016-09-06 16:15 ` Manish Jaggi
2016-09-06 16:42 ` Marc Zyngier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160823112343.GC13501@localhost.localdomain \
--to=panand@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).