|
[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |