On 01/08/2018 09:20, Jan Beulich wrote: >>>> 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?
This is sufficiently broken on AMD as well. Take a look at all the IVRS/IVHT reports we've had on xen-devel. Furthermore, on by default is the only reasonable option. Dom0 is specifically given cpu mappings of the reserved regions, therefore it should have matching IOMMU mappings. ~Andrew _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
