o.h |5 +
> arch/x86/mm/ioremap.c | 179
> +
> include/linux/io.h|2 +
> kernel/memremap.c | 20 -
> mm/early_ioremap.c| 18 -
> 5 files changed, 217 insertions(+), 7 deletions(-)
Reviewed
> Signed-off-by: Tom Lendacky
> ---
> arch/x86/platform/efi/efi_64.c | 15 +++
> 1 file changed, 11 insertions(+), 4 deletions(-)
Reviewed-by: Matt Fleming
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to ma
ware/efi/efi.c | 33 +
> include/linux/efi.h|7 +++
> 2 files changed, 40 insertions(+)
Reviewed-by: Matt Fleming
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info
/efi/efi.c |6 +++---
> include/linux/efi.h |2 +-
> 3 files changed, 6 insertions(+), 6 deletions(-)
Reviewed-by: Matt Fleming
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 15 May, at 08:35:17PM, Borislav Petkov wrote:
> On Tue, Apr 18, 2017 at 04:19:21PM -0500, Tom Lendacky wrote:
>
> > + paddr = boot_params.efi_info.efi_memmap_hi;
> > + paddr <<= 32;
> > + paddr |= boot_params.efi_info.efi_memmap;
> > + if (phys_addr =
On Thu, 23 Feb, at 11:27:55AM, Tom Lendacky wrote:
>
> I can do that, I'll change the return type to an int. For the
> !efi_enabled I can return -ENOTSUPP and for when an entry isn't
> found I can return -EINVAL. Sound good?
Sounds good to me!
--
To unsubscribe from this list: send the line "un
On Thu, 16 Feb, at 09:44:57AM, Tom Lendacky wrote:
> Update the efi_mem_type() to return EFI_RESERVED_TYPE instead of a
> hardcoded 0.
>
> Signed-off-by: Tom Lendacky
> ---
> arch/x86/platform/efi/efi.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/pla
On Wed, 09 Nov, at 06:36:31PM, Tom Lendacky wrote:
> Boot data (such as EFI related data) is not encrypted when the system is
> booted and needs to be accessed unencrypted. Add support to apply the
> proper attributes to the EFI page tables and to the early_memremap and
> memremap APIs to identify
On Wed, 14 Sep, at 09:20:44AM, Tom Lendacky wrote:
> On 09/12/2016 11:55 AM, Andy Lutomirski wrote:
> > On Aug 22, 2016 6:53 PM, "Tom Lendacky" wrote:
> >>
> >> BOOT data (such as EFI related data) is not encyrpted when the system is
> >> booted and needs to be accessed as non-encrypted. Add supp
On Thu, 16 Jun, at 09:38:31AM, Tom Lendacky wrote:
>
> Ok, I think this was happening before the commit to build our own
> EFI page table structures:
>
> commit 67a9108ed ("x86/efi: Build our own page table structures")
>
> Before this commit the boot services ended up mapped into the kernel
> p
On Thu, 09 Jun, at 01:33:30PM, Tom Lendacky wrote:
>
> I was trying to play it safe here, but as you say, the firmware should
> be using our page tables so we can get rid of this call. The problem
> will actually be if we transition to a 32-bit efi. The encryption bit
> will be lost in cr3 and so
On Mon, 13 Jun, at 01:03:22PM, Matt Fleming wrote:
>
> Would we need a new function? Couldn't we just have a new
> FIXMAP_PAGE_* constant? e.g. would something like this work?
>
> ---
>
> enum memremap_owner {
> KERNEL_DATA = 0,
> BOOT_DATA,
> };
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
applica
On Tue, 26 Apr, at 05:57:40PM, Tom Lendacky wrote:
> The EFI tables are not encrypted and need to be accessed as such. Be sure
> to memmap them without the encryption attribute set. For EFI support that
> lives outside of the arch/x86 tree, create a routine that uses the __weak
> attribute so that
(Sorry for the delay)
On Thu, 26 May, at 08:45:58AM, Tom Lendacky wrote:
>
> The patch in question is patch 6/18 where PAGE_KERNEL is changed to
> include the _PAGE_ENC attribute (the encryption mask). This now
> makes FIXMAP_PAGE_NORMAL contain the encryption mask while
> FIXMAP_PAGE_IO does not
On Tue, 24 May, at 09:54:31AM, Tom Lendacky wrote:
>
> I looked into this and this would be a large change also to parse tables
> and build lists. It occurred to me that this could all be taken care of
> if the early_memremap calls were changed to early_ioremap calls. Looking
> in the git log I s
On Tue, 26 Apr, at 05:57:40PM, Tom Lendacky wrote:
> The EFI tables are not encrypted and need to be accessed as such. Be sure
> to memmap them without the encryption attribute set. For EFI support that
> lives outside of the arch/x86 tree, create a routine that uses the __weak
> attribute so that
17 matches
Mail list logo
