From: "Tian, Kevin" <kevin.tian@intel.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: "dwmw2@infradead.org" <dwmw2@infradead.org>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"shameerali.kolothum.thodi@huawei.com"
<shameerali.kolothum.thodi@huawei.com>
Subject: RE: [RFC PATCH] iommu/vt-d: Exclude known RMRRs from reserved ranges
Date: Fri, 8 Jun 2018 02:56:08 +0000 [thread overview]
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D1911FD12E@SHSMSX101.ccr.corp.intel.com> (raw)
In-Reply-To: <20180607090157.5458a2ae@w520.home>
> From: Alex Williamson [mailto:alex.williamson@redhat.com]
> Sent: Thursday, June 7, 2018 11:02 PM
>
> On Wed, 6 Jun 2018 05:29:58 +0000
> "Tian, Kevin" <kevin.tian@intel.com> wrote:
>
> > > From: Alex Williamson
> > > Sent: Wednesday, June 6, 2018 3:07 AM
> > >
> > > device_is_rmrr_locked() allows graphics and USB devices to participate
> > > in the IOMMU API despite, and ignoring their RMRR association,
> however
> > > intel_iommu_get_resv_regions() still includes the RMRRs as unavailable
> > > IOVA space for the device. Are we ignoring the RMRR for these devices
> > > or are we not? If vfio starts consuming reserved regions, perhaps we
> > > no longer need to consider devices with RMRRs excluded from the
> IOMMU
> > > API interface, but we have a transitional problem that these allowed
> > > devices still impose incompatible IOVA restrictions per the reserved
> > > region reporting. Dive further down the rabbit hole by also ignoring
> > > RMRRs for "known" devices in the reserved region reporting.
> >
> > intel_iommu_get_resv_regions is used not just for IOMMU API. I'm
> > afraid doing so will make RMRR completely ignored, even in normal
> > DMA API path...
>
> Well, I'm a bit stuck then, we have existing IOMMU API users that
> ignore these ranges and in fact conflict with these ranges blocking us
> from restricting mappings within these ranges. My impression is that
> IOMMU reserved ranges should only be ranges which have some
> fundamental
> limitation in the IOMMU, not simply mappings for which firmware has
> requested an identity mapped range. The latter should simply be a
> pre-allocation of the IOVA space, for the cases where we choose to
> honor the RMRR. Thanks,
>
Then possibly need introduce a different interface for pre-allocation
scenario, if above definition of reserved ranges is agreed. Currently
two categories are both called reserved resources, e.g. IOMMU_RESV
_DIRECT for rmrr and IOMMU_RESV_MSI for MSI...
Thanks
Kevin
next prev parent reply other threads:[~2018-06-08 2:56 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-05 19:06 [RFC PATCH] iommu/vt-d: Exclude known RMRRs from reserved ranges Alex Williamson
2018-06-06 4:27 ` Jacob Pan
2018-06-06 5:29 ` Tian, Kevin
2018-06-07 15:01 ` Alex Williamson
2018-06-08 2:56 ` Tian, Kevin [this message]
2018-07-03 10:46 ` Shameerali Kolothum Thodi
2018-07-03 10:52 ` David Woodhouse
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=AADFC41AFE54684AB9EE6CBC0274A5D1911FD12E@SHSMSX101.ccr.corp.intel.com \
--to=kevin.tian@intel.com \
--cc=alex.williamson@redhat.com \
--cc=dwmw2@infradead.org \
--cc=iommu@lists.linux-foundation.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=shameerali.kolothum.thodi@huawei.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;
as well as URLs for NNTP newsgroup(s).