Re: [PATCH 01/13] x86/efi: Clean up efi CR3 save/restore

[Andy Lutomirski]

On Mon, Jun 5, 2017 at 9:03 AM, Ard Biesheuvel
<ard.biesheuvel@xxxxxxxxxx> wrote:
> On 5 June 2017 at 15:40, Ingo Molnar <mingo@xxxxxxxxxx> wrote:
>>
>> * Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote:
>>
>>> From: Andy Lutomirski <luto@xxxxxxxxxx>
>>>
>>> efi_call_phys_prolog() used to return a "pgd_t *" that meant one of
>>> three different things depending on kernel and system configuration.
>>> Clean it up so it uses a union and is more explicit about what's
>>> going on.
>>>
>>> Signed-off-by: Andy Lutomirski <luto@xxxxxxxxxx>
>>> Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
>>> Cc: Borislav Petkov <bp@xxxxxxxxx>
>>> Cc: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
>>> Cc: Ingo Molnar <mingo@xxxxxxxxxx>
>>> Signed-off-by: Matt Fleming <matt@xxxxxxxxxxxxxxxxxxx>
>>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
>>> ---
>>>  arch/x86/include/asm/efi.h     | 17 +++++++++++++++--
>>>  arch/x86/platform/efi/efi.c    |  6 +++---
>>>  arch/x86/platform/efi/efi_32.c | 12 ++++++------
>>>  arch/x86/platform/efi/efi_64.c | 22 ++++++++++++----------
>>>  4 files changed, 36 insertions(+), 21 deletions(-)
>>
>> Hm, this patch does not apply cleanly to v4.12-rc4:
>>
>>  Applying patch patches/x86efi_Clean_up_efi_CR3_saverestore-1.patch
>>  patching file arch/x86/include/asm/efi.h
>>  patching file arch/x86/platform/efi/efi.c
>>  patching file arch/x86/platform/efi/efi_32.c
>>  patching file arch/x86/platform/efi/efi_64.c
>>  Hunk #1 FAILED at 69.
>>  Hunk #2 FAILED at 86.
>>  Hunk #3 succeeded at 152 with fuzz 1 (offset 44 lines).
>>  Hunk #4 FAILED at 116.
>>  3 out of 4 hunks FAILED -- rejects in file arch/x86/platform/efi/efi_64.c
>>
>> what tree is this against?
>>
>
> This is against v4.12-rc3, which lacked the EFI fix Matt sent out in
> the mean time.
>
> Feel free to drop it for now, and we can requeue it later if Andy is
> willing to rebase it.

I had hoped this would make it into 4.12-rc1 so I could base PCID on
top of it.  I'll probably resend it once PCID lands and base it on
PCID instead.  (It's a trivial one-line conflict, but still...)

--Andy