[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 11/11] xen/arm: List static shared memory regions as /memory nodes
- To: Michal Orzel <michal.orzel@xxxxxxx>
- From: Luca Fancellu <Luca.Fancellu@xxxxxxx>
- Date: Tue, 26 Mar 2024 14:19:23 +0000
- Accept-language: en-GB, en-US
- Arc-authentication-results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com])
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
- Arc-message-signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Z+tYe4elhZdJp+BiMVTqTs9S+x6YORR9gCYEcIpP5hk=; b=HNxcGru1NLElXHBtn2d8Qo/UJEGbzANSiP/9Yg4vHsT2lrTJU+AQ7K2/WNlfb+Cn1Gn2Ety3+p0BWW/l0DdER9PcWHf/mVhZJTAxnUH9AGcuKPEdgZdEhD7M2zhrt/s9beWlx0lMarsCVIC6UWAc+c7oohr8z+hhV3ZsADwp4v5UjQESwEUyq8npNplZhnL0cq9/rhwF/mWkZnzsYHLxRTUMXJALrlrbfnb1xc/E2FqdxvcAnMWkWlAvjrQLyRW8Ibt2T+6BN8OeBKpbX9JzjXUq+SLiS/wQ/RPHZlHhLp90M+alfZNweM89qYqOxUYpQx1709RmELXmiPqs88bn2A==
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Z+tYe4elhZdJp+BiMVTqTs9S+x6YORR9gCYEcIpP5hk=; b=lIzwr0BXk8lLvbWHShXfMTJWuv3dIIzKP+cKaHDFOAbEMFLZa2kcLHJ5R2TythkZaXkB6XX/lZuiIytnd+VX+satsaydKPZJpfgVB9G5ApM7BBGnOuyMEZJRN5zviS68Xn2NtUIuJf0onETfaeZYvZaXt2ZUcj68Sd0/Q6S2paPWQXyraBfdTyt1jRgX7HqEy4i5UwYisVhctQA3VGadzLqKaCrlra+Ockhir0EoxFql76Un6Ic2V5Ehzu0SOhV6+nxKxKveMuRNPELVFisYMaOBq8PYmfR//gO7WqITsSl80YPFqY8QtlOZ9GiRGgN8KI4pPfzvAVoLTSfLKLvIbw==
- Arc-seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=TEwintZXPnOIzpiwbyWE04CVa/Hyti2gyQtsOcqasYpWGU8/znzLp74ImTcS57l9llqZriqek+I0R2qF13Q+T1JBfH5h7zg78WcNW0CJxkmty8NAdWZA8VgHxIMBLcdgYryRqNMeVjO/OSj6LOS8n2MAZLaIHcIu4qnG3o8Hc0P2RC4Go6+VMMCikUAVKT5xgQ6u0RLH1xy2WGugoBSpmf/93/gszdFMYj1m0XM/SLR58AGUQuuR3y3n4v2O+4cKNl/WWMqJfLPlxXHx2bvBlr+l7ewsga6lJByw9gTwAh/bEyn6v1UESEl1/YynvXyw9mDRpYjZfWW77ypGt5SKwA==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RfzbmzTNejDD+wKeAaEZlKWRi/PO2O+eQO3vYq4WUhm2W8tiW0smlC9ZcRTu90b/mOd6jULuXMmB124/5ZSTW25CZNlNrNsu7TX9/VTZvDbzCCht/mXtO1hxhMuX8xnY+EHhWHG3TDH5dIIyBIaypkUx8ZfzpYM07Vt1bfQDRLmiuzB0lZzJTfkIcrlOvtI80xS69CQcbjBbGW1/pYkeI+9pnwE3zMPLXHybGfJCCE0hdiSb7HWtbyNq9lry8dbP7sIatngY/gcLrUHqJJa4yIzkypY9ZswKVHrjvdLNHmcx0jHTDwSPk4cNvx945X+WgCHIrkiS6ygUTvLOiAiXjg==
- Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
- Delivery-date: Tue, 26 Mar 2024 14:19:43 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Nodisclaimer: true
- Thread-index: AQHadH3e45Ool8yPzEGouaBUJ1T0kbFIPF2AgAHrzQA=
- Thread-topic: [PATCH 11/11] xen/arm: List static shared memory regions as /memory nodes
> On 25 Mar 2024, at 08:58, Michal Orzel <michal.orzel@xxxxxxx> wrote:
>
> Hi Luca,
>
Hi Michal,
> On 12/03/2024 14:03, Luca Fancellu wrote:
>>
>>
>> Currently Xen is not exporting the static shared memory regions
>> to the device tree as /memory node, this commit is fixing this
>> issue.
> Looking at the implementation, you will always call make_shm_memory_node()
> twice. For the first
> time, to create /memory node and for the second time to create entry under
> /reserved-memory. Also,
> you will create a separate /memory node for every single shmem region instead
> of combining them
> in a single /memory region like make_memory_node() would do. Can't we reuse
> this function for simplicity?
You mean using make_memory_node() to populate /reserved-memory and /memory? I
feel they are very different
In terms of properties to be created, so I don’t think we should create a
make_memory_node() that does both.
Otherwise if you were suggesting to modify make_memory_node() only for what
concerns the /memory nodes,
it might be feasible, however there are some parts that need to be skipped with
some flags (all the code accessing .type
member), if I understand correctly you like this function because it doesn’t
create one node for every bank, but it creates
reg addresses instead, in that case I could modify the current
make_shm_memory_node() to do the same.
>
> Also, afaict it is not forbidden to specify shmem range (correct me if I'm
> wrong), where guest address will be
> within with RAM allocated by Xen (e.g. GPA RAM range 0x40000000 - 0x60000000
> and shmem is at 0x50000000). In this case,
> you would create yet another /memory node that would result in overlap (i.e.
> more than one /memory node specifying the same range).
This is a good point I didn’t think about, yes currently the code is creating
overlapping nodes in that case, wow so it means I
need to compute the non overlapping regions and emit a /memory node then! :)
ouch
Please let me know if I understood correctly your comments.
Cheers,
Luca
>
> ~Michal
|
