On Fri, Aug 02, 2019 at 03:48:53PM +0800, kernel test robot wrote:
> FYI, we noticed the following commit (built with gcc-7):
>
> commit: 5b51ae969e3d8ab0134ee3c98a769ad6d2cc2e24 ("x86/boot: Call
> get_rsdp_addr() after console_init()")
>
On Wed, Jun 12, 2019 at 04:52:22PM +, Lendacky, Thomas wrote:
> I think the discussion ended up being that debuginfo wasn't being stripped
> from the kernel and initrd (mainly the initrd). What are the sizes of
> the kernel and initrd that you are loading for kdump via kexec?
>
> From
On Wed, Jun 12, 2019 at 09:55:49AM +0800, Baoquan He wrote:
> With further investigation, the failure after applying Tom's patch is
> caused by OOM. When increase crashkernel reservation to 512M, kdump
> kernel can boot successfully. I noticed your crashkernel reservation is
> 256M, that will fail
On Sat, Jun 08, 2019 at 06:26:59PM +0800, Baoquan He wrote:
> OK, I see. Then it should be the issue we have met and talked about with
> Tom.
> https://lkml.kernel.org/r/20190604134952.GC26891@MiWiFi-R3L-srv
>
> You can apply Tom's patch as below. I tested it, it can make kexec
> kernel succeed
On Mon, Jun 10, 2019 at 11:07:05AM +, Junichi Nomura wrote:
> I had tested the version I posted here on bunch of physical machines
> I had access and confirmed it didn't broke working setups:
> https://lore.kernel.org/lkml/20190515051717.ga13...@jeru.linux.bs1.fc.nec.co.jp/
>
> Since the
On Mon, Jun 10, 2019 at 06:18:50PM +0800, Kairui Song wrote:
> Hi Boris, unfortunately I don't have a real machine which only have
> the NVS region. I did fake the memmap to emulate such problem but
> can't really promise this will fix the real case. So just declare it
> won't break anything that
On Mon, Jun 10, 2019 at 03:36:17PM +0800, Kairui Song wrote:
> With the recent addition of RSDP parsing in decompression stage, kexec
> kernel now needs ACPI tables to be covered by the identity mapping.
> And in commit 6bbeb276b71f ("x86/kexec: Add the EFI system tables and
> ACPI tables to the
On Sat, Jun 08, 2019 at 06:01:39PM +0800, Baoquan He wrote:
> OK, it may be different with the case we met, if panic happened when
> load a kdump kernel.
>
> We can load with 'kexec -l' or 'kexec -p', but can't boot after triggering
> crash or execute 'kexec -e' to do kexec jumping.
No, I load a
On Sat, Jun 08, 2019 at 11:54:51AM +0800, Baoquan He wrote:
> Is it a UEFI box?
Yes.
> If it's uefi machine, it should relate to below issue. Because kexec
> always fails to randomly choose a new position for kernel.
The kernel succeeds in selecting a position for the kernel - the kexec
kernel
On Tue, May 28, 2019 at 03:30:21PM +0800, lijiang wrote:
> Hi, Boris and Thomas
>
> Could you give me any suggestions about this patch series? Other reviewers?
So I'm testing this on a box with SME enabled but after loading the
crash kernel, it freezes instead of rebooting. My cmdline is:
On Mon, Jan 28, 2019 at 11:18:31AM +0100, Borislav Petkov wrote:
> On Mon, Jan 28, 2019 at 05:58:09PM +0800, Dave Young wrote:
> > Another reason is in case ,high we will need automatically reserve a
> > region in low area for swiotlb. So for example one use
> > crashkern
On Tue, May 28, 2019 at 10:49:54AM +0800, Kairui Song wrote:
> Hi, by now, I still didn't see any tip branch pick up this patch yet,
> any update?
Ok, stuff is queued in tip:x86/boot now. Please test it as much as you
can and send all fixes ontop.
Thx.
--
Regards/Gruss,
Boris.
Good
On Tue, May 21, 2019 at 02:53:52PM -0700, Dirk van der Merwe wrote:
> Where can I find the next-merge-window tree?
>
> I can test against that too.
It'll appear soon in a tip branch. I'd appreciate if you tested that
instead - stay tuned...
Thx.
--
Regards/Gruss,
Boris.
ECO tip #101:
On Tue, May 21, 2019 at 05:02:59PM +0800, Kairui Song wrote:
> Hi Boris, would you prefer to just fold Junichi update patch into the
> previous one or I should send an updated patch?
Please send a patch ontop after Ingo queues your old one, which should
happen soon. This way it would also
And now as a proper patch:
---
From: Borislav Petkov
... so that early debugging output from the RSDP parsing code can be
visible and collected.
Suggested-by: Dave Young
Signed-off-by: Borislav Petkov
Cc: Baoquan He
Cc: Chao Fan
Cc: Jun'ichi Nomura
Cc: Kairui Song
Cc: kexec
On Tue, May 14, 2019 at 11:22:08AM +0800, Dave Young wrote:
> Another thing is we can move the get rsdp after console_init, but that
> can be done later as separate patch.
https://lkml.kernel.org/r/20190417090247.gd20...@zn.tnic
--
Regards/Gruss,
Boris.
Good mailing practices for 400:
On Tue, Apr 30, 2019 at 03:44:20PM +0800, Lianbo Jiang wrote:
> When SEV is active, the second kernel image is loaded into the
> encrypted memory. Lets make sure that when kexec builds the
> identity mapping page table it adds the memory encryption mask(C-bit).
>
> Co-developed-by: Brijesh Singh
On Wed, May 15, 2019 at 05:17:19AM +, Junichi Nomura wrote:
> Hi Kairui,
>
> On 5/13/19 5:02 PM, Baoquan He wrote:
> > On 05/13/19 at 09:50am, Borislav Petkov wrote:
> >> On Mon, May 13, 2019 at 03:32:54PM +0800, Baoquan He wrote:
> >> So we're going to try i
On Mon, May 13, 2019 at 03:32:54PM +0800, Baoquan He wrote:
> This is a critical bug which breaks memory hotplug,
Please concentrate and stop the blabla:
36f0c423552d ("x86/boot: Disable RSDP parsing temporarily")
already explains what the deal is. This code was *purposefully* disabled
because
Baoquan,
On Mon, May 13, 2019 at 09:43:05AM +0800, Baoquan He wrote:
> Can this patchset be merged, or picked into tip?
what is this thing that happens everytime after a kernel is released and
lasts for approximately 2 weeks?
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid
1 GB area with the physical memory.
Therefore, make sure they're always mapped.
[ bp: productize half-baked patch:
- rewrite commit message.
- s/init_acpi_pgtable/map_acpi_tables/ in the !ACPI case. ]
Signed-off-by: Kairui Song
Signed-off-by: Baoquan He
Signed-off-by: Borislav Petkov
C
On Sun, Apr 28, 2019 at 01:41:14PM +0800, Baoquan He wrote:
> About this place, do you think below change is OK to you?
>
> ~~~
> The current code only builds identity mapping for physical memory during
> kexec-type loading. The regions reserved by firmware are not covered.
> In the later code
On Wed, Apr 24, 2019 at 05:29:43PM +0800, Baoquan He wrote:
> From: Kairui Song
>
> The current code only builds identity mapping for physical memory during
> kexec-type loading. The regions reserved by firmware are not covered.
> In the next patch, the boot decompressing code of kexec-ed kernel
On Fri, Apr 26, 2019 at 09:59:54AM +0800, lijiang wrote:
> Hope this help. Thanks.
It does help, yes. When this explanation above is part of the commit
message, it helps immensely!
:-)
> So sorry for the delay, i am trying my best to explain it in detail.
I don't care about the delay as long
On Fri, Apr 26, 2019 at 05:51:34PM +0800, Baoquan He wrote:
> I can make a patch to add a bit into xloadflags, to indicate that this
> is kexec-ed kernel. It can help to differentiate kexec-ed kernel from
> kdump kernel.
>From the recent snafu, the only thing we needed is to differentiate
between
On Wed, Apr 24, 2019 at 05:29:42PM +0800, Baoquan He wrote:
> In this series, patch 2/2 has dependency on patch 1/1, otherwise
> it may cause system to reset to firmware on some machines.
>
> The patch 2/2 is the version Boris organized:
> http://lkml.kernel.org/r/20190416095209.gg27...@zn.tnic
>
+ hpa
On Mon, Apr 22, 2019 at 10:33:46PM +0800, Baoquan He wrote:
> On 04/19/19 at 01:36pm, Borislav Petkov wrote:
> > On Fri, Apr 19, 2019 at 01:28:01PM +0200, Borislav Petkov wrote:
> > > Read again what I said: "should all be passed through boot_params".
> >
the outstanding issues.
---
From: Borislav Petkov
The original intention to move RDSP parsing very early, before KASLR
does its ranges selection, was to accommodate movable memory regions
machines (CONFIG_MEMORY_HOTREMOVE) to still be able to do memory
hotplug.
However, that broke kexec'ing a kernel on EFI
On Fri, Apr 19, 2019 at 01:28:01PM +0200, Borislav Petkov wrote:
> Read again what I said: "should all be passed through boot_params".
> Which means, boot_params should be extended with a field of a flag to
> say: "this is a kexec'ed kernel".
And by that I mean
On Fri, Apr 19, 2019 at 07:20:06PM +0800, Kairui Song wrote:
> Thanks for the declaration Bao, I can verify on the machine I have,
> the issue still exist without kaslr. Currently, we read rsdp in early
> code and fill in boot_params unconditional, so it will read from the
> systab anyway.
Yes,
On Fri, Apr 19, 2019 at 06:50:14PM +0800, Baoquan He wrote:
> Talked with Kairui privately just now. Seems Junichi's patch need add
> this systab mapping. Since the systab region is not mapped on some
> machines. Those machine don't have this issue because they got systab
> region luckily coverred
Breaking thread because this one got too big.
On Fri, Apr 19, 2019 at 04:34:58PM +0800, Kairui Song wrote:
> There are two approach to fix it, detect if the systab is mapped, and
> avoid reading it if not.
Ok, so tglx and I discussed this situation which is slowly getting out
of hand with all
On Thu, Apr 18, 2019 at 01:17:03PM +, Lendacky, Thomas wrote:
> You could probably make this unsigned int for now since you're creating
> the new enum used to assign to this variable and it only uses two bits
> currently.
Right.
> > + if (res->desc & (IORES_DESC_NONE |
On Wed, Apr 17, 2019 at 02:40:09PM +0800, lijiang wrote:
> Based on the above description, i made a draft patch, please refer to it. But
> it
> seems that the code has been changed a lot.
It goes in the right direction. Here is a version where I corrected some
things:
---
diff --git
On Wed, Apr 17, 2019 at 10:54:34AM +0200, Borislav Petkov wrote:
> On Wed, Apr 17, 2019 at 03:02:50PM +0800, Dave Young wrote:
> > How about move it after console_init,
>
> Sounds ok to me. That's still before KASLR gets setup and should work
> for Chao's movable regions to
On Wed, Apr 17, 2019 at 03:02:50PM +0800, Dave Young wrote:
> How about move it after console_init,
Sounds ok to me. That's still before KASLR gets setup and should work
for Chao's movable regions too.
> and at the same time skip efi_get_rsdp_addr in case kexec?
If kexec_get_rsdp_addr() gets a
On Wed, Apr 17, 2019 at 09:38:38AM +0800, Dave Young wrote:
> But if you want to apply it now, I think it is fine as well, probably
> the laptop issue is lenovo firmware specific, we can add rsdp in cmdline
> or boot params via kexec-tools so it should be good by using new kexec-tools.
I'm not in
On Tue, Apr 16, 2019 at 07:41:33PM +0800, Dave Young wrote:
> On 04/16/19 at 11:52am, Borislav Petkov wrote:
> > I'll queue the below in the next days if there are no more complaints:
>
> As for the kexec breakage, even with the V3 patch, kexec still hangs on
> a Lenovo T420 la
On Tue, Apr 16, 2019 at 07:35:15PM +0800, Chen Zhou wrote:
> When crashkernel is reserved above 4G in memory, kernel should reserve
> some amount of low memory for swiotlb and some DMA buffers. So there may
> be two crash kernel regions, one is below 4G, the other is above 4G.
>
> Crash dump
On Tue, Apr 16, 2019 at 12:02:26PM +0200, Ingo Molnar wrote:
>
> * Borislav Petkov wrote:
>
> > I'll queue the below in the next days if there are no more complaints:
>
> Just a minor style nit, this was inherited from existing code:
>
> > +
On Mon, Apr 15, 2019 at 11:14:34PM +, Junichi Nomura wrote:
> I see kexec is only supported on 64bit kernel. But are we sure
> we don't need to support kexec on EFI32 + 64bit kernel?
>
> I don't have such an environment and as far as I tried with OVMF i386
> and KVM guest, that combination
i Nomura
Signed-off-by: Borislav Petkov
Cc: Chao Fan
Cc: Borislav Petkov
Cc: Dave Young
Link:
https://lkml.kernel.org/r/20190408231011.ga5...@jeru.linux.bs1.fc.nec.co.jp
---
arch/x86/boot/compressed/acpi.c | 143
1 file changed, 107 insertions(+), 36 deletions(-
On Mon, Apr 15, 2019 at 11:00:25PM +, Junichi Nomura wrote:
> I thought we should hang here instead of return so that we
> don't run into efi_get_rsdp_addr() in case of kexec.
Hanging that early without debug output is not very friendly to
debuggers, methinks.
> > + ei = _params->efi_info;
On Mon, Apr 15, 2019 at 11:07:17AM +0200, Borislav Petkov wrote:
> On Mon, Apr 15, 2019 at 07:01:54AM +, Junichi Nomura wrote:
> > OK. Then I'll go back to v3 and make sure to hang when
> > something is wrong during kexec boot on EFI system.
>
> No need - I have it her
On Mon, Apr 15, 2019 at 07:01:54AM +, Junichi Nomura wrote:
> OK. Then I'll go back to v3 and make sure to hang when
> something is wrong during kexec boot on EFI system.
No need - I have it here locally. I'll clean it up and post it for
review.
--
Regards/Gruss,
Boris.
Good mailing
On Fri, Apr 12, 2019 at 10:49:56AM +0200, Borislav Petkov wrote:
> Now I need to go figure out whether there's a reliable way to know in
> the kexec kernel that it *is* a kexec kernel.
Actually, thinking about this more, we don't need to know whether the
kernel was kexeced or not. Why?
B
On Fri, Apr 12, 2019 at 02:54:17AM +, Junichi Nomura wrote:
> Without #ifdef CONFIG_X86_64, I got compiler warnings on 32bit build
> about casting u64 to pointer.
Yah, stupid ifdeffery.
> We need #ifdef CONFIG_EFI to avoid build failure about undefined
> __efi_get_rsdp_addr().
diff --git
Something like this based on your v3. I still need to figure out a
reliable way to check in kexec_get_rsdp_addr() whether we're a kexec-ed
kernel but other than that, it should look something like this:
---
diff --git a/arch/x86/boot/compressed/acpi.c b/arch/x86/boot/compressed/acpi.c
index
On Thu, Apr 11, 2019 at 08:16:45AM +, Junichi Nomura wrote:
> kexec_get_rsdp_addr() might fail on kexec-booted kernel, e.g. if the
> setup_data was invalid. In such a case, falling back to efi_get_rsdp_addr()
> will hit the problem of accessing invalid table pointer again.
Then you need to do
On Wed, Apr 10, 2019 at 11:34:51PM +, Junichi Nomura wrote:
> But efi_get_rsdp_addr() needs to check whether the kernel was
> kexec booted to avoid accessing invalid EFI table address.
> efi_get_kexec_setup_data_addr() is the only method I know
> to check if it was kexec-booted.
Your v3 had
inters depending
> on whether the kernel is booted by kexec or not.
>
> Fixes: 3a63f70bf4c3a ("x86/boot: Early parse RSDP and save it in boot_params")
> Signed-off-by: Jun'ichi Nomura
> Acked-by: Baoquan He
> Tested-by: Chao Fan
> Cc: Borislav Petkov
> Cc
On Thu, Apr 04, 2019 at 10:12:41PM +0800, Dave Young wrote:
> The early code hang can make people confused, it is hard to
> say what happens and not easy to debug. But if we return 0 then kernel
> just continue to boot, and fail later because of no acpi root pointer, at
> least we can have some
On Thu, Apr 04, 2019 at 03:32:33PM +0800, Dave Young wrote:
> BTW, it would be good to start a new thread when you send V4 :)
Yes please.
> > + /* Get systab from boot params. */
> > + systab = (efi_system_table_64_t *) (ei->efi_systab |
> > ((__u64)ei->efi_systab_hi << 32));
> > + if
On Thu, Apr 04, 2019 at 03:41:02PM +0800, Dave Young wrote:
> It is hard to find 32bit efi hardware, I can confirm all the laptop I
> have are 64bit efi.
You can use 32-bit OVMF with qemu, like in the link Chao gave a couple
of mails earlier.
--
Regards/Gruss,
Boris.
Good mailing practices
On Wed, Apr 03, 2019 at 04:26:34PM +0800, Dave Young wrote:
> Personally I would like to have a cmdline to bypass the early acpi code
> because early code is hard to debug, if we have something weird happens
> we can try to gate out these code, and then get some idea..
No, this early crap better
On Tue, Apr 02, 2019 at 08:02:04PM +0800, lijiang wrote:
> These regions(E820_TYPE_{RESERVED_KERN,RAM,UNUSABLE}) are still marked as
> IORES_DESC_NONE and should not be mapped encrypted when using ioremap().
Seems to me like we're going in circles. You said here:
On Wed, Mar 27, 2019 at 01:36:27PM +0800, Lianbo Jiang wrote:
> Currently, the arch_kexec_post_{alloc,free}_pages() unconditionally
> maps the kexec area as decrypted. This works fine when SME is active.
> Because in SME, the first kernel is loaded in decrypted area by the
> BIOS, so the second
On Fri, Mar 29, 2019 at 08:39:13PM +0800, Lianbo Jiang wrote:
> -static int __ioremap_check_desc_other(struct resource *res)
> +/*
> + * Originally, these areas described as IORES_DESC_NONE are not mapped
> + * as encrypted when using ioremap(), for example, E820_TYPE_{RESERVED,
> + *
e code originally related to the
> descriptor 'IORES_DESC_NONE' also need to be updated.
>
> Suggested-by: Borislav Petkov
> Signed-off-by: Lianbo Jiang
> ---
> arch/x86/kernel/e820.c | 2 +-
> arch/x86/mm/ioremap.c | 16 ++--
> include/linux/ioport.h | 1 +
On Fri, Mar 29, 2019 at 05:05:50PM +0800, Chao Fan wrote:
> But in my code, I am not sure which version will be found firstly, so I
> write this logical, if ACPI20 found, return directly, then consider ACPI 1.0.
Thanks.
Junichi, please add a shorter version of that as a comment to the code,
On Fri, Mar 29, 2019 at 03:05:52AM +, Junichi Nomura wrote:
> > You don't need that variable and can return "table" or 0 after the endif
> > below.
>
> I could do that but it will slightly change the current logic.
>
> Existing code does this:
>
> if (!(efi_guidcmp(guid,
On Wed, Mar 27, 2019 at 09:48:52AM +0800, b...@redhat.com wrote:
> I guess Boris is suggesting code like below. Please correct me if I am
> wrong.
Yap, exactly.
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On Mon, Mar 25, 2019 at 11:10:01PM +, Junichi Nomura wrote:
> efi_get_rsdp_addr() and kexec_get_rsdp_addr() could be implemented
> like this (sorry about the pseudo code):
This doesn't look like what I suggested:
> So efi_get_rsdp_addr() needs to be refactored in such a way so that at
>
On Mon, Mar 25, 2019 at 05:17:55PM +, Singh, Brijesh wrote:
> By default all the memory regions are mapped encrypted. The
> set_memory_{encrypt,decrypt}() is a generic function which can be
> called explicitly to clear/set the encryption mask from the existing
> memory mapping. The
On Mon, Mar 25, 2019 at 08:23:02PM +0800, Dave Young wrote:
> efi_enter_virtual_mode() can only run once because of efi firmware/spec
> limitation, and after entered virtual mode, efi firmware just updated
I should remember that - I did it at the time.
> Kexec saved the original physical
On Mon, Mar 25, 2019 at 02:53:02PM +0800, lijiang wrote:
> In this function, i printed its values, and only got the value of reserved
> type, so i changed the IORES_DESC_NONE to the IORES_DESC_RESERVED.
>
> In addition, after the new descriptor 'IORES_DESC_RESERVED' is introduced,
> the
On Mon, Mar 25, 2019 at 05:20:43PM +0800, lijiang wrote:
> Let's look at the discussion in patch v8, please refer to this link:
> https://lkml.org/lkml/2019/3/16/15
>
> I did a test according to Tom's reply, and the test indicated his suggestion
> was
> correct, we should change this to check
On Mon, Mar 25, 2019 at 10:36:33AM +, Junichi Nomura wrote:
> AFAIU, early parsing is new code in v5.1-rc1 to support kexec on systems
> with hotpluggable memory with KASLR enabled. For systems that requires the
> new feature, it may be ok to say "you need to use another kexec interface"
>
On Mon, Mar 25, 2019 at 11:11:45AM +0800, lijiang wrote:
> I mean it needs to find all the value of the 'IORES_DESC_ACPI_*' type.
A function called __ioremap_check_desc_other() needs to find
IORES_DESC_ACPI_* types...
No, still don't know what you're trying to do.
> As above mentioned, it needs
On Mon, Mar 25, 2019 at 09:58:07AM +0800, lijiang wrote:
> For the SEV virtual machine, it maps the kexec memroy area as
> encrypted, so, no need to invoke this function to change anything.
Look at the code:
set_memory_decrypted->__set_memory_enc_dec
It already *does* invoke this function.
> >
> Subject: Re: [PATCH 1/3] kexec: Do not map the kexec area as decrypted when
> SEV is active
The tip tree preferred format for patch subject prefixes is
'subsys/component:', e.g. 'x86/apic:', 'x86/mm/fault:', 'sched/fair:',
'genirq/core:'. Please do not use file names or complete file paths as
DESC_RESERVED' instead of 'IORES_DESC_NONE', it has been
> changed.
That sentence I cannot parse.
> Suggested-by: Borislav Petkov
> Signed-off-by: Lianbo Jiang
> ---
> arch/x86/kernel/e820.c | 2 +-
> include/linux/ioport.h | 1 +
> kernel/resource.c | 6 +++---
>
On Thu, Mar 21, 2019 at 06:33:07PM +0800, Lianbo Jiang wrote:
> Following the commit <0e4c12b45aa8> ("x86/mm, resource: Use
> PAGE_KERNEL protection for ioremap of memory pages"),
The proper commit quotation format is done by adding this to your
.gitconfig:
[core]
abbrev = 12
[alias]
On Mon, Feb 25, 2019 at 07:12:16PM +0800, Dave Young wrote:
> If we move to high as default, it will allocate 160M high + 256M low. It
We won't move to high by default - we will *fall* back to high if the
default allocation fails.
> To make the process less fragile maybe we can remove the 896M
On Sun, Feb 24, 2019 at 09:25:18PM +0800, Pingfan Liu wrote:
> Maybe I misunderstood you, but does "requested range failed" mean that
> user specify the range? If yes, then it should be the duty of user as
> you said later, not the duty of kernel"
No, it should say that it selected a different
On Fri, Feb 22, 2019 at 09:42:41AM +0100, Joerg Roedel wrote:
> The current default of 256MB was found by experiments on a bigger
> number of machines, to create a reasonable default that is at least
> likely to be sufficient of an average machine.
Exactly, and this is what makes sense.
The code
On Wed, Feb 20, 2019 at 05:41:46PM +0800, Dave Young wrote:
> Previously Joerg posted below patch, maybe he has some idea. Joerg?
Isn't it clear from the commit message?
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On Mon, Feb 18, 2019 at 09:48:20AM +0800, Dave Young wrote:
> It is ideal if kernel can do it automatically, but I'm not sure if
> kernel can predict the swiotlb reserved size automatically.
Do you see how even more absurd this gets?
If the kernel cannot know the swiotlb reserved size
On Tue, Feb 12, 2019 at 04:48:16AM +0800, Dave Young wrote:
> Even we make it automatic in kernel, but we have to have some default
> value for swiotlb in case crashkernel can not find a free region under 4G.
> So this default value can not work for every use cases, people need
> manually use
On Mon, Feb 04, 2019 at 03:30:16PM -0700, Jerry Hoemann wrote:
> Is your objection only to the second fallback of allocating
> memory above >= 4GB? Or are you objecting to allocating from
> (896 .. 4GB) as well?
My problem is why should the user need to specify high or low allocation
explicitly
On Thu, Jan 31, 2019 at 03:27:32PM -0700, Jerry Hoemann wrote:
> So even if a system administrator is diligent and tests
> that a chosen kdump configuration works, that configuration
> might not work on some random reboot 7 months in the future.
Jerry, did you read the rest of the thread where
On Thu, Jan 31, 2019 at 03:59:07PM +0800, Dave Young wrote:
> As Pingfan/me mentioned in another reply, there are two reasons:
> 1. old kexec-tools can not load kernel to high memory
> 2. ,high will not work on some systems without some amounts of low
> memory so it nees reserve extra low memory,
On Tue, Jan 29, 2019 at 01:51:45PM +0800, Pingfan Liu wrote:
> Sorry, can not catch up with you. Do you suggestion
> memblock_find_in_range(0, kernel_start) and
> memblock_find_in_range(kernel_end, mem_end)? But the memory is
> truncated into fraction by many component which call
>
On Mon, Jan 28, 2019 at 05:58:09PM +0800, Dave Young wrote:
> Another reason is in case ,high we will need automatically reserve a
> region in low area for swiotlb. So for example one use
> crashkernel=256M,high, actual reserved memory is 256M above 4G and
> another 256M under 4G for swiotlb.
On Fri, Jan 25, 2019 at 09:45:18PM +0800, Dave Young wrote:
> AFAIK, some people prefer to explictly reserve crash memory at high
> region even if it is possible to reserve at low area. May because
> <4G memory is limited on large server, they want to leave this for other
> use.
>
> Yinghai or
ere was an old discussion below (previously posted by Chao Wang):
> https://lkml.org/lkml/2013/10/15/601
All that changelog info doesn't belong in the commit message ...
> Signed-off-by: Pingfan Liu
> Cc: Dave Young
> Cc: Baoquan He
> Cc: Andrew Morton
> Cc: Mike Rap
On Tue, Jan 22, 2019 at 11:32:41AM +0800, Chao Fan wrote:
> But I notice the only function call entry is in kaslr.c which needs
> RANDOMIZE_BASE, so do I need change it as:
> vmlinux-objs-$(CONFIG_RANDOMIZE_BASE) += $(obj)/acpi.o
Well, the very first patch in this thread doesn't have anything to
On Mon, Jan 21, 2019 at 04:43:52PM +0800, Chao Fan wrote:
> Since I didn't see where Xen to fill the value, if
> boot_params->acpi_rsdp_addr is filled before my code, I just need to
> read it. If when I try to read it but not found, then parse RSDP and
> fill the RSDP address to
On Mon, Jan 21, 2019 at 09:18:30AM +0800, Chao Fan wrote:
> So I have changed as this method and put in my mail thread, you may not
> notice, so I put here for my function if I need to fill the
> boot_parameters:
>
> static inline acpi_physical_address get_boot_params_rsdp(void)
> {
>
On Fri, Jan 18, 2019 at 07:13:09PM +0800, Kairui Song wrote:
> Currently we have acpi_os_get_root_pointer as the universal function
> to get RSDP address. But the function itself and some functions it
> depends on are in .init section and make it not easy to retrieve the
> RSDP value once kernel
On Thu, Jan 17, 2019 at 03:41:13PM +0800, Kairui Song wrote:
> How about we refill the boot_params.acpi_rsdp_addr if it is not valid
> in early code, so it could be used as a reliable RSDP address source?
> That should make things easier.
>
> But if early code should parse it and store it should
On Wed, Jan 16, 2019 at 03:08:42PM +0800, Kairui Song wrote:
> I didn't see a way to reuse things in that patch series, situation is
> different, in that patch it needs to get RSDP in very early boot stage
> so it did everything from scratch, in this patch kexec_file_load need
> to get RSDP too,
On Tue, Jan 15, 2019 at 05:58:34PM +0800, Kairui Song wrote:
> When efi=noruntime or efi=oldmap is used, EFI services won't be available
> in the second kernel, therefore the second kernel will not be able to get
> the ACPI RSDP address from firmware by calling EFI services and won't
> boot.
On Mon, Jan 14, 2019 at 03:49:14PM -0500, Dave Anderson wrote:
> Yeah, I've been watching the thread, and the document looks fine to me.
> It's just that when I saw the discussion of this one being removed that
> I felt the need to respond... ;-)
Good. :-)
Ok, I've amended the
On Mon, Jan 14, 2019 at 03:26:32PM -0500, Dave Anderson wrote:
> No. It needs *both* the vmlinux file and the vmcore file in order to read
> kernel
> virtual memory, so just having a kernel virtual address is insufficient.
>
> So it's a chicken-and-egg situation. This particular --osrelease
On Mon, Jan 14, 2019 at 03:07:33PM -0500, Dave Anderson wrote:
> That's what it *does* utilize -- it takes a standalone vmcore dumpfile, and
> pulls out the OSRELEASE string from it, so that a user can determine what
> vmlinux file should be used with that vmcore for normal crash analysis.
And
On Mon, Jan 14, 2019 at 02:36:47PM -0500, Dave Anderson wrote:
> There's no reading of the dumpfile's memory involved, and that being the case,
> the vmlinux file is not utilized. That's the whole point of the crash
> option, i.e.,
> taking a vmcore file, and trying to determine what kernel
On Mon, Jan 14, 2019 at 01:58:32PM -0500, Dave Anderson wrote:
> Preferably it would be left as-is. The crash utility has a "crash
> --osrelease vmcore"
> option that only looks at the dumpfile header, and just dump the string.
> With respect
> to compressed kdumps, crash could alternatively
On Mon, Jan 14, 2019 at 05:48:48PM +, Kazuhito Hagio wrote:
> As for makedumpfile, it will be not impossible to remove the
> init_uts_ns.name.relase (OSRELEASE), but some fixes are needed.
> Because historically OSRELEASE has been a kind of a mandatory entry
> in vmcoreinfo from the beginning
On Mon, Jan 14, 2019 at 01:30:30PM +0800, lijiang wrote:
> I noticed that the checkpatch was coded in Perl. But i am not familiar with
> the Perl program language, that would be beyond my ability to do this, i have
> to learn the Perl program language step by step. :-)
You could give it a try -
201 - 300 of 601 matches
Mail list logo
