Messages in this thread | | | Date | Mon, 15 Apr 2019 17:41:55 +0200 | From | Borislav Petkov <> | Subject | Re: [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.
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.
| |