[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.