[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v12 4/6] IOMMU/x86: using a struct pci_dev* instead of SBDF
On June 27, 2016 4:17 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote: > >>> On 24.06.16 at 07:51, <quan.xu@xxxxxxxxx> wrote: > > --- a/xen/drivers/passthrough/x86/ats.c > > +++ b/xen/drivers/passthrough/x86/ats.c > > @@ -22,26 +22,34 @@ LIST_HEAD(ats_devices); bool_t __read_mostly > > ats_enabled = 0; boolean_param("ats", ats_enabled); > > > > -int enable_ats_device(int seg, int bus, int devfn, const void *iommu) > > +int enable_ats_device(const void *iommu, struct pci_dev *pci_dev) > > Is there anything preventing the second parameter to become a pointer to > const too? Afaict that would in turn eliminate the need for some of the > changes further up. > If I make the second parameter to const, then compilation fails: """ ats.c: In function 'enable_ats_device': ats.c:71:23: error: assignment discards 'const' qualifier from pointer target type [-Werror] ats_dev->pdev = pdev; ^ """ Also I will hide pci_dev as device IOTLB flush error, with changing of pci_dev. A const 'struct pci_dev *' in 'struct pci_ats_dev' is not working.. I have not verified this, correct me if I am wrong. > > { > > struct pci_ats_dev *pdev = NULL; > > u32 value; > > int pos; > > > > - pos = pci_find_ext_capability(seg, bus, devfn, PCI_EXT_CAP_ID_ATS); > > + pos = pci_find_ext_capability(pci_dev->seg, pci_dev->bus, pci_dev- > >devfn, > > + PCI_EXT_CAP_ID_ATS); > > Please add local variables seg, bus, and devfn, which will greatly reduce the > number of changes you need to do to this function (and which likely will also > produce better code). Agreed. Good idea. > > > @@ -98,7 +104,13 @@ void disable_ats_device(int seg, int bus, int > > devfn) > > For symmetry reasons this function would also get converted to taking const > struct pci_dev *. > What about ' struct pci_dev *', without const? > > @@ -120,7 +132,13 @@ struct pci_ats_dev *get_ats_device(int seg, int > > bus, int devfn) > > And this one then probably too. > Ditto. Quan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |