linux-toradex.git/include/linux/io.h, branch v5.1-rc4

x86/mm: Add support to access boot related data in the clear

2017-07-18T09:38:02+00:00

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 arch specific routine to modify the
pagetable protection attributes before they are applied to the new
mapping. This is used to remove the encryption mask for boot related data.

Update memremap() to provide an arch specific routine to determine if RAM
remapping is allowed.  RAM remapping will cause an encrypted mapping to be
generated. By preventing RAM remapping, ioremap_cache() will be used
instead, which will provide a decrypted mapping of the boot related data.

Signed-off-by: Tom Lendacky 
Reviewed-by: Thomas Gleixner 
Reviewed-by: Matt Fleming 
Reviewed-by: Borislav Petkov 
Cc: Alexander Potapenko 
Cc: Andrey Ryabinin 
Cc: Andy Lutomirski 
Cc: Arnd Bergmann 
Cc: Borislav Petkov 
Cc: Brijesh Singh 
Cc: Dave Young 
Cc: Dmitry Vyukov 
Cc: Jonathan Corbet 
Cc: Konrad Rzeszutek Wilk 
Cc: Larry Woodman 
Cc: Linus Torvalds 
Cc: Michael S. Tsirkin 
Cc: Paolo Bonzini 
Cc: Peter Zijlstra 
Cc: Radim Krčmář 
Cc: Rik van Riel 
Cc: Toshimitsu Kani 
Cc: kasan-dev@googlegroups.com
Cc: kvm@vger.kernel.org
Cc: linux-arch@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: linux-efi@vger.kernel.org
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/81fb6b4117a5df6b9f2eda342f81bbef4b23d2e5.1500319216.git.thomas.lendacky@amd.com
Signed-off-by: Ingo Molnar

linux/io.h: Add pci_remap_cfgspace() interface

2017-04-19T18:58:51+00:00

The PCI specifications (Rev 3.0, 3.2.5 "Transaction Ordering and Posting")
mandate non-posted configuration transactions. As further highlighted in
the PCIe specifications (4.0 - Rev0.3, "Ordering Considerations for the
Enhanced Configuration Access Mechanism"), through ECAM and ECAM-derivative
configuration mechanism, the memory mapped transactions from the host CPU
into Configuration Requests on the PCI express fabric may create ordering
problems for software because writes to memory address are typically posted
transactions (unless the architecture can enforce through virtual address
mapping non-posted write transactions behaviour) but writes to
Configuration Space are not posted on the PCI express fabric.

Current DT and ACPI host bridge controllers map PCI configuration space
(ECAM and ECAM-derivative) into the virtual address space through ioremap()
calls, that are non-cacheable device accesses on most architectures, but
may provide "bufferable" or "posted" write semantics in architecture like
eg ARM/ARM64 that allow ioremap'ed regions writes to be buffered in the bus
connecting the host CPU to the PCI fabric; this behaviour, as underlined in
the PCIe specifications, may trigger transactions ordering rules and must
be prevented.

Introduce a new generic and explicit API to create a memory mapping for
ECAM and ECAM-derivative config space area that defaults to
ioremap_nocache() (which should provide a sane default behaviour) but still
allowing architectures on which ioremap_nocache() results in posted write
transactions to override the function call with an arch specific
implementation that complies with the PCI specifications for configuration
transactions.

[bhelgaas: fold in #ifdef CONFIG_PCI wrapper]
Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Bjorn Helgaas 
Cc: Arnd Bergmann 
Cc: Will Deacon 
Cc: Russell King 
Cc: Catalin Marinas

x86/io: add interface to reserve io memtype for a resource range. (v1.1)

2016-10-26T05:45:38+00:00

A recent change to the mm code in:
87744ab3832b mm: fix cache mode tracking in vm_insert_mixed()

started enforcing checking the memory type against the registered list for
amixed pfn insertion mappings. It happens that the drm drivers for a number
of gpus relied on this being broken. Currently the driver only inserted
VRAM mappings into the tracking table when they came from the kernel,
and userspace mappings never landed in the table. This led to a regression
where all the mapping end up as UC instead of WC now.

I've considered a number of solutions but since this needs to be fixed
in fixes and not next, and some of the solutions were going to introduce
overhead that hadn't been there before I didn't consider them viable at
this stage. These mainly concerned hooking into the TTM io reserve APIs,
but these API have a bunch of fast paths I didn't want to unwind to add
this to.

The solution I've decided on is to add a new API like the arch_phys_wc
APIs (these would have worked but wc_del didn't take a range), and
use them from the drivers to add a WC compatible mapping to the table
for all VRAM on those GPUs. This means we can then create userspace
mapping that won't get degraded to UC.

v1.1: use CONFIG_X86_PAT + add some comments in io.h

Cc: Toshi Kani 
Cc: Borislav Petkov 
Cc: H. Peter Anvin 
Cc: Andy Lutomirski 
Cc: Denys Vlasenko 
Cc: Brian Gerst 
Cc: x86@kernel.org
Cc: mcgrof@suse.com
Cc: Dan Williams 
Acked-by: Ingo Molnar 
Reviewed-by: Thomas Gleixner 
Signed-off-by: Dave Airlie

memremap: add MEMREMAP_WC flag

2016-03-22T22:36:02+00:00

Add a flag to memremap() for writecombine mappings.  Mappings satisfied
by this flag will not be cached, however writes may be delayed or
combined into more efficient bursts.  This is most suitable for buffers
written sequentially by the CPU for use by other DMA devices.

Signed-off-by: Brian Starkey 
Reviewed-by: Catalin Marinas 
Cc: Dan Williams 
Cc: Greg Kroah-Hartman 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

lib/iomap_copy.c: add __ioread32_copy()

2016-01-21T01:09:18+00:00

Some drivers need to read data out of iomem areas 32-bits at a time.
Add an API to do this.

Signed-off-by: Stephen Boyd 
Cc: Bjorn Andersson 
Cc: 
Cc: David Howells 
Cc: Hauke Mehrtens 
Cc: Paul Walmsley 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm: introduce find_dev_pagemap()

2016-01-16T01:56:32+00:00

There are several scenarios where we need to retrieve and update
metadata associated with a given devm_memremap_pages() mapping, and the
only lookup key available is a pfn in the range:

1/ We want to augment vmemmap_populate() (called via arch_add_memory())
   to allocate memmap storage from pre-allocated pages reserved by the
   device driver.  At vmemmap_alloc_block_buf() time it grabs device pages
   rather than page allocator pages.  This is in support of
   devm_memremap_pages() mappings where the memmap is too large to fit in
   main memory (i.e. large persistent memory devices).

2/ Taking a reference against the mapping when inserting device pages
   into the address_space radix of a given inode.  This facilitates
   unmap_mapping_range() and truncate_inode_pages() operations when the
   driver is tearing down the mapping.

3/ get_user_pages() operations on ZONE_DEVICE memory require taking a
   reference against the mapping so that the driver teardown path can
   revoke and drain usage of device pages.

Signed-off-by: Dan Williams 
Tested-by: Logan Gunthorpe 
Cc: Christoph Hellwig 
Cc: Dave Chinner 
Cc: Ross Zwisler 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

add devm_memremap_pages

2015-08-27T23:40:58+00:00

This behaves like devm_memremap except that it ensures we have page
structures available that can back the region.

Signed-off-by: Christoph Hellwig 
[djbw: catch attempts to remap RAM, drop flags]
Signed-off-by: Dan Williams

devres: add devm_memremap

2015-08-14T20:01:21+00:00

Signed-off-by: Christoph Hellwig 
Signed-off-by: Dan Williams

arch: introduce memremap()

2015-08-14T17:23:28+00:00

Existing users of ioremap_cache() are mapping memory that is known in
advance to not have i/o side effects.  These users are forced to cast
away the __iomem annotation, or otherwise neglect to fix the sparse
errors thrown when dereferencing pointers to this memory.  Provide
memremap() as a non __iomem annotated ioremap_*() in the case when
ioremap is otherwise a pointer to cacheable memory. Empirically,
ioremap_() call sites are seeking memory-like semantics
(e.g.  speculative reads, and prefetching permitted).

memremap() is a break from the ioremap implementation pattern of adding
a new memremap_() for each mapping type and having silent
compatibility fall backs.  Instead, the implementation defines flags
that are passed to the central memremap() and if a mapping type is not
supported by an arch memremap returns NULL.

We introduce a memremap prototype as a trivial wrapper of
ioremap_cache() and ioremap_wt().  Later, once all ioremap_cache() and
ioremap_wt() usage has been removed from drivers we teach archs to
implement arch_memremap() with the ability to strictly enforce the
mapping type.

Cc: Arnd Bergmann 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Dan Williams

x86/mm: Decouple from

2015-06-03T10:02:00+00:00

Nothing in  uses anything from , so
remove it from there and fix up the resulting build problems
triggered on x86 {64|32}-bit {def|allmod|allno}configs.

The breakages were triggering in places where x86 builds relied
on vmalloc() facilities but did not include 
explicitly and relied on the implicit inclusion via .

Also add:

  -  to 
  -  to 

... which were two other implicit header file dependencies.

Suggested-by: David Miller 
Signed-off-by: Stephen Rothwell 
[ Tidied up the changelog. ]
Acked-by: David Miller 
Acked-by: Takashi Iwai 
Acked-by: Viresh Kumar 
Acked-by: Vinod Koul 
Cc: Andrew Morton 
Cc: Anton Vorontsov 
Cc: Boris Ostrovsky 
Cc: Colin Cross 
Cc: David Vrabel 
Cc: H. Peter Anvin 
Cc: Haiyang Zhang 
Cc: James E.J. Bottomley 
Cc: Jaroslav Kysela 
Cc: K. Y. Srinivasan 
Cc: Kees Cook 
Cc: Konrad Rzeszutek Wilk 
Cc: Kristen Carlson Accardi 
Cc: Len Brown 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Rafael J. Wysocki 
Cc: Suma Ramars 
Cc: Thomas Gleixner 
Cc: Tony Luck 
Signed-off-by: Ingo Molnar