Also cc Masaki/Masahiko/piliu.
Thanks.
Lianbo
在 2018年03月06日 18:07, Lianbo Jiang 写道:
> A data overflow may lead to a reversal, which may turn a positive
> number into a large negative number, in this case, the string's
> length will exceed the array size(for example, eta: -2147483648s),
> here the
在 2018年04月09日 17:40, Petr Tesarik 写道:
> Essentially, the estimated remaining time is calculated as:
>
> elapsed * (100 - progress) / progress
>
> However, print_progress() is also called when progress is 0. The
> result of a floating point division by zero is either NaN (if
> elapsed is zero),
在 2018年05月15日 22:34, Tom Lendacky 写道:
> On 5/14/2018 8:51 PM, Lianbo Jiang wrote:
>> It is convenient to remap the old memory encrypted to the second kernel
>> by calling ioremap_encrypted().
>>
>> Signed-off-by: Lianbo Jiang
>> ---
>> arch/x86/include/asm/io.h | 2 ++
>> arch/x86/mm/ioremap.c
在 2018年05月16日 04:18, Tom Lendacky 写道:
> On 5/14/2018 8:51 PM, Lianbo Jiang wrote:
>> When sme enabled on AMD server, we also need to support kdump. Because
>> the memory is encrypted in the first kernel, we will remap the old memory
>> encrypted to the second kernel(crash kernel), and sme is also e
在 2018年05月16日 04:18, Tom Lendacky 写道:
> On 5/14/2018 8:51 PM, Lianbo Jiang wrote:
>> When sme enabled on AMD server, we also need to support kdump. Because
>> the memory is encrypted in the first kernel, we will remap the old memory
>> encrypted to the second kernel(crash kernel), and sme is also e
在 2018年05月15日 21:31, Tom Lendacky 写道:
> On 5/14/2018 8:51 PM, Lianbo Jiang wrote:
>> It is convenient to remap the old memory encrypted to the second kernel by
>> calling ioremap_encrypted().
>>
>> When sme enabled on AMD server, we also need to support kdump. Because
>> the memory is encrypted in
在 2018年05月17日 21:45, lijiang 写道:
> 在 2018年05月15日 21:31, Tom Lendacky 写道:
>> On 5/14/2018 8:51 PM, Lianbo Jiang wrote:
>>> It is convenient to remap the old memory encrypted to the second kernel by
>>> calling ioremap_encrypted().
>>>
>>> When sme e
在 2018年05月21日 21:23, Tom Lendacky 写道:
> On 5/20/2018 10:45 PM, lijiang wrote:
>> 在 2018年05月17日 21:45, lijiang 写道:
>>> 在 2018年05月15日 21:31, Tom Lendacky 写道:
>>>> On 5/14/2018 8:51 PM, Lianbo Jiang wrote:
>>>>> It is convenient to remap the old memory en
在 2018年06月14日 20:55, kbuild test robot 写道:
> Hi Lianbo,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on v4.17 next-20180614]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve t
在 2018年06月15日 15:19, Dave Young 写道:
> On 06/14/18 at 04:47pm, Lianbo Jiang wrote:
>> When sme enabled on AMD server, we also need to support kdump. Because
>> the memory is encrypted in the first kernel, we will remap the old memory
>> encrypted to the second kernel(crash kernel), and sme is also e
在 2018年06月19日 11:16, Dave Young 写道:
> On 06/16/18 at 04:27pm, Lianbo Jiang wrote:
>> In kdump mode, we need to dump the old memory into vmcore file,
>> if SME is enabled in the first kernel, we must remap the old
>> memory in encrypted manner, which will be automatically decrypted
>> when we read f
在 2018年04月10日 15:47, Petr Tesarik 写道:
> On Tue, 10 Apr 2018 15:09:37 +0800
> lijiang wrote:
>
>> 在 2018年04月09日 17:40, Petr Tesarik 写道:
>> [...]
>>> Last but not least, part of the issue was probably caused by the
>>> wrong assumption that integers < 1
在 2018年06月19日 22:46, lijiang 写道:
> 在 2018年06月19日 11:16, Dave Young 写道:
>> On 06/16/18 at 04:27pm, Lianbo Jiang wrote:
>>> In kdump mode, we need to dump the old memory into vmcore file,
>>> if SME is enabled in the first kernel, we must remap the old
>>> memor
在 2018年06月20日 15:17, Petr Tesarik 写道:
> Hi Lianbo,
>
> On Wed, 20 Jun 2018 11:07:46 +0800
> lijiang wrote:
>
>> 在 2018年04月10日 15:47, Petr Tesarik 写道:
>> [...]
>>> Yes, the current code will not produce sensible results if the system
>>> clock moves
在 2018年06月21日 09:21, Baoquan He 写道:
> On 06/16/18 at 04:27pm, Lianbo Jiang wrote:
>> It is convenient to remap the old memory encrypted to the second kernel by
>> calling ioremap_encrypted().
>>
>> When sme enabled on AMD server, we also need to support kdump. Because
>> the memory is encrypted in
在 2018年06月21日 09:53, Baoquan He 写道:
> On 06/16/18 at 04:27pm, Lianbo Jiang wrote:
>> When SME is enabled in the first kernel, we will allocate pages
>> for kdump without encryption in order to be able to boot the
>> second kernel in the same manner as kexec, which helps to keep
>> the same code sty
在 2018年06月21日 00:42, Tom Lendacky 写道:
> On 6/16/2018 3:27 AM, Lianbo Jiang wrote:
>> In kdump mode, it will copy the device table of IOMMU from the old
>> device table, which is encrypted when SME is enabled in the first
>> kernel. So we must remap it in encrypted manner in order to be
>> automatic
在 2018年06月21日 00:00, Tom Lendacky 写道:
> On 6/16/2018 3:27 AM, Lianbo Jiang wrote:
>> It is convenient to remap the old memory encrypted to the second
>> kernel by calling ioremap_encrypted().
>>
>> Signed-off-by: Lianbo Jiang
>> ---
>> Some changes:
>> 1. remove the sme_active() check in __ioremap
在 2018年06月21日 16:39, Baoquan He 写道:
> On 06/21/18 at 01:42pm, lijiang wrote:
>> 在 2018年06月21日 00:42, Tom Lendacky 写道:
>>> On 6/16/2018 3:27 AM, Lianbo Jiang wrote:
>>>> In kdump mode, it will copy the device table of IOMMU from the old
>>>> device table,
在 2018年06月21日 18:23, Baoquan He 写道:
> On 06/21/18 at 01:06pm, lijiang wrote:
>> 在 2018年06月21日 09:53, Baoquan He 写道:
>>> On 06/16/18 at 04:27pm, Lianbo Jiang wrote:
>>>> When SME is enabled in the first kernel, we will allocate pages
>>>> for kdump without
在 2018年06月20日 17:50, Petr Tesarik 写道:
> Execution time should be always measured by a monotonic clock,
> because the system clock may be affected by discontinuous jumps,
> e.g. when time is set manually by an admin.
>
> Signed-off-by: Petr Tesarik
> ---
That might be better if CC Masaki.
Thanks.
在 2018年07月02日 18:14, Borislav Petkov 写道:
> On Mon, Jul 02, 2018 at 03:26:35PM +0800, Lianbo Jiang wrote:
>> @@ -131,7 +132,8 @@ static void __ioremap_check_mem(resource_size_t addr,
>> unsigned long size,
>> * caller shouldn't need to know that small detail.
>> */
>> static void __iomem *__io
在 2018年07月03日 10:17, lijiang 写道:
> 在 2018年07月02日 18:14, Borislav Petkov 写道:
>> On Mon, Jul 02, 2018 at 03:26:35PM +0800, Lianbo Jiang wrote:
>>> @@ -131,7 +132,8 @@ static void __ioremap_check_mem(resource_size_t addr,
>>> unsigned long size,
>>> * call
在 2018年07月03日 17:39, Borislav Petkov 写道:
> On Tue, Jul 03, 2018 at 10:17:19AM +0800, lijiang wrote:
>> for example, the elfcorehdr. In fact, the elfcorehdr and notes
>
> You mean this?
>
> ssize_t __weak elfcorehdr_read_notes(char *buf, size_t count, u64 *ppos)
在 2018年07月03日 19:14, Borislav Petkov 写道:
> On Tue, Jul 03, 2018 at 06:58:14PM +0800, lijiang wrote:
>> For kdump, the elf header finally use the crash kernel reserved memory, it
>> is not an old memory.
>
> Lamme repeat my suggestion:
>
> So beef up the logic in __ior
在 2018年07月03日 19:44, lijiang 写道:
> 在 2018年07月03日 19:14, Borislav Petkov 写道:
>> On Tue, Jul 03, 2018 at 06:58:14PM +0800, lijiang wrote:
>>> For kdump, the elf header finally use the crash kernel reserved memory, it
>>> is not an old memory.
>>
>> Lamme rep
在 2018年07月09日 17:29, Borislav Petkov 写道:
> On Mon, Jul 09, 2018 at 02:28:11PM +0800, lijiang wrote:
>> Last week, I had tried many ways to do this work, but it looks
>> like that the ways of deducing address is not suitable to another
>> scenarios, such as mapping some devi
在 2018年07月14日 01:08, Borislav Petkov 写道:
> On Mon, Jul 09, 2018 at 09:55:35PM +0800, lijiang wrote:
>> About this issue, i want to use an example to describe it.
>> /* drivers/iommu/amd_iommu_init.c */
>> static u8 __iomem * __init iommu_map_mmio_space(u64 address, u64 end)
在 2018年07月20日 15:32, Borislav Petkov 写道:
> On Fri, Jul 20, 2018 at 01:23:04PM +0800, Dave Young wrote:
>>> Here, it doesn't need to dump MMIO space of the previous kernel, when the
>>> kdump kernel boot, the MMIO address will be remapped in decryption manners,
>>> but the MMIO address don't belong
在 2018年07月20日 18:08, Boris Petkov 写道:
> On July 20, 2018 12:55:04 PM GMT+03:00, lijiang wrote:>
>> Thanks for your advice, I will rewrite the log and send them again.
>
> Do not send them again - explain the problem properly first!
>
I have compared two solutions to handle
在 2018年09月03日 10:45, Dave Young 写道:
> On 08/31/18 at 04:19pm, Lianbo Jiang wrote:
>> For kdump kernel, when SME is enabled, the acpi table and dmi table will need
>> to be remapped without the memory encryption mask. So we have to strengthen
>> the logic in early_memremap_pgprot_adjust(), which mak
在 2018年09月04日 08:44, Dave Young 写道:
> On 09/03/18 at 10:06pm, lijiang wrote:
>> 在 2018年09月03日 10:45, Dave Young 写道:
>>> On 08/31/18 at 04:19pm, Lianbo Jiang wrote:
>>>> For kdump kernel, when SME is enabled, the acpi table and dmi table will
>>>> n
在 2018年09月04日 09:51, Dave Young 写道:
> On 09/04/18 at 09:29am, Dave Young wrote:
>> On 09/04/18 at 08:44am, Dave Young wrote:
>>> On 09/03/18 at 10:06pm, lijiang wrote:
>>>> 在 2018年09月03日 10:45, Dave Young 写道:
>>>>> On 08/31/18 at 04:19pm, Lianbo Jian
在 2018年09月05日 14:46, Dave Young 写道:
> [snip]
>>
>> As previously mentioned, there are also many differences between kexec and
>> kdump. In general,
>> kexec needs to look at all of available physical memory, but kdump doesn't
>> need.
>>
>> For kexec, kexec-tools will read /sys/firmware/memmap an
在 2018年09月06日 10:30, Dave Young 写道:
> Hi Lianbo,
>
> On 09/05/18 at 09:41pm, Lianbo Jiang wrote:
>> When kexec-tools load the kernel and initramfs for kdump, kexec-tools will
>> read /proc/iomem and recreate the e820 ranges for kdump kernel. But it fails
>> to parse the e820 reserved region, becau
在 2018年09月19日 21:29, Borislav Petkov 写道:
> On Wed, Sep 19, 2018 at 08:52:49PM +0800, Lianbo Jiang wrote:
>
> ...
>
>> In fact, we should get the resource A and B when we walk through the
>> whole tree, but it only gets the resource A, the resource B is missed.
>>
>> Signed-off-by: Dave Young
>>
在 2018年09月25日 01:52, Bjorn Helgaas 写道:
> On Fri, Sep 21, 2018 at 03:32:09PM +0800, Lianbo Jiang wrote:
>> When we walk through iomem resources by calling walk_iomem_res_desc(),
>> the values of the function parameter may be modified in the while loop
>> of __walk_iomem_res_desc(), which will cause
在 2018年09月26日 03:10, Lendacky, Thomas 写道:
> On 09/07/2018 03:18 AM, Lianbo Jiang wrote:
>> When SME is enabled on AMD machine, we also need to support kdump. Because
>> the memory is encrypted in the first kernel, we will remap the old memory
>> to the kdump kernel for dumping data, and SME is also
Also cc maintainer and other reviewer. Thanks.
在 2018年09月26日 13:52, lijiang 写道:
> 在 2018年09月26日 03:10, Lendacky, Thomas 写道:
>> On 09/07/2018 03:18 AM, Lianbo Jiang wrote:
>>> When SME is enabled on AMD machine, we also need to support kdump. Because
>>> the memory is en
在 2018年09月26日 10:21, Baoquan He 写道:
> Hi Lianbo,
>
> On 09/07/18 at 04:18pm, Lianbo Jiang wrote:
>> When SME is enabled on AMD machine, the memory is encrypted in the first
>> kernel. In this case, SME also needs to be enabled in kdump kernel, and
>> we have to remap the old memory with the memory
在 2018年09月25日 06:14, Bjorn Helgaas 写道:
> Hi Lianbo,
>
> These three patches are a possible replacement for your first patch
> ("[PATCH 1/3 v3] resource: fix an error which walks through iomem
> resources").
>
> I think the interface of find_next_iomem_res() can be improved to make
> the code ea
When SME is enabled on AMD machine, the memory is encrypted in the first
kernel. In this case, SME also needs to be enabled in kdump kernel, and
we have to remap the old memory with the memory encryption mask.
Here we only talk about the case that SME is active in the first kernel,
and only care i
在 2018年09月26日 17:22, lijiang 写道:
>
>
> 在 2018年09月25日 06:14, Bjorn Helgaas 写道:
>> Hi Lianbo,
>>
>> These three patches are a possible replacement for your first patch
>> ("[PATCH 1/3 v3] resource: fix an error which walks through iomem
>>
在 2018年09月25日 20:04, Joerg Roedel 写道:
> On Fri, Sep 07, 2018 at 04:18:04PM +0800, Lianbo Jiang wrote:
>> In kdump kernel, it will copy the device table of IOMMU from the old device
>> table, which is encrypted when SME is enabled in the first kernel. So we
>> have to remap the old device table with
在 2018年09月27日 10:06, Baoquan He 写道:
> Hi Lianbo,
>
> On 09/26/18 at 05:34pm, lijiang wrote:
>> When SME is enabled on AMD machine, the memory is encrypted in the first
>> kernel. In this case, SME also needs to be enabled in kdump kernel, and
>> we have to remap the
在 2018年09月25日 06:15, Bjorn Helgaas 写道:
> From: Bjorn Helgaas
>
> Previously find_next_iomem_res() used "*res" as both an input parameter for
> the range to search and the type of resource to search for, and an output
> parameter for the resource we found, which makes the interface confusing
> and
在 2018年09月27日 21:17, Borislav Petkov 写道:
> On Thu, Sep 27, 2018 at 03:19:51PM +0800, Lianbo Jiang wrote:
>> diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
>> index 6de64840dd22..f8795f9581c7 100644
>> --- a/arch/x86/include/asm/io.h
>> +++ b/arch/x86/include/asm/io.h
>> @@ -192,
在 2018年09月28日 00:10, Borislav Petkov 写道:
> On Thu, Sep 27, 2018 at 10:53:47PM +0800, lijiang wrote:
>> If no need to break this line, it will cause a warning of exceeding 80
>> characters per line.
>
> That's fine - we don't take the 80 cols rule blindly bu
在 2018年09月28日 00:53, Borislav Petkov 写道:
> On Thu, Sep 27, 2018 at 03:19:52PM +0800, Lianbo Jiang wrote:
>> When SME is enabled in the first kernel, we will allocate unencrypted pages
>> for kdump in order to be able to boot the kdump kernel like kexec.
>
> This is not what the commit does - it ma
在 2018年09月27日 22:03, Bjorn Helgaas 写道:
> On Thu, Sep 27, 2018 at 01:27:41PM +0800, lijiang wrote:
>> 在 2018年09月25日 06:15, Bjorn Helgaas 写道:
>>> From: Bjorn Helgaas
>>>
>>> Previously find_next_iomem_res() used "*res" as both an input paramet
在 2018年09月28日 15:57, Borislav Petkov 写道:
> On Fri, Sep 28, 2018 at 11:52:21AM +0800, lijiang wrote:
>> There are two functions that are usually called in pairs, they are:
>> arch_kexec_post_alloc_pages() and arch_kexec_pre_free_pages().
>>
>> One marks the pages as decry
在 2018年09月28日 16:38, Borislav Petkov 写道:
> On Thu, Sep 27, 2018 at 03:19:54PM +0800, Lianbo Jiang wrote:
>> In kdump kernel, we need to dump the old memory into vmcore file,if SME
>> is enabled in the first kernel, we have to remap the old memory with the
>> memory encryption mask, which will be au
在 2018年09月29日 16:30, Borislav Petkov 写道:
> On Sat, Sep 29, 2018 at 02:24:52PM +0800, lijiang wrote:
>> At first, i added an input parameter for read_from_oldmem() because of
>> encryption(SME). But
>> for avoiding to also add the same parameter for copy_oldmem_page(),
在 2018年09月30日 02:25, kbuild test robot 写道:
> Hi Lianbo,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on sof-driver-fuweitax/master]
> [also build test ERROR on v4.19-rc5 next-20180928]
> [if your patch is applied to the wrong git tree, please drop us a note to
In kdump kernel, the old memory needs to be dumped into vmcore file.
If SME is enabled in the first kernel, the old memory has to be
remapped with the memory encryption mask, which will be automatically
decrypted when read from DRAM.
For SME kdump, there are two cases that doesn't support:
-
在 2018年10月02日 19:40, Borislav Petkov 写道:
> On Sun, Sep 30, 2018 at 11:10:29AM +0800, Lianbo Jiang wrote:
>> When SME is enabled on AMD machine, it also needs to support kdump. Because
>
> Ok, I've cleaned them up heavily and pushed them here:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/bp
在 2018年10月03日 19:34, Borislav Petkov 写道:
> On Wed, Oct 03, 2018 at 11:57:59AM +0800, lijiang wrote:
>> I noticed that your test was based on [patch v8 RESEND 4/4],
>
> How did you notice that?
>
> Let's see, the patch in question is this one:
>
> https://git.ker
在 2018年10月05日 03:02, Borislav Petkov 写道:
> On Thu, Oct 04, 2018 at 05:33:14PM +0800, lijiang wrote:
>> I have tested the patch again based on upstream 4.19.0-rc6, it works very
>> well.
>
> How have you tested this?
>
> Please describe the steps in detail.
>
在 2018年10月06日 17:56, Borislav Petkov 写道:
> On Fri, Oct 05, 2018 at 01:52:26PM +0800, lijiang wrote:
>> b. add the parameter "mem_encrypt=on" for kernel command-line to
>> grub.cfg, if
>> this machine has SME feature. And also add crashke
在 2018年10月02日 20:02, Simon Horman 写道:
> On Fri, Sep 07, 2018 at 09:05:50AM +0800, Dave Young wrote:
>> On 09/06/18 at 01:56pm, Lianbo Jiang wrote:
>>> When kexec-tools load the kernel and initramfs for kdump, kexec-tools will
>>> read /proc/iomem and recreate the e820 ranges for kdump kernel. But i
在 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.
>>
>> Fu
在 2018年10月26日 17:43, Boris Petkov 写道:
> On October 26, 2018 10:36:30 AM GMT+01:00, Lianbo Jiang
> wrote:
>> For AMD machine with SME feature, makedumpfile tools need to know
>> whether the crash kernel was encrypted or not.
>
> Why?
>
If SME is enabled in the first kernel, the crash kernel's
在 2018年10月27日 00:35, Borislav Petkov 写道:
> On Fri, Oct 26, 2018 at 08:32:11PM +0800, lijiang wrote:
>> If SME is enabled in the first kernel, the crash kernel's page
>> table(pgd/pud/pmd/pte)
>> contains the memory encryption mask, so i have to remove the sme mask
在 2018年10月27日 06:25, Borislav Petkov 写道:
> On Fri, Oct 26, 2018 at 06:24:40PM +0200, Petr Tesarik wrote:
>> But we need the MSR value from the panic kernel environment, not while
>> the production kernel is still running, right?
>
> Actually, we need only the encryption bit number (and it should b
在 2018年10月27日 21:17, Boris Petkov 写道:
> On October 27, 2018 12:08:58 PM GMT+01:00, Baoquan He wrote:
>> OK, then it's fine to get the bit number, e.g calling
>> find_first_bit(sme_me_mask, BITS_PER_LONG), and export it to
>> vmcoreinfo. Thanks.
>
> You can simply assign sme_me_mask for now...
>
在 2018年10月27日 22:51, Borislav Petkov 写道:
> On Sat, Oct 27, 2018 at 10:41:56PM +0800, lijiang wrote:
>> Actually, the value of 'sme_me_mask' is 0x8000 when SME is
>> enabled, otherwise it is 0. That is to say, if the bit 47 is set, the
>> bit number is
在 2018年10月29日 16:31, Baoquan He 写道:
> On 10/29/18 at 03:59pm, lijiang wrote:
>> diff --git a/arch/x86/kernel/machine_kexec_64.c
>> b/arch/x86/kernel/machine_kexec_64.c
>> index 4c8acdfdc5a7..de363796ed20 100644
>> --- a/arch/x86/kernel/machine_kexec_64.c
>> +++ b
在 2018年10月29日 17:57, Borislav Petkov 写道:
> On Mon, Oct 29, 2018 at 05:29:16PM +0800, lijiang wrote:
>> Ok, i will change it to a local variable and export it.
>
> Why do you have to export it at all?!
>
I mean that i will write the value of local variable to the vmcoreinfo. F
在 2018年10月29日 19:44, Baoquan He 写道:
> On 10/29/18 at 06:12pm, lijiang wrote:
>> diff --git a/arch/x86/kernel/machine_kexec_64.c
>> b/arch/x86/kernel/machine_kexec_64.c
>> index 4c8acdfdc5a7..3cc975e7ff8f 100644
>> --- a/arch/x86/kernel/machine_kexec_64.c
>> +++ b
在 2018年10月29日 21:49, Borislav Petkov 写道:
> On Mon, Oct 29, 2018 at 09:41:26PM +0800, lijiang wrote:
>>> VMCOREINFO_NUMBER(phys_base);
>>> VMCOREINFO_SYMBOL(init_top_pgt);
>>> vmcoreinfo_append_str(&q
在 2018年10月30日 17:23, Baoquan He 写道:
>
> Hi Boris, DaveY and Lianbo,
>
> On 10/30/18 at 10:15am, Borislav Petkov wrote:
>> On Tue, Oct 30, 2018 at 01:09:00PM +0800, Dave Young wrote:
>>> It is not the content, I think it is a good catch from Boris, it would
>>> be good to document the exported thi
在 2018年10月31日 10:47, Dave Young 写道:
> Add Kazu, the makedumpfile maintainer in cc.
>
> On 10/31/18 at 10:26am, lijiang wrote:
>> 在 2018年10月30日 17:23, Baoquan He 写道:
>>>
>>> Hi Boris, DaveY and Lianbo,
>>>
>>> On 10/30/18 at 10:15am, Borislav Pe
在 2018年11月07日 13:23, Baoquan He 写道:
> On 11/07/18 at 01:00pm, Lianbo Jiang wrote:
>> E820 reserved ranges is useful in kdump kernel, it has been added in
>> kexec-tools code.
>>
>> One reason is PCI mmconf (extended mode) requires reserved region otherwise
>> it falls back to legacy mode, and also
在 2018年11月09日 14:51, Baoquan He 写道:
> On 11/07/18 at 05:10pm, lijiang wrote:
>> In fact, these patches are really simple. As the subject mentioned, this
>> patch
>> [PATCH 2/2] adds the reserved e820 ranges to kdump kernel e820 table, and the
>> first patch [PATCH 1/
在 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 i
在 2018年11月15日 13:58, Dave Young 写道:
> On 11/15/18 at 01:44pm, lijiang wrote:
>> 在 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,
在 2018年11月15日 18:39, Borislav Petkov 写道:
> + Bjorn.
>
> On Thu, Nov 15, 2018 at 01:44:07PM +0800, lijiang wrote:
>> At present, the upstream kernel does not pass the e820 reserved ranges to the
>> second kernel, which might cause two problems:
>>
>> The first o
在 2018年11月19日 18:28, Borislav Petkov 写道:
> On Mon, Nov 19, 2018 at 05:55:15PM +0800, Dave Young wrote:
>> Another thing is it is not worth to get the exact info, the 1st kernel
>> reserved part is just fine to be reserved as well in 2nd kernel, no
>> side effects. Actually there might be some obs
在 2018年11月18日 19:52, Borislav Petkov 写道:
> 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 0x7800-0x8fff] is only passed to the second
>
在 2018年11月18日 19:52, Borislav Petkov 写道:
> 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 0x7800-0x8fff] is only passed to the second
>
在 2018年11月22日 15:42, Dave Young 写道:
> On 11/15/18 at 05:55pm, Lianbo Jiang wrote:
>> The upstream kernel can not accurately add the e820 reserved type to
>> kdump krenel e820 table.
>>
>> Kdump uses walk_iomem_res_desc() to iterate io resources, then adds
>> the matched resource ranges to the e820
在 2018年11月27日 02:54, Dave Hansen 写道:
> On 11/23/18 9:12 PM, Lianbo Jiang wrote:
>> These patches add the new I/O resource descriptor 'IORES_DESC_RESERVED'
>> for the iomem resources search interfaces, and in order to make it still
>> work after the new descriptor is added, these codes originally re
在 2018年11月27日 04:52, Dave Hansen 写道:
> On 11/23/18 9:12 PM, Lianbo Jiang wrote:
>> The upstream kernel can not accurately add the e820 reserved type to> kdump
>> krenel e820 table.
>
> ^ kernel
>
>> Kdump uses walk_iomem_res_desc() to iterate io resources, then adds
>> the matched resource
在 2018年11月27日 23:34, Dave Hansen 写道:
> On 11/27/18 2:04 AM, lijiang wrote:
>> What happens if we don't modify this functions
>> __ioremap_check_desc_other()? -When SEV is active, it might map these
>> reserved regions with the encryption mask. That is incorrect.
&g
在 2018年11月29日 00:02, Dave Hansen 写道:
> On 11/27/18 7:51 PM, lijiang wrote:
>> But now, the 'E820_TYPE_RESERVED' type is converted to the descriptor
>> 'IORES_DESC_RESERVED'
>> instead of 'IORES_DESC_NONE', it has been changed and the value of
&g
在 2018年11月30日 11:41, Dave Young 写道:
> On 11/29/18 at 04:09pm, Lianbo Jiang wrote:
>> When doing kexec_file_load, the first kernel needs to pass the e820
>> reserved ranges to the second kernel. But kernel can not exactly
>> match the e820 reserved ranges when walking through the iomem resources
>>
在 2018年11月30日 11:37, Dave Young 写道:
> + more people
>
Thank you, Dave.
That would be fine to let more people review this patch.
> On 11/29/18 at 04:09pm, Lianbo Jiang wrote:
>> When doing kexec_file_load, the first kernel needs to pass the e820
>> reserved ranges to the second kernel. But kerne
在 2018年12月03日 23:08, Borislav Petkov 写道:
> Add some more Ccs.
>
Thanks a lot.
There are more people to review and improve this document together, that would
be fine.
> On Sun, Dec 02, 2018 at 11:08:38AM +0800, Lianbo Jiang wrote:
>> This document lists some variables that export to vmcoreinfo,
在 2018年12月05日 19:30, Borislav Petkov 写道:
> On Tue, Dec 04, 2018 at 05:35:09PM +0800, lijiang wrote:
>> There are more people to review and improve this document together, that
>> would
>> be fine.
>
> That's basically kernel development :)
>
>> Generati
在 2018年12月05日 18:16, Dave Young 写道:
+init_uts_ns
+===
+This is the UTS namespace, which is used to isolate two specific elements
+of the system that relate to the uname system call. The UTS namespace is
+named after the data structure used to store information retur
在 2018年12月05日 18:24, Dave Young 写道:
> On 12/02/18 at 11:08am, Lianbo Jiang wrote:
>> For AMD machine with SME feature, makedumpfile tools need to know
>> whether the crash kernel was encrypted or not. If SME is enabled
>> in the first kernel, the crash kernel's page table(pgd/pud/pmd/pte)
>> contai
在 2018年12月07日 04:11, Borislav Petkov 写道:
> On Fri, Nov 30, 2018 at 03:04:44PM +0800, lijiang wrote:
>> I have noticed the changes on x86, but for IA64, i'm not sure whether it
>> should do the same
>> thing, so keep it as before.
>>
>> If IA64 people would
在 2018年12月05日 05:33, Lendacky, Thomas 写道:
> On 11/29/2018 09:37 PM, Dave Young wrote:
>> + more people
>>
>> On 11/29/18 at 04:09pm, Lianbo Jiang wrote:
>>> When doing kexec_file_load, the first kernel needs to pass the e820
>>> reserved ranges to the second kernel. But kernel can not exactly
>>> m
在 2018年12月17日 21:00, Borislav Petkov 写道:
> On Sun, Dec 16, 2018 at 09:16:16PM +0800, Lianbo Jiang wrote:
>> +clear_idx
>> +=
>> +The index that the next printk record to read after the last 'clear'
>> +command. It indicates the first record after the last SYSLOG_ACTION
>> +_CLEAR, like issu
在 2018年12月17日 21:01, Borislav Petkov 写道:
> On Sun, Dec 16, 2018 at 09:16:17PM +0800, Lianbo Jiang wrote:
>> For AMD machine with SME feature, makedumpfile tools need to know
>> whether the crash kernel was encrypted or not. If SME is enabled
>> in the first kernel, the crash kernel's page table(pgd
在 2018年12月26日 11:36, Dave Young 写道:
> On 12/26/18 at 11:24am, Dave Young wrote:
> +
> +KERNEL_IMAGE_SIZE
> +=
> +The size of 'KERNEL_IMAGE_SIZE', currently unused.
So remove?
>>>
>>> I'm not sure whether it should be removed, so i keep it.
>>
>> Just r
在 2019年01月04日 03:28, Kazuhito Hagio 写道:
> Hi Lianbo,
>
> -Original Message-
>> +===
>> +What is the VMCOREINFO?
>> +===
>> +
>> +VMCOREINFO is a special ELF note section. It contains various
>> +information from the kernel like structure size, page s
在 2018年12月07日 04:11, Borislav Petkov 写道:
> On Fri, Nov 30, 2018 at 03:04:44PM +0800, lijiang wrote:
>> I have noticed the changes on x86, but for IA64, i'm not sure whether it
>> should do the same
>> thing, so keep it as before.
>>
>> If IA64 people would
在 2019年01月07日 15:55, Hatayama, Daisuke 写道:
> Hi,
>
>> -Original Message-
>> From: linux-kernel-ow...@vger.kernel.org
>> [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Lianbo Jiang
>> Sent: Monday, January 7, 2019 10:48 AM
>> To: linux-ker...@vger.kernel.org
>> Cc: kexec@lists.inf
在 2019年01月07日 10:29, Baoquan He 写道:
> On 01/07/19 at 09:47am, Lianbo Jiang wrote:
>> For AMD machine with SME feature, makedumpfile tools need to know
>> whether the crash kernel was encrypted or not. If SME is enabled
> ^ crashed
>> in the first kernel, the crash kernel's page table(
1 - 100 of 206 matches
Mail list logo
