On Tue, Aug 20, 2019 at 03:51:45PM +0100, Robin Murphy wrote: > On 20/08/2019 11:30, Will Deacon wrote: > > On Mon, Aug 19, 2019 at 07:19:31PM +0100, Robin Murphy wrote: > > > Now that callers are free to use a given table for TTBR1 if they wish > > > (all they need do is shift the provided attributes when constructing > > > their final TCR value), the only remaining impediment is the address > > > validation on map/unmap. The fact that the LPAE address space split is > > > symmetric makes this easy to accommodate - by simplifying the current > > > range checks into explicit tests that address bits above IAS are all > > > zero, it then follows straightforwardly to add the inverse test to > > > allow the all-ones case as well. > > > > > > Signed-off-by: Robin Murphy <[email protected]> > > > --- > > > drivers/iommu/io-pgtable-arm.c | 7 ++++--- > > > 1 file changed, 4 insertions(+), 3 deletions(-) > > > > > > diff --git a/drivers/iommu/io-pgtable-arm.c > > > b/drivers/iommu/io-pgtable-arm.c > > > index 09cb20671fbb..f39c50356351 100644 > > > --- a/drivers/iommu/io-pgtable-arm.c > > > +++ b/drivers/iommu/io-pgtable-arm.c > > > @@ -475,13 +475,13 @@ static int arm_lpae_map(struct io_pgtable_ops *ops, > > > unsigned long iova, > > > arm_lpae_iopte *ptep = data->pgd; > > > int ret, lvl = ARM_LPAE_START_LVL(data); > > > arm_lpae_iopte prot; > > > + long iaext = (long)iova >> data->iop.cfg.ias; > > > /* If no access, then nothing to do */ > > > if (!(iommu_prot & (IOMMU_READ | IOMMU_WRITE))) > > > return 0; > > > - if (WARN_ON(iova >= (1ULL << data->iop.cfg.ias) || > > > - paddr >= (1ULL << data->iop.cfg.oas))) > > > + if (WARN_ON((iaext && ~iaext) || paddr >> data->iop.cfg.oas)) > > > > I had to read that '&&' twice, but I see what you're doing now :) > > > > > return -ERANGE; > > > > This doesn't seem sufficient to prevent a mixture of TTBR1 and TTBR0 > > addresses from being mapped in the same TTBR. Perhaps we need a quirk for > > TTBR1, which could then take care of setting EPDx appropriately? > > Right, that's the one downside of going for the minimalist "io-pgtable > doesn't even have to know" approach. On reflection, though, in that paradigm > it should probably be the caller's responsibility to convert TTBR1 addresses > to preserve the "as if TTBR0" illusion anyway :/
Right, and I'd rather not push stuff into the caller for the common case. It's not exactly onerous to support this in io-pgtable. It's also why I'd still like to keep the EPDx in there, because the callers that care can rewrite the stuff, but at least we provided a default. > The advantage of not having a quirk is that it allows split address spaces > to fit more closely with the aux_domain idea, i.e. we could allocate and > initialise a domain without having to assume, or even care, whether it will > end up attached as a primary or aux domain. It *might* even be potentially > useful to have a domain attached to TTBR0 of one device's context and TTBR1 > of another's at the same time, although that's pretty niche. That sounds pretty theoretical to me at the moment. Will _______________________________________________ iommu mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/iommu
