>>> On 31.07.18 at 17:33, <[email protected]> wrote: > On Tue, Jul 31, 2018 at 08:39:22AM -0600, Jan Beulich wrote: >> >>> On 27.07.18 at 17:31, <[email protected]> wrote: >> > Introduce a new iommu=inclusive generic option that supersedes >> > iommu_inclusive_mapping. This should be a non-functional change on >> > Intel hardware, while AMD hardware will gain the same functionality of >> > mapping almost everything below the 4GB boundary. >> >> So first of all - what's the motivation behind this change? So far we >> had no need for hacks line the VT-d side one on AMD. I don't think >> this should be widened without there being indication of a problem >> with non-niche AMD systems. > > OK, I can leave the default on for Intel and off for everything else, > but I will introduce the generic dom0-iommu= option anyway.
Hmm, I've always been wishing we'd change to a default of off for VT-d as well - imo we shouldn't by default assume broken firmware. Kevin? As to AMD - you still don't really say why this would be needed there. I'm not in favor of workarounds when there's nothing to work around. IOW - if the logic isn't needed on AMD, do we need this code movement in the first place? Jan _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
