Re: [PATCH] iommu/vt-d: gracefully handle DMAR units with no supported address widths
On Wed, 2021-01-20 at 18:04 +0100, Greg KH wrote:
> I tried applying these to 5.4, 4.19, and 4.14, and they all fail to
> build:
>
> drivers/iommu/dmar.c: In function ‘free_iommu’:
> drivers/iommu/dmar.c:1140:35: error: ‘struct intel_iommu’ has no member named
> ‘drhd’
> 1140 | if (intel_iommu_enabled && !iommu->drhd->ignored) {
> | ^~
>
> So if you could provide a working set of patches backported, I will be
> glad to queue them up.
Thanks.
I'm just heckling at Sam's backport of those, and we'll post tested
patches as soon as we're done.
smime.p7s
Description: S/MIME cryptographic signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/vt-d: gracefully handle DMAR units with no supported address widths
On Wed, Jan 20, 2021 at 03:55:05PM +, David Woodhouse wrote:
> On Wed, 2021-01-20 at 13:06 +0100, Greg KH wrote:
> > On Wed, Jan 20, 2021 at 09:42:43AM +, David Woodhouse wrote:
> > > On Thu, 2020-09-24 at 15:08 +0100, David Woodhouse wrote:
> > > > From: David Woodhouse
> > > >
> > > > Instead of bailing out completely, such a unit can still be used for
> > > > interrupt remapping.
> > > >
> > > > Signed-off-by: David Woodhouse
> > >
> > > Could we have this for stable too please, along with the trivial
> > > subsequent fixup. They are:
> > >
> > > c40c1018 ("iommu/vt-d: Gracefully handle DMAR units with no supported
> > > address widths")
> > > 9def3b1a07c4 ("iommu/vt-d: Don't dereference iommu_device if IOMMU_API is
> > > not built")
> > >
> > > They apply fairly straightforwardly when backported; let me know if you
> > > want us to send patches.
> >
> > What stable kernel(s) do you want this in? The above patches are
> > already in 5.10.
>
> It's a fairly simple bug fix, to still use a given IOMMU for interrupt
> remapping even if it can't be used for DMA mapping.
>
> Those features are somewhat orthogonal, and it was wrong for the kernel
> to bail out on the IOMMU hardware completely.
>
> The interrupt remapping support is what's required for Intel boxes (or
> VMs) to run with more than 255 CPUs. It should be fairly simple to fix
> the same bug at least as far back as 4.14.
I tried applying these to 5.4, 4.19, and 4.14, and they all fail to
build:
drivers/iommu/dmar.c: In function ‘free_iommu’:
drivers/iommu/dmar.c:1140:35: error: ‘struct intel_iommu’ has no member named
‘drhd’
1140 | if (intel_iommu_enabled && !iommu->drhd->ignored) {
| ^~
So if you could provide a working set of patches backported, I will be
glad to queue them up.
thanks,
greg k-h
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/vt-d: gracefully handle DMAR units with no supported address widths
On Wed, 2021-01-20 at 13:06 +0100, Greg KH wrote:
> On Wed, Jan 20, 2021 at 09:42:43AM +, David Woodhouse wrote:
> > On Thu, 2020-09-24 at 15:08 +0100, David Woodhouse wrote:
> > > From: David Woodhouse
> > >
> > > Instead of bailing out completely, such a unit can still be used for
> > > interrupt remapping.
> > >
> > > Signed-off-by: David Woodhouse
> >
> > Could we have this for stable too please, along with the trivial
> > subsequent fixup. They are:
> >
> > c40c1018 ("iommu/vt-d: Gracefully handle DMAR units with no supported
> > address widths")
> > 9def3b1a07c4 ("iommu/vt-d: Don't dereference iommu_device if IOMMU_API is
> > not built")
> >
> > They apply fairly straightforwardly when backported; let me know if you
> > want us to send patches.
>
> What stable kernel(s) do you want this in? The above patches are
> already in 5.10.
It's a fairly simple bug fix, to still use a given IOMMU for interrupt
remapping even if it can't be used for DMA mapping.
Those features are somewhat orthogonal, and it was wrong for the kernel
to bail out on the IOMMU hardware completely.
The interrupt remapping support is what's required for Intel boxes (or
VMs) to run with more than 255 CPUs. It should be fairly simple to fix
the same bug at least as far back as 4.14.
smime.p7s
Description: S/MIME cryptographic signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/vt-d: gracefully handle DMAR units with no supported address widths
On Wed, Jan 20, 2021 at 09:42:43AM +, David Woodhouse wrote:
> On Thu, 2020-09-24 at 15:08 +0100, David Woodhouse wrote:
> > From: David Woodhouse
> >
> > Instead of bailing out completely, such a unit can still be used for
> > interrupt remapping.
> >
> > Signed-off-by: David Woodhouse
>
> Could we have this for stable too please, along with the trivial
> subsequent fixup. They are:
>
> c40c1018 ("iommu/vt-d: Gracefully handle DMAR units with no supported
> address widths")
> 9def3b1a07c4 ("iommu/vt-d: Don't dereference iommu_device if IOMMU_API is not
> built")
>
> They apply fairly straightforwardly when backported; let me know if you
> want us to send patches.
What stable kernel(s) do you want this in? The above patches are
already in 5.10.
thanks,
greg k-h
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/vt-d: gracefully handle DMAR units with no supported address widths
On Thu, 2020-09-24 at 15:08 +0100, David Woodhouse wrote:
> From: David Woodhouse
>
> Instead of bailing out completely, such a unit can still be used for
> interrupt remapping.
>
> Signed-off-by: David Woodhouse
Could we have this for stable too please, along with the trivial
subsequent fixup. They are:
c40c1018 ("iommu/vt-d: Gracefully handle DMAR units with no supported
address widths")
9def3b1a07c4 ("iommu/vt-d: Don't dereference iommu_device if IOMMU_API is not
built")
They apply fairly straightforwardly when backported; let me know if you
want us to send patches.
smime.p7s
Description: S/MIME cryptographic signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/vt-d: gracefully handle DMAR units with no supported address widths
On Fri, Sep 25, 2020 at 09:52:31AM +0800, Lu Baolu wrote: > > On 9/24/20 10:08 PM, David Woodhouse wrote: > > From: David Woodhouse > > > > Instead of bailing out completely, such a unit can still be used for > > interrupt remapping. > > Reviewed-by: Lu Baolu Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/vt-d: gracefully handle DMAR units with no supported address widths
On 9/24/20 10:08 PM, David Woodhouse wrote:
From: David Woodhouse
Instead of bailing out completely, such a unit can still be used for
interrupt remapping.
Reviewed-by: Lu Baolu
Best regards,
baolu
Signed-off-by: David Woodhouse
---
drivers/iommu/intel/dmar.c | 46 +-
1 file changed, 31 insertions(+), 15 deletions(-)
diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c
index 93e6345f3414..4420a759f095 100644
--- a/drivers/iommu/intel/dmar.c
+++ b/drivers/iommu/intel/dmar.c
@@ -1024,8 +1024,8 @@ static int alloc_iommu(struct dmar_drhd_unit *drhd)
{
struct intel_iommu *iommu;
u32 ver, sts;
- int agaw = 0;
- int msagaw = 0;
+ int agaw = -1;
+ int msagaw = -1;
int err;
if (!drhd->reg_base_addr) {
@@ -1050,17 +1050,28 @@ static int alloc_iommu(struct dmar_drhd_unit *drhd)
}
err = -EINVAL;
- agaw = iommu_calculate_agaw(iommu);
- if (agaw < 0) {
- pr_err("Cannot get a valid agaw for iommu (seq_id = %d)\n",
- iommu->seq_id);
- goto err_unmap;
- }
- msagaw = iommu_calculate_max_sagaw(iommu);
- if (msagaw < 0) {
- pr_err("Cannot get a valid max agaw for iommu (seq_id = %d)\n",
- iommu->seq_id);
- goto err_unmap;
+ if (cap_sagaw(iommu->cap) == 0) {
+ pr_info("%s: No supported address widths. Not attempting DMA
translation.\n",
+ iommu->name);
+ drhd->ignored = 1;
+ }
+
+ if (!drhd->ignored) {
+ agaw = iommu_calculate_agaw(iommu);
+ if (agaw < 0) {
+ pr_err("Cannot get a valid agaw for iommu (seq_id =
%d)\n",
+ iommu->seq_id);
+ drhd->ignored = 1;
+ }
+ }
+ if (!drhd->ignored) {
+ msagaw = iommu_calculate_max_sagaw(iommu);
+ if (msagaw < 0) {
+ pr_err("Cannot get a valid max agaw for iommu (seq_id =
%d)\n",
+ iommu->seq_id);
+ drhd->ignored = 1;
+ agaw = -1;
+ }
}
iommu->agaw = agaw;
iommu->msagaw = msagaw;
@@ -1087,7 +1098,12 @@ static int alloc_iommu(struct dmar_drhd_unit *drhd)
raw_spin_lock_init(>register_lock);
- if (intel_iommu_enabled) {
+ /*
+* This is only for hotplug; at boot time intel_iommu_enabled won't
+* be set yet. When intel_iommu_init() runs, it registers the units
+* present at boot time, then sets intel_iommu_enabled.
+*/
+ if (intel_iommu_enabled && !drhd->ignored) {
err = iommu_device_sysfs_add(>iommu, NULL,
intel_iommu_groups,
"%s", iommu->name);
@@ -1117,7 +1133,7 @@ static int alloc_iommu(struct dmar_drhd_unit *drhd)
static void free_iommu(struct intel_iommu *iommu)
{
- if (intel_iommu_enabled) {
+ if (intel_iommu_enabled && iommu->iommu.ops) {
iommu_device_unregister(>iommu);
iommu_device_sysfs_remove(>iommu);
}
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH] iommu/vt-d: gracefully handle DMAR units with no supported address widths
From: David Woodhouse
Instead of bailing out completely, such a unit can still be used for
interrupt remapping.
Signed-off-by: David Woodhouse
---
drivers/iommu/intel/dmar.c | 46 +-
1 file changed, 31 insertions(+), 15 deletions(-)
diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c
index 93e6345f3414..4420a759f095 100644
--- a/drivers/iommu/intel/dmar.c
+++ b/drivers/iommu/intel/dmar.c
@@ -1024,8 +1024,8 @@ static int alloc_iommu(struct dmar_drhd_unit *drhd)
{
struct intel_iommu *iommu;
u32 ver, sts;
- int agaw = 0;
- int msagaw = 0;
+ int agaw = -1;
+ int msagaw = -1;
int err;
if (!drhd->reg_base_addr) {
@@ -1050,17 +1050,28 @@ static int alloc_iommu(struct dmar_drhd_unit *drhd)
}
err = -EINVAL;
- agaw = iommu_calculate_agaw(iommu);
- if (agaw < 0) {
- pr_err("Cannot get a valid agaw for iommu (seq_id = %d)\n",
- iommu->seq_id);
- goto err_unmap;
- }
- msagaw = iommu_calculate_max_sagaw(iommu);
- if (msagaw < 0) {
- pr_err("Cannot get a valid max agaw for iommu (seq_id = %d)\n",
- iommu->seq_id);
- goto err_unmap;
+ if (cap_sagaw(iommu->cap) == 0) {
+ pr_info("%s: No supported address widths. Not attempting DMA
translation.\n",
+ iommu->name);
+ drhd->ignored = 1;
+ }
+
+ if (!drhd->ignored) {
+ agaw = iommu_calculate_agaw(iommu);
+ if (agaw < 0) {
+ pr_err("Cannot get a valid agaw for iommu (seq_id =
%d)\n",
+ iommu->seq_id);
+ drhd->ignored = 1;
+ }
+ }
+ if (!drhd->ignored) {
+ msagaw = iommu_calculate_max_sagaw(iommu);
+ if (msagaw < 0) {
+ pr_err("Cannot get a valid max agaw for iommu (seq_id =
%d)\n",
+ iommu->seq_id);
+ drhd->ignored = 1;
+ agaw = -1;
+ }
}
iommu->agaw = agaw;
iommu->msagaw = msagaw;
@@ -1087,7 +1098,12 @@ static int alloc_iommu(struct dmar_drhd_unit *drhd)
raw_spin_lock_init(>register_lock);
- if (intel_iommu_enabled) {
+ /*
+* This is only for hotplug; at boot time intel_iommu_enabled won't
+* be set yet. When intel_iommu_init() runs, it registers the units
+* present at boot time, then sets intel_iommu_enabled.
+*/
+ if (intel_iommu_enabled && !drhd->ignored) {
err = iommu_device_sysfs_add(>iommu, NULL,
intel_iommu_groups,
"%s", iommu->name);
@@ -1117,7 +1133,7 @@ static int alloc_iommu(struct dmar_drhd_unit *drhd)
static void free_iommu(struct intel_iommu *iommu)
{
- if (intel_iommu_enabled) {
+ if (intel_iommu_enabled && iommu->iommu.ops) {
iommu_device_unregister(>iommu);
iommu_device_sysfs_remove(>iommu);
}
--
2.17.1
smime.p7s
Description: S/MIME cryptographic signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
