On 11.08.20 11:44, Roger Pau Monne wrote:
To be used in order to create foreign mappings. This is based on the
ZONE_DEVICE facility which is used by persistent memory devices in
order to create struct pages and kernel virtual mappings for the IOMEM
areas of such devices. Note that on kernels without support for
ZONE_DEVICE Xen will fallback to use ballooned pages in order to
create foreign mappings.
The newly added helpers use the same parameters as the existing
{alloc/free}_xenballooned_pages functions, which allows for in-place
replacement of the callers. Once a memory region has been added to be
used as scratch mapping space it will no longer be released, and pages
returned are kept in a linked list. This allows to have a buffer of
pages and prevents resorting to frequent additions and removals of
regions.
If enabled (because ZONE_DEVICE is supported) the usage of the new
functionality untangles Xen balloon and RAM hotplug from the usage of
unpopulated physical memory ranges to map foreign pages, which is the
correct thing to do in order to avoid mappings of foreign pages depend
on memory hotplug.
Note the driver is currently not enabled on Arm platforms because it
would interfere with the identity mapping required on some platforms.
Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
---
Cc: Oleksandr Andrushchenko <oleksandr_andrushchenko@xxxxxxxx>
Cc: David Airlie <airlied@xxxxxxxx>
Cc: Daniel Vetter <daniel@xxxxxxxx>
Cc: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
Cc: Juergen Gross <jgross@xxxxxxxx>
Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>
Cc: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
Cc: Roger Pau Monne <roger.pau@xxxxxxxxxx>
Cc: Wei Liu <wl@xxxxxxx>
Cc: Yan Yankovskyi <yyankovskyi@xxxxxxxxx>
Cc: dri-devel@xxxxxxxxxxxxxxxxxxxxx
Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx
Cc: linux-mm@xxxxxxxxx
Cc: David Hildenbrand <david@xxxxxxxxxx>
Cc: Michal Hocko <mhocko@xxxxxxxxxx>
Cc: Dan Williams <dan.j.williams@xxxxxxxxx>
---
Changes since v3:
- Introduce a Kconfig option that gates the addition of the
unpopulated alloc driver. This allows to easily disable it on Arm
platforms.
- Dropped Juergen RB due to the addition of the Kconfig option.
- Switched from MEMORY_DEVICE_DEVDAX to MEMORY_DEVICE_GENERIC.
Changes since v2:
- Drop BUILD_BUG_ON regarding PVMMU page sizes.
- Use a SPDX license identifier.
- Call fill with only the minimum required number of pages.
- Include xen.h header in xen_drm_front_gem.c.
- Use less generic function names.
- Exit early from the init function if not a PV guest.
- Don't use all caps for region name.
---
drivers/gpu/drm/xen/xen_drm_front_gem.c | 9 +-
drivers/xen/Kconfig | 4 +
drivers/xen/Makefile | 1 +
drivers/xen/balloon.c | 4 +-
drivers/xen/grant-table.c | 4 +-
drivers/xen/privcmd.c | 4 +-
drivers/xen/unpopulated-alloc.c | 185 ++++++++++++++++++++++++
drivers/xen/xenbus/xenbus_client.c | 6 +-
drivers/xen/xlate_mmu.c | 4 +-
include/xen/xen.h | 9 ++
10 files changed, 215 insertions(+), 15 deletions(-)
create mode 100644 drivers/xen/unpopulated-alloc.c
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 1d339ef92422..018020b91baa 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -327,4 +327,8 @@ config XEN_HAVE_VPMU
config XEN_FRONT_PGDIR_SHBUF
tristate
+config XEN_UNPOPULATED_ALLOC
+ bool
+ default y if ZONE_DEVICE && !ARM && !ARM64
There is a current effort to enable Xen on RISC-V. Do we expect this
option to be usable for this architecture? If yes, I'm fine with the
exclusion of Arm, otherwise I'd opt for defaulting to yes only for
X86.
Either way you can have my:
Reviewed-by: Juergen Gross <jgross@xxxxxxxx>
Juergen
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
