Robin Murphy <[email protected]> writes: > On 21/09/2026 7:36 am, Aneesh Kumar K.V (Arm) wrote: >> On x86, iommu=off historically prevented SWIOTLB initialization by not >> setting SWIOTLB_INIT_ADDRESSING_LIMIT. This overloads that flag: it >> controls both whether a pool is selected and where the pool is >> allocated. If another requirement, swiotlb=force selects a pool >> independently, omitting SWIOTLB_INIT_ADDRESSING_LIMIT may place it above >> the addressable range of devices which need bounce buffering. > > Well then surely something is wrong with the design? If > SWIOTLB_INIT_ADDRESSING_LIMIT is set then SWIOTLB still needs to respect > it irrespective of any *additional* reasons for activating (either from > arch code or internally). And conversely, if devices have addressing > limits but SWIOTLB_INIT_ADDRESSING_LIMIT is *not* set, then the arch > code has clearly gone wrong or made a bad assumption, but that doesn't > seem like SWIOTLB's problem to worry about. >
That is what this patch does. It sets SWIOTLB_INIT_ADDRESSING_LIMIT based on max_possible_pfn, while SWIOTLB_INIT_FORCE_DISABLE allows the architecture to opt out of SWIOTLB initialization independently. > >> Add SWIOTLB_INIT_FORCE_DISABLE to let an architecture opt out of normal >> pool initialization without discarding the pool placement constraints. >> >> Unlike swiotlb_force_disable, which is set by swiotlb=noforce and >> unconditionally prevents pool initialization, the new flag is an >> architecture default. Explicit requirements such as memory encryption, >> architecture remapping, or swiotlb=force take precedence over it. > > Logically, that should already be implied by the architecture passing no > SWIOTLB_INIT flags. > We now have a case where max_possible_pfn causes SWIOTLB_INIT_ADDRESSING_LIMIT to be set, while the kernel command line specifies iommu=off. We want to disable SWIOTLB in this case even though the SWIOTLB_INIT flags are nonzero. -aneesh
