lkml.org 
[lkml]   [2018]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 1/5 V5] Add a function(ioremap_encrypted) for kdump when AMD sme enabled
    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)

    Those addresses come from the IVHD header which is an ACPI table. So the
    dump kernel can find that out too.

    > Obviously, the iommu mmio space is not encrypted, and the device
    > mmio space is outside kdump kernel. We know that the old memory is
    > encrypted, and the old memory is also outside kdump kernel. For the
    > current case, e820__get_entry_type() and walk_iomem_res_desc() can't
    > get the desired result, so we can't also decide whether encryption
    > or not according to this result(rules). If we want to know whether
    > encryption or not by deducing the address, we will need to read the
    > content of memory and have a reference value for comparison, then
    > what's a reference value? Sometimes we don't know that.

    Again, if we don't know that how is the *caller* supposed to know
    whether the memory is encrypted or not? Because

    "we" == "caller"

    in the kdump kernel.

    And the more important question is, why are we dumping MMIO space of the
    previous kernel *at* *all*? That doesn't make any sense to me.

    --
    Regards/Gruss,
    Boris.

    ECO tip #101: Trim your mails when you reply.
    --
    \
     
     \ /
      Last update: 2018-07-15 22:07    [W:6.784 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site