Re: IOMMU page table freeing

[Paul Durrant <xadimgnik@xxxxxxxxx>]

On 10/08/2021 14:37, Jan Beulich wrote:
> Hello,
>
> while I don't expect this case to occur often in practice, for
> superpage support we will need to be able to correctly free a
> page table (hierarchy) after replacing its mapping range by a
> superpage. Following P2M by carrying out an immediate iotlb flush
> prior to synchronously freeing the memory looks, to me at least,
> out of question as an option - the latest when considering ATS
> the flush may simply take too long.
>
> Making use of RCU doesn't look like a good option either, as
> this would require callers of map/unmap + flush to enclose the
> whole group of operations in an RCU-read-locked region. Yet I
> think we want to avoid to concern callers with details of the
> implementation of the IOMMU operations.
>
> Which I think leaves deferring the freeing to a softirq or
> tasklet, of which the latter - to me - would seem the better
> (easier) choice. If you have any alternative / better suggestions
> I'd appreciate a reply; ideally you would also reply if you
> simply agree.
I agree, I can't think of a more preferable option.

  Paul

> FAOD I don't think I want to make an attempt just yet to care
> about the case of flushes getting carried out asynchronously:
> That would require a means to signal to the freeing function
> which prior page table pages are ready to be freed. For now I'm
> rather considering to merely accumulate these pages simply on a
> (perhaps per-CPU) list, for the tasklet handler to consume.
>
> Thanks, Jan