From: Eric Auger <eric.auger@redhat.com>
To: eric.auger.pro@gmail.com, eric.auger@redhat.com, joro@8bytes.org,
iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
dwmw2@infradead.org, lorenzo.pieralisi@arm.com,
robin.murphy@arm.com, will.deacon@arm.com, hanjun.guo@linaro.org,
sudeep.holla@arm.com
Cc: alex.williamson@redhat.com
Subject: [PATCH v2 0/7] RMRR related fixes and enhancements
Date: Thu, 16 May 2019 10:47:13 +0200 [thread overview]
Message-ID: <20190516084720.10498-1-eric.auger@redhat.com> (raw)
Currently the Intel reserved region is attached to the
RMRR unit and when building the list of RMRR seen by a device
we link this unique reserved region without taking care of
potential multiple usage of this reserved region by several devices.
Also while reading the vtd spec it is unclear to me whether
the RMRR device scope referenced by an RMRR ACPI struct could
be a PCI-PCI bridge, in which case I think we also need to
check the device belongs to the PCI sub-hierarchy of the device
referenced in the scope. This would be true for device_has_rmrr()
and intel_iommu_get_resv_regions().
Last, the VFIO subsystem would need to compute the usable IOVA range
by querying the iommu_get_group_resv_regions() API. This would allow,
for instance, to report potential conflicts between the guest physical
address space and host reserved regions.
However iommu_get_group_resv_regions() currently fails to differentiate
RMRRs that are known safe for device assignment and RMRRs that must be
enforced. So we introduce a new reserved memory region type (relaxable),
reported when associated to an USB or GFX device. The last 2 patches aim
at unblocking [1] which is stuck since 4.18.
[1-5] are fixes
[6-7] are enhancements
References:
[1] [PATCH v6 0/7] vfio/type1: Add support for valid iova list management
https://patchwork.kernel.org/patch/10425309/
The two parts can be considered separately if needed.
History
1->2:
- introduce is_downstream_to_pci_bridge() in a separate patch, change param
names and add kerneldoc comment (Jacob)
- add 6,7
Eric Auger (7):
iommu: Pass a GFP flag parameter to iommu_alloc_resv_region()
iommu/vt-d: Duplicate iommu_resv_region objects per device list
iommu/vt-d: Introduce is_downstream_to_pci_bridge helper
iommu/vt-d: Handle RMRR with PCI bridge device scopes
iommu/vt-d: Handle PCI bridge RMRR device scopes in
intel_iommu_get_resv_regions
iommu: Introduce IOMMU_RESV_DIRECT_RELAXABLE reserved memory regions
iommu/vt-d: Differentiate relaxable and non relaxable RMRRs
drivers/acpi/arm64/iort.c | 3 +-
drivers/iommu/amd_iommu.c | 7 ++--
drivers/iommu/arm-smmu-v3.c | 2 +-
drivers/iommu/arm-smmu.c | 2 +-
drivers/iommu/intel-iommu.c | 82 +++++++++++++++++++++++++------------
drivers/iommu/iommu.c | 19 +++++----
include/linux/iommu.h | 8 +++-
7 files changed, 82 insertions(+), 41 deletions(-)
--
2.20.1
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next reply other threads:[~2019-05-16 8:47 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-16 8:47 Eric Auger [this message]
2019-05-16 8:47 ` [PATCH v2 1/7] iommu: Pass a GFP flag parameter to iommu_alloc_resv_region() Eric Auger
2019-05-16 8:47 ` [PATCH v2 2/7] iommu/vt-d: Duplicate iommu_resv_region objects per device list Eric Auger
2019-05-16 8:47 ` [PATCH v2 3/7] iommu/vt-d: Introduce is_downstream_to_pci_bridge helper Eric Auger
2019-05-16 8:47 ` [PATCH v2 4/7] iommu/vt-d: Handle RMRR with PCI bridge device scopes Eric Auger
2019-05-16 8:47 ` [PATCH v2 5/7] iommu/vt-d: Handle PCI bridge RMRR device scopes in intel_iommu_get_resv_regions Eric Auger
2019-05-16 8:47 ` [PATCH v2 6/7] iommu: Introduce IOMMU_RESV_DIRECT_RELAXABLE reserved memory regions Eric Auger
2019-05-16 9:32 ` Auger Eric
2019-05-16 8:47 ` [PATCH v2 7/7] iommu/vt-d: Differentiate relaxable and non relaxable RMRRs Eric Auger
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=20190516084720.10498-1-eric.auger@redhat.com \
--to=eric.auger@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=dwmw2@infradead.org \
--cc=eric.auger.pro@gmail.com \
--cc=hanjun.guo@linaro.org \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--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