Re: [Xen-devel] [PATCH 2/4] iommu: generalize iommu_inclusive_mapping

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 01.08.18 at 10:33, <Paul.Durrant@xxxxxxxxxx> wrote:
>> From: Xen-devel [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf
>> Of Jan Beulich
>> Sent: 01 August 2018 09:21
>> >>> On 31.07.18 at 17:33, <roger.pau@xxxxxxxxxx> wrote:
>> > On Tue, Jul 31, 2018 at 08:39:22AM -0600, Jan Beulich wrote:
>> >> >>> On 27.07.18 at 17:31, <roger.pau@xxxxxxxxxx> 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
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel