Re: [PATCH 11/12] swiotlb: merge swiotlb-xen initialization into swiotlb
From: Stefano Stabellini <sstabellini@kernel.org>
Date: 2022-03-03 01:26:53
Also in:
linux-arm-kernel, linux-hyperv, linux-iommu, linux-mips, linux-pci, linux-riscv, linux-s390, xen-devel
On Wed, 2 Mar 2022, Christoph Hellwig wrote:
On Tue, Mar 01, 2022 at 06:55:47PM -0800, Stefano Stabellini wrote:quoted
Unrelated to this specific patch series: now that I think about it, if io_tlb_default_mem.nslabs is already allocated by the time xen_mm_init is called, wouldn't we potentially have an issue with the GFP flags used for the earlier allocation (e.g. GFP_DMA32 not used)? Maybe something for another day.swiotlb_init allocates low memory from meblock, which is roughly equivalent to GFP_DMA allocations, so we'll be fine.quoted
quoted
@@ -143,10 +141,15 @@ static int __init xen_mm_init(void) if (!xen_swiotlb_detect()) return 0; - rc = xen_swiotlb_init(); /* we can work with the default swiotlb */ - if (rc < 0 && rc != -EEXIST) - return rc; + if (!io_tlb_default_mem.nslabs) { + if (!xen_initial_domain()) + return -EINVAL;I don't think we need this xen_initial_domain() check. It is all already sorted out by the xen_swiotlb_detect() check above.Is it? static inline int xen_swiotlb_detect(void) { if (!xen_domain()) return 0; if (xen_feature(XENFEAT_direct_mapped)) return 1; /* legacy case */ if (!xen_feature(XENFEAT_not_direct_mapped) && xen_initial_domain()) return 1; return 0; }
It used to be that we had a
if (!xen_initial_domain())
return -EINVAL;
check in the initialization of swiotlb-xen on ARM. Then we replaced it
with the more sophisticated xen_swiotlb_detect().
The reason is that swiotlb-xen on ARM relies on Dom0 being 1:1 mapped
(guest physical addresses == physical addresses). Recent changes in Xen
allowed also DomUs to be 1:1 mapped. Changes still under discussion will
allow Dom0 not to be 1:1 mapped.
So, before all the Xen-side changes, knowing what was going to happen, I
introduced a clearer interface: XENFEAT_direct_mapped and
XENFEAT_not_direct_mapped tell us whether the guest (Linux) is 1:1
mapped or not. If it is 1:1 mapped then Linux can take advantage of
swiotlb-xen. Now xen_swiotlb_detect() returns true if Linux is 1:1
mapped.
Then of course there is the legacy case. That's taken care of by:
if (!xen_feature(XENFEAT_not_direct_mapped) && xen_initial_domain())
return 1;
The intention is to say that if
XENFEAT_direct_mapped/XENFEAT_not_direct_mapped are not present, then
use xen_initial_domain() like we did before.
So if xen_swiotlb_detect() returns true we know that Linux is either
dom0 (xen_initial_domain() == true) or we have very good reasons to
think we should initialize swiotlb-xen anyway
(xen_feature(XENFEAT_direct_mapped) == true).
I think I'd keep it as-is for now, as my planned next step would be to fold xen-swiotlb into swiotlb entirely.
Thinking more about it we actually need to drop the xen_initial_domain() check otherwise some cases won't be functional (Dom0 not 1:1 mapped, or DomU 1:1 mapped).