[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2] IOMMU: Prevent VT-d device IOTLB operations on wrong IOMMU
On 17/06/14 14:49, Jan Beulich wrote: >>>> On 17.06.14 at 14:28, <malcolm.crossley@xxxxxxxxxx> wrote: >> Optimised AMD's IOMMU code by leveraging the new IOMMU field in the ATS >> structure. > > This optimization should presumably be dropped after having done > the constification: An ATS device will always be physically connected to the same IOMMU so the optimisation should still be valid. > >> --- a/xen/drivers/passthrough/amd/iommu_cmd.c >> +++ b/xen/drivers/passthrough/amd/iommu_cmd.c >> @@ -303,8 +303,7 @@ void amd_iommu_flush_iotlb(u8 devfn, con >> if ( !pci_ats_enabled(ats_pdev->seg, ats_pdev->bus, ats_pdev->devfn) ) >> return; >> >> - iommu = find_iommu_for_device(ats_pdev->seg, >> - PCI_BDF2(ats_pdev->bus, ats_pdev->devfn)); >> + iommu = (struct amd_iommu *) ats_pdev->iommu; > > Casts like this are ugly and error prone (leaving aside that it violates > the promises "const" makes). It was either this or I have to patch several later functions to expect const struct amd_iommu, this may unravel to needing to patch many locations. > >> @@ -34,7 +35,7 @@ struct pci_ats_dev { >> extern struct list_head ats_devices; >> extern bool_t ats_enabled; >> >> -int enable_ats_device(int seg, int bus, int devfn); >> +int enable_ats_device(void *iommu, int seg, int bus, int devfn); > > The first parameter should now be "const" too. Ok, I missed that. > > Jan > So do I drop the optimisation to avoid the problems with using the const? Malcolm _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |