Re: [PATCH v7 27/36] iommu/amd: Allow the AMD IOMMU to work with memory encryption

2017-06-22 Thread Tom Lendacky
On 6/22/2017 5:56 AM, Borislav Petkov wrote: On Fri, Jun 16, 2017 at 01:54:59PM -0500, Tom Lendacky wrote: The IOMMU is programmed with physical addresses for the various tables and buffers that are used to communicate between the device and the driver. When the driver allocates this memory it

Re: [PATCH v7 19/36] x86/mm: Add support to access boot related data in the clear

2017-06-22 Thread Matt Fleming
On Fri, 16 Jun, at 01:53:26PM, Tom Lendacky wrote: > Boot data (such as EFI related data) is not encrypted when the system is > booted because UEFI/BIOS does not run with SME active. In order to access > this data properly it needs to be mapped decrypted. > > Update early_memremap() to provide an

Re: [PATCH v7 18/36] x86/efi: Update EFI pagetable creation to work with SME

2017-06-22 Thread Matt Fleming
On Fri, 16 Jun, at 01:53:17PM, Tom Lendacky wrote: > When SME is active, pagetable entries created for EFI need to have the > encryption mask set as necessary. > > When the new pagetable pages are allocated they are mapped encrypted. So, > update the efi_pgt value that will be used in cr3 to

Re: [PATCH v7 16/36] efi: Add an EFI table address match function

2017-06-22 Thread Matt Fleming
On Fri, 16 Jun, at 01:52:53PM, Tom Lendacky wrote: > Add a function that will determine if a supplied physical address matches > the address of an EFI table. > > Reviewed-by: Borislav Petkov > Signed-off-by: Tom Lendacky > --- > drivers/firmware/efi/efi.c

Re: [PATCH v7 27/36] iommu/amd: Allow the AMD IOMMU to work with memory encryption

2017-06-22 Thread Borislav Petkov
On Fri, Jun 16, 2017 at 01:54:59PM -0500, Tom Lendacky wrote: > The IOMMU is programmed with physical addresses for the various tables > and buffers that are used to communicate between the device and the > driver. When the driver allocates this memory it is encrypted. In order > for the IOMMU to

Re: [PATCH v7 17/36] efi: Update efi_mem_type() to return an error rather than 0

2017-06-22 Thread Matt Fleming
On Fri, 16 Jun, at 01:53:06PM, Tom Lendacky wrote: > The efi_mem_type() function currently returns a 0, which maps to > EFI_RESERVED_TYPE, if the function is unable to find a memmap entry for > the supplied physical address. Returning EFI_RESERVED_TYPE implies that > a memmap entry exists, when it

Re: [PATCH v7 26/36] x86/CPU/AMD: Make the microcode level available earlier in the boot

2017-06-22 Thread Borislav Petkov
On Fri, Jun 16, 2017 at 01:54:47PM -0500, Tom Lendacky wrote: > Move the setting of the cpuinfo_x86.microcode field from amd_init() to > early_amd_init() so that it is available earlier in the boot process. This > avoids having to read MSR_AMD64_PATCH_LEVEL directly during early boot. > >

Re: [PATCH] s390/crash: Fix KEXEC_NOTE_BYTES definition

2017-06-22 Thread Xunlei Pang
On 06/22/2017 at 01:44 AM, Michael Holzheu wrote: > Am Fri, 9 Jun 2017 10:17:05 +0800 > schrieb Xunlei Pang : > >> S390 KEXEC_NOTE_BYTES is not used by note_buf_t as before, which >> is now defined as follows: >> typedef u32 note_buf_t[CRASH_CORE_NOTE_BYTES/4]; >> It was