On Mon, Apr 15, 2019 at 08:22:22PM +0800, lijiang wrote:
> They are different problems.
Aha, so we're getting closer. You should've lead with that!
> The first problem is that passes the e820 reserved ranges to the second kernel,
Passes or *doesn't* pass?
Because from all the staring, it wants to pass the reserved ranges.
> for this case, it is good enough to use the IORES_DESC_RESERVED, which
> can ensure that exactly matches the reserved resource ranges when
> walking through iomem resources.
Ok.
> The second problem is about the SEV case. Now, the IORES_DESC_RESERVED has been
> created for the reserved areas, therefore 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)
That name is crap. If you need to add another desc type, it becomes
wrong again. And that whole code around flags->desc_other is just silly:
Make that machinery around it something like this:
struct ioremap_desc {
u64 flags;
};
instead of "struct ioremap_mem_flags" and that struct ioremap_desc is an
ioremap descriptor which will carry all kinds of settings. system_ram
can then be a simple flag too.
__ioremap_caller() will hand it down to __ioremap_check_mem() etc
and there it will set flags like IOREMAP_DESC_MAP_ENCRYPTED or
IOREMAP_DESC_MAP_DECRYPTED and this way you'll have it explicit and
clear in __ioremap_caller():
if ((sev_active() &&
(io_desc.flags & IOREMAP_DESC_MAP_ENCRYPTED)) ||
encrypted)
prot = pgprot_encrypted(prot);
But that would need a pre-patch which does that conversion.
> Maybe i should split it into two patches. The change of
> __ioremap_check_desc_none_and_reserved() should be a separate patch.
> Any idea?
See above and yes, definitely separate patches.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec
