On 16/08/2019 19:12, Rob Clark wrote:
On Fri, Aug 16, 2019 at 9:58 AM Robin Murphy <robin.murphy@xxxxxxx> wrote:
Hi Jordan,
On 15/08/2019 16:33, Jordan Crouse wrote:
On Wed, Aug 07, 2019 at 04:21:38PM -0600, Jordan Crouse wrote:
(Sigh, resend. I freaked out my SMTP server)
This is part of an ongoing evolution for enabling split pagetable support for
arm-smmu. Previous versions can be found [1].
In the discussion for v2 Robin pointed out that this is a very Adreno specific
use case and that is exactly true. Not only do we want to configure and use a
pagetable in the TTBR1 space, we also want to configure the TTBR0 region but
not allocate a pagetable for it or touch it until the GPU hardware does so. As
much as I want it to be a generic concept it really isn't.
This revision leans into that idea. Most of the same io-pgtable code is there
but now it is wrapped as an Adreno GPU specific format that is selected by the
compatible string in the arm-smmu device.
Additionally, per Robin's suggestion we are skipping creating a TTBR0 pagetable
to save on wasted memory.
This isn't as clean as I would like it to be but I think that this is a better
direction than trying to pretend that the generic format would work.
I'm tempting fate by posting this and then taking some time off, but I wanted
to try to kick off a conversation or at least get some flames so I can try to
refine this again next week. Please take a look and give some advice on the
direction.
Will, Robin -
Modulo the impl changes from Robin, do you think that using a dedicated
pagetable format is the right approach for supporting split pagetables for the
Adreno GPU?
How many different Adreno drivers would benefit from sharing it?
Hypothetically everything back to a3xx, so I *could* see usefulness of
this in qcom_iommu (or maybe even msm-iommu). OTOH maybe with
"modularizing" arm-smmu we could re-combine qcom_iommu and arm-smmu.
Indeed, that's certainly something I'm planning to investigate as a
future refactoring step.
And as a practical matter, I'm not sure if anyone will get around to
backporting per-context pagetables as far back as a3xx.
BR,
-R
The more I come back to this, the more I'm convinced that io-pgtable
should focus on the heavy lifting of pagetable management - the code
that nobody wants to have to write at all, let alone more than once -
and any subtleties which aren't essential to that should be pushed back
into whichever callers actually care. Consider that already, literally
no caller actually uses an unmodified stage 1 TCR value as provided in
the io_pgtable_cfg.
I feel it would be most productive to elaborate further in the form of
patches, so let me get right on that and try to bash something out
before I go home tonight...
...and now there's a rough WIP branch here:
http://linux-arm.org/git?p=linux-rm.git;a=shortlog;h=refs/heads/iommu/pgtable
I'll finish testing and polishing those patches at some point next week,
probably, but hopefully they're sufficiently illustrative for the moment.
Robin.
