On 11.05.2022 03:46, Wei Chen wrote: > 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 <[email protected]> > Tested-by: Jiamei Xie <[email protected]>
Acked-by: Jan Beulich <[email protected]>
