[lkml]   [2019]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 1/2 RESEND v10] x86/mm, resource: add a new I/O resource descriptor 'IORES_DESC_RESERVED'
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.


> 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)) ||
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.


Good mailing practices for 400: avoid top-posting and trim the reply.

 \ /
  Last update: 2019-04-15 17:45    [W:0.080 / U:0.116 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site