Hi Baolu,
On 2021/4/19 21:33, Lu Baolu wrote:
Hi Keqian,Right. If I understand you correct, actually that is what this series does.
On 2021/4/19 17:32, Keqian Zhu wrote:
Yes, I don't think up a scenario except dirty tracking.+EXPORT_SYMBOL_GPL(iommu_split_block);Do you really have any consumers of this interface other than the dirty
bit tracking? If not, I don't suggest to make this as a generic IOMMU
interface.
There is an implicit requirement for such interfaces. The
iommu_map/unmap(iova, size) shouldn't be called at the same time.
Currently there's no such sanity check in the iommu core. A poorly
written driver could mess up the kernel by misusing this interface.
Indeed, we'd better not make them as a generic interface.
Do you have any suggestion that underlying iommu drivers can share these code but
not make it as a generic iommu interface?
I have a not so good idea. Make the "split" interfaces as a static function, and
transfer the function pointer to start_dirty_log. But it looks weird and inflexible.
I understand splitting/merging super pages is an optimization, but not a
functional requirement. So is it possible to let the vendor iommu driver
decide whether splitting super pages when starting dirty bit tracking
and the opposite operation during when stopping it? The requirement for
We realized split/merge in IOMMU core layer, but don't force vendor driver to use it.
The problem is that when we expose these interfaces to vendor IOMMU driver, will also
expose them to upper driver.
upper layer is that starting/stopping dirty bit tracking andOK, I will explicitly add the hints. Thanks.
mapping/unmapping are mutually exclusive.
Thanks,
Keqian
On the other hand, if a driver calls map/unmap with split/merge at the same time,
it's a bug of driver, it should follow the rule.
Best regards,
baolu
.