From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752181AbdI2KeY (ORCPT ); Fri, 29 Sep 2017 06:34:24 -0400 Received: from mail-ve1eur01on0071.outbound.protection.outlook.com ([104.47.1.71]:16736 "EHLO EUR01-VE1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751830AbdI2KeW (ORCPT ); Fri, 29 Sep 2017 06:34:22 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Volodymyr_Babchuk@epam.com; Subject: Re: [PATCH v1 06/14] tee: optee: add page list manipulation functions To: Yury Norov Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, tee-dev@lists.linaro.org, Jens Wiklander , Volodymyr Babchuk References: <1506621851-6929-1-git-send-email-volodymyr_babchuk@epam.com> <1506621851-6929-7-git-send-email-volodymyr_babchuk@epam.com> <20170929002300.zxu4n47m5jdymdyt@yury-thinkpad> From: Volodymyr Babchuk Message-ID: Date: Fri, 29 Sep 2017 13:34:13 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170929002300.zxu4n47m5jdymdyt@yury-thinkpad> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [85.223.209.59] X-ClientProxiedBy: HE1PR0401CA0061.eurprd04.prod.outlook.com (2603:10a6:3:19::29) To VI1PR0301MB2144.eurprd03.prod.outlook.com (2603:10a6:800:26::17) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 792f124e-65ab-4e97-b782-08d50725a47f X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075);SRVR:VI1PR0301MB2144; X-Microsoft-Exchange-Diagnostics: 1;VI1PR0301MB2144;3:bPpH+7KhheXc+uwo/6YqDj9hL6WkekXzOJeGzbUQx/BwsvsKilQCiVfDhgj8t/UAttzKkRlRRif2KufqKw58zUl/UTTNEgeiR7jIte+5kebd+WRf0k98r6+eDMQjLGQNiaAjl7dAO8aBWfCAisYjhLj5Xu+1oklZNMZZRmY5Bwey4bQ/Ptedd8HUVLBYDfI00zQJyvsHDP3uuQD1ByVqXp06RuRncOBQEzP4FrogOsFA/2yNHVq7VFKcpJksLg/T;25:fNcqyXJ+WHfZZS8R6jjaqUVRzgorqUOCJ9d7QxY1eiRCGEPs1F2Mro+sTbjQJkDSy4J9AS3MgTUuxERD7imzEZFOG6kp++hx68yXUXFPNPLrqFB96cw7AyOPN9jKAHifOhcAB0aeHBZxuNno3J2BshHajXHBLEhe3Sx50+ORJC036lM5XDutIAIX92j0TZ90zh0E7Bmy1rz+yL5TzY/rL6FTWVjnVOdxNHpqW8PEkAySmCbyyRehbo0xY0WBEBLrPYead3UHTJ96WYDf8+9NndUO2LzB+yWf8r4Jmf/3JGt3YIzxpBC947LyTpqpATcbd4rUyDisrwHN90eLW+Tdtg==;31:bhQiAvS2xv5xjAgpKTRkmlZg4u5Sd0jNn1pOW3ThCl7f56cvQ9hPHxMQ3YjDigHqCaE3tR04Y+Fb5WO9+sPuntD78WJ24M85oOCM85XFmuu6hPo15tIASSKaUYm+yw5lHkNJmbD/6OlzOTLPwBmI0bO38ZJE7p4Xdz/mTTZK8TyR/mxX2aeaRzjneGYwaIb7UUqqtA4enI/919Y2JF/9Z5wQ6vn0u4dUOrgranmgB6k= X-MS-TrafficTypeDiagnostic: VI1PR0301MB2144: X-Microsoft-Exchange-Diagnostics: 1;VI1PR0301MB2144;20:KiQISPhMKMmNfOYMvVYCqzwufrinadOyoRl0I5D/xioHwkJUJ7JqwAuNQZTT3P4Gx+JfXzc0VslYgrGgIZfdM2pDB4VOVLalmxGfko+/QUYHD3jhCv/6hgHX751q2/KRyuk2mDMeA6LJeuWglg5tfBZZAT70Qj7R7VqnyZrabQ72SYZSSOpT84Vu+N+vFZ129NMIbloD93N6OBw15Fp4qv5gBPj7dDYdaPJOzUi3ydZfUJzLCZ88Jpa8u6Mzz9jrchbkG5ZEq2cGA2WmDDtwNMapvTOLDArq/+HvRjCIfVV3E/dz8KFSmdw8DS8VKz6vFOxhwWuNEP/y58SMGsClOW6/JyCtJdOYtSSkuafWnS9798tYi0SChLcJm2z7odn/FaUg3hyzJj5JAgd9xjNYFNrlipaiCh5ms6JQMkYdREhVmVGvpVN0lA8mwPcVShPMVPyDm6bmtLiE/b0a4ZA9TCsU9g6jM6q9UN291T7+BmZnJfGPv50J65eVsZHxwBfV;4:XBM2TNe4wPnCFSJ5PB/mjsxCCbh9G/pMfazkpPtBZ6CErNLHtkUQqAbv2wTnHHS2wYsM3tTtp02jf7Y5qXMIulUwcdKCriPMezNGc8RQWWPWGpqXShMR9fyo678HJXs+B2/hvgNT+BQrvG9YXE1IQpHvpXUW3De8jDNiME4iOc4L+VgwB5oJA7ikBevyv/WtADx0/o6/Draj9PzPBv0k6Pxsb3XeDucIAPQCidpU0WRYCsW/M9IbmKWGlV8rASA6 X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123555025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:VI1PR0301MB2144;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:VI1PR0301MB2144; X-Forefront-PRVS: 0445A82F82 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(6049001)(6009001)(376002)(346002)(189002)(24454002)(51444003)(199003)(16576012)(36756003)(6916009)(2906002)(80792005)(2950100002)(105586002)(106356001)(33646002)(97736004)(54906003)(23676002)(6246003)(316002)(305945005)(31686004)(65956001)(47776003)(66066001)(230700001)(65806001)(83506001)(50466002)(64126003)(86362001)(6486002)(101416001)(345774005)(39060400002)(68736007)(77096006)(6116002)(3846002)(65826007)(58126008)(53936002)(7736002)(5660300001)(31696002)(4326008)(76176999)(72206003)(189998001)(53546010)(478600001)(81156014)(8936002)(229853002)(81166006)(25786009)(8676002)(54356999)(6666003)(50986999);DIR:OUT;SFP:1101;SCL:1;SRVR:VI1PR0301MB2144;H:[10.17.182.79];FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQUjAzMDFNQjIxNDQ7MjM6MGFtalBsdVZmcy9mb3FTNTNjdCt1cDhk?= =?utf-8?B?Sm5uSE1IRTNNWi8vb3R0REl1akgrVitLYVFRQk1rejdkN3hXb1Y5UkxvRzRu?= =?utf-8?B?Rk56S2Q3MzdJV0FCZ0VJQjJJTk1iOFVDTlc1dDl2SjNJSGkzYjFvb3Y1UTR3?= =?utf-8?B?YmYrQTFuSGJJaTh1TlJuVkhMK2FVbk9tRmZ5UldHMHo4OFlmUDdKVlE0Z1ZX?= =?utf-8?B?WXcxcE12QmJONkNhOUZaY0lXWHpmTkRDUnlHQzdDNkxVUTNWdHlkUCt3RDRC?= =?utf-8?B?Njc3T0NUMUxXcERnTGNab0pWSVVSWGsrOTRreFZ0MHA0ZDc2WTRoUFJyVGNT?= =?utf-8?B?RllVM0RWZENUTFJpRDZCTGFqbHNqWGRQeHpDOXBoSzZReHZQN1o3THpva0tC?= =?utf-8?B?VHZzS2pQM2lsQW51RTlYeVpFNWpzZlh6aVlXUHNMSW9scml0c3hwaWxIZERX?= =?utf-8?B?OXR5QjBtcUxSemFWc3VNYzljRkNET2xsY05vSU5IcGdmMi93K0F5Ym1xS1Vs?= =?utf-8?B?bFBJUEJXTTI1QXRzdTdDSEtWOUxlVjIxa1k5TkJQSHJVN01RQVV0anc3N0ZD?= =?utf-8?B?YnNSSFVDNnkzMnlSVkJFckFkeHFUYTNRVVlGR2o4VEpxMlpmZ1NYVmJmOEdh?= =?utf-8?B?MUQ4UEEyck01QUJOdklibzVxRU5PaXJKTExST1dRODVoSFBYV3IzcUxlVFp5?= =?utf-8?B?L2VZd1VBQk8renlrQ3c5Wjd1cVZBRWYwcFZLcU9nOUp4TTdZYUh1Z3gvZTBp?= =?utf-8?B?aWpVNnJDSWpOTzgwbTkxdVoxUVpyQ3NUZC9IOWpJblg0amhqdnhJY09jWUta?= =?utf-8?B?Yzg1ZEV6cGxpMlpQaUowalZyNzB0R1Rmc09za2swRnhiN2cyNWxlK2ZpSmlT?= =?utf-8?B?WE1TMHFwRTZiRExtdDk0T1dyajVGc3lBcGtCbjBIQmJQc3hxTHVzZnRsTkl6?= =?utf-8?B?YzJqTFZ4cm95VTJHVHdwZUt0U2VoR2s5T1ZBVGJUaFNudG0wbXd6NmdkNjMw?= =?utf-8?B?TmxNZzB6Z1diK3JLWndwWnVQZ0o4UlNzQ1VPcldGUS9ldnB5dDhvV2dqU1Fl?= =?utf-8?B?NTFSb3J6bGVwYU1nNmdobmxWY2ozVDJYZWFNNCs5OXZHbFdtSXFFZEhSalpm?= =?utf-8?B?L0ZubDNmeVRncHZVNjlNbXF6REhveVlmeXF4eVhTaFUyREo1bEVNUDU2YmNX?= =?utf-8?B?YjhFQ2ZVUktXenRNOSs2WGdVM2dUSk11U2U2RjRKcnhJbzNEcEo0OXhhRjdN?= =?utf-8?B?SGs5SGI2ODVuUW1qYUo3enBwNzJHVEU3TDlMNisrSEszaENKaFQyUVhJYW4v?= =?utf-8?B?Rnl6T2MxdEtGbmdPc216Vk4ycDRGSHRmRGxXVFFIajM0dUZUYmE0eE53MlBS?= =?utf-8?B?VzZEL0h5WUJISjBCdDhTOWZOMmk5RStpakRLdGFqTkcvVm5TREpWNHZJL0F5?= =?utf-8?B?WldpdXBVU25ZWkhnWU9FcHVjaDIyRHJoRFY0TVhocUw5dFM0WTZmNGRkb2tN?= =?utf-8?B?aVVvWktNYjZnOExaR2p6cTdyWk1yanFNV2Q1NmFDUGxEcndiUkJFM3VjM2RX?= =?utf-8?B?SFdmdTlHbE03VUVxYTN0dHVNS21DNWRiT1IrdkRucGYrTlBPWk9FV0Vva2Zs?= =?utf-8?B?NDlabkNHc3ZSbkV5VXN0SnRXNGVLZ3E3UzNWcGhPQ0t0Z1RXVXh2b2xxOVMv?= =?utf-8?B?QTEwUDI0bk5pNThBM2U5RmtsWWtrd2c3QUgzb2VKbzA3SUlxRXdZTnRGRzhl?= =?utf-8?B?Mk5jRXB3SFdiLzlwNk5Mb001a1lUWmRaNndnTE9KQ0hiWktKQktTekVyNFpS?= =?utf-8?B?aHRncm15T1JYck4yREdERFhMQ0Jic1Q3RFFHQWVhTGU3QWZjYWlaWUJlbTNM?= =?utf-8?B?d3l2WkhKUmh6UkFlRWUrbDAvU1cwV2M4WTZHSkZ5TVZscXN4M2VUVldEa0ZQ?= =?utf-8?B?YVpxN1QxMU90SGc9PQ==?= X-Microsoft-Exchange-Diagnostics: 1;VI1PR0301MB2144;6:uFw7fRgt7CW9T4vXTGqrtW0BRPJFBQN+KXeSccFXkfF2/knFQd04Zl3wu3ICpGCaqupb1pTZTNuTZTAKXNZFnSe+jfDImkiYcNpWaLw1u98pqIvMrAizqmeH4P9FtLJfnIWD+wM74rSFx+kF/ZKjv3Xy3nPIcYXdmdH6ma6ajX1LALenYUflAtv7+h8H918veWaGVY84VLzj1LbnGAkjKrSkUv28codw41CXVGdIXJ/65BMyBVzSIwrJydBpNKOYSWdXalE1jdNB5GQy7eCmcGDA+2m+Brz1Ca5E3o63C2+B+2KnS1e1MEhMuKMruyCWc9EOsqzcmurxwxoqZLaoBg==;5:veOzGfEXX3HbBkMZJP2xQO3EZ/Wa0yGNLDlUvg+suJUoRbBGJXbdKgZcklmrKZHs82xXIkx18hNnSmgH6opQP4RY62IWIFnQAtpe4xCUSsZQl5Y6MyQLviv3ZEtNvn5djCS/rSZcC/EvYKdLEofhLw==;24:SgyIlxkwHG6RrrQJqvcWLXwmzb3He1ZnQaCH2ERkQqUzsMLVkKBD7QpOkysjEZGmbcP2XdipuIB4t6C1mUzDW9meQdpm/N4pYxfPpBVSkQQ=;7:R30twleV8iOG2BS5Z/bo6dyEUpWoCZnbLyrV1/mmWsdPQMwBIoyP4KNwCOSXITSFtq/v/rTwqCEFCoPaPcwQX+NIyi6G3Es5OqTwrkP7NtDQtFI/7aw0P8iiKHf4P/trAMnF0Bgx1bw2ydbpnXsRgrorYLRz9Q/+tA0uC+o3KQlWQCgtFMr9eXMRApXbs7oCXvye98pN3599Wn6CDBjq/y35rxgJtCvyLxSEvWIBj+k= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Sep 2017 10:34:18.9686 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0301MB2144 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 29.09.17 03:23, Yury Norov wrote: > On Thu, Sep 28, 2017 at 09:04:03PM +0300, Volodymyr Babchuk wrote: >> From: Volodymyr Babchuk >> >> These functions will be used to pass information about shared >> buffers to OP-TEE. >> >> Signed-off-by: Volodymyr Babchuk >> --- >> drivers/tee/optee/call.c | 48 +++++++++++++++++++++++++++++++++++++++ >> drivers/tee/optee/optee_private.h | 4 ++++ >> 2 files changed, 52 insertions(+) >> >> diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c >> index f7b7b40..f8e044d 100644 >> --- a/drivers/tee/optee/call.c >> +++ b/drivers/tee/optee/call.c >> @@ -11,6 +11,7 @@ >> * GNU General Public License for more details. >> * >> */ >> +#include >> #include >> #include >> #include >> @@ -442,3 +443,50 @@ void optee_disable_shm_cache(struct optee *optee) >> } >> optee_cq_wait_final(&optee->call_queue, &w); >> } >> + >> +/** >> + * optee_fill_pages_list() - write list of user pages to given shared >> + * buffer. >> + * >> + * @dst: page-aligned buffer where list of pages will be stored > > I'm not much familiar with the subsystem you work on, but I don't > understand why the type of dst is u64*. If it's just a buffer, it > should be void *. Also, if we assuming running it on arm were pointers > are 32-bit, the result of page_to_phys() will be u32, and you will > waste half of your u64 array for storing zeroes; this line: > *dst = page_to_phys(pages[i]); Yep. There is defined ABI between OP-TEE OS and OP-TEE clients. That ABI demands that page addresses should be stored in 64-bit fields even on 32-bit architectures. >> + * @pages: array of pages that represents shared buffer >> + * @num_pages: number of entries in @pages >> + * >> + * @dst should be big enough to hold list of user page addresses and >> + * links to the next pages of buffer >> + */ >> +void optee_fill_pages_list(u64 *dst, struct page **pages, size_t num_pages) >> +{ >> + size_t i; >> + >> + /* TODO: add support for RichOS page sizes that != 4096 */ >> + BUILD_BUG_ON(PAGE_SIZE != OPTEE_MSG_NONCONTIG_PAGE_SIZE); > > RichOS stands for Linux? Why I am still not a rich OS developer? :) I'm asking the same question :) Yes, in terms of TEE, Linux is RichOS and OP-TEE is TrustedOS. > This is the first occurrence of the term in kernel sources, please > explain it. I'd rather change "RichOS" to "Linux". > Also, I think that it would be more logical to add the dependency on > page size to Kconfig, not here, and move the comment there, so user > will be simply unable to build the whole module. I event didn't thought of this. Thank you for suggestion. Will do in this way. >> + for (i = 0; i < num_pages; i++, dst++) { >> + /* Check if we are going to roll over the page boundary */ >> + if (IS_ALIGNED((uintptr_t)(dst + 1), >> + OPTEE_MSG_NONCONTIG_PAGE_SIZE)) { >> + *dst = virt_to_phys(dst + 1); >> + dst++; >> + } > > Is my understanding correct that @dst is not a simple array of buffer > page addresses? Instead, it has a complex structure: First 511 records > store buffer page entries, and last one points to the next page of dst. > Is it somehow documented? Also, did you consider to create a header structure > for the buffer page, like memory allocators do? You can place there number > of entries, pointer to the next page, maybe some flags. I think it will be > more transparent, especially if we consider communication protocol between > independent software products. This is documented in the previous patch "tee: optee: Update protocol definitions" (5/14). I like your idea about header structure. Just to clarify: it should be structure that covers whole page. Like that described in the previous patch: + * struct page_data { + * uint64_t pages_array[OPTEE_MSG_NONCONTIG_PAGE_SIZE/sizeof(uint64_t) - 1]; + * uint64_t next_page_data; + * }; Right? From mboxrd@z Thu Jan 1 00:00:00 1970 From: volodymyr_babchuk@epam.com (Volodymyr Babchuk) Date: Fri, 29 Sep 2017 13:34:13 +0300 Subject: [PATCH v1 06/14] tee: optee: add page list manipulation functions In-Reply-To: <20170929002300.zxu4n47m5jdymdyt@yury-thinkpad> References: <1506621851-6929-1-git-send-email-volodymyr_babchuk@epam.com> <1506621851-6929-7-git-send-email-volodymyr_babchuk@epam.com> <20170929002300.zxu4n47m5jdymdyt@yury-thinkpad> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 29.09.17 03:23, Yury Norov wrote: > On Thu, Sep 28, 2017 at 09:04:03PM +0300, Volodymyr Babchuk wrote: >> From: Volodymyr Babchuk >> >> These functions will be used to pass information about shared >> buffers to OP-TEE. >> >> Signed-off-by: Volodymyr Babchuk >> --- >> drivers/tee/optee/call.c | 48 +++++++++++++++++++++++++++++++++++++++ >> drivers/tee/optee/optee_private.h | 4 ++++ >> 2 files changed, 52 insertions(+) >> >> diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c >> index f7b7b40..f8e044d 100644 >> --- a/drivers/tee/optee/call.c >> +++ b/drivers/tee/optee/call.c >> @@ -11,6 +11,7 @@ >> * GNU General Public License for more details. >> * >> */ >> +#include >> #include >> #include >> #include >> @@ -442,3 +443,50 @@ void optee_disable_shm_cache(struct optee *optee) >> } >> optee_cq_wait_final(&optee->call_queue, &w); >> } >> + >> +/** >> + * optee_fill_pages_list() - write list of user pages to given shared >> + * buffer. >> + * >> + * @dst: page-aligned buffer where list of pages will be stored > > I'm not much familiar with the subsystem you work on, but I don't > understand why the type of dst is u64*. If it's just a buffer, it > should be void *. Also, if we assuming running it on arm were pointers > are 32-bit, the result of page_to_phys() will be u32, and you will > waste half of your u64 array for storing zeroes; this line: > *dst = page_to_phys(pages[i]); Yep. There is defined ABI between OP-TEE OS and OP-TEE clients. That ABI demands that page addresses should be stored in 64-bit fields even on 32-bit architectures. >> + * @pages: array of pages that represents shared buffer >> + * @num_pages: number of entries in @pages >> + * >> + * @dst should be big enough to hold list of user page addresses and >> + * links to the next pages of buffer >> + */ >> +void optee_fill_pages_list(u64 *dst, struct page **pages, size_t num_pages) >> +{ >> + size_t i; >> + >> + /* TODO: add support for RichOS page sizes that != 4096 */ >> + BUILD_BUG_ON(PAGE_SIZE != OPTEE_MSG_NONCONTIG_PAGE_SIZE); > > RichOS stands for Linux? Why I am still not a rich OS developer? :) I'm asking the same question :) Yes, in terms of TEE, Linux is RichOS and OP-TEE is TrustedOS. > This is the first occurrence of the term in kernel sources, please > explain it. I'd rather change "RichOS" to "Linux". > Also, I think that it would be more logical to add the dependency on > page size to Kconfig, not here, and move the comment there, so user > will be simply unable to build the whole module. I event didn't thought of this. Thank you for suggestion. Will do in this way. >> + for (i = 0; i < num_pages; i++, dst++) { >> + /* Check if we are going to roll over the page boundary */ >> + if (IS_ALIGNED((uintptr_t)(dst + 1), >> + OPTEE_MSG_NONCONTIG_PAGE_SIZE)) { >> + *dst = virt_to_phys(dst + 1); >> + dst++; >> + } > > Is my understanding correct that @dst is not a simple array of buffer > page addresses? Instead, it has a complex structure: First 511 records > store buffer page entries, and last one points to the next page of dst. > Is it somehow documented? Also, did you consider to create a header structure > for the buffer page, like memory allocators do? You can place there number > of entries, pointer to the next page, maybe some flags. I think it will be > more transparent, especially if we consider communication protocol between > independent software products. This is documented in the previous patch "tee: optee: Update protocol definitions" (5/14). I like your idea about header structure. Just to clarify: it should be structure that covers whole page. Like that described in the previous patch: + * struct page_data { + * uint64_t pages_array[OPTEE_MSG_NONCONTIG_PAGE_SIZE/sizeof(uint64_t) - 1]; + * uint64_t next_page_data; + * }; Right?