On 04/03/19 at 01:35pm, Chao Fan wrote:
> On Tue, Apr 02, 2019 at 08:03:19PM +0800, Dave Young wrote:
> >On 04/01/19 at 12:08am, Junichi Nomura wrote:
> >> Commit 3a63f70bf4c3a ("x86/boot: Early parse RSDP and save it in
> >> boot_params") broke kexec boot on EFI systems. efi_get_rsdp_addr()
> >>
On Tue, Apr 02, 2019 at 08:03:19PM +0800, Dave Young wrote:
>On 04/01/19 at 12:08am, Junichi Nomura wrote:
>> Commit 3a63f70bf4c3a ("x86/boot: Early parse RSDP and save it in
>> boot_params") broke kexec boot on EFI systems. efi_get_rsdp_addr()
>> in the early parsing code tries to search RSDP
Now we support crashkernel=X,[high,low] on arm64, update the
Documentation.
Signed-off-by: Chen Zhou
---
Documentation/admin-guide/kernel-parameters.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
When crashkernel is reserved above 4G in memory, kernel should
reserve some amount of low memory for swiotlb and some DMA buffers.
Kernel would try to allocate at least 256M below 4G automatically
as x86_64 if crashkernel is above 4G. Meanwhile, support
crashkernel=X,[high,low] in arm64.
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 kernel reads more than one crash kernel regions via a dtb
property under
After commit (arm64: kdump: support reserving crashkernel above 4G),
there may be two crash kernel regions, one is below 4G, the other is
above 4G.
Crash dump kernel reads more than one crash kernel regions via a dtb
property under node /chosen,
linux,usable-memory-range =
Signed-off-by: Chen
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.
Currently, there is only one crash kernel region on arm64, and pass
Hi Kazu,
On 27/03/2019 16:07, Kazuhito Hagio wrote:
> On 3/26/2019 12:36 PM, James Morse wrote:
>> On 20/03/2019 05:09, Bhupesh Sharma wrote:
>>> With ARMv8.2-LVA architecture extension availability, arm64 hardware
>>> which supports this extension can support a virtual address-space upto
>>>
Hi Bhupesh,
On 28/03/2019 11:42, Bhupesh Sharma wrote:
> On 03/26/2019 10:06 PM, James Morse wrote:
>> On 20/03/2019 05:09, Bhupesh Sharma wrote:
>>> With ARMv8.2-LVA architecture extension availability, arm64 hardware
>>> which supports this extension can support a virtual address-space upto
>>>
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:
在 2019年04月02日 17:06, Borislav Petkov 写道:
> 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
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
Commit 3a63f70bf4c3a ("x86/boot: Early parse RSDP and save it in
boot_params") broke kexec boot on EFI systems. efi_get_rsdp_addr()
in the early parsing code tries to search RSDP from EFI table but
that will crash because the table address is virtual when the kernel
was booted by kexec.
In the
On 4/2/19 8:06 PM, Chao Fan wrote:
> On Tue, Apr 02, 2019 at 09:53:51AM +, Junichi Nomura wrote:
>> On Tue, Apr 02, 2019 at 05:41:49PM +0800, Chao Fan wrote:
>>> [ 77.989030] kexec_core: Starting new kernel
>>> early console in extract_kernel
>>> input_data: 0x00017f6033b1
>>> input_len:
On Tue, Apr 02, 2019 at 09:53:51AM +, Junichi Nomura wrote:
>On Tue, Apr 02, 2019 at 05:41:49PM +0800, Chao Fan wrote:
>> [ 77.989030] kexec_core: Starting new kernel
>> early console in extract_kernel
>> input_data: 0x00017f6033b1
>> input_len: 0x008412d4
>> output:
On Tue, Apr 02, 2019 at 05:41:49PM +0800, Chao Fan wrote:
> [ 77.989030] kexec_core: Starting new kernel
> early console in extract_kernel
> input_data: 0x00017f6033b1
> input_len: 0x008412d4
> output: 0x00017e00
> output_len: 0x01e15844
> kernel_total_size:
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,
> + *
Hi,
I have test your PATCH in Qemu guest:
--
Fedora 29 (Workstation Edition)
Kernel 5.1.0-rc3+ on an x86_64 (ttyS0)
localhost login: root
Password:
Last login: Tue Apr 2 05:30:33 on ttyS0
[root@localhost ~]# cd /boot
[root@localhost boot]# ls
config-4.18.16-300.fc29.x86_64
efi
extlinux
18 matches
Mail list logo
