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