linux-stable.git/include/linux/ioport.h, branch v5.6.2

x86/efi: EFI soft reservation to E820 enumeration

2019-11-07T14:44:14+00:00

UEFI 2.8 defines an EFI_MEMORY_SP attribute bit to augment the
interpretation of the EFI Memory Types as "reserved for a specific
purpose".

The proposed Linux behavior for specific purpose memory is that it is
reserved for direct-access (device-dax) by default and not available for
any kernel usage, not even as an OOM fallback.  Later, through udev
scripts or another init mechanism, these device-dax claimed ranges can
be reconfigured and hot-added to the available System-RAM with a unique
node identifier. This device-dax management scheme implements "soft" in
the "soft reserved" designation by allowing some or all of the
reservation to be recovered as typical memory. This policy can be
disabled at compile-time with CONFIG_EFI_SOFT_RESERVE=n, or runtime with
efi=nosoftreserve.

This patch introduces 2 new concepts at once given the entanglement
between early boot enumeration relative to memory that can optionally be
reserved from the kernel page allocator by default. The new concepts
are:

- E820_TYPE_SOFT_RESERVED: Upon detecting the EFI_MEMORY_SP
  attribute on EFI_CONVENTIONAL memory, update the E820 map with this
  new type. Only perform this classification if the
  CONFIG_EFI_SOFT_RESERVE=y policy is enabled, otherwise treat it as
  typical ram.

- IORES_DESC_SOFT_RESERVED: Add a new I/O resource descriptor for
  a device driver to search iomem resources for application specific
  memory. Teach the iomem code to identify such ranges as "Soft Reserved".

Note that the comment for do_add_efi_memmap() needed refreshing since it
seemed to imply that the efi map might overflow the e820 table, but that
is not an issue as of commit 7b6e4ba3cb1f "x86/boot/e820: Clean up the
E820_X_MAX definition" that removed the 128 entry limit for
e820__range_add().

A follow-on change integrates parsing of the ACPI HMAT to identify the
node and sub-range boundaries of EFI_MEMORY_SP designated memory. For
now, just identify and reserve memory of this type.

Acked-by: Ard Biesheuvel 
Reported-by: kbuild test robot 
Reviewed-by: Dave Hansen 
Signed-off-by: Dan Williams 
Acked-by: Thomas Gleixner 
Signed-off-by: Rafael J. Wysocki

resource: add a not device managed request_free_mem_region variant

2019-08-20T12:39:41+00:00

Factor out the guts of devm_request_free_mem_region so that we can
implement both a device managed and a manually release version as tiny
wrappers around it.

Link: https://lore.kernel.org/r/20190818090557.17853-2-hch@lst.de
Signed-off-by: Christoph Hellwig 
Reviewed-by: Ira Weiny 
Reviewed-by: Dan Williams 
Tested-by: Bharata B Rao 
Reviewed-by: Jason Gunthorpe 
Signed-off-by: Jason Gunthorpe

Merge tag 'for-linus-hmm' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma

2019-07-15T02:42:11+00:00

Pull HMM updates from Jason Gunthorpe:
 "Improvements and bug fixes for the hmm interface in the kernel:

   - Improve clarity, locking and APIs related to the 'hmm mirror'
     feature merged last cycle. In linux-next we now see AMDGPU and
     nouveau to be using this API.

   - Remove old or transitional hmm APIs. These are hold overs from the
     past with no users, or APIs that existed only to manage cross tree
     conflicts. There are still a few more of these cleanups that didn't
     make the merge window cut off.

   - Improve some core mm APIs:
       - export alloc_pages_vma() for driver use
       - refactor into devm_request_free_mem_region() to manage
         DEVICE_PRIVATE resource reservations
       - refactor duplicative driver code into the core dev_pagemap
         struct

   - Remove hmm wrappers of improved core mm APIs, instead have drivers
     use the simplified API directly

   - Remove DEVICE_PUBLIC

   - Simplify the kconfig flow for the hmm users and core code"

* tag 'for-linus-hmm' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma: (42 commits)
  mm: don't select MIGRATE_VMA_HELPER from HMM_MIRROR
  mm: remove the HMM config option
  mm: sort out the DEVICE_PRIVATE Kconfig mess
  mm: simplify ZONE_DEVICE page private data
  mm: remove hmm_devmem_add
  mm: remove hmm_vma_alloc_locked_page
  nouveau: use devm_memremap_pages directly
  nouveau: use alloc_page_vma directly
  PCI/P2PDMA: use the dev_pagemap internal refcount
  device-dax: use the dev_pagemap internal refcount
  memremap: provide an optional internal refcount in struct dev_pagemap
  memremap: replace the altmap_valid field with a PGMAP_ALTMAP_VALID flag
  memremap: remove the data field in struct dev_pagemap
  memremap: add a migrate_to_ram method to struct dev_pagemap_ops
  memremap: lift the devmap_enable manipulation into devm_memremap_pages
  memremap: pass a struct dev_pagemap to ->kill and ->cleanup
  memremap: move dev_pagemap callbacks into a separate structure
  memremap: validate the pagemap type passed to devm_memremap_pages
  mm: factor out a devm_request_free_mem_region helper
  mm: export alloc_pages_vma
  ...

mm: factor out a devm_request_free_mem_region helper

2019-07-02T17:32:44+00:00

Keep the physical address allocation that hmm_add_device does with the
rest of the resource code, and allow future reuse of it without the hmm
wrapper.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Jason Gunthorpe 
Reviewed-by: John Hubbard 
Reviewed-by: Dan Williams 
Signed-off-by: Jason Gunthorpe

mm: remove MEMORY_DEVICE_PUBLIC support

2019-07-02T17:32:43+00:00

The code hasn't been used since it was added to the tree, and doesn't
appear to actually be usable.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Jason Gunthorpe 
Acked-by: Michal Hocko 
Reviewed-by: Dan Williams 
Tested-by: Dan Williams 
Signed-off-by: Jason Gunthorpe

x86/mm: Rework ioremap resource mapping determination

2019-06-20T07:58:07+00:00

On ioremap(), __ioremap_check_mem() does a couple of checks on the
supplied memory range to determine how the range should be mapped and in
particular what protection flags should be used.

Generalize the procedure by introducing IORES_MAP_* flags which control
different aspects of the ioremapping and use them in the respective
helpers which determine which descriptor flags should be set per range.

 [ bp:
   - Rewrite commit message.
   - Add/improve comments.
   - Reflow __ioremap_caller()'s args.
   - s/__ioremap_check_desc/__ioremap_check_encrypted/g;
   - s/__ioremap_res_check/__ioremap_collect_map_flags/g;
   - clarify __ioremap_check_ram()'s purpose. ]

Signed-off-by: Lianbo Jiang 
Co-developed-by: Borislav Petkov 
Signed-off-by: Borislav Petkov 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: bhe@redhat.com
Cc: Dave Hansen 
Cc: dyoung@redhat.com
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: kexec@lists.infradead.org
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Tom Lendacky 
Cc: x86-ml 
Link: https://lkml.kernel.org/r/20190423013007.17838-3-lijiang@redhat.com

x86/e820, ioport: Add a new I/O resource descriptor IORES_DESC_RESERVED

2019-06-20T07:54:31+00:00

When executing the kexec_file_load() syscall, the first kernel needs to
pass the e820 reserved ranges to the second kernel because some devices
(PCI, for example) need them present in the kdump kernel for proper
initialization.

But the kernel can not exactly match the e820 reserved ranges when
walking through the iomem resources using the default IORES_DESC_NONE
descriptor, because there are several types of e820 ranges which are
marked IORES_DESC_NONE, see e820_type_to_iores_desc().

Therefore, add a new I/O resource descriptor called IORES_DESC_RESERVED
to mark exactly those ranges. It will be used to match the reserved
resource ranges when walking through iomem resources.

 [ bp: Massage commit message. ]

Suggested-by: Borislav Petkov 
Signed-off-by: Lianbo Jiang 
Signed-off-by: Borislav Petkov 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: bhe@redhat.com
Cc: dave.hansen@linux.intel.com
Cc: dyoung@redhat.com
Cc: "H. Peter Anvin" 
Cc: Huang Zijiang 
Cc: Ingo Molnar 
Cc: Joe Perches 
Cc: Juergen Gross 
Cc: kexec@lists.infradead.org
Cc: Masayoshi Mizuma 
Cc: Michal Hocko 
Cc: Mike Rapoport 
Cc: Naoya Horiguchi 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Tom Lendacky 
Cc: x86-ml 
Link: https://lkml.kernel.org/r/20190423013007.17838-2-lijiang@redhat.com

kernel/resource: iomem_is_exclusive can be boolean

2018-02-07T02:32:47+00:00

Make iomem_is_exclusive return bool due to this particular function only
using either one or zero as its return value.

No functional change.

Link: http://lkml.kernel.org/r/1513266622-15860-5-git-send-email-baiyaowei@cmss.chinamobile.com
Signed-off-by: Yaowei Bai 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

x86/mm, resource: Use PAGE_KERNEL protection for ioremap of memory pages

2017-11-07T14:35:58+00:00

In order for memory pages to be properly mapped when SEV is active, it's
necessary to use the PAGE_KERNEL protection attribute as the base
protection.  This ensures that memory mapping of, e.g. ACPI tables,
receives the proper mapping attributes.

Signed-off-by: Tom Lendacky 
Signed-off-by: Brijesh Singh 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Borislav Petkov 
Tested-by: Borislav Petkov 
Cc: Laura Abbott 
Cc: Kees Cook 
Cc: kvm@vger.kernel.org
Cc: Jérôme Glisse 
Cc: Borislav Petkov 
Cc: Andy Lutomirski 
Cc: Andrew Morton 
Cc: Dan Williams 
Cc: "Kirill A. Shutemov" 
Link: https://lkml.kernel.org/r/20171020143059.3291-11-brijesh.singh@amd.com

resource: Provide resource struct in resource walk callback

2017-11-07T14:35:57+00:00

In preperation for a new function that will need additional resource
information during the resource walk, update the resource walk callback to
pass the resource structure.  Since the current callback start and end
arguments are pulled from the resource structure, the callback functions
can obtain them from the resource structure directly.

Signed-off-by: Tom Lendacky 
Signed-off-by: Brijesh Singh 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Kees Cook 
Reviewed-by: Borislav Petkov 
Tested-by: Borislav Petkov 
Cc: kvm@vger.kernel.org
Cc: Benjamin Herrenschmidt 
Cc: Borislav Petkov 
Cc: linuxppc-dev@lists.ozlabs.org
Link: https://lkml.kernel.org/r/20171020143059.3291-10-brijesh.singh@amd.com