* [Xen-devel] [PATCH v2] AMD/IOMMU: don't "add" IOMMUs
@ 2019-06-04 12:15 Jan Beulich
2019-06-26 12:30 ` Andrew Cooper
0 siblings, 1 reply; 3+ messages in thread
From: Jan Beulich @ 2019-06-04 12:15 UTC (permalink / raw)
To: xen-devel; +Cc: Brian Woods, Suravee Suthikulpanit
For find_iommu_for_device() to consistently (independent of ACPI tables)
return NULL for the PCI devices corresponding to IOMMUs, make sure
IOMMUs don't get mapped to themselves by ivrs_mappings[].
While amd_iommu_add_device() won't be called for IOMMUs from
pci_add_device(), as IOMMUs have got marked r/o,
_setup_hwdom_pci_devices() calls there nevertheless. Avoid issuing the
bogus debugging only "No iommu for ...; cannot be handed to ..." log
message as well as the non-debugging "setup ... for ... failed (-19)"
one.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: Also change add_ivrs_mapping_entry() and find_iommu_for_device()
(I should have checked why I didn't recall seeing the log messages
on the older AMD system before sending v1). Only return success
from amd_iommu_add_device() for Dom0.
---
The situation for host bridges is similar: Behavior currently depends
on whether they're within the device ranges reported by IVRS entries.
On the older system 0000:00:00.0 is included, while on the newer one
it's not. Whether it gets its device table entry point to Dom0's page
tables depends on this.
--- a/xen/drivers/passthrough/amd/iommu_acpi.c
+++ b/xen/drivers/passthrough/amd/iommu_acpi.c
@@ -81,8 +81,8 @@ static void __init add_ivrs_mapping_entr
ivrs_mappings[alias_id].intremap_inuse = shared_intremap_inuse;
}
}
- /* assgin iommu hardware */
- ivrs_mappings[bdf].iommu = iommu;
+ /* Assign IOMMU hardware, but don't map an IOMMU by itself. */
+ ivrs_mappings[bdf].iommu = iommu->bdf != bdf ? iommu : NULL;
}
static struct amd_iommu * __init find_iommu_from_bdf_cap(
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -43,7 +43,7 @@ struct amd_iommu *find_iommu_for_device(
{
unsigned int bd0 = bdf & ~PCI_FUNC(~0);
- if ( ivrs_mappings[bd0].iommu )
+ if ( ivrs_mappings[bd0].iommu && ivrs_mappings[bd0].iommu->bdf != bdf )
{
struct ivrs_mappings tmp = ivrs_mappings[bd0];
@@ -424,6 +424,11 @@ static int amd_iommu_add_device(u8 devfn
return -EINVAL;
bdf = PCI_BDF2(pdev->bus, pdev->devfn);
+
+ for_each_amd_iommu(iommu)
+ if ( pdev->seg == iommu->seg && bdf == iommu->bdf )
+ return is_hardware_domain(pdev->domain) ? 0 : -ENODEV;
+
iommu = find_iommu_for_device(pdev->seg, bdf);
if ( unlikely(!iommu) )
{
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Xen-devel] [PATCH v2] AMD/IOMMU: don't "add" IOMMUs
2019-06-04 12:15 [Xen-devel] [PATCH v2] AMD/IOMMU: don't "add" IOMMUs Jan Beulich
@ 2019-06-26 12:30 ` Andrew Cooper
2019-06-26 16:46 ` Woods, Brian
0 siblings, 1 reply; 3+ messages in thread
From: Andrew Cooper @ 2019-06-26 12:30 UTC (permalink / raw)
To: Jan Beulich, xen-devel; +Cc: Brian Woods, Suravee Suthikulpanit
On 04/06/2019 13:15, Jan Beulich wrote:
> For find_iommu_for_device() to consistently (independent of ACPI tables)
> return NULL for the PCI devices corresponding to IOMMUs, make sure
> IOMMUs don't get mapped to themselves by ivrs_mappings[].
>
> While amd_iommu_add_device() won't be called for IOMMUs from
> pci_add_device(), as IOMMUs have got marked r/o,
> _setup_hwdom_pci_devices() calls there nevertheless. Avoid issuing the
> bogus debugging only "No iommu for ...; cannot be handed to ..." log
> message as well as the non-debugging "setup ... for ... failed (-19)"
> one.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Xen-devel] [PATCH v2] AMD/IOMMU: don't "add" IOMMUs
2019-06-26 12:30 ` Andrew Cooper
@ 2019-06-26 16:46 ` Woods, Brian
0 siblings, 0 replies; 3+ messages in thread
From: Woods, Brian @ 2019-06-26 16:46 UTC (permalink / raw)
To: Andrew Cooper
Cc: xen-devel, Woods, Brian, Suthikulpanit, Suravee, Jan Beulich
On Wed, Jun 26, 2019 at 01:30:28PM +0100, Andy Cooper wrote:
> On 04/06/2019 13:15, Jan Beulich wrote:
> > For find_iommu_for_device() to consistently (independent of ACPI tables)
> > return NULL for the PCI devices corresponding to IOMMUs, make sure
> > IOMMUs don't get mapped to themselves by ivrs_mappings[].
> >
> > While amd_iommu_add_device() won't be called for IOMMUs from
> > pci_add_device(), as IOMMUs have got marked r/o,
> > _setup_hwdom_pci_devices() calls there nevertheless. Avoid issuing the
> > bogus debugging only "No iommu for ...; cannot be handed to ..." log
> > message as well as the non-debugging "setup ... for ... failed (-19)"
> > one.
> >
> > Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Brian Woods <brian.woods@amd.com>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel
--
Brian Woods
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-06-26 16:47 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-06-04 12:15 [Xen-devel] [PATCH v2] AMD/IOMMU: don't "add" IOMMUs Jan Beulich
2019-06-26 12:30 ` Andrew Cooper
2019-06-26 16:46 ` Woods, Brian
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.