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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Xen-devel [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf
> Of Jan Beulich
> Sent: 01 August 2018 09:21
> To: Roger Pau Monne <roger.pau@xxxxxxxxxx>
> Cc: Kevin Tian <kevin.tian@xxxxxxxxx>; Stefano Stabellini
> <sstabellini@xxxxxxxxxx>; Wei Liu <wei.liu2@xxxxxxxxxx>; George Dunlap
> <George.Dunlap@xxxxxxxxxx>; Andrew Cooper
> <Andrew.Cooper3@xxxxxxxxxx>; Ian Jackson <Ian.Jackson@xxxxxxxxxx>; Tim
> (Xen.org) <tim@xxxxxxx>; Julien Grall <julien.grall@xxxxxxx>; xen-devel
> <xen-devel@xxxxxxxxxxxxxxxxxxxx>
> Subject: Re: [Xen-devel] [PATCH 2/4] iommu: generalize
> iommu_inclusive_mapping
> 
> >>> 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.

  Paul

> 
> 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
> Xen-devel@xxxxxxxxxxxxxxxxxxxx
> https://lists.xenproject.org/mailman/listinfo/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel