From: "joro@8bytes.org" <joro@8bytes.org>
To: "Sironi, Filippo" <sironi@amazon.de>
Cc: "Serebrin, Benjamin" <serebrin@amazon.com>,
"sebott@amazon.de" <sebott@amazon.de>,
"robin.murphy@arm.com" <robin.murphy@arm.com>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>
Subject: Re: [PATCH v2 0/3] iommu/amd: I/O VA address limits
Date: Wed, 22 Jul 2020 16:00:30 +0200 [thread overview]
Message-ID: <20200722140029.GI27672@8bytes.org> (raw)
In-Reply-To: <88c26491f2e429380028e9c04755965bc3f0341a.camel@amazon.de>
On Wed, Jul 22, 2020 at 12:34:57PM +0000, Sironi, Filippo wrote:
> On Wed, 2020-07-22 at 14:19 +0200, joro@8bytes.org wrote:
> I wouldn't be surprised if a PCIe device raises a PCIe SERR if it is
> asked to do DMA beyond its abilities.
Yeah, but that would also make it impossible to safely assign the device
to any untrusted entity, like a guest of user-space driver.
> I think that this discussion is orthogonal wrt the spirit of the
> patches. They are actually adding a few bits to the AMD IOMMU driver
> (and propagating them to the right places) to implement a portion of the
> specification that wasn't implemented, i.e., relying on the IVRS table.
> These patches are valuable independently on the content of the IVRS
> table, be it 32, 48, or 64 bits.
You are right from a technical point of view, and the patches are as
well. The problem I see is that there are a lot of systems out there
with an AMD IOMMU and possibly broken ACPI tables. And if the driver
starts checking this field now it is possible that it breaks formerly
working setups.
So doing this needs a strong reason, like upcoming hardware that has
lower limits in the supported address space size than before. The
use-case you have described is not a strong enough reason to take the
risk.
Regards,
Joerg
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2020-07-22 14:00 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-05 14:56 [PATCH 0/3] iommu/amd: I/O VA address limits Sebastian Ott via iommu
2020-06-05 14:56 ` [PATCH 1/3] iommu/amd: Parse supported address sizes from IVRS Sebastian Ott via iommu
2020-06-05 14:56 ` [PATCH 2/3] iommu/amd: Restrict aperture for domains to conform with IVRS Sebastian Ott via iommu
2020-06-05 14:56 ` [PATCH 3/3] iommu/amd: Actually enforce geometry aperture Sebastian Ott via iommu
2020-06-30 9:30 ` Joerg Roedel
2020-06-30 22:46 ` [PATCH v2 0/3] iommu/amd: I/O VA address limits Sebastian Ott via iommu
2020-06-30 22:46 ` [PATCH v2 1/3] iommu/amd: Parse supported address sizes from IVRS Sebastian Ott via iommu
2020-06-30 22:46 ` [PATCH v2 2/3] iommu/amd: Restrict aperture for domains to conform with IVRS Sebastian Ott via iommu
2020-06-30 22:46 ` [PATCH v2 3/3] iommu/amd: Actually enforce geometry aperture Sebastian Ott via iommu
2020-07-10 12:31 ` [PATCH v2 0/3] iommu/amd: I/O VA address limits Joerg Roedel
2020-07-17 9:20 ` Sebastian Ott via iommu
2020-07-17 9:47 ` Robin Murphy
2020-07-17 13:22 ` Sironi, Filippo via iommu
2020-07-17 14:36 ` Robin Murphy
2020-07-17 15:15 ` Sironi, Filippo via iommu
2020-07-22 12:19 ` joro
2020-07-22 12:34 ` Sironi, Filippo via iommu
2020-07-22 14:00 ` joro [this message]
2020-06-24 16:09 ` [PATCH " Sebastian Ott via iommu
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=20200722140029.GI27672@8bytes.org \
--to=joro@8bytes.org \
--cc=iommu@lists.linux-foundation.org \
--cc=robin.murphy@arm.com \
--cc=sebott@amazon.de \
--cc=serebrin@amazon.com \
--cc=sironi@amazon.de \
/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).