>>> On 01.08.18 at 10:33, <[email protected]> wrote: >> From: Xen-devel [mailto:[email protected]] On Behalf >> Of Jan Beulich >> Sent: 01 August 2018 09:21 >> >>> 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? > > I suspect that a seriously large number of Xen users will find their systems > fail to boot if the default is changed. I'm testing on a Dell R730 with (to > my knowledge) up-to-date firmware. Not exactly a rare system and turning off > inclusive mapping will cause it to wedge during boot.
Hmm, that's rather sad indeed. Jan _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
