public inbox for iommu@lists.linux-foundation.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Auger Eric <eric.auger@redhat.com>
Cc: Robin Murphy <robin.murphy@arm.com>,
	will.deacon@arm.com, linux-kernel@vger.kernel.org,
	iommu@lists.linux-foundation.org, sudeep.holla@arm.com,
	dwmw2@infradead.org, eric.auger.pro@gmail.com
Subject: Re: [PATCH v3 6/7] iommu: Introduce IOMMU_RESV_DIRECT_RELAXABLE reserved memory regions
Date: Thu, 16 May 2019 10:53:44 -0600	[thread overview]
Message-ID: <20190516105344.5add5520@x1.home> (raw)
In-Reply-To: <57db1955-9d19-7c0b-eca3-37cc0d7d745b@redhat.com>

On Thu, 16 May 2019 15:23:17 +0200
Auger Eric <eric.auger@redhat.com> 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
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  reply	other threads:[~2019-05-16 16:53 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-16 10:08 [PATCH v3 0/7] RMRR related fixes and enhancements Eric Auger
2019-05-16 10:08 ` [PATCH v3 1/7] iommu: Pass a GFP flag parameter to iommu_alloc_resv_region() Eric Auger
2019-05-16 10:08 ` [PATCH v3 2/7] iommu/vt-d: Duplicate iommu_resv_region objects per device list Eric Auger
2019-05-16 10:08 ` [PATCH v3 3/7] iommu/vt-d: Introduce is_downstream_to_pci_bridge helper Eric Auger
2019-05-16 10:08 ` [PATCH v3 4/7] iommu/vt-d: Handle RMRR with PCI bridge device scopes Eric Auger
2019-05-16 10:08 ` [PATCH v3 5/7] iommu/vt-d: Handle PCI bridge RMRR device scopes in intel_iommu_get_resv_regions Eric Auger
2019-05-16 10:08 ` [PATCH v3 6/7] iommu: Introduce IOMMU_RESV_DIRECT_RELAXABLE reserved memory regions Eric Auger
2019-05-16 11:16   ` Jean-Philippe Brucker
2019-05-16 11:45     ` Auger Eric
2019-05-16 12:43       ` Jean-Philippe Brucker
2019-05-16 12:58         ` Auger Eric
2019-05-16 17:06           ` Alex Williamson
2019-05-16 17:23             ` Robin Murphy
2019-05-16 12:46   ` Robin Murphy
2019-05-16 13:23     ` Auger Eric
2019-05-16 16:53       ` Alex Williamson [this message]
2019-05-16 17:53       ` Robin Murphy
2019-05-17  7:11         ` Auger Eric
2019-05-20 12:45         ` Auger Eric
2019-05-16 10:08 ` [PATCH v3 7/7] iommu/vt-d: Differentiate relaxable and non relaxable RMRRs Eric Auger
2019-05-17  4:46   ` Lu Baolu
2019-05-17  7:07     ` Auger Eric

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190516105344.5add5520@x1.home \
    --to=alex.williamson@redhat.com \
    --cc=dwmw2@infradead.org \
    --cc=eric.auger.pro@gmail.com \
    --cc=eric.auger@redhat.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=sudeep.holla@arm.com \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox