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

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Wed, Aug 01, 2018 at 02:20:36AM -0600, Jan Beulich wrote:
> >>> 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'm all for it, but even in newish systems (as recently reported by
people trying PVH Dom0) RMRR entries are missing and will make some
devices unusable.

> 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?

There's nothing VTd specific in this code at all, I could see it
living in a VTd specific file if it had quirks specific to VTd, but I
think the code is generic enough that it warrants being shared, so
that people running on AMD hw can also enable it if required.

As requested I've left this off for AMD and on by default on Intel, so
the default functionality is not changed at all.

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel