Re: [RFC PATCH v1 10/18] x86/efi: Access EFI related tables in the clear
From: Tom Lendacky <thomas.lendacky@amd.com>
Date: 2016-06-13 15:16:34
Also in:
kvm, linux-arch, linux-efi, linux-iommu, lkml
On 06/13/2016 07:03 AM, Matt Fleming wrote:
On Thu, 09 Jun, at 11:16:40AM, Tom Lendacky wrote:quoted
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.quoted
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, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>