Re: [PATCH v3 6/7] iommu: Introduce IOMMU_RESV_DIRECT_RELAXABLE reserved memory regions

[Alex Williamson]

On Thu, 16 May 2019 15:23:17 +0200
Auger Eric <eric.auger@xxxxxxxxxx> wrote:

> Hi Robin,
> On 5/16/19 2:46 PM, Robin Murphy wrote:
> >> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> >> index ba91666998fb..14a521f85f14 100644
> >> --- a/include/linux/iommu.h
> >> +++ b/include/linux/iommu.h
> >> @@ -135,6 +135,12 @@ enum iommu_attr {
> >> Â enum iommu_resv_type {
> >> ÂÂÂÂÂ /* Memory regions which must be mapped 1:1 at all times */
> >> ÂÂÂÂÂ IOMMU_RESV_DIRECT,
> >> +ÂÂÂ /*
> >> +ÂÂÂÂ * Memory regions which are advertised to be 1:1 but are
> >> +ÂÂÂÂ * commonly considered relaxable in some conditions,
> >> +ÂÂÂÂ * for instance in device assignment use case (USB, Graphics)
> >> +ÂÂÂÂ */
> >> +ÂÂÂ IOMMU_RESV_DIRECT_RELAXABLE,  
> > 
> > What do you think of s/RELAXABLE/BOOT/ ? My understanding is that these
> > regions are only considered relevant until Linux has taken full control
> > of the endpoint, and having a slightly more well-defined scope than
> > "some conditions" might be nice.  
> That's not my current understanding. I think those RMRRs may be used
> post-boot (especially the IGD stolen memory covered by RMRR). I
> understand this depends on the video mode or FW in use by the IGD. But I
> am definitively not an expert here.

Nor am I, but generally the distinction I'm trying to achieve is
whether the reserved region is necessary for the device operation or
for the system operation.  If we deny the IGD device its mapping to
stolen memory, then maybe the IGD device doesn't work, no big deal.  If
we deny USB its RMRR, then we assume we're only cutting off PS/2
emulation that we expect isn't used at this point anyway.  Both of these
are choices in how the driver wants to use the device.  On the other
hand if we have a system where management firmware has backdoors to
devices for system health monitoring, then declining to honor the RMRR
has larger implications.  Thanks,

Alex