From: Borislav Petkov <bp@alien8.de>
To: lijiang <lijiang@redhat.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
linux-kernel@vger.kernel.org, kexec@lists.infradead.org,
x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
akpm@linux-foundation.org, dyoung@redhat.com, bhe@redhat.com
Subject: Re: [PATCH 1/2 v6] x86/kexec_file: add e820 entry in case e820 type string matches to io resource name
Date: Sun, 18 Nov 2018 12:52:51 +0100 [thread overview]
Message-ID: <20181118115251.GB19380@zn.tnic> (raw)
In-Reply-To: <c3347d48-aa32-e8e4-c99b-baf2e6a21dc2@redhat.com>
On Fri, Nov 16, 2018 at 11:25:55AM +0800, lijiang wrote:
> For the pci mmconfig issue, it should be good enough that the e820 reserved region
> [mem 0x0000000078000000-0x000000008fffffff] is only passed to the second kernel, but
> the pci mmconfig region is not the same in another machine.
Yes. And now the question is, *which* reserved regions need to be mapped
for the second kernel to function properly? How do we figure that out?
> A simple case, hotplug a pci network card and use the ssh/nfs to dump the vmcore.
> If the pci mmconfig region is not reserved in kdump kernel, the pci hotplug device
> could not be recognized. So the pci network card won't work.
Yes that's a good example; put *that* example in your commit message.
> Here, there is an example about SME kdump. Maybe it can help to better understand.
You keep pasting that and I've read it already. And you keep repeating
that the reserved regions need to be mapped in the second kernel and I'm
asking, how do we determine *which* regions should we pass to the second
kernel?
If we should pass *all* reserved regions, why?
IOW, I'm looking for the *why* first.
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
next prev parent reply other threads:[~2018-11-18 11:53 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-14 7:29 [PATCH 0/2 v6] add reserved e820 ranges to the kdump kernel e820 table Lianbo Jiang
2018-11-14 7:29 ` [PATCH 1/2 v6] x86/kexec_file: add e820 entry in case e820 type string matches to io resource name Lianbo Jiang
2018-11-14 11:26 ` Borislav Petkov
2018-11-15 5:44 ` lijiang
2018-11-15 5:58 ` Dave Young
2018-11-16 1:34 ` lijiang
2018-11-15 10:39 ` Borislav Petkov
2018-11-16 3:25 ` lijiang
2018-11-18 11:52 ` Borislav Petkov [this message]
2018-11-20 4:07 ` lijiang
2018-11-21 10:54 ` lijiang
2018-11-21 13:06 ` Boris Petkov
2018-11-19 9:55 ` Dave Young
2018-11-19 10:28 ` Borislav Petkov
2018-11-20 3:37 ` lijiang
2018-11-20 19:29 ` Borislav Petkov
2018-11-20 20:43 ` Bjorn Helgaas
2018-11-21 18:42 ` Borislav Petkov
2018-11-14 7:29 ` [PATCH 2/2 v6] x86/kexec_file: add reserved e820 ranges to kdump kernel e820 table Lianbo Jiang
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=20181118115251.GB19380@zn.tnic \
--to=bp@alien8.de \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=dyoung@redhat.com \
--cc=helgaas@kernel.org \
--cc=kexec@lists.infradead.org \
--cc=lijiang@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.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;
as well as URLs for NNTP newsgroup(s).