[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PATCH v3 4/9] xen: introduce an arch helper for default dma zone status


  • To: <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Wei Chen <wei.chen@xxxxxxx>
  • Date: Wed, 11 May 2022 09:46:34 +0800
  • Arc-authentication-results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dmarc=[1,1,header.from=arm.com])
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 40.67.248.234) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=none (message not signed); arc=none
  • Arc-message-signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=hPSfIwEjnBcSkjkYn/EHN2y2ss0WA2Wo+7fHC3m1wHA=; b=aHtTsncjJ/3fqjcEOoVPaJ+vVbHWwfsHwztj5HYVVQSFV3WZIbQTAehm7Ct8PRpGnKpG1ct8Fw+zPfaSyQfQZqTDk4oQVw0GksMK4ghE9cN93mrfzCWYVEw6TP2ByUTVQHBpMI3jw7i5ECrWAbG7fVJPELKHlFpLjexQEh0nD4zy++rItVVIKgsxJ0tz8WgPpYQbKVKJ7uQiDNB0YMrL6plY+z7U02/NhGoa6cPBJ85RLED9Ax5OdCZSZUujuyOcwH8zS3vGiEKARuC22XAgsvk57ecMky1yuYwVmVXmPXcg+WAVQa5mBq0GKpWALo8QRp4D+cLOlbg/F5kdD6Kh2g==
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=hPSfIwEjnBcSkjkYn/EHN2y2ss0WA2Wo+7fHC3m1wHA=; b=eKvr/qiqMTxDc98TEiuYzexaz8pnjdORcXsQGlgrQGq2JIRgrgq72VSKQYec5yb8Y86w+D2yeJjAe1xgfYJQl1uWdTpQVb+JnWYAjs/eu4fl2CYJHoGxGdFihD7AkN96hPTdTWRsd/KkwoZKPUp/qJERBcTmN8C+lzrDfYDVkBIbT7sA8BC+ZaAOPRHt5oJcN3YknozfnswQRpRR6avSDx8V0irkf5VL1RvMmXNEsPObdsl1Lp8kuIqgjfMtSNXx8JFxZzXcsyG7+VZ5sWZjuyolT94XeBZccR2EsZIAzeegFW92mkBtWsjaz2hm4zNUDaW6gDr+NlICYKXOgPYFEA==
  • Arc-seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=YiKQ1FZZNHv/Je8IQtgbwbBMH6wuLh1BNvcKBiy5P1LnlHeepHb9mmuPLV4/bQwHKyMLpfrgYPDfszkrK09YShYng9hQVumYJOO7VUKL144d6F5QGHLFLOUBTQObi60zzyjTAFERkwDcMxf1fONHi3tOoUeI56V/tpKcNk8/onBSzUxPpAHJafv9YcZKox29G6bXUxCUZHdnK7mosZor7jdSz6gurWgzi+qv82T4Qom41hllbStutthAw85GvFZSDt4wBsONJiYJzfC05j18xBLbVVFK51p8+JY37QVHj2gAr+0w7TUaD8eBvBnVNvxSUyo9fBdl8yLavpOlfkhnEw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mOw4vk8d6PaxtAWqKBSPAcuG1Wt0ABsIDKk6C6hd8d7pJyC/Z1/7KkERwbqNLfwA0DZDP0fSBX6tUgyepyEu7n+ZStSqFumIxmNB3nOXBiTOv6/ysDPsUHmc5s6Gl6+FRQBz5x6N3eFnvWHa7OM4LDvoZvSkmZI2r3BARzhuCKzyTaeHCRuh7Phzk9ZEVZXLMRviTpDiV+qEUJhjI2GB8cj2MhfTZwHVr++W9TyN4H9s59ammJHO/ak2Vet3lNKzQY1DkdXavH8R5uAYL6xxuhdLdASvFHLy+0fIWRi3xNRGcWf0o/pEXgl/IbLTl482Atd1zGN2IJOa6eSOdjjLfg==
  • Cc: <nd@xxxxxxx>, Wei Chen <wei.chen@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Jiamei Xie <jiamei.xie@xxxxxxx>
  • Delivery-date: Wed, 11 May 2022 01:47:16 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true

In current code, when Xen is running in a multiple nodes
NUMA system, it will set dma_bitsize in end_boot_allocator
to reserve some low address memory as DMA zone.

There are some x86 implications in the implementation.
Because on x86, memory starts from 0. On a multiple-nodes
NUMA system, if a single node contains the majority or all
of the DMA memory, x86 prefers to give out memory from
non-local allocations rather than exhausting the DMA memory
ranges. Hence x86 uses dma_bitsize to set aside some largely
arbitrary amount of memory for DMA zone. The allocations
from DMA zone would happen only after exhausting all other
nodes' memory.

But the implications are not shared across all architectures.
For example, Arm cannot guarantee the availability of memory
below a certain boundary for DMA limited-capability devices
either. But currently, Arm doesn't need a reserved DMA zone
in Xen. Because there is no DMA device in Xen. And for guests,
Xen Arm only allows Dom0 to have DMA operations without IOMMU.
Xen will try to allocate memory under 4GB or memory range that
is limited by dma_bitsize for Dom0 in boot time. For DomU, even
Xen can passthrough devices to DomU without IOMMU, but Xen Arm
doesn't guarantee their DMA operations. So, Xen Arm doesn't
need a reserved DMA zone to provide DMA memory for guests.

In this patch, we introduce an arch_want_default_dmazone helper
for different architectures to determine whether they need to
set dma_bitsize for DMA zone reservation or not.

At the same time, when x86 Xen is built with CONFIG_PV=n could
probably leverage this new helper to actually not trigger DMA
zone reservation.

Signed-off-by: Wei Chen <wei.chen@xxxxxxx>
Tested-by: Jiamei Xie <jiamei.xie@xxxxxxx>
---
v2 -> v3:
1. Add Tb.
2. Rename arch_have_default_dmazone to arch_want_default_dmazone.
v1 -> v2:
1. Extend the description of Arm's workaround for reserve DMA
   allocations to avoid the same discussion every time.
2. Use a macro to define arch_have_default_dmazone, because
   it's little hard to make x86 version to static inline.
   Use a macro will also avoid add __init for this function.
3. Change arch_have_default_dmazone return value from
   unsigned int to bool.
4. Un-addressed comment: make arch_have_default_dmazone
   of x86 to be static inline. Because, if we move
   arch_have_default_dmazone to x86/asm/numa.h, it depends
   on nodemask.h to provide num_online_nodes. But nodemask.h
   needs numa.h to provide MAX_NUMANODES. This will cause a
   loop dependency. And this function can only be used in
   end_boot_allocator, in Xen initialization. So I think,
   compared to the changes introduced by inline, it doesn't
   mean much.
---
 xen/arch/arm/include/asm/numa.h | 1 +
 xen/arch/x86/include/asm/numa.h | 1 +
 xen/common/page_alloc.c         | 2 +-
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/include/asm/numa.h b/xen/arch/arm/include/asm/numa.h
index 31a6de4e23..e4c4d89192 100644
--- a/xen/arch/arm/include/asm/numa.h
+++ b/xen/arch/arm/include/asm/numa.h
@@ -24,6 +24,7 @@ extern mfn_t first_valid_mfn;
 #define node_spanned_pages(nid) (max_page - mfn_x(first_valid_mfn))
 #define node_start_pfn(nid) (mfn_x(first_valid_mfn))
 #define __node_distance(a, b) (20)
+#define arch_want_default_dmazone() (false)
 
 #endif /* __ARCH_ARM_NUMA_H */
 /*
diff --git a/xen/arch/x86/include/asm/numa.h b/xen/arch/x86/include/asm/numa.h
index bada2c0bb9..5d8385f2e1 100644
--- a/xen/arch/x86/include/asm/numa.h
+++ b/xen/arch/x86/include/asm/numa.h
@@ -74,6 +74,7 @@ static inline __attribute__((pure)) nodeid_t 
phys_to_nid(paddr_t addr)
 #define node_spanned_pages(nid)        (NODE_DATA(nid)->node_spanned_pages)
 #define node_end_pfn(nid)       (NODE_DATA(nid)->node_start_pfn + \
                                 NODE_DATA(nid)->node_spanned_pages)
+#define arch_want_default_dmazone() (num_online_nodes() > 1)
 
 extern int valid_numa_range(u64 start, u64 end, nodeid_t node);
 
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 319029140f..b3bddc719b 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -1889,7 +1889,7 @@ void __init end_boot_allocator(void)
     }
     nr_bootmem_regions = 0;
 
-    if ( !dma_bitsize && (num_online_nodes() > 1) )
+    if ( !dma_bitsize && arch_want_default_dmazone() )
         dma_bitsize = arch_get_dma_bitsize();
 
     printk("Domain heap initialised");
-- 
2.25.1




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.