linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: lijiang <lijiang@redhat.com>
To: Borislav Petkov <bp@alien8.de>
Cc: 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: Thu, 15 Nov 2018 13:44:07 +0800	[thread overview]
Message-ID: <9eb61523-7a08-24c4-ac15-050537bd9203@redhat.com> (raw)
In-Reply-To: <20181114112600.GD13926@zn.tnic>

在 2018年11月14日 19:26, Borislav Petkov 写道:
> On Wed, Nov 14, 2018 at 03:29:25PM +0800, Lianbo Jiang wrote:
>> When load the kernel image and initramfs by kexec_file_load syscall, it can
>> not add exact e820 reserved type to kdump kernel e820 table.
>>
>> Kdump uses walk_iomem_res_desc() to iterate io resources, then adds matched
>> desc to e820 table for kdump kernel. But, when convert the e820 type into
>> the iores descriptors, several e820 types are converted to 'IORES_DES_NONE'
>> in this function e820_type_to_iores_desc(). So the walk_iomem_res_desc()
>> will get these unnecessary types(E820_TYPE_RAM/E820_TYPE_UNUSABLE/E820_TYPE
>> _KERN) when iterate io resources by the 'IORES_DES_NONE'.
>>
>> It needs filter out these redundant type(such as E820_TYPE_RAM/E820_TYPE_
>> UNUSABLE/E820_TYPE_KERN) in order to add exact e820 reserved type to kdump
>> kernel e820 table. Thus it also needs an extra checking in memmap_entry_
>> callback() to match the e820 type and resource name.
> 
> Ok, it took me a while to parse what this is trying to say so let's
> start from the top:
> 
> * What resource type do you do need in the second kernel?
> 

Thanks for your comment.

The e820 reserved ranges need to be passed to the second kernel.

> * The most important question: why?
> 

At present, the upstream kernel does not pass the e820 reserved ranges to the
second kernel, which might cause two problems:

The first one is the MMCONFIG issue, the PCI MMCONFIG(extended mode) requires
the reserved region otherwise it falls back to legacy mode, which might lead to
the hot-plug device could not be recognized in kdump kernel.

Another one is that the e820 reserved ranges do not setup in kdump kernel, which
could cause kdump can't work in some machines. To know more information, please
refer to the [PATCH 2/2 v6] patch log.


> * If it is the reserved resource, why aren't you adding
> IORES_DESC_RESERVED or so which to look for instead of this hacky string
> comparison?
> 

Adding the new descriptor 'IORES_DESC_RESERVED' is also a good solution. I will
modify these patches based on your suggestion and post again.

Thanks.
Lianbo

  reply	other threads:[~2018-11-15  5:44 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 [this message]
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
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=9eb61523-7a08-24c4-ac15-050537bd9203@redhat.com \
    --to=lijiang@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=bhe@redhat.com \
    --cc=bp@alien8.de \
    --cc=dyoung@redhat.com \
    --cc=kexec@lists.infradead.org \
    --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).