Re: [PATCH v6 25/34] swiotlb: Add warnings for use of bounce buffers with SME

Hi Tom, [auto build test ERROR on linus/master] [also build test ERROR on v4.12-rc4 next-20170607] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Tom-Lendacky/x86

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

Hi Tom, [auto build test ERROR on linus/master] [also build test ERROR on v4.12-rc4 next-20170607] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Tom-Lendacky/x86

Re: [PATCH v6 26/34] iommu/amd: Allow the AMD IOMMU to work with memory encryption

On Wed, Jun 7, 2017 at 3:17 PM, 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 >

Re: [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against just the physical address in cr3

On 06/07/2017 03:14 PM, Tom Lendacky wrote: > The cr3 register entry can contain the SME encryption bit that indicates > the PGD is encrypted. The encryption bit should not be used when creating > a virtual address for the PGD table. > > Create a new function, read_cr3_pa(), that will extract the

[PATCH 3/3] dax: use common 4k zero page for dax mmap reads

When servicing mmap() reads from file holes the current DAX code allocates a page cache page of all zeroes and places the struct page pointer in the mapping->page_tree radix tree. This has two major drawbacks: 1) It consumes memory unnecessarily. For every 4k page that is read via a DAX mmap()

[PATCH 1/3] mm: add vm_insert_mixed_mkwrite()

To be able to use the common 4k zero page in DAX we need to have our PTE fault path look more like our PMD fault path where a PTE entry can be marked as dirty and writeable as it is first inserted, rather than waiting for a follow-up dax_pfn_mkwrite() => finish_mkwrite_fault() call. Right now we

[PATCH 2/3] dax: relocate dax_load_hole()

dax_load_hole() will soon need to call dax_insert_mapping_entry(), so it needs to be moved lower in dax.c so the definition exists. Signed-off-by: Ross Zwisler --- fs/dax.c | 88 1 file changed, 44

[PATCH v6 20/34] x86, mpparse: Use memremap to map the mpf and mpc data

The SMP MP-table is built by UEFI and placed in memory in a decrypted state. These tables are accessed using a mix of early_memremap(), early_memunmap(), phys_to_virt() and virt_to_phys(). Change all accesses to use early_memremap()/early_memunmap(). This allows for proper setting of the

[PATCH v6 06/34] x86/mm: Add Secure Memory Encryption (SME) support

Add support for Secure Memory Encryption (SME). This initial support provides a Kconfig entry to build the SME support into the kernel and defines the memory encryption mask that will be used in subsequent patches to mark pages as encrypted. Signed-off-by: Tom Lendacky

[PATCH v6 07/34] x86/mm: Don't use phys_to_virt in ioremap() if SME is active

Currently there is a check if the address being mapped is in the ISA range (is_ISA_range()), and if it is then phys_to_virt() is used to perform the mapping. When SME is active, however, this will result in the mapping having the encryption bit set when it is expected that an ioremap() should not

[PATCH v6 27/34] x86, realmode: Check for memory encryption on the APs

Add support to check if memory encryption is active in the kernel and that it has been enabled on the AP. If memory encryption is active in the kernel but has not been enabled on the AP, then set the memory encryption bit (bit 23) of MSR_K8_SYSCFG to enable memory encryption on that AP and allow

[PATCH v6 28/34] x86, drm, fbdev: Do not specify encrypted memory for video mappings

Since video memory needs to be accessed decrypted, be sure that the memory encryption mask is not set for the video ranges. Signed-off-by: Tom Lendacky --- arch/x86/include/asm/vga.h | 14 +- arch/x86/mm/pageattr.c |2 ++

[PATCH v6 26/34] iommu/amd: Allow the AMD IOMMU to work with memory encryption

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 access the memory as encrypted the encryption mask needs to be

[PATCH v6 30/34] x86/mm, kexec: Allow kexec to be used with SME

Provide support so that kexec can be used to boot a kernel when SME is enabled. Support is needed to allocate pages for kexec without encryption. This is needed in order to be able to reboot in the kernel in the same manner as originally booted. Additionally, when shutting down all of the CPUs

[PATCH v6 32/34] x86/mm: Add support to encrypt the kernel in-place

Add the support to encrypt the kernel in-place. This is done by creating new page mappings for the kernel - a decrypted write-protected mapping and an encrypted mapping. The kernel is encrypted by copying it through a temporary buffer. Signed-off-by: Tom Lendacky ---

[PATCH v6 31/34] x86/mm: Use proper encryption attributes with /dev/mem

When accessing memory using /dev/mem (or /dev/kmem) use the proper encryption attributes when mapping the memory. To insure the proper attributes are applied when reading or writing /dev/mem, update the xlate_dev_mem_ptr() function to use memremap() which will essentially perform the same steps

[PATCH v6 33/34] x86/boot: Add early cmdline parsing for options with arguments

Add a cmdline_find_option() function to look for cmdline options that take arguments. The argument is returned in a supplied buffer and the argument length (regardless of whether it fits in the supplied buffer) is returned, with -1 indicating not found. Signed-off-by: Tom Lendacky

[PATCH v6 24/34] x86, swiotlb: Add memory encryption support

Since DMA addresses will effectively look like 48-bit addresses when the memory encryption mask is set, SWIOTLB is needed if the DMA mask of the device performing the DMA does not support 48-bits. SWIOTLB will be initialized to create decrypted bounce buffers for use by these devices.

[PATCH v6 22/34] x86/mm: Add support for changing the memory encryption attribute

Add support for changing the memory encryption attribute for one or more memory pages. This will be useful when we have to change the AP trampoline area to not be encrypted. Or when we need to change the SWIOTLB area to not be encrypted in support of devices that can't support the encryption mask

[PATCH v6 11/34] x86/mm: Provide general kernel support for memory encryption

Changes to the existing page table macros will allow the SME support to be enabled in a simple fashion with minimal changes to files that use these macros. Since the memory encryption mask will now be part of the regular pagetable macros, we introduce two new macros (_PAGE_TABLE_NOENC and

[PATCH v6 03/34] x86, mpparse, x86/acpi, x86/PCI, x86/dmi, SFI: Use memremap for RAM mappings

The ioremap() function is intended for mapping MMIO. For RAM, the memremap() function should be used. Convert calls from ioremap() to memremap() when re-mapping RAM. This will be used later by SME to control how the encryption mask is applied to memory mappings, with certain memory locations

[PATCH v6 01/34] x86: Document AMD Secure Memory Encryption (SME)

Create a Documentation entry to describe the AMD Secure Memory Encryption (SME) feature and add documentation for the mem_encrypt= kernel parameter. Reviewed-by: Borislav Petkov Signed-off-by: Tom Lendacky ---

Re: [PATCH 03/20] asm-generic: Drop getrlimit and setrlimit syscalls from default list

On Mon, Jun 05, 2017 at 03:44:06PM +0100, James Hogan wrote: > Hi Yury, > > On Sun, Jun 04, 2017 at 02:59:52PM +0300, Yury Norov wrote: > > The newer prlimit64 syscall provides all the functionality provided by > > the getrlimit and setrlimit syscalls and adds the pid of target process, > > so

Re: [PATCH v3] hwmon: Add support for MAX31785 intelligent fan controller

On Wed, Jun 07, 2017 at 04:15:06PM +0930, Andrew Jeffery wrote: > On Wed, 2017-06-07 at 12:18 +0930, Joel Stanley wrote: > > On Wed, Jun 7, 2017 at 1:50 AM, Matthew Barth > > > wrote: > > > > > > On 06/06/17 8:33 AM, Guenter Roeck wrote: > > > > > > > > On 06/06/2017

Re: [PATCH v3] hwmon: Add support for MAX31785 intelligent fan controller

On Tue, Jun 06, 2017 at 04:32:30PM +0930, Andrew Jeffery wrote: > Add a basic driver for the MAX31785, focusing on the fan control > features but ignoring the temperature and voltage monitoring > features of the device. > > This driver supports all fan control modes and tachometer / PWM >

Re: [PATCH 1/3] include: linux: visorbus: Add visorbus to include/linux directory

Please don't send any move patches but the actual code added to the kernel proper. And based on what's in linux-next I don't think this giant pile of junk is anywhere near mergeable. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to

Re: [PATCH 04/17] Documentation: atomic_ops.txt is core-api/atomic_ops.rst

CC doc folks On Wed, Jun 7, 2017 at 12:59 AM, Palmer Dabbelt wrote: > I was reading the memory barries documentation in order to make sure the > RISC-V barries were correct, and I found a broken link to the atomic > operations documentation. > > Signed-off-by: Palmer Dabbelt

Re: [PATCH v3] hwmon: Add support for MAX31785 intelligent fan controller

On Tue, 2017-06-06 at 06:33 -0700, Guenter Roeck wrote: > On 06/06/2017 12:02 AM, Andrew Jeffery wrote: > > Add a basic driver for the MAX31785, focusing on the fan control > > features but ignoring the temperature and voltage monitoring > > features of the device. > > > > This driver supports

Re: [PATCH v3] hwmon: Add support for MAX31785 intelligent fan controller

On Wed, 2017-06-07 at 12:18 +0930, Joel Stanley wrote: > On Wed, Jun 7, 2017 at 1:50 AM, Matthew Barth > > wrote: > > > > On 06/06/17 8:33 AM, Guenter Roeck wrote: > > > > > > On 06/06/2017 12:02 AM, Andrew Jeffery wrote: > > > > Over and above the features of the