From: lijiang <lijiang@redhat.com>
To: Dave Young <dyoung@redhat.com>
Cc: linux-kernel@vger.kernel.org, kexec@lists.infradead.org,
tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com,
x86@kernel.org, akpm@linux-foundation.org,
dan.j.williams@intel.com, thomas.lendacky@amd.com,
bhelgaas@google.com, baiyaowei@cmss.chinamobile.com,
tiwai@suse.de, bp@suse.de, brijesh.singh@amd.com, bhe@redhat.com
Subject: Re: [PATCH 0/3 v3] add reserved e820 ranges to the kdump kernel e820 table
Date: Tue, 16 Oct 2018 11:45:06 +0800 [thread overview]
Message-ID: <53b582bd-e30a-848a-dfcd-e79e51296598@redhat.com> (raw)
In-Reply-To: <20181016025657.GB13006@dhcp-128-65.nay.redhat.com>
在 2018年10月16日 10:56, Dave Young 写道:
> On 09/21/18 at 03:32pm, Lianbo Jiang wrote:
>> E820 reserved ranges is useful in kdump kernel, we have added this in
>> kexec-tools code.
>>
>> One reason is PCI mmconf (extended mode) requires reserved region otherwise
>> it falls back to legacy mode.
>>
>> Furthermore, when AMD SME kdump support, it needs to map dmi table area as
>> unencrypted. For normal boot, these ranges sit in e820 reserved ranges,
>> thus the early ioremap code naturally map them as unencrypted. If we also
>> have same e820 reserve setup in kdump kernel then it will just work like
>> normal kernel.
>>
>> Kdump uses walk_iomem_res_desc to iterate resources, then adds matched desc
>> to e820 table for the kdump kernel.
>>
>> But IORES_DESC_NONE resource type includes several different e820 types, we
>> need add exact e820 type to the kdump kernel e820 table, thus it also needs
>> an extra checking in memmap_entry_callback() to match the e820 type and
>> resource name.
>>
>> By the way, we also fix an error which walks through iomem resources, the
>> values of the function parameter may be modified in the while loop of
>> __walk_iomem_res_desc(), which will cause us to not get the desired result
>> in some cases.
>>
>> Changes since v2:
>> 1. Modified the value of flags to "0", when walking through the whole
>> tree for e820 reserved ranges.
>> 2. Modified the invalid SOB chain issue.
>>
>> Lianbo Jiang (3):
>> resource: fix an error which walks through iomem resources
>> x86/kexec_file: add e820 entry in case e820 type string matches to io
>> resource name
>> x86/kexec_file: add reserved e820 ranges to kdump kernel e820 table
>
> Lianbo, since Bjorn has fixed the resource issue in another patchset,
> can you rebase your patch 2 and 3 on top of his patches and resend?
>
Ok, Thanks for your reminder.
I will adjust these patches and post again.
Thanks.
Lianbo
>>
>> arch/x86/include/asm/e820/api.h | 2 ++
>> arch/x86/kernel/crash.c | 11 ++++++++++-
>> arch/x86/kernel/e820.c | 2 +-
>> kernel/resource.c | 3 +++
>> 4 files changed, 16 insertions(+), 2 deletions(-)
>>
>> --
>> 2.17.1
>>
>
> Thanks
> Dave
>
prev parent reply other threads:[~2018-10-16 3:45 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-21 7:32 [PATCH 0/3 v3] add reserved e820 ranges to the kdump kernel e820 table Lianbo Jiang
2018-09-21 7:32 ` [PATCH 1/3 v3] resource: fix an error which walks through iomem resources Lianbo Jiang
2018-09-24 17:52 ` Bjorn Helgaas
2018-09-25 7:08 ` lijiang
2018-09-24 22:14 ` [PATCH 0/3] find_next_iomem_res() fixes Bjorn Helgaas
2018-09-24 22:14 ` [PATCH 1/3] x86/kexec: Correct KEXEC_BACKUP_SRC_END off-by-one error Bjorn Helgaas
2018-09-24 22:14 ` [PATCH 2/3] resource: Include resource end in walk_*() interfaces Bjorn Helgaas
2018-09-24 22:15 ` [PATCH 3/3] resource: Fix find_next_iomem_res() iteration issue Bjorn Helgaas
2018-09-25 8:58 ` Baoquan He
2018-09-25 11:20 ` Baoquan He
2018-09-27 5:27 ` lijiang
2018-09-27 14:03 ` Bjorn Helgaas
2018-09-28 5:09 ` lijiang
2018-09-28 13:10 ` Borislav Petkov
2018-09-26 9:22 ` [PATCH 0/3] find_next_iomem_res() fixes lijiang
2018-09-26 13:36 ` lijiang
2018-09-21 7:32 ` [PATCH 2/3 v3] x86/kexec_file: add e820 entry in case e820 type string matches to io resource name Lianbo Jiang
2018-09-21 7:32 ` [PATCH 3/3 v3] x86/kexec_file: add reserved e820 ranges to kdump kernel e820 table Lianbo Jiang
2018-10-16 2:56 ` [PATCH 0/3 v3] add reserved e820 ranges to the " Dave Young
2018-10-16 3:45 ` lijiang [this message]
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=53b582bd-e30a-848a-dfcd-e79e51296598@redhat.com \
--to=lijiang@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=baiyaowei@cmss.chinamobile.com \
--cc=bhe@redhat.com \
--cc=bhelgaas@google.com \
--cc=bp@suse.de \
--cc=brijesh.singh@amd.com \
--cc=dan.j.williams@intel.com \
--cc=dyoung@redhat.com \
--cc=hpa@zytor.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=tiwai@suse.de \
--cc=x86@kernel.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