| 
    
 [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  |