APM smmu implementation

[Feng Kan]

On Mon, Jan 9, 2017 at 4:03 AM, Will Deacon <will.deacon at arm.com> wrote:
> On Mon, Jan 09, 2017 at 11:34:42AM +0000, Robin Murphy wrote:
>> On 06/01/17 23:21, Feng Kan wrote:
>> > The APM IOMMU implementation is mostly just the ARM SMMU 500 variant.
>>
>> "Mostly"? Have APM actually modified it (which I strongly doubt) or do
>> you mean it's simply been integrated with the upper address lines tied
>> off?
Yes, and that we only do stage 2 translation.

 MMU-500 reports a 48-bit IAS because MMU-500 has 48-bit-wide slave
>> interfaces; that's all there is to it. Whether or not you use all of
>> those bits is up to you as a system integrator.
>
> That's a good point; MMU-500 doesn't appear to let you change the IAS
> anyway. That should also mean that UBS and OAS are unchanged.
>
>> > However, our internal bus is only 42 bits wide. Our IAS field is coded
>> > as 48 bits, which cause IPA to truncated to 42 bits on the physical
>> > bus. In order for our system to work with the arm-smmu.c, there needs
>> > to be a way to force the ipa_size to 42. The current internal solution
>> > is to use the cpuid, but that is quite ugly. I was thinking of using
>> > the model
>> > as indication to right the ipa_size, but I am not too sure of the ACPI
>> > side. Would it be okay to add an APM MMU500 variant? I would also
>> > appreciated it if you guys have any alternate solutions.
>>
>> This is something we've been axpecting to run into for a while now - the
>> appropriate solution is to use a "dma-ranges" property on the master
>> device(s) to describe that they have 42 bits of address wired up, from
>> which they will then inherit the appropriate DMA mask. The outstanding
>> issue which remains is that we're still missing some way of preventing
>> drivers simply clobbering that with a 64-bit mask later, but that's a
>> more general problem[1].
Thanks, I have thought about this as well. As you have stated, it
simply does not work for all at this point.
>
> I wonder if the driver is actually using IAS, OAS and UBS incorrectly.
> We're using them to parameterise the DMA aperture, which is then used
> to size the IOVA domain, but that's wrong because the IAS, OAS and UBS
> are upper bounds and we can still end up allocating unusable/unreachable
> addresses.
>
> So I do think that this should be fixed on the SMMU firmware node, rather
> than restricting the range of each master device.
I am more partial to the Will's idea, adding an override
attribute would be the simplest at this point.
>
> Will