[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190329145101.GA27670@8bytes.org>
Date: Fri, 29 Mar 2019 15:51:01 +0100
From: Joerg Roedel <joro@...tes.org>
To: Gary R Hook <ghook@....com>
Cc: "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
Joerg Roedel <jroedel@...e.de>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] iommu/amd: Reserve exclusion range in iova-domain
Hi Gary,
On Thu, Mar 28, 2019 at 02:52:19PM +0000, Gary R Hook wrote:
> On 3/28/19 5:44 AM, Joerg Roedel wrote:
> > + if (entry->prot & (1 << 2))
>
> Could we add #define IOMMU_WRITE_EXCL (1 << 2) to amd_iommu_types.h?
Yes, I replace that magic number with a descriptive name.
> 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.
No, you are not, this could still be a problem. Until now it isn't,
because this week was the first time I have every seen an AMD IOMMU
system making use of exclusion ranges, and it doesn't have this problem.
But this problem has been in the code even before this patch and needs
to be addressed separatly. I think it is the best option to cancel IOMMU
initialization when the IVRS table defines conflicting exclusion ranges
for a single IOMMU instance.
Regards,
Joerg
Powered by blists - more mailing lists