[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 4/4] iommu / pci: re-implement XEN_DOMCTL_get_device_group...
On 16.07.2019 12:16, Paul Durrant wrote: > +int iommu_get_device_group(struct domain *d, pci_sbdf_t sbdf, > + XEN_GUEST_HANDLE_64(uint32) buf, > + unsigned int max_sdevs) > +{ > + struct iommu_group *grp = NULL; > + struct pci_dev *pdev; > + unsigned int i = 0; > + > + pcidevs_lock(); > + > + for_each_pdev ( d, pdev ) > + { > + if ( pdev->sbdf.sbdf == sbdf.sbdf ) > + { > + grp = pdev->grp; > + break; > + } > + } > + > + if ( !grp ) > + goto out; > + > + for_each_pdev ( d, pdev ) > + { > + if ( xsm_get_device_group(XSM_HOOK, pdev->sbdf.sbdf) || > + pdev->grp != grp ) > + continue; > + > + if ( i < max_sdevs && > + unlikely(copy_to_guest_offset(buf, i++, &pdev->sbdf.sbdf, 1)) ) If you want to avoid breaking existing callers, you'll have to mimic here ... > -static int iommu_get_device_group( > - struct domain *d, u16 seg, u8 bus, u8 devfn, > - XEN_GUEST_HANDLE_64(uint32) buf, int max_sdevs) > -{ > - const struct domain_iommu *hd = dom_iommu(d); > - struct pci_dev *pdev; > - int group_id, sdev_id; > - u32 bdf; > - int i = 0; > - const struct iommu_ops *ops = hd->platform_ops; > - > - if ( !iommu_enabled || !ops || !ops->get_device_group_id ) > - return 0; > - > - group_id = ops->get_device_group_id(seg, bus, devfn); > - > - pcidevs_lock(); > - for_each_pdev( d, pdev ) > - { > - if ( (pdev->seg != seg) || > - ((pdev->bus == bus) && (pdev->devfn == devfn)) ) > - continue; > - > - if ( xsm_get_device_group(XSM_HOOK, (seg << 16) | (pdev->bus << 8) | > pdev->devfn) ) > - continue; > - > - sdev_id = ops->get_device_group_id(seg, pdev->bus, pdev->devfn); > - if ( (sdev_id == group_id) && (i < max_sdevs) ) > - { > - bdf = 0; > - bdf |= (pdev->bus & 0xff) << 16; > - bdf |= (pdev->devfn & 0xff) << 8; > - > - if ( unlikely(copy_to_guest_offset(buf, i, &bdf, 1)) ) ... this rather odd organization of BDF. Omitting the segment is, I think, fine, as I don't expect groups to extend past segment boundaries (and iirc neither Intel's nor AMD's implementation have any means for this to happen). 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 |