On 14.08.20 11:56, Roger Pau Monné wrote:
On Fri, Aug 14, 2020 at 08:29:20AM +0100, Christoph Hellwig wrote:
On Thu, Aug 13, 2020 at 09:54:20AM +0200, Roger Pau Monn?? wrote:
On Thu, Aug 13, 2020 at 08:33:37AM +0100, Christoph Hellwig wrote:
On Tue, Aug 11, 2020 at 11:44:47AM +0200, Roger Pau Monne wrote:
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.
So please just select ZONE_DEVICE if this is so much better rather
than maintaining two variants.
We still need to other variant for Arm at least, so both need to be
maintained anyway, even if we force ZONE_DEVICE on x86.
Well, it still really helps reproducability if you stick to one
implementation of x86.
The alternative would be an explicit config option to opt into it,
but just getting a different implementation based on a random
kernel option is strange.
Would adding something like the chunk below to the patch be OK?
---8<---
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 018020b91baa..5f321a1319e6 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -328,7 +328,14 @@ config XEN_FRONT_PGDIR_SHBUF
tristate
config XEN_UNPOPULATED_ALLOC
- bool
- default y if ZONE_DEVICE && !ARM && !ARM64
+ bool "Use unpopulated memory ranges for guest mappings"
+ depends on X86
+ select ZONE_DEVICE
+ default y
I'd rather use "default XEN_BACKEND" here, as mappings of other guest's
memory is rarely used for non-backend guests.
Juergen
