Re: [PATCH] pstore: return error code (if any) from efi_pstore_write

On 14 March 2017 at 09:59, Kalugin, Evgeny wrote: > On Tue, 2017-03-14 at 08:24 +, Ard Biesheuvel wrote: >> On 13 March 2017 at 12:46, Kalugin, Evgeny wrote: >> > From 655a261d71af9de62e0e23ae0eb6f75037ae5e3e Mon Sep 17 00:00:00 2001 >> >

Re: [RFC PATCH v4 25/28] x86: Access the setup data through sysfs decrypted

On 3/8/2017 1:09 AM, Dave Young wrote: On 02/16/17 at 09:47am, Tom Lendacky wrote: Use memremap() to map the setup data. This will make the appropriate decision as to whether a RAM remapping can be done or if a fallback to ioremap_cache() is needed (similar to the setup data debugfs support).

Re: [RFC PATCH v4 14/28] Add support to access boot related data in the clear

On 3/8/2017 12:55 AM, Dave Young wrote: On 02/16/17 at 09:45am, Tom Lendacky wrote: [snip] + * This function determines if an address should be mapped encrypted. + * Boot setup data, EFI data and E820 areas are checked in making this + * determination. + */ +static bool

Re: [RFC PATCH v4 24/28] x86: Access the setup data through debugfs decrypted

On 3/8/2017 1:04 AM, Dave Young wrote: On 02/16/17 at 09:47am, Tom Lendacky wrote: Use memremap() to map the setup data. This simplifies the code and will make the appropriate decision as to whether a RAM remapping can be done or if a fallback to ioremap_cache() is needed (which includes

[GIT PULL] UEFI fix for v4.11-rc

Hi all, At Matt's request, we are proposing this single patch as a bugfix for v4.11. Please pull. The following changes since commit 4495c08e84729385774601b5146d51d9e5849f81: Linux 4.11-rc2 (2017-03-12 14:47:08 -0700) are available in the git repository at:

[PATCH] efi/esrt: Cleanup bad memory map log messages

From: Daniel Drake The Intel Compute Stick STCK1A8LFC and Weibu F3C platforms both log 2 error messages during boot: efi: requested map not found. esrt: ESRT header is not in the memory map. Searching the web, this seems to affect many other platforms too. Since these

Re: [PATCH V12 05/10] acpi: apei: handle SEA notification type for ARMv8

Hi Tyler, On 06/03/17 20:44, Tyler Baicar wrote: > ARM APEI extension proposal added SEA (Synchronous External Abort) > notification type for ARMv8. > Add a new GHES error source handling function for SEA. If an error > source's notification type is SEA, then this function can be registered >

Re: [RFC PATCH v2 08/32] x86: Use PAGE_KERNEL protection for ioremap of memory page

On 3/16/2017 3:04 PM, Tom Lendacky wrote: On 3/7/2017 8:59 AM, Borislav Petkov wrote: On Thu, Mar 02, 2017 at 10:13:32AM -0500, Brijesh Singh wrote: From: Tom Lendacky In order for memory pages to be properly mapped when SEV is active, we need to use the PAGE_KERNEL

Re: [RFC PATCH v2 08/32] x86: Use PAGE_KERNEL protection for ioremap of memory page

On 3/17/2017 9:32 AM, Tom Lendacky wrote: On 3/16/2017 3:04 PM, Tom Lendacky wrote: On 3/7/2017 8:59 AM, Borislav Petkov wrote: On Thu, Mar 02, 2017 at 10:13:32AM -0500, Brijesh Singh wrote: From: Tom Lendacky In order for memory pages to be properly mapped when SEV

Re: [RFC PATCH v2 14/32] x86: mm: Provide support to use memblock when spliting large pages

On 17/03/2017 12:33, Borislav Petkov wrote: > On Fri, Mar 17, 2017 at 12:03:31PM +0100, Paolo Bonzini wrote: > >> If it is possible to do it in a fairly hypervisor-independent manner, >> I'm all for it. That is, only by looking at AMD-specified CPUID leaves >> and at kernel ELF sections. > >

Re: kexec regression since 4.9 caused by efi

On Fri, 17 Mar, at 10:09:51AM, Dave Young wrote: > > Matt, I think it should be fine although I think the md type checking in > efi_mem_desc_lookup() is causing confusion and not easy to understand.. Could you make that a separate patch if you think of improvements there? > How about move the

Re: kexec regression since 4.9 caused by efi

On 17 March 2017 at 02:09, Dave Young wrote: > On 03/16/17 at 12:41pm, Matt Fleming wrote: >> On Mon, 13 Mar, at 03:37:48PM, Dave Young wrote: >> > >> > Omar, could you try below patch? Looking at the efi_mem_desc_lookup, it is >> > not >> > correct to be used in

Re: [RFC PATCH v2 14/32] x86: mm: Provide support to use memblock when spliting large pages

On Fri, Mar 17, 2017 at 12:03:31PM +0100, Paolo Bonzini wrote: > If it is possible to do it in a fairly hypervisor-independent manner, > I'm all for it. That is, only by looking at AMD-specified CPUID leaves > and at kernel ELF sections. Not even that. What that needs to be able to do is:

Re: [RFC PATCH v2 29/32] kvm: svm: Add support for SEV DEBUG_DECRYPT command

On 16/03/2017 19:41, Brijesh Singh wrote: >> >> Please do add it, it doesn't seem very different from what you're doing >> in LAUNCH_UPDATE_DATA. There's no need for a separate >> __sev_dbg_decrypt_page function, you can just pin/unpin here and do a >> per-page loop as in LAUNCH_UPDATE_DATA. >

Re: [RFC PATCH v2 14/32] x86: mm: Provide support to use memblock when spliting large pages

On 17/03/2017 11:56, Borislav Petkov wrote: >> Theoretically or practically? > In the sense, it needs to be tried first to see how ugly it can get. > >> It only looks at the E820 map, doesn't it? Why does it have to do >> anything with percpu memory areas? > That's irrelevant. What we want to

Re: [RFC PATCH v2 14/32] x86: mm: Provide support to use memblock when spliting large pages

On Thu, Mar 16, 2017 at 11:25:36PM +0100, Paolo Bonzini wrote: > The kvmclock memory is initially zero so there is no need for the > hypervisor to allocate anything; the point of these patches is just to > access the data in a natural way from Linux source code. I realize that. > I also don't