lkml.org 
[lkml]   [2016]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH v1 10/18] x86/efi: Access EFI related tables in the clear
    On Tue, May 24, 2016 at 09:54:31AM -0500, Tom Lendacky wrote:
    > On 05/12/2016 01:20 PM, Tom Lendacky wrote:
    > > On 05/10/2016 08:57 AM, Borislav Petkov wrote:
    > >> On Tue, May 10, 2016 at 02:43:58PM +0100, Matt Fleming wrote:
    > >>> Is it not possible to maintain some kind of kernel virtual address
    > >>> mapping so memremap*() and friends can figure out when to twiddle the
    > >>> mapping attributes and map with/without encryption?
    > >>
    > >> I guess we can move the sme_* specific stuff one indirection layer
    > >> below, i.e., in the *memremap() routines so that callers don't have to
    > >> care... That should keep the churn down...
    > >>
    > >
    > > We could do that, but we'll have to generate that list of addresses so
    > > that it can be checked against the range being mapped. Since this is
    > > part of early memmap support searching that list every time might not be
    > > too bad. I'll have to look into that and see what that looks like.
    >
    > 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 see that they were originally early_ioremap calls but
    > were changed to early_memremap calls with this commit:
    >
    > commit abc93f8eb6e4 ("efi: Use early_mem*() instead of early_io*()")
    >
    > Looking at the early_memremap code and the early_ioremap code they both
    > call __early_ioremap so I don't see how this change makes any
    > difference (especially since FIXMAP_PAGE_NORMAL and FIXMAP_PAGE_IO are
    > identical in this case).
    >
    > Is it safe to change these back to early_ioremap calls (at least on
    > x86)?

    Commit f955371ca9d3986bca100666041fcfa9b6d21962 (x86: remove the Xen-specific
    _PAGE_IOMAP PTE flag) made commit abc93f8eb6e4 unnecessary. Though, IMO, it
    is still valid code cleanup. So, if it is not very strongly needed I would
    not revert this change.

    Daniel

    \
     
     \ /
      Last update: 2016-05-25 18:41    [W:4.251 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site