On 07.02.2024 10:01, Roger Pau Monné wrote: > On Tue, Feb 06, 2024 at 12:28:07PM +0100, Jan Beulich wrote: >> On 01.02.2024 18:01, Roger Pau Monne wrote: >>> Use the newly introduced generic unity map checker. >>> >>> Also drop the message recommending the usage of iommu_inclusive_mapping: the >>> ranges would end up being mapped anyway even if some of the checks above >>> failed, regardless of whether iommu_inclusive_mapping is set. >> >> I'm afraid I don't understand this: When not in an appropriate E820 >> region, you now even fail IOMMU initialization. Shouldn't such >> failure only occur when inclusive mappings weren't requested? At >> which point referring to that option is still relevant? > > This is now better handled, since the VT-d code will use the same > logic as the AMD-Vi logic and attempt to 'convert' such bogus RMRR > regions so they can be safely used. iommu_unity_region_ok() signals > the RMRR region is impossible to be used, and hence not even > iommu_inclusive_mapping would help in that case.
Impossible only in so far as we don't know whether a such named region would actually still be accessed post-boot. But yes, if it wouldn't be accessed, there would also be no need for passing the extra option. > Also note that > iommu_inclusive_mapping is only applicable to PV, so the message was > already wrong in the PVH case. This is a fair point, which probably wants mentioning as (partial) justification. Plus iirc the intention was to get rid of that option anyway, at some point. Jan
