From: Gary R Hook <ghook@amd.com>
To: Joerg Roedel <joro@8bytes.org>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>
Cc: Joerg Roedel <jroedel@suse.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] iommu/amd: Reserve exclusion range in iova-domain
Date: Thu, 28 Mar 2019 14:52:19 +0000 [thread overview]
Message-ID: <3850c381-30d6-b2a3-d976-66939d8e612a@amd.com> (raw)
In-Reply-To: <20190328104459.18589-1-joro@8bytes.org>
On 3/28/19 5:44 AM, Joerg Roedel wrote:
> From: Joerg Roedel <jroedel@suse.de>
>
> If a device has an exclusion range specified in the IVRS
> table, this region needs to be reserved in the iova-domain
> of that device. This hasn't happened until now and can cause
> data corruption on data transfered with these devices.
>
> Treat exclusion ranges as reserved regions in the iommu-core
> to fix the problem.
>
> Fixes: be2a022c0dd0 ('x86, AMD IOMMU: add functions to parse IOMMU memory mapping requirements for devices')
> Signed-off-by: Joerg Roedel <jroedel@suse.de>
> ---
> drivers/iommu/amd_iommu.c | 9 ++++++---
> drivers/iommu/amd_iommu_init.c | 7 ++++---
> 2 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
> index 21cb088d6687..2a8d2806d5b9 100644
> --- a/drivers/iommu/amd_iommu.c
> +++ b/drivers/iommu/amd_iommu.c
> @@ -3169,21 +3169,24 @@ static void amd_iommu_get_resv_regions(struct device *dev,
> return;
>
> list_for_each_entry(entry, &amd_iommu_unity_map, list) {
> + int type, prot = 0;
> size_t length;
> - int prot = 0;
>
> if (devid < entry->devid_start || devid > entry->devid_end)
> continue;
>
> + type = IOMMU_RESV_DIRECT;
> length = entry->address_end - entry->address_start;
> if (entry->prot & IOMMU_PROT_IR)
> prot |= IOMMU_READ;
> if (entry->prot & IOMMU_PROT_IW)
> prot |= IOMMU_WRITE;
> + if (entry->prot & (1 << 2))
Could we add
#define IOMMU_WRITE_EXCL (1 << 2)
to amd_iommu_types.h?
The bit is documented in the AMD IOMMU spec, so this seems safe...
> + /* Exclusion range */
> + type = IOMMU_RESV_RESERVED;
>
> region = iommu_alloc_resv_region(entry->address_start,
> - length, prot,
> - IOMMU_RESV_DIRECT);
> + length, prot, type);
> if (!region) {
> dev_err(dev, "Out of memory allocating dm-regions\n");
> return;
> diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
> index f773792d77fd..1b1378619fc9 100644
> --- a/drivers/iommu/amd_iommu_init.c
> +++ b/drivers/iommu/amd_iommu_init.c
> @@ -2013,6 +2013,9 @@ static int __init init_unity_map_range(struct ivmd_header *m)
> if (e == NULL)
> return -ENOMEM;
>
> + if (m->flags & IVMD_FLAG_EXCL_RANGE)
> + init_exclusion_range(m);
> +
> switch (m->type) {
> default:
> kfree(e);
> @@ -2059,9 +2062,7 @@ static int __init init_memory_definitions(struct acpi_table_header *table)
>
> while (p < end) {
> m = (struct ivmd_header *)p;
> - if (m->flags & IVMD_FLAG_EXCL_RANGE)
> - init_exclusion_range(m);
> - else if (m->flags & IVMD_FLAG_UNITY_MAP)
> + if (m->flags & (IVMD_FLAG_UNITY_MAP | IVMD_FLAG_EXCL_RANGE))
> init_unity_map_range(m);
>
> p += m->length;
>
The problem I see here is that if, for some untold reason, there is more
than one exclusion range emitted, where only the last one wins in the
hardware, we'd still end up with more than one range reserved in the
IOVA tree. Clearly, this is extremely unlikely, but wouldn't we want to
protect against that sort of misuse/mistake?
I could be missing something.
next prev parent reply other threads:[~2019-03-28 14:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-28 10:44 Joerg Roedel
2019-03-28 14:52 ` Gary R Hook [this message]
2019-03-29 14:51 ` Joerg Roedel
2019-03-29 15:06 ` Gary R Hook
2019-03-30 4:56 ` Stuart Hayes
2019-03-30 4:49 Stuart Hayes
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=3850c381-30d6-b2a3-d976-66939d8e612a@amd.com \
--to=ghook@amd.com \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--cc=jroedel@suse.de \
--cc=linux-kernel@vger.kernel.org \
/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
all inboxes | Powered by JetHome®