On 06/13/2016 07:03 AM, Matt Fleming wrote: > On Thu, 09 Jun, at 11:16:40AM, Tom Lendacky wrote: >> >> So maybe something along the lines of an enum that would have entries >> (initially) like KERNEL_DATA (equal to zero) and EFI_DATA. Others could >> be added later as needed. > > Sure, that works for me, though maybe BOOT_DATA would be more > applicable considering the devicetree case too. > >> Would you then want to allow the protection attributes to be updated >> by architecture specific code through something like a __weak function? >> In the x86 case I can add this function as a non-SME specific function >> that would initially just have the SME-related mask modification in it. > > Would we need a new function? Couldn't we just have a new > FIXMAP_PAGE_* constant? e.g. would something like this work? Looking forward to the virtualization support (SEV), the VM will be completely encrypted from the time it is started. In this case all of the UEFI data will be encrypted and I would need to insure that the mapping reflects that. When I do the SEV patches, I can change the FIXMAP #define to add some logic to return a value, so I think the FIXMAP_PAGE_ idea can work. Thanks, Tom > > --- > > enum memremap_owner { > KERNEL_DATA = 0, > BOOT_DATA, > }; > > void __init * > early_memremap(resource_size_t phys_addr, unsigned long size, > enum memremap_owner owner) > { > pgprot_t prot; > > switch (owner) { > case BOOT_DATA: > prot = FIXMAP_PAGE_BOOT; > break; > case KERNEL_DATA: /* FALLTHROUGH */ > default: > prot = FIXMAP_PAGE_NORMAL; > > } > > return (__force void *)__early_ioremap(phys_addr, size, prot); > } > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html