From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4C22DC433FE for ; Mon, 11 Oct 2021 05:59:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2E7DE60F21 for ; Mon, 11 Oct 2021 05:59:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232721AbhJKGBI (ORCPT ); Mon, 11 Oct 2021 02:01:08 -0400 Received: from szxga03-in.huawei.com ([45.249.212.189]:24233 "EHLO szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232716AbhJKGBI (ORCPT ); Mon, 11 Oct 2021 02:01:08 -0400 Received: from dggemv703-chm.china.huawei.com (unknown [172.30.72.57]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4HSSky0l9Yz8tWZ; Mon, 11 Oct 2021 13:58:02 +0800 (CST) Received: from dggpemm100008.china.huawei.com (7.185.36.125) by dggemv703-chm.china.huawei.com (10.3.19.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Mon, 11 Oct 2021 13:59:06 +0800 Received: from lhreml710-chm.china.huawei.com (10.201.108.61) by dggpemm100008.china.huawei.com (7.185.36.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Mon, 11 Oct 2021 13:59:05 +0800 Received: from lhreml710-chm.china.huawei.com ([169.254.81.184]) by lhreml710-chm.china.huawei.com ([169.254.81.184]) with mapi id 15.01.2308.008; Mon, 11 Oct 2021 06:59:03 +0100 From: Shameerali Kolothum Thodi To: Robin Murphy , "linux-arm-kernel@lists.infradead.org" , "linux-acpi@vger.kernel.org" , "iommu@lists.linux-foundation.org" CC: "jon@solid-run.com" , Linuxarm , "steven.price@arm.com" , "Guohanjun (Hanjun Guo)" , yangyicong , "Sami.Mujawar@arm.com" , "will@kernel.org" , wanghuiqiang Subject: RE: [PATCH v7 2/9] ACPI/IORT: Add support for RMR node parsing Thread-Topic: [PATCH v7 2/9] ACPI/IORT: Add support for RMR node parsing Thread-Index: AQHXidEiKr58723PTUGGkSglF1QKPavJYUsAgART7vA= Date: Mon, 11 Oct 2021 05:59:03 +0000 Message-ID: References: <20210805080724.480-1-shameerali.kolothum.thodi@huawei.com> <20210805080724.480-3-shameerali.kolothum.thodi@huawei.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.25.32] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUm9iaW4gTXVycGh5IFtt YWlsdG86cm9iaW4ubXVycGh5QGFybS5jb21dDQo+IFNlbnQ6IDA4IE9jdG9iZXIgMjAyMSAxMzo0 OQ0KPiBUbzogU2hhbWVlcmFsaSBLb2xvdGh1bSBUaG9kaSA8c2hhbWVlcmFsaS5rb2xvdGh1bS50 aG9kaUBodWF3ZWkuY29tPjsNCj4gbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3Jn OyBsaW51eC1hY3BpQHZnZXIua2VybmVsLm9yZzsNCj4gaW9tbXVAbGlzdHMubGludXgtZm91bmRh dGlvbi5vcmcNCj4gQ2M6IGpvbkBzb2xpZC1ydW4uY29tOyBMaW51eGFybSA8bGludXhhcm1AaHVh d2VpLmNvbT47DQo+IHN0ZXZlbi5wcmljZUBhcm0uY29tOyBHdW9oYW5qdW4gKEhhbmp1biBHdW8p IDxndW9oYW5qdW5AaHVhd2VpLmNvbT47DQo+IHlhbmd5aWNvbmcgPHlhbmd5aWNvbmdAaHVhd2Vp LmNvbT47IFNhbWkuTXVqYXdhckBhcm0uY29tOw0KPiB3aWxsQGtlcm5lbC5vcmc7IHdhbmdodWlx aWFuZyA8d2FuZ2h1aXFpYW5nQGh1YXdlaS5jb20+DQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggdjcg Mi85XSBBQ1BJL0lPUlQ6IEFkZCBzdXBwb3J0IGZvciBSTVIgbm9kZSBwYXJzaW5nDQo+IA0KPiBP biAyMDIxLTA4LTA1IDA5OjA3LCBTaGFtZWVyIEtvbG90aHVtIHdyb3RlOg0KPiA+IEFkZCBzdXBw b3J0IGZvciBwYXJzaW5nIFJNUiBub2RlIGluZm9ybWF0aW9uIGZyb20gQUNQSS4NCj4gPg0KPiA+ IEZpbmQgdGhlIGFzc29jaWF0ZWQgc3RyZWFtaWQgYW5kIHNtbXUgbm9kZSBpbmZvIGZyb20gdGhl DQo+ID4gUk1SIG5vZGUgYW5kIHBvcHVsYXRlIGEgbGlua2VkIGxpc3Qgd2l0aCBSTVIgbWVtb3J5 DQo+ID4gZGVzY3JpcHRvcnMuDQo+ID4NCj4gPiBTaWduZWQtb2ZmLWJ5OiBTaGFtZWVyIEtvbG90 aHVtDQo+IDxzaGFtZWVyYWxpLmtvbG90aHVtLnRob2RpQGh1YXdlaS5jb20+DQo+ID4gLS0tDQo+ ID4gICBkcml2ZXJzL2FjcGkvYXJtNjQvaW9ydC5jIHwgMTM0DQo+ICsrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKystDQo+ID4gICAxIGZpbGUgY2hhbmdlZCwgMTMzIGluc2VydGlv bnMoKyksIDEgZGVsZXRpb24oLSkNCj4gPg0KPiA+IGRpZmYgLS1naXQgYS9kcml2ZXJzL2FjcGkv YXJtNjQvaW9ydC5jIGIvZHJpdmVycy9hY3BpL2FybTY0L2lvcnQuYw0KPiA+IGluZGV4IDNiMjNm Yjc3NWFjNC4uZDc2YmE0NmViZTY3IDEwMDY0NA0KPiA+IC0tLSBhL2RyaXZlcnMvYWNwaS9hcm02 NC9pb3J0LmMNCj4gPiArKysgYi9kcml2ZXJzL2FjcGkvYXJtNjQvaW9ydC5jDQo+ID4gQEAgLTQw LDYgKzQwLDggQEAgc3RydWN0IGlvcnRfZndub2RlIHsNCj4gPiAgIHN0YXRpYyBMSVNUX0hFQUQo aW9ydF9md25vZGVfbGlzdCk7DQo+ID4gICBzdGF0aWMgREVGSU5FX1NQSU5MT0NLKGlvcnRfZndu b2RlX2xvY2spOw0KPiA+DQo+ID4gK3N0YXRpYyBMSVNUX0hFQUQoaW9ydF9ybXJfbGlzdCk7CS8q IGxpc3Qgb2YgUk1SIHJlZ2lvbnMgZnJvbSBBQ1BJICovDQo+ID4gKw0KPiA+ICAgLyoqDQo+ID4g ICAgKiBpb3J0X3NldF9md25vZGUoKSAtIENyZWF0ZSBpb3J0X2Z3bm9kZSBhbmQgdXNlIGl0IHRv IHJlZ2lzdGVyDQo+ID4gICAgKgkJICAgICAgIGlvbW11IGRhdGEgaW4gdGhlIGlvcnRfZndub2Rl X2xpc3QNCj4gPiBAQCAtMzkzLDcgKzM5NSw4IEBAIHN0YXRpYyBzdHJ1Y3QgYWNwaV9pb3J0X25v ZGUNCj4gKmlvcnRfbm9kZV9nZXRfaWQoc3RydWN0IGFjcGlfaW9ydF9ub2RlICpub2RlLA0KPiA+ ICAgCQlpZiAobm9kZS0+dHlwZSA9PSBBQ1BJX0lPUlRfTk9ERV9OQU1FRF9DT01QT05FTlQgfHwN Cj4gPiAgIAkJICAgIG5vZGUtPnR5cGUgPT0gQUNQSV9JT1JUX05PREVfUENJX1JPT1RfQ09NUExF WCB8fA0KPiA+ICAgCQkgICAgbm9kZS0+dHlwZSA9PSBBQ1BJX0lPUlRfTk9ERV9TTU1VX1YzIHx8 DQo+ID4gLQkJICAgIG5vZGUtPnR5cGUgPT0gQUNQSV9JT1JUX05PREVfUE1DRykgew0KPiA+ICsJ CSAgICBub2RlLT50eXBlID09IEFDUElfSU9SVF9OT0RFX1BNQ0cgfHwNCj4gPiArCQkgICAgbm9k ZS0+dHlwZSA9PSBBQ1BJX0lPUlRfTk9ERV9STVIpIHsNCj4gPiAgIAkJCSppZF9vdXQgPSBtYXAt Pm91dHB1dF9iYXNlOw0KPiA+ICAgCQkJcmV0dXJuIHBhcmVudDsNCj4gPiAgIAkJfQ0KPiA+IEBA IC0xNTY2LDYgKzE1NjksMTM0IEBAIHN0YXRpYyB2b2lkIF9faW5pdCBpb3J0X2VuYWJsZV9hY3Mo c3RydWN0DQo+IGFjcGlfaW9ydF9ub2RlICppb3J0X25vZGUpDQo+ID4gICAjZWxzZQ0KPiA+ICAg c3RhdGljIGlubGluZSB2b2lkIGlvcnRfZW5hYmxlX2FjcyhzdHJ1Y3QgYWNwaV9pb3J0X25vZGUg KmlvcnRfbm9kZSkgeyB9DQo+ID4gICAjZW5kaWYNCj4gPiArc3RhdGljIHZvaWQgaW9ydF9ybXJf ZGVzY19jaGVja19vdmVybGFwKHN0cnVjdCBhY3BpX2lvcnRfcm1yX2Rlc2MgKmRlc2MsDQo+IHUz MiBjb3VudCkNCj4gPiArew0KPiA+ICsJaW50IGksIGo7DQo+ID4gKw0KPiA+ICsJZm9yIChpID0g MDsgaSA8IGNvdW50OyBpKyspIHsNCj4gPiArCQl1NjQgZW5kLCBzdGFydCA9IGRlc2NbaV0uYmFz ZV9hZGRyZXNzLCBsZW5ndGggPSBkZXNjW2ldLmxlbmd0aDsNCj4gPiArDQo+ID4gKwkJZW5kID0g c3RhcnQgKyBsZW5ndGggLSAxOw0KPiA+ICsNCj4gPiArCQkvKiBDaGVjayBmb3IgYWRkcmVzcyBv dmVybGFwICovDQo+ID4gKwkJZm9yIChqID0gaSArIDE7IGogPCBjb3VudDsgaisrKSB7DQo+ID4g KwkJCXU2NCBlX3N0YXJ0ID0gZGVzY1tqXS5iYXNlX2FkZHJlc3M7DQo+ID4gKwkJCXU2NCBlX2Vu ZCA9IGVfc3RhcnQgKyBkZXNjW2pdLmxlbmd0aCAtIDE7DQo+ID4gKw0KPiA+ICsJCQlpZiAoc3Rh cnQgPD0gZV9lbmQgJiYgZW5kID49IGVfc3RhcnQpDQo+ID4gKwkJCQlwcl9lcnIoRldfQlVHICJS TVIgZGVzY3JpcHRvclsweCVsbHggLSAweCVsbHhdIG92ZXJsYXBzLA0KPiBjb250aW51ZSBhbnl3 YXlcbiIsDQo+ID4gKwkJCQkgICAgICAgc3RhcnQsIGVuZCk7DQo+ID4gKwkJfQ0KPiA+ICsJfQ0K PiA+ICt9DQo+ID4gKw0KPiA+ICtzdGF0aWMgdm9pZCBfX2luaXQgaW9ydF9ub2RlX2dldF9ybXJf aW5mbyhzdHJ1Y3QgYWNwaV9pb3J0X25vZGUgKmlvcnRfbm9kZSkNCj4gPiArew0KPiA+ICsJc3Ry dWN0IGFjcGlfaW9ydF9ub2RlICpzbW11Ow0KPiA+ICsJc3RydWN0IGFjcGlfaW9ydF9ybXIgKnJt cjsNCj4gPiArCXN0cnVjdCBhY3BpX2lvcnRfcm1yX2Rlc2MgKnJtcl9kZXNjOw0KPiA+ICsJdTMy IG1hcF9jb3VudCA9IGlvcnRfbm9kZS0+bWFwcGluZ19jb3VudDsNCj4gPiArCXUzMiBzaWQ7DQo+ ID4gKwlpbnQgaTsNCj4gPiArDQo+ID4gKwlpZiAoIWlvcnRfbm9kZS0+bWFwcGluZ19vZmZzZXQg fHwgbWFwX2NvdW50ICE9IDEpIHsNCj4gPiArCQlwcl9lcnIoRldfQlVHICJJbnZhbGlkIElEIG1h cHBpbmcsIHNraXBwaW5nIFJNUiBub2RlICVwXG4iLA0KPiA+ICsJCSAgICAgICBpb3J0X25vZGUp Ow0KPiA+ICsJCXJldHVybjsNCj4gPiArCX0NCj4gPiArDQo+ID4gKwkvKiBSZXRyaWV2ZSBhc3Nv Y2lhdGVkIHNtbXUgYW5kIHN0cmVhbSBpZCAqLw0KPiA+ICsJc21tdSA9IGlvcnRfbm9kZV9nZXRf aWQoaW9ydF9ub2RlLCAmc2lkLCAwKTsNCj4gPiArCWlmICghc21tdSkgew0KPiA+ICsJCXByX2Vy cihGV19CVUcgIkludmFsaWQgU01NVSByZWZlcmVuY2UsIHNraXBwaW5nIFJNUg0KPiBub2RlICVw XG4iLA0KPiA+ICsJCSAgICAgICBpb3J0X25vZGUpOw0KPiA+ICsJCXJldHVybjsNCj4gPiArCX0N Cj4gPiArDQo+ID4gKwkvKiBSZXRyaWV2ZSBSTVIgZGF0YSAqLw0KPiA+ICsJcm1yID0gKHN0cnVj dCBhY3BpX2lvcnRfcm1yICopaW9ydF9ub2RlLT5ub2RlX2RhdGE7DQo+ID4gKwlpZiAoIXJtci0+ cm1yX29mZnNldCB8fCAhcm1yLT5ybXJfY291bnQpIHsNCj4gPiArCQlwcl9lcnIoRldfQlVHICJJ bnZhbGlkIFJNUiBkZXNjcmlwdG9yIGFycmF5LCBza2lwcGluZyBSTVINCj4gbm9kZSAlcFxuIiwN Cj4gPiArCQkgICAgICAgaW9ydF9ub2RlKTsNCj4gPiArCQlyZXR1cm47DQo+ID4gKwl9DQo+ID4g Kw0KPiA+ICsJcm1yX2Rlc2MgPSBBQ1BJX0FERF9QVFIoc3RydWN0IGFjcGlfaW9ydF9ybXJfZGVz YywgaW9ydF9ub2RlLA0KPiA+ICsJCQkJcm1yLT5ybXJfb2Zmc2V0KTsNCj4gPiArDQo+ID4gKwlp b3J0X3Jtcl9kZXNjX2NoZWNrX292ZXJsYXAocm1yX2Rlc2MsIHJtci0+cm1yX2NvdW50KTsNCj4g PiArDQo+ID4gKwlmb3IgKGkgPSAwOyBpIDwgcm1yLT5ybXJfY291bnQ7IGkrKywgcm1yX2Rlc2Mr Kykgew0KPiA+ICsJCXN0cnVjdCBpb21tdV9yZXN2X3JlZ2lvbiAqcmVnaW9uOw0KPiA+ICsJCWVu dW0gaW9tbXVfcmVzdl90eXBlIHR5cGU7DQo+ID4gKwkJaW50IHByb3QgPSBJT01NVV9SRUFEIHwg SU9NTVVfV1JJVEU7DQo+ID4gKwkJdTY0IGFkZHIgPSBybXJfZGVzYy0+YmFzZV9hZGRyZXNzLCBz aXplID0gcm1yX2Rlc2MtPmxlbmd0aDsNCj4gPiArDQo+ID4gKwkJaWYgKCFJU19BTElHTkVEKGFk ZHIsIFNaXzY0SykgfHwgIUlTX0FMSUdORUQoc2l6ZSwgU1pfNjRLKSkgew0KPiA+ICsJCQkvKiBQ QUdFIGFsaWduIGJhc2UgYWRkciBhbmQgc2l6ZSAqLw0KPiA+ICsJCQlhZGRyICY9IFBBR0VfTUFT SzsNCj4gPiArCQkJc2l6ZSA9IFBBR0VfQUxJR04oc2l6ZSArDQo+IG9mZnNldF9pbl9wYWdlKHJt cl9kZXNjLT5iYXNlX2FkZHJlc3MpKTsNCj4gPiArDQo+ID4gKwkJCXByX2VycihGV19CVUcgIlJN UiBkZXNjcmlwdG9yWzB4JWxseCAtIDB4JWxseF0gbm90IGFsaWduZWQgdG8NCj4gNjRLLCBjb250 aW51ZSB3aXRoIFsweCVsbHggLSAweCVsbHhdXG4iLA0KPiA+ICsJCQkgICAgICAgcm1yX2Rlc2Mt PmJhc2VfYWRkcmVzcywNCj4gPiArCQkJICAgICAgIHJtcl9kZXNjLT5iYXNlX2FkZHJlc3MgKyBy bXJfZGVzYy0+bGVuZ3RoIC0gMSwNCj4gPiArCQkJICAgICAgIGFkZHIsIGFkZHIgKyBzaXplIC0g MSk7DQo+ID4gKwkJfQ0KPiA+ICsJCWlmIChybXItPmZsYWdzICYgSU9NTVVfUk1SX1JFTUFQX1BF Uk1JVFRFRCkgew0KPiA+ICsJCQl0eXBlID0gSU9NTVVfUkVTVl9ESVJFQ1RfUkVMQVhBQkxFOw0K PiA+ICsJCQkvKg0KPiA+ICsJCQkgKiBTZXQgSU9NTVVfQ0FDSEUgYXMgSU9NTVVfUkVTVl9ESVJF Q1RfUkVMQVhBQkxFIGlzDQo+ID4gKwkJCSAqIG5vcm1hbGx5IHVzZWQgZm9yIGFsbG9jYXRlZCBz eXN0ZW0gbWVtb3J5IHRoYXQgaXMNCj4gPiArCQkJICogdGhlbiB1c2VkIGZvciBkZXZpY2Ugc3Bl Y2lmaWMgcmVzZXJ2ZWQgcmVnaW9ucy4NCj4gPiArCQkJICovDQo+ID4gKwkJCXByb3QgfD0gSU9N TVVfQ0FDSEU7DQo+ID4gKwkJfSBlbHNlIHsNCj4gPiArCQkJdHlwZSA9IElPTU1VX1JFU1ZfRElS RUNUOw0KPiA+ICsJCQkvKg0KPiA+ICsJCQkgKiBTZXQgSU9NTVVfTU1JTyBhcyBJT01NVV9SRVNW X0RJUkVDVCBpcyBub3JtYWxseQ0KPiB1c2VkDQo+ID4gKwkJCSAqIGZvciBkZXZpY2UgbWVtb3J5 IGxpa2UgTVNJIGRvb3JiZWxsLg0KPiA+ICsJCQkgKi8NCj4gPiArCQkJcHJvdCB8PSBJT01NVV9N TUlPOw0KPiA+ICsJCX0NCj4gDQo+IEknbSBub3Qgc3VyZSB3ZSBldmVyIGdvdCBhIGRlZmluaXRp dmUgYW5zd2VyIHRvIHRoaXMgLSBkb2VzIERQQUEyDQo+IGFjdHVhbGx5IGdvIHdyb25nIGlmIHdl IHVzZSBJT01NVV9NTUlPIGhlcmU/IEknZCBzdGlsbCBtdWNoIHByZWZlciB0bw0KPiBtYWtlIHRo ZSBmZXdlc3QgcG9zc2libGUgYXNzdW1wdGlvbnMsIHNpbmNlIGF0IHRoaXMgcG9pbnQgaXQncyBi YXNpY2FsbHkNCj4ganVzdCBhIHN0b3AtZ2FwIHVudGlsIHdlIGNhbiBmaXggdGhlIHNwZWMuIEl0 J3MgYmVjb21lIGNsZWFyIHRoYXQgd2UNCj4gY2FuJ3QgcmVsaWFibHkgcmVseSBvbiBndWVzc2lu ZyBhdHRyaWJ1dGVzLCBzbyBJJ20gbm90IHRvbyBmdXNzZWQgYWJvdXQNCj4gdGhlb3JldGljYWwg Y2FzZXMgdGhhdCBjdXJyZW50bHkgZG9uJ3Qgd29yayAoZHVlIHRvIGNvbXBsZXRlIGxhY2sgb2Yg Uk1SDQo+IHN1cHBvcnQpIGNvbnRpbnVpbmcgdG8gbm90IHdvcmsgZm9yIHRoZSBtb21lbnQsIGFz IGxvbmcgYXMgd2UgY2FuIG1ha2UNCj4gdGhlIHJlYWwtd29ybGQgY2FzZXMgd2UgYWN0dWFsbHkg aGF2ZSB3b3JrIGF0IGFsbC4gQW55dGhpbmcgd2hpY2ggb25seQ0KPiBhZmZlY3RzIHBlcmZvcm1h bmNlIEknZCByYXRoZXIgbGVhdmUgdW50aWwgZmlybXdhcmUgY2FuIHRlbGwgdXMgd2hhdCB0byBk by4NCg0KSnVzdCB0byByZXBvcnQgYmFjaywgd2UgaGF2ZSBkb25lIHNvbWUgYmFzaWMgc2FuaXR5 IHRlc3RzIHdpdGggSU9NTVVfTU1JTw0Kc2V0IGFzIGRlZmF1bHQgYW5kIGl0IHdvcmtzIGZvciB1 cy4gQnV0IEkgc2VlIHRoYXQgaXQgZG9lc24ndCBmb3IgSm9uJ3MgY2FzZS4NClNvIG5vdCBzdXJl IHdoYXQgdGhlIHN0b3AtZ2FwIGNhbiBiZS4uIENhbiB3ZSB1c2UgdGhlIF9DQ0EgKyBFRkkgYXBw cm9hY2gNCmFuZCBvdmVycmlkZSBpdCBsYXRlciB3aGVuIHRoZSBzcGVjIGdldHMgdXBkYXRlZD8N Cg0KVGhhbmtzLA0KU2hhbWVlcg0KIA0KPiANCj4gPiArCQlyZWdpb24gPSBpb21tdV9hbGxvY19y ZXN2X3JlZ2lvbihhZGRyLCBzaXplLCBwcm90LCB0eXBlKTsNCj4gPiArCQlpZiAocmVnaW9uKSB7 DQo+ID4gKwkJCXJlZ2lvbi0+ZndfZGF0YS5ybXIuZmxhZ3MgPSBybXItPmZsYWdzOw0KPiA+ICsJ CQlyZWdpb24tPmZ3X2RhdGEucm1yLnNpZCA9IHNpZDsNCj4gPiArCQkJcmVnaW9uLT5md19kYXRh LnJtci5zbW11ID0gc21tdTsNCj4gPiArCQkJbGlzdF9hZGRfdGFpbCgmcmVnaW9uLT5saXN0LCAm aW9ydF9ybXJfbGlzdCk7DQo+ID4gKwkJfQ0KPiA+ICsJfQ0KPiA+ICt9DQo+ID4gKw0KPiA+ICtz dGF0aWMgdm9pZCBfX2luaXQgaW9ydF9wYXJzZV9ybXIodm9pZCkNCj4gPiArew0KPiA+ICsJc3Ry dWN0IGFjcGlfaW9ydF9ub2RlICppb3J0X25vZGUsICppb3J0X2VuZDsNCj4gPiArCXN0cnVjdCBh Y3BpX3RhYmxlX2lvcnQgKmlvcnQ7DQo+ID4gKwlpbnQgaTsNCj4gPiArDQo+ID4gKwlpZiAoaW9y dF90YWJsZS0+cmV2aXNpb24gPCAzKQ0KPiA+ICsJCXJldHVybjsNCj4gPiArDQo+ID4gKwlpb3J0 ID0gKHN0cnVjdCBhY3BpX3RhYmxlX2lvcnQgKilpb3J0X3RhYmxlOw0KPiA+ICsNCj4gPiArCWlv cnRfbm9kZSA9IEFDUElfQUREX1BUUihzdHJ1Y3QgYWNwaV9pb3J0X25vZGUsIGlvcnQsDQo+ID4g KwkJCQkgaW9ydC0+bm9kZV9vZmZzZXQpOw0KPiA+ICsJaW9ydF9lbmQgPSBBQ1BJX0FERF9QVFIo c3RydWN0IGFjcGlfaW9ydF9ub2RlLCBpb3J0LA0KPiA+ICsJCQkJaW9ydF90YWJsZS0+bGVuZ3Ro KTsNCj4gPiArDQo+ID4gKwlmb3IgKGkgPSAwOyBpIDwgaW9ydC0+bm9kZV9jb3VudDsgaSsrKSB7 DQo+ID4gKwkJaWYgKFdBUk5fVEFJTlQoaW9ydF9ub2RlID49IGlvcnRfZW5kLA0KPiBUQUlOVF9G SVJNV0FSRV9XT1JLQVJPVU5ELA0KPiA+ICsJCQkgICAgICAgIklPUlQgbm9kZSBwb2ludGVyIG92 ZXJmbG93cywgYmFkIHRhYmxlIVxuIikpDQo+ID4gKwkJCXJldHVybjsNCj4gPiArDQo+ID4gKwkJ aWYgKGlvcnRfbm9kZS0+dHlwZSA9PSBBQ1BJX0lPUlRfTk9ERV9STVIpDQo+ID4gKwkJCWlvcnRf bm9kZV9nZXRfcm1yX2luZm8oaW9ydF9ub2RlKTsNCj4gPiArDQo+ID4gKwkJaW9ydF9ub2RlID0g QUNQSV9BRERfUFRSKHN0cnVjdCBhY3BpX2lvcnRfbm9kZSwgaW9ydF9ub2RlLA0KPiA+ICsJCQkJ CSBpb3J0X25vZGUtPmxlbmd0aCk7DQo+ID4gKwl9DQo+ID4gK30NCj4gPg0KPiA+ICAgc3RhdGlj IHZvaWQgX19pbml0IGlvcnRfaW5pdF9wbGF0Zm9ybV9kZXZpY2VzKHZvaWQpDQo+ID4gICB7DQo+ ID4gQEAgLTE2MzYsNiArMTc2Nyw3IEBAIHZvaWQgX19pbml0IGFjcGlfaW9ydF9pbml0KHZvaWQp DQo+ID4gICAJfQ0KPiA+DQo+ID4gICAJaW9ydF9pbml0X3BsYXRmb3JtX2RldmljZXMoKTsNCj4g PiArCWlvcnRfcGFyc2Vfcm1yKCk7DQo+IA0KPiBJIGd1ZXNzIGluaXRjYWxsIG9yZGVyaW5nIHZz LiBkcml2ZXIgcmVnaXN0cmF0aW9uIHByb2JhYmx5IGNvdmVycyBpdCB1cCwNCj4gYnV0IGZvciB0 aGUgc2FrZSBvZiBjbGVhbmxpbmVzcyBJJ2QgcmF0aGVyIG1ha2Ugc3VyZSB0aGUgUk1ScyBhcmUg ZnVsbHkNCj4gZGlzY292ZXJlZCAqYmVmb3JlKiB3ZSBjcmVhdGUgdGhlIFNNTVUgZGV2aWNlcyB0 aGF0IHdlIGV4cGVjdCB0byBzdGFydA0KPiBjb25zdW1pbmcgdGhlbS4NCj4gDQo+IFJvYmluLg0K PiANCj4gPiAgIH0NCj4gPg0KPiA+ICAgI2lmZGVmIENPTkZJR19aT05FX0RNQQ0KPiA+DQo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9713CC433EF for ; Mon, 11 Oct 2021 05:59:13 +0000 (UTC) Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 37EAC60EE7 for ; Mon, 11 Oct 2021 05:59:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 37EAC60EE7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 017BD4039B; Mon, 11 Oct 2021 05:59:13 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8LSjuUS8vzo; Mon, 11 Oct 2021 05:59:11 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [IPv6:2605:bc80:3010:104::8cd3:938]) by smtp4.osuosl.org (Postfix) with ESMTPS id 89A4F4021A; Mon, 11 Oct 2021 05:59:11 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6B4C2C0011; Mon, 11 Oct 2021 05:59:11 +0000 (UTC) Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 0B103C000D for ; Mon, 11 Oct 2021 05:59:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id EEE2340224 for ; Mon, 11 Oct 2021 05:59:10 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9hcb9Sqc0MJ for ; Mon, 11 Oct 2021 05:59:09 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by smtp4.osuosl.org (Postfix) with ESMTPS id 79EAE4021A for ; Mon, 11 Oct 2021 05:59:09 +0000 (UTC) Received: from dggemv703-chm.china.huawei.com (unknown [172.30.72.57]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4HSSky0l9Yz8tWZ; Mon, 11 Oct 2021 13:58:02 +0800 (CST) Received: from dggpemm100008.china.huawei.com (7.185.36.125) by dggemv703-chm.china.huawei.com (10.3.19.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Mon, 11 Oct 2021 13:59:06 +0800 Received: from lhreml710-chm.china.huawei.com (10.201.108.61) by dggpemm100008.china.huawei.com (7.185.36.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Mon, 11 Oct 2021 13:59:05 +0800 Received: from lhreml710-chm.china.huawei.com ([169.254.81.184]) by lhreml710-chm.china.huawei.com ([169.254.81.184]) with mapi id 15.01.2308.008; Mon, 11 Oct 2021 06:59:03 +0100 From: Shameerali Kolothum Thodi To: Robin Murphy , "linux-arm-kernel@lists.infradead.org" , "linux-acpi@vger.kernel.org" , "iommu@lists.linux-foundation.org" Subject: RE: [PATCH v7 2/9] ACPI/IORT: Add support for RMR node parsing Thread-Topic: [PATCH v7 2/9] ACPI/IORT: Add support for RMR node parsing Thread-Index: AQHXidEiKr58723PTUGGkSglF1QKPavJYUsAgART7vA= Date: Mon, 11 Oct 2021 05:59:03 +0000 Message-ID: References: <20210805080724.480-1-shameerali.kolothum.thodi@huawei.com> <20210805080724.480-3-shameerali.kolothum.thodi@huawei.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.25.32] MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "jon@solid-run.com" , Linuxarm , "steven.price@arm.com" , "Guohanjun \(Hanjun Guo\)" , yangyicong , "Sami.Mujawar@arm.com" , "will@kernel.org" , wanghuiqiang X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" > -----Original Message----- > From: Robin Murphy [mailto:robin.murphy@arm.com] > Sent: 08 October 2021 13:49 > To: Shameerali Kolothum Thodi ; > linux-arm-kernel@lists.infradead.org; linux-acpi@vger.kernel.org; > iommu@lists.linux-foundation.org > Cc: jon@solid-run.com; Linuxarm ; > steven.price@arm.com; Guohanjun (Hanjun Guo) ; > yangyicong ; Sami.Mujawar@arm.com; > will@kernel.org; wanghuiqiang > Subject: Re: [PATCH v7 2/9] ACPI/IORT: Add support for RMR node parsing > > On 2021-08-05 09:07, Shameer Kolothum wrote: > > Add support for parsing RMR node information from ACPI. > > > > Find the associated streamid and smmu node info from the > > RMR node and populate a linked list with RMR memory > > descriptors. > > > > Signed-off-by: Shameer Kolothum > > > --- > > drivers/acpi/arm64/iort.c | 134 > +++++++++++++++++++++++++++++++++++++- > > 1 file changed, 133 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c > > index 3b23fb775ac4..d76ba46ebe67 100644 > > --- a/drivers/acpi/arm64/iort.c > > +++ b/drivers/acpi/arm64/iort.c > > @@ -40,6 +40,8 @@ struct iort_fwnode { > > static LIST_HEAD(iort_fwnode_list); > > static DEFINE_SPINLOCK(iort_fwnode_lock); > > > > +static LIST_HEAD(iort_rmr_list); /* list of RMR regions from ACPI */ > > + > > /** > > * iort_set_fwnode() - Create iort_fwnode and use it to register > > * iommu data in the iort_fwnode_list > > @@ -393,7 +395,8 @@ static struct acpi_iort_node > *iort_node_get_id(struct acpi_iort_node *node, > > if (node->type == ACPI_IORT_NODE_NAMED_COMPONENT || > > node->type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX || > > node->type == ACPI_IORT_NODE_SMMU_V3 || > > - node->type == ACPI_IORT_NODE_PMCG) { > > + node->type == ACPI_IORT_NODE_PMCG || > > + node->type == ACPI_IORT_NODE_RMR) { > > *id_out = map->output_base; > > return parent; > > } > > @@ -1566,6 +1569,134 @@ static void __init iort_enable_acs(struct > acpi_iort_node *iort_node) > > #else > > static inline void iort_enable_acs(struct acpi_iort_node *iort_node) { } > > #endif > > +static void iort_rmr_desc_check_overlap(struct acpi_iort_rmr_desc *desc, > u32 count) > > +{ > > + int i, j; > > + > > + for (i = 0; i < count; i++) { > > + u64 end, start = desc[i].base_address, length = desc[i].length; > > + > > + end = start + length - 1; > > + > > + /* Check for address overlap */ > > + for (j = i + 1; j < count; j++) { > > + u64 e_start = desc[j].base_address; > > + u64 e_end = e_start + desc[j].length - 1; > > + > > + if (start <= e_end && end >= e_start) > > + pr_err(FW_BUG "RMR descriptor[0x%llx - 0x%llx] overlaps, > continue anyway\n", > > + start, end); > > + } > > + } > > +} > > + > > +static void __init iort_node_get_rmr_info(struct acpi_iort_node *iort_node) > > +{ > > + struct acpi_iort_node *smmu; > > + struct acpi_iort_rmr *rmr; > > + struct acpi_iort_rmr_desc *rmr_desc; > > + u32 map_count = iort_node->mapping_count; > > + u32 sid; > > + int i; > > + > > + if (!iort_node->mapping_offset || map_count != 1) { > > + pr_err(FW_BUG "Invalid ID mapping, skipping RMR node %p\n", > > + iort_node); > > + return; > > + } > > + > > + /* Retrieve associated smmu and stream id */ > > + smmu = iort_node_get_id(iort_node, &sid, 0); > > + if (!smmu) { > > + pr_err(FW_BUG "Invalid SMMU reference, skipping RMR > node %p\n", > > + iort_node); > > + return; > > + } > > + > > + /* Retrieve RMR data */ > > + rmr = (struct acpi_iort_rmr *)iort_node->node_data; > > + if (!rmr->rmr_offset || !rmr->rmr_count) { > > + pr_err(FW_BUG "Invalid RMR descriptor array, skipping RMR > node %p\n", > > + iort_node); > > + return; > > + } > > + > > + rmr_desc = ACPI_ADD_PTR(struct acpi_iort_rmr_desc, iort_node, > > + rmr->rmr_offset); > > + > > + iort_rmr_desc_check_overlap(rmr_desc, rmr->rmr_count); > > + > > + for (i = 0; i < rmr->rmr_count; i++, rmr_desc++) { > > + struct iommu_resv_region *region; > > + enum iommu_resv_type type; > > + int prot = IOMMU_READ | IOMMU_WRITE; > > + u64 addr = rmr_desc->base_address, size = rmr_desc->length; > > + > > + if (!IS_ALIGNED(addr, SZ_64K) || !IS_ALIGNED(size, SZ_64K)) { > > + /* PAGE align base addr and size */ > > + addr &= PAGE_MASK; > > + size = PAGE_ALIGN(size + > offset_in_page(rmr_desc->base_address)); > > + > > + pr_err(FW_BUG "RMR descriptor[0x%llx - 0x%llx] not aligned to > 64K, continue with [0x%llx - 0x%llx]\n", > > + rmr_desc->base_address, > > + rmr_desc->base_address + rmr_desc->length - 1, > > + addr, addr + size - 1); > > + } > > + if (rmr->flags & IOMMU_RMR_REMAP_PERMITTED) { > > + type = IOMMU_RESV_DIRECT_RELAXABLE; > > + /* > > + * Set IOMMU_CACHE as IOMMU_RESV_DIRECT_RELAXABLE is > > + * normally used for allocated system memory that is > > + * then used for device specific reserved regions. > > + */ > > + prot |= IOMMU_CACHE; > > + } else { > > + type = IOMMU_RESV_DIRECT; > > + /* > > + * Set IOMMU_MMIO as IOMMU_RESV_DIRECT is normally > used > > + * for device memory like MSI doorbell. > > + */ > > + prot |= IOMMU_MMIO; > > + } > > I'm not sure we ever got a definitive answer to this - does DPAA2 > actually go wrong if we use IOMMU_MMIO here? I'd still much prefer to > make the fewest possible assumptions, since at this point it's basically > just a stop-gap until we can fix the spec. It's become clear that we > can't reliably rely on guessing attributes, so I'm not too fussed about > theoretical cases that currently don't work (due to complete lack of RMR > support) continuing to not work for the moment, as long as we can make > the real-world cases we actually have work at all. Anything which only > affects performance I'd rather leave until firmware can tell us what to do. Just to report back, we have done some basic sanity tests with IOMMU_MMIO set as default and it works for us. But I see that it doesn't for Jon's case. So not sure what the stop-gap can be.. Can we use the _CCA + EFI approach and override it later when the spec gets updated? Thanks, Shameer > > > + region = iommu_alloc_resv_region(addr, size, prot, type); > > + if (region) { > > + region->fw_data.rmr.flags = rmr->flags; > > + region->fw_data.rmr.sid = sid; > > + region->fw_data.rmr.smmu = smmu; > > + list_add_tail(®ion->list, &iort_rmr_list); > > + } > > + } > > +} > > + > > +static void __init iort_parse_rmr(void) > > +{ > > + struct acpi_iort_node *iort_node, *iort_end; > > + struct acpi_table_iort *iort; > > + int i; > > + > > + if (iort_table->revision < 3) > > + return; > > + > > + iort = (struct acpi_table_iort *)iort_table; > > + > > + iort_node = ACPI_ADD_PTR(struct acpi_iort_node, iort, > > + iort->node_offset); > > + iort_end = ACPI_ADD_PTR(struct acpi_iort_node, iort, > > + iort_table->length); > > + > > + for (i = 0; i < iort->node_count; i++) { > > + if (WARN_TAINT(iort_node >= iort_end, > TAINT_FIRMWARE_WORKAROUND, > > + "IORT node pointer overflows, bad table!\n")) > > + return; > > + > > + if (iort_node->type == ACPI_IORT_NODE_RMR) > > + iort_node_get_rmr_info(iort_node); > > + > > + iort_node = ACPI_ADD_PTR(struct acpi_iort_node, iort_node, > > + iort_node->length); > > + } > > +} > > > > static void __init iort_init_platform_devices(void) > > { > > @@ -1636,6 +1767,7 @@ void __init acpi_iort_init(void) > > } > > > > iort_init_platform_devices(); > > + iort_parse_rmr(); > > I guess initcall ordering vs. driver registration probably covers it up, > but for the sake of cleanliness I'd rather make sure the RMRs are fully > discovered *before* we create the SMMU devices that we expect to start > consuming them. > > Robin. > > > } > > > > #ifdef CONFIG_ZONE_DMA > > _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 974A5C433F5 for ; Mon, 11 Oct 2021 06:02:07 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 40C2F60231 for ; Mon, 11 Oct 2021 06:02:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 40C2F60231 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:In-Reply-To:References: Message-ID:Date:Subject:CC:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=aTOglP2AfxgTZQGRpXqykCXbO8CJ7SH84NiL5jfiJW8=; b=Ik2Ue1E2p8mmhD sAXOw5hb+zOXudRYvf4mKHzJUUsgqDp5jn16b9932U6Qwg99KtkRm9ivNbxH6lIN4vyqiVvR9IfBF VYKYRpj/FlszGNTQNd+ytemn9GK0jrpoGDkwXxDwORtkars8UpOKR4QCv0I4ZFdIZWLS4Uoi4MYmQ I7czJgp7KslKxCsxqivv8b31L2upx/mzvb5Qlcqu8ys/1/1OpYqCnQ+WJaHX6SHVu8gaKnxoU2JuM +lAY7no8CYVoOaeSJo9YfdiaaRZaB1JLTtHHQb1TU34OczIVpOhvSx7wOBKxX/hy0SLIBK/tN0DnI rb5rgCV+75fUlptunJHQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mZoLC-007sO9-Ne; Mon, 11 Oct 2021 05:59:14 +0000 Received: from szxga03-in.huawei.com ([45.249.212.189]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mZoL7-007sMg-5X for linux-arm-kernel@lists.infradead.org; Mon, 11 Oct 2021 05:59:11 +0000 Received: from dggemv703-chm.china.huawei.com (unknown [172.30.72.57]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4HSSky0l9Yz8tWZ; Mon, 11 Oct 2021 13:58:02 +0800 (CST) Received: from dggpemm100008.china.huawei.com (7.185.36.125) by dggemv703-chm.china.huawei.com (10.3.19.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Mon, 11 Oct 2021 13:59:06 +0800 Received: from lhreml710-chm.china.huawei.com (10.201.108.61) by dggpemm100008.china.huawei.com (7.185.36.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Mon, 11 Oct 2021 13:59:05 +0800 Received: from lhreml710-chm.china.huawei.com ([169.254.81.184]) by lhreml710-chm.china.huawei.com ([169.254.81.184]) with mapi id 15.01.2308.008; Mon, 11 Oct 2021 06:59:03 +0100 From: Shameerali Kolothum Thodi To: Robin Murphy , "linux-arm-kernel@lists.infradead.org" , "linux-acpi@vger.kernel.org" , "iommu@lists.linux-foundation.org" CC: "jon@solid-run.com" , Linuxarm , "steven.price@arm.com" , "Guohanjun (Hanjun Guo)" , yangyicong , "Sami.Mujawar@arm.com" , "will@kernel.org" , wanghuiqiang Subject: RE: [PATCH v7 2/9] ACPI/IORT: Add support for RMR node parsing Thread-Topic: [PATCH v7 2/9] ACPI/IORT: Add support for RMR node parsing Thread-Index: AQHXidEiKr58723PTUGGkSglF1QKPavJYUsAgART7vA= Date: Mon, 11 Oct 2021 05:59:03 +0000 Message-ID: References: <20210805080724.480-1-shameerali.kolothum.thodi@huawei.com> <20210805080724.480-3-shameerali.kolothum.thodi@huawei.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.25.32] MIME-Version: 1.0 X-CFilter-Loop: Reflected X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211010_225909_640200_4C0C939D X-CRM114-Status: GOOD ( 39.92 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org > -----Original Message----- > From: Robin Murphy [mailto:robin.murphy@arm.com] > Sent: 08 October 2021 13:49 > To: Shameerali Kolothum Thodi ; > linux-arm-kernel@lists.infradead.org; linux-acpi@vger.kernel.org; > iommu@lists.linux-foundation.org > Cc: jon@solid-run.com; Linuxarm ; > steven.price@arm.com; Guohanjun (Hanjun Guo) ; > yangyicong ; Sami.Mujawar@arm.com; > will@kernel.org; wanghuiqiang > Subject: Re: [PATCH v7 2/9] ACPI/IORT: Add support for RMR node parsing > > On 2021-08-05 09:07, Shameer Kolothum wrote: > > Add support for parsing RMR node information from ACPI. > > > > Find the associated streamid and smmu node info from the > > RMR node and populate a linked list with RMR memory > > descriptors. > > > > Signed-off-by: Shameer Kolothum > > > --- > > drivers/acpi/arm64/iort.c | 134 > +++++++++++++++++++++++++++++++++++++- > > 1 file changed, 133 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c > > index 3b23fb775ac4..d76ba46ebe67 100644 > > --- a/drivers/acpi/arm64/iort.c > > +++ b/drivers/acpi/arm64/iort.c > > @@ -40,6 +40,8 @@ struct iort_fwnode { > > static LIST_HEAD(iort_fwnode_list); > > static DEFINE_SPINLOCK(iort_fwnode_lock); > > > > +static LIST_HEAD(iort_rmr_list); /* list of RMR regions from ACPI */ > > + > > /** > > * iort_set_fwnode() - Create iort_fwnode and use it to register > > * iommu data in the iort_fwnode_list > > @@ -393,7 +395,8 @@ static struct acpi_iort_node > *iort_node_get_id(struct acpi_iort_node *node, > > if (node->type == ACPI_IORT_NODE_NAMED_COMPONENT || > > node->type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX || > > node->type == ACPI_IORT_NODE_SMMU_V3 || > > - node->type == ACPI_IORT_NODE_PMCG) { > > + node->type == ACPI_IORT_NODE_PMCG || > > + node->type == ACPI_IORT_NODE_RMR) { > > *id_out = map->output_base; > > return parent; > > } > > @@ -1566,6 +1569,134 @@ static void __init iort_enable_acs(struct > acpi_iort_node *iort_node) > > #else > > static inline void iort_enable_acs(struct acpi_iort_node *iort_node) { } > > #endif > > +static void iort_rmr_desc_check_overlap(struct acpi_iort_rmr_desc *desc, > u32 count) > > +{ > > + int i, j; > > + > > + for (i = 0; i < count; i++) { > > + u64 end, start = desc[i].base_address, length = desc[i].length; > > + > > + end = start + length - 1; > > + > > + /* Check for address overlap */ > > + for (j = i + 1; j < count; j++) { > > + u64 e_start = desc[j].base_address; > > + u64 e_end = e_start + desc[j].length - 1; > > + > > + if (start <= e_end && end >= e_start) > > + pr_err(FW_BUG "RMR descriptor[0x%llx - 0x%llx] overlaps, > continue anyway\n", > > + start, end); > > + } > > + } > > +} > > + > > +static void __init iort_node_get_rmr_info(struct acpi_iort_node *iort_node) > > +{ > > + struct acpi_iort_node *smmu; > > + struct acpi_iort_rmr *rmr; > > + struct acpi_iort_rmr_desc *rmr_desc; > > + u32 map_count = iort_node->mapping_count; > > + u32 sid; > > + int i; > > + > > + if (!iort_node->mapping_offset || map_count != 1) { > > + pr_err(FW_BUG "Invalid ID mapping, skipping RMR node %p\n", > > + iort_node); > > + return; > > + } > > + > > + /* Retrieve associated smmu and stream id */ > > + smmu = iort_node_get_id(iort_node, &sid, 0); > > + if (!smmu) { > > + pr_err(FW_BUG "Invalid SMMU reference, skipping RMR > node %p\n", > > + iort_node); > > + return; > > + } > > + > > + /* Retrieve RMR data */ > > + rmr = (struct acpi_iort_rmr *)iort_node->node_data; > > + if (!rmr->rmr_offset || !rmr->rmr_count) { > > + pr_err(FW_BUG "Invalid RMR descriptor array, skipping RMR > node %p\n", > > + iort_node); > > + return; > > + } > > + > > + rmr_desc = ACPI_ADD_PTR(struct acpi_iort_rmr_desc, iort_node, > > + rmr->rmr_offset); > > + > > + iort_rmr_desc_check_overlap(rmr_desc, rmr->rmr_count); > > + > > + for (i = 0; i < rmr->rmr_count; i++, rmr_desc++) { > > + struct iommu_resv_region *region; > > + enum iommu_resv_type type; > > + int prot = IOMMU_READ | IOMMU_WRITE; > > + u64 addr = rmr_desc->base_address, size = rmr_desc->length; > > + > > + if (!IS_ALIGNED(addr, SZ_64K) || !IS_ALIGNED(size, SZ_64K)) { > > + /* PAGE align base addr and size */ > > + addr &= PAGE_MASK; > > + size = PAGE_ALIGN(size + > offset_in_page(rmr_desc->base_address)); > > + > > + pr_err(FW_BUG "RMR descriptor[0x%llx - 0x%llx] not aligned to > 64K, continue with [0x%llx - 0x%llx]\n", > > + rmr_desc->base_address, > > + rmr_desc->base_address + rmr_desc->length - 1, > > + addr, addr + size - 1); > > + } > > + if (rmr->flags & IOMMU_RMR_REMAP_PERMITTED) { > > + type = IOMMU_RESV_DIRECT_RELAXABLE; > > + /* > > + * Set IOMMU_CACHE as IOMMU_RESV_DIRECT_RELAXABLE is > > + * normally used for allocated system memory that is > > + * then used for device specific reserved regions. > > + */ > > + prot |= IOMMU_CACHE; > > + } else { > > + type = IOMMU_RESV_DIRECT; > > + /* > > + * Set IOMMU_MMIO as IOMMU_RESV_DIRECT is normally > used > > + * for device memory like MSI doorbell. > > + */ > > + prot |= IOMMU_MMIO; > > + } > > I'm not sure we ever got a definitive answer to this - does DPAA2 > actually go wrong if we use IOMMU_MMIO here? I'd still much prefer to > make the fewest possible assumptions, since at this point it's basically > just a stop-gap until we can fix the spec. It's become clear that we > can't reliably rely on guessing attributes, so I'm not too fussed about > theoretical cases that currently don't work (due to complete lack of RMR > support) continuing to not work for the moment, as long as we can make > the real-world cases we actually have work at all. Anything which only > affects performance I'd rather leave until firmware can tell us what to do. Just to report back, we have done some basic sanity tests with IOMMU_MMIO set as default and it works for us. But I see that it doesn't for Jon's case. So not sure what the stop-gap can be.. Can we use the _CCA + EFI approach and override it later when the spec gets updated? Thanks, Shameer > > > + region = iommu_alloc_resv_region(addr, size, prot, type); > > + if (region) { > > + region->fw_data.rmr.flags = rmr->flags; > > + region->fw_data.rmr.sid = sid; > > + region->fw_data.rmr.smmu = smmu; > > + list_add_tail(®ion->list, &iort_rmr_list); > > + } > > + } > > +} > > + > > +static void __init iort_parse_rmr(void) > > +{ > > + struct acpi_iort_node *iort_node, *iort_end; > > + struct acpi_table_iort *iort; > > + int i; > > + > > + if (iort_table->revision < 3) > > + return; > > + > > + iort = (struct acpi_table_iort *)iort_table; > > + > > + iort_node = ACPI_ADD_PTR(struct acpi_iort_node, iort, > > + iort->node_offset); > > + iort_end = ACPI_ADD_PTR(struct acpi_iort_node, iort, > > + iort_table->length); > > + > > + for (i = 0; i < iort->node_count; i++) { > > + if (WARN_TAINT(iort_node >= iort_end, > TAINT_FIRMWARE_WORKAROUND, > > + "IORT node pointer overflows, bad table!\n")) > > + return; > > + > > + if (iort_node->type == ACPI_IORT_NODE_RMR) > > + iort_node_get_rmr_info(iort_node); > > + > > + iort_node = ACPI_ADD_PTR(struct acpi_iort_node, iort_node, > > + iort_node->length); > > + } > > +} > > > > static void __init iort_init_platform_devices(void) > > { > > @@ -1636,6 +1767,7 @@ void __init acpi_iort_init(void) > > } > > > > iort_init_platform_devices(); > > + iort_parse_rmr(); > > I guess initcall ordering vs. driver registration probably covers it up, > but for the sake of cleanliness I'd rather make sure the RMRs are fully > discovered *before* we create the SMMU devices that we expect to start > consuming them. > > Robin. > > > } > > > > #ifdef CONFIG_ZONE_DMA > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel