[PATCH 1/2 RESEND v10] x86/mm, resource: add a new I/O resource descriptor 'IORES_DESC_RESERVED'

Borislav Petkov bp at alien8.de
Mon Apr 15 08:41:55 PDT 2019


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.



More information about the kexec mailing list