From mboxrd@z Thu Jan 1 00:00:00 1970 From: Will Deacon Subject: Re: iommu/arm-smmu-v2 ASID/VMID calculation Date: Tue, 26 Jan 2016 11:54:35 +0000 Message-ID: <20160126115435.GB21553@arm.com> References: <198F501C-8D30-4EB5-BC40-4F40BB75D40B@caviumnetworks.com> <20160125170312.GJ22927@arm.com> <6F24A28A-6302-4C48-A933-B47A9735808C@caviumnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Disposition: inline In-Reply-To: <6F24A28A-6302-4C48-A933-B47A9735808C-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: "Chalamarla, Tirumalesh" Cc: "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org" , linux-arm-kernel List-Id: iommu@lists.linux-foundation.org T24gVHVlLCBKYW4gMjYsIDIwMTYgYXQgMDM6MTE6MjdBTSArMDAwMCwgQ2hhbGFtYXJsYSwgVGly dW1hbGVzaCB3cm90ZToKPiBvbmUgbXkgY29sbGVhZ3VlIHBvaW50cyBvdXQsIEFTSURQTkUgYWxz byBpbXBsZW1lbnRhdGlvbiBkZWZpbmVkLiAKCkl0IGxvb2tzIHByZXR0eSB3ZWxsIGRlZmluZWQg dG8gbWUsIGRlc3BpdGUgYmVpbmcgYSBoaW50OgoKICBUaGlzIEFTSURQTkUgaW5kaWNhdGlvbiBp cyBvbmx5IGEgaGludCwgYW5kIGFuIFNNTVUgY2FuIGlnbm9yZSBpdC4gSW4KICBwYXJ0aWN1bGFy LCBpZiB0aGUgU01NVSBpbXBsZW1lbnRhdGlvbiBkb2VzIG5vdCBzdXBwb3J0IHRoZSBBU0lEUE5F CiAgZmVhdHVyZSwgYnJvYWRjYXN0IFRMQiBpbnZhbGlkYXRlIG9wZXJhdGlvbnMgaWdub3JlIHRo aXMgaGludCBhbmQKICBpbnZhbGlkYXRlIG1hdGNoaW5nIFRMQiBlbnRyaWVzIHdoZW4gYnJvYWRj YXN0IFRMQiBpbnZhbGlkYXRpb24gaXMKICBlbmFibGVkLgoKQnV0IHdoYXQgZG9lcyB0aGlzIGhh dmUgdG8gZG8gd2l0aCB0aGUgcHJvYmxlbSBhdCBoYW5kPwoKPiA+SSBkb27igJl0IHRoaW5rIGl0 IGZvbGxvd2VkIHNwZWMuCj4gPgo+ID5UaGUgU01NVSBzcGVjIChJSEkwMDYyQykgc2F5cyAoc2Vj dGlvbiAyLjIpOgo+ID4KPiA+ICAgLSBUaGUgZXhhY3QgYmVoYXZpb3Igb2YgYW55IFRMQiBmdW5j dGlvbmFsaXR5IGlzIElNUExFTUVOVEFUSU9OIERFRklORUQKCi4uLiBhbmQgaW1tZWRpYXRlbHkg cXVhbGlmaWVzIHRoYXQgd2l0aDoKCiAgVGhlIFNNTVUgYXJjaGl0ZWN0dXJlIGRvZXMgbm90IGxp bWl0IGhvdyBhIFRMQiBpcyBpbXBsZW1lbnRlZCwgcHJvdmlkZWQKICBpdCBvYmV5cyB0aGUgVExC IEludmFsaWRhdGUgb3BlcmF0aW9ucy4KCndoaWNoIGlzIHRvIHNheSwgeW91IGNhbiBidWlsZCB0 aGUgVExCIGhvdyB5b3UgbGlrZSwgcHJvdmlkaW5nIHRoYXQgaXQKZm9sbG93cyB0aGUgcHJvZ3Jh bW1lcnMgbW9kZWwgZm9yIGludmFsaWRhdGlvbi4gT3RoZXJ3aXNlIHBvcnRhYmxlCnNvZnR3YXJl IHdpbGwgYnJlYWsgYW5kIHBlb3BsZSB3aWxsIHNlbmQgcGF0Y2hlcyB0byAiZml4IiBpdC4KCj4g PlNlY3Rpb24gMi4yIGRlc2NyaWJlcyB0aGUgY29uc3RyYWludHMgb24gc2hhcmluZyAoZS5nLiBt dWx0aXBsZSBjb250ZXh0cwo+ID51c2luZyB0aGUgc2FtZSBBU0lEIHNheXMpOgo+ID4KPiA+ICAg ICAgIklmIG11bHRpcGxlIGNvbnRleHQgYmFua3MgaGF2ZSBodGUgc2FtZSBhdHRyaWJ1dGVzIGJ1 dCBkZXNjcmliZQo+ID4gICAgICAgZGlmZmVyZW50IHRyYW5zbGF0aW9ucywgdGhlIHJlc3VsdHMg b2YgYSBUTEIgbG9va3VwIGFyZSBVTlBSRURJQ1RBQkxFIi4KClRoYXQncyBkZXNjcmliaW5nIGEg VExCIGNvbmZsaWN0LiBUaGVzZSBkb24ndCBvY2N1ciwgYmVjYXVzZSB3ZSBlbnN1cmUKZWFjaCBv ZiB5b3VyIDEyOCBjb250ZXh0IGJhbmtzIGhhcyBkaWZmZXJlbnQgYXR0cmlidXRlcyAoaS5lLiBB U0lEL1ZNSUQpLgoKVGhlIHByb2JsZW0gaXMgdGhhdCB5b3UgaGF2ZSBzaGFyZWQgc3RhdGUgYmV0 d2VlbiBtdWx0aXBsZSBTTU1VIGluc3RhbmNlcywKd2hpY2ggSSBkb24ndCB0aGluayBpcyBjb3Jy ZWN0LiBJJ20gZmluZSB3aXRoIGEgd29ya2Fyb3VuZCwgYnV0IEkgZG9uJ3QKd2FudCB0aGlzIGxv Z2ljIHRvIGJlIHVzZWQgb24gb3RoZXIgaW1wbGVtZW50YXRpb25zIHdoZXJlIGl0IGlzIG5vdApu ZWVkZWQuCgo+ID5UaGUgcHJlc2VudCBzbW11IGRyaXZlciBhc3N1bWVzIEFTSUQgc2hvdWxkIG9u bHkgYmUgdW5pcXVlIHBlciBTTU1VLCB0aGlzCj4gPm1pZ2h0IG5vdCBiZSB0cnVlIGZvciBhbGwg SW1wbGVtZW50YXRpb25zLiAKClNvIGZhciwgaXQgYXBwZWFycyB0byBiZSB0cnVlIGZvciBhbGwg SW1wbGVtZW50YXRpb25zIGFwYXJ0IGZyb20geW91cnMKYW5kIHRoZXJlZm9yZSBuZWVkcyB0byBi ZSBxdWlya2VkLgoKV2lsbApfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXwppb21tdSBtYWlsaW5nIGxpc3QKaW9tbXVAbGlzdHMubGludXgtZm91bmRhdGlvbi5v cmcKaHR0cHM6Ly9saXN0cy5saW51eGZvdW5kYXRpb24ub3JnL21haWxtYW4vbGlzdGluZm8vaW9t bXU= From mboxrd@z Thu Jan 1 00:00:00 1970 From: will.deacon@arm.com (Will Deacon) Date: Tue, 26 Jan 2016 11:54:35 +0000 Subject: iommu/arm-smmu-v2 ASID/VMID calculation In-Reply-To: <6F24A28A-6302-4C48-A933-B47A9735808C@caviumnetworks.com> References: <198F501C-8D30-4EB5-BC40-4F40BB75D40B@caviumnetworks.com> <20160125170312.GJ22927@arm.com> <6F24A28A-6302-4C48-A933-B47A9735808C@caviumnetworks.com> Message-ID: <20160126115435.GB21553@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tue, Jan 26, 2016 at 03:11:27AM +0000, Chalamarla, Tirumalesh wrote: > one my colleague points out, ASIDPNE also implementation defined. It looks pretty well defined to me, despite being a hint: This ASIDPNE indication is only a hint, and an SMMU can ignore it. In particular, if the SMMU implementation does not support the ASIDPNE feature, broadcast TLB invalidate operations ignore this hint and invalidate matching TLB entries when broadcast TLB invalidation is enabled. But what does this have to do with the problem at hand? > >I don?t think it followed spec. > > > >The SMMU spec (IHI0062C) says (section 2.2): > > > > - The exact behavior of any TLB functionality is IMPLEMENTATION DEFINED ... and immediately qualifies that with: The SMMU architecture does not limit how a TLB is implemented, provided it obeys the TLB Invalidate operations. which is to say, you can build the TLB how you like, providing that it follows the programmers model for invalidation. Otherwise portable software will break and people will send patches to "fix" it. > >Section 2.2 describes the constraints on sharing (e.g. multiple contexts > >using the same ASID says): > > > > "If multiple context banks have hte same attributes but describe > > different translations, the results of a TLB lookup are UNPREDICTABLE". That's describing a TLB conflict. These don't occur, because we ensure each of your 128 context banks has different attributes (i.e. ASID/VMID). The problem is that you have shared state between multiple SMMU instances, which I don't think is correct. I'm fine with a workaround, but I don't want this logic to be used on other implementations where it is not needed. > >The present smmu driver assumes ASID should only be unique per SMMU, this > >might not be true for all Implementations. So far, it appears to be true for all Implementations apart from yours and therefore needs to be quirked. Will