在 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 example, E820_TYPE_{RESERVED, >> + * RESERVED_KERN,RAM,UNUSABLE}, etc. It checks for a resource that is >> + * not described as IORES_DESC_NONE, which can make sure the reserved >> + * areas are not mapped as encrypted when using ioremap(). >> + * >> + * Now IORES_DESC_RESERVED has been created for the reserved areas so >> + * the check needs to be expanded so that these areas are not mapped >> + * encrypted when using ioremap(). >> + */ >> +static int __ioremap_check_desc_none_and_reserved(struct resource *res) >> { >> - return (res->desc != IORES_DESC_NONE); >> + return ((res->desc != IORES_DESC_NONE) && > > Why is this still checking IORES_DESC_NONE when the idea is to have this > specific IORES_DESC_RESERVED for all marked as *reserved* regions in > e820 which should not be mapped encrypted? > > IOW, which regions are still marked as IORES_DESC_NONE and should not be > mapped encrypted? > Thanks for your comment. These regions(E820_TYPE_{RESERVED_KERN,RAM,UNUSABLE}) are still marked as IORES_DESC_NONE and should not be mapped encrypted when using ioremap(). Please refer to the following function. static unsigned long __init e820_type_to_iores_desc(struct e820_entry *entry) { switch (entry->type) { case E820_TYPE_ACPI: return IORES_DESC_ACPI_TABLES; case E820_TYPE_NVS: return IORES_DESC_ACPI_NV_STORAGE; case E820_TYPE_PMEM: return IORES_DESC_PERSISTENT_MEMORY; case E820_TYPE_PRAM: return IORES_DESC_PERSISTENT_MEMORY_LEGACY; case E820_TYPE_RESERVED: return IORES_DESC_RESERVED; case E820_TYPE_RESERVED_KERN: /* Fall-through: */ case E820_TYPE_RAM: /* Fall-through: */ case E820_TYPE_UNUSABLE: /* Fall-through: */ default: return IORES_DESC_NONE; } } Thanks. Lianbo _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec