|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 3/4] iommu: introduce iommu_groups
On 16.07.2019 12:16, Paul Durrant wrote:
> --- a/xen/drivers/passthrough/Makefile
> +++ b/xen/drivers/passthrough/Makefile
> @@ -4,6 +4,7 @@ subdir-$(CONFIG_X86) += x86
> subdir-$(CONFIG_ARM) += arm
>
> obj-y += iommu.o
> +obj-$(CONFIG_HAS_PCI) += groups.o
I assume this dependency on PCI is temporary, as there's nothing
inherently tying grouping of devices to PCI (afaict)?
> +int iommu_group_assign(struct pci_dev *pdev, void *arg)
> +{
> + const struct iommu_ops *ops = iommu_get_ops();
> + int id;
> + struct iommu_group *grp;
> +
> + if ( !ops->get_device_group_id )
> + return 0;
With you making groups mandatory (i.e. even solitary devices getting
put in a group), shouldn't this be -EOPNOTSUPP, maybe accompanied by
ASSERT_UNREACHABLE()?
> + id = ops->get_device_group_id(pdev->seg, pdev->bus, pdev->devfn);
> + if ( id < 0 )
> + return -ENODATA;
> +
> + grp = get_iommu_group(id);
> + if ( !grp )
> + return -ENOMEM;
> +
> + if ( iommu_verbose )
> + printk(XENLOG_INFO "Assign %04x:%02x:%02x.%u -> IOMMU group %x\n",
> + pdev->seg, pdev->bus, PCI_SLOT(pdev->devfn),
> + PCI_FUNC(pdev->devfn), grp->id);
I'm not overly happy about this new logging: On modern systems a
debug level run is already rather verbose about PCI devices,
simply because there are so many. If my hope to not see individual
devices put in groups is not going to be fulfilled, can we at least
try to come to some agreement that certain devices which can't
sensibly be passed through won't be assigned groups (and hence
won't produce output here)? A group-less device then would
automatically be unable to have its owner changed.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |