Changes since v4:
- v4 can be seen here:
https://www.spinics.net/lists/kexec/msg23850.html
- Removed the patch (via [PATCH 4/4] in v3) which marked '--mem-usage'
option as unsupported for arm64 architecture, as we now have a mechanism
to read the 'vabits_actual' value from
This patch adds a common feature for archs (except arm64, for which
similar support is added via subsequent patch) to retrieve
'MAX_PHYSMEM_BITS' from vmcoreinfo (if available).
I recently posted a kernel patch (see [0]) which appends
'MAX_PHYSMEM_BITS' to vmcoreinfo in the core code itself
ARMv8.2-LPA architecture extension (if available on underlying hardware)
can support 52-bit physical addresses, while the kernel virtual
addresses remain 48-bit.
Make sure that we read the 52-bit PA address capability from
'MAX_PHYSMEM_BITS' variable (if available in vmcoreinfo) and
accordingly
With ARMv8.2-LVA architecture extension availability, arm64 hardware
which supports this extension can support upto 52-bit virtual
addresses. It is specially useful for having a 52-bit user-space virtual
address space while the kernel can still retain 48-bit/52-bit virtual
addressing.
Since at
Currently makedumpfile fails on arm64 for 5.4 and newer kernels with
the following :
[9.595476] kdump-tools[513]: Starting kdump-tools:
[9.597988] kdump-tools[519]: * running makedumpfile -c -d 31 /proc/vmcore
/var/crash/202009011332/dump-incomplete
[9.636915] kdump-tools[537]:
On Wed, Sep 9, 2020 at 10:04 PM Eric W. Biederman wrote:
>
> Kairui Song writes:
>
> > Currently vmcore only supports reading, this patch series is an RFC
> > to add writing support to vmcore. It's x86_64 only yet, I'll add other
> > architecture later if there is no problem with this idea.
> >
On Tue 2020-09-08 22:34:58, John Ogness wrote:
> Add support for extending the newest data block. For this, introduce
> a new finalization state (desc_finalized) denoting a committed
> descriptor that cannot be extended.
>
> Until a record is finalized, a writer can reopen that record to
> append
Kairui Song writes:
> Currently vmcore only supports reading, this patch series is an RFC
> to add writing support to vmcore. It's x86_64 only yet, I'll add other
> architecture later if there is no problem with this idea.
>
> My purpose of adding writing support is to reuse the crashed kernel's
On Tue 2020-09-08 22:34:57, John Ogness wrote:
> Rather than deriving the state by evaluating bits within the flags
> area of the state variable, assign the states explicit values and
> set those values in the flags area. Introduce macros to make it
> simple to read and write state values for the
On Tue 2020-09-08 22:34:56, John Ogness wrote:
> prb_reserve() will set some meta data values and leave others
> uninitialized (or rather, containing the values of the previous
> wrap). Simplify the API by always clearing out all the fields.
> Only the sequence number is filled in. The caller is
Previous commit introduced writing support for vmcore, it requires
per-architecture implementation for the writing function.
Signed-off-by: Kairui Song
---
arch/x86/kernel/crash_dump_64.c | 49 +++--
1 file changed, 40 insertions(+), 9 deletions(-)
diff --git
vmcore is used as the interface to access crashed kernel's memory in
kdump, and currently vmcore only supports reading.
Adding writing support is useful for enabling userspace making better
use of the old memory.
For kdump, `makedumpfile` is widely used to reduce the dumped vmcore
size, and in
Currently vmcore only supports reading, this patch series is an RFC
to add writing support to vmcore. It's x86_64 only yet, I'll add other
architecture later if there is no problem with this idea.
My purpose of adding writing support is to reuse the crashed kernel's
old memory in kdump kernel,
Simplify the code logic, also helps reduce object size and stack usage.
Stack usage:
Before: fs/proc/vmcore.c:106:9:read_from_oldmem.part.0 80 static
fs/proc/vmcore.c:106:9:read_from_oldmem 16 static
After: fs/proc/vmcore.c:106:9:read_from_oldmem 80
, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/John-Ogness/printk-reimplement-LOG_CONT-handling/20200909-115852
base:dff9f829e5b0181d4ed9d35aa62d695292399b54
config: mips-randconfig-r035-20200909
On 09.09.20 09:16, Greg Kroah-Hartman wrote:
> On Tue, Sep 08, 2020 at 10:10:07PM +0200, David Hildenbrand wrote:
>> IORESOURCE_MEM_DRIVER_MANAGED currently uses an unused PnP bit, which is
>> always set to 0 by hardware. This is far from beautiful (and confusing),
>> and the bit only applies to
On Tue, Sep 08, 2020 at 10:10:07PM +0200, David Hildenbrand wrote:
> IORESOURCE_MEM_DRIVER_MANAGED currently uses an unused PnP bit, which is
> always set to 0 by hardware. This is far from beautiful (and confusing),
> and the bit only applies to SYSRAM. So let's move it out of the
> bus-specific
17 matches
Mail list logo
