[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 2/2] iommu: elide flushing for higher order map/unmap operations



>>> On 30.11.18 at 13:49, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 30/11/2018 10:45, Paul Durrant wrote:
>> +enum iommu_flush_type
>> +{
>> +    IOMMU_FLUSH_none, /* no flush required */
>> +    IOMMU_FLUSH_added, /* no modified entries, just additional entries */
> 
> IOMMU_FLUSH_invalid ?  I think it is more descriptive of the scenario in
> which it is used.

This reads in a pretty misleading way to me. IOMMU_FLUSH_new
or IOMMU_FLUSH_new_ents perhaps? Otoh I was quite okay with
the name Paul had chosen.

>> @@ -177,7 +184,8 @@ struct iommu_ops {
>>       * other by the caller in order to have meaningful results.
>>       */
>>      int __must_check (*map_page)(struct domain *d, dfn_t dfn, mfn_t mfn,
>> -                                 unsigned int flags);
>> +                                 unsigned int flags,
>> +                                 enum iommu_flush_type *flush_type);
> 
> Maintaining the flush type by pointer is quite awkward.
> 
> How about folding a positive flush type in with negative errors?  i.e.
> map_page() becomes < 0 on error, 0 for success/no flush and >0 for
> success/w flush.
> 
> I think the result would be rather cleaner to read.

It would, but mapping operations with higher orders may fail
_and_ require flushing.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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