On 21/10/2024 16:24, Julien Grall wrote:
Hi Ayan,
Hi Julien,
On 21/10/2024 12:12, Ayan Kumar Halder wrote:
On 18/10/2024 14:41, Julien Grall wrote:
Hi Ayan,
Hi Julien,
On 10/10/2024 15:03, Ayan Kumar Halder wrote:
If the BSS section is empty, then the function can just return.
This is more than "can", right? If we don't do it, we will end up to
zero outside of BSS. This could be critical data...
s/can just/should
Also, I am tempted to suggest to add a Fixes tag because even if it
is unlikely BSS will be zero in the current Xen, it is also not
unlikely.
The tag would be:
Fixes: dac84b66cc9a ("xen: arm64: initial build + config changes,
start of day code")
Ack.
Signed-off-by: Ayan Kumar Halder <ayan.kumar.hal...@amd.com>
I saw the discussion. I don't have a strong opinion on the exact
approach choosen for zeroing. With the commit message updated:
Acked-by: Julien Grall <jgr...@amazon.com>
I propose that this patch to be committed. The changes to the commit
message can be done on commit.
---
Changes from :-
v1..v2 - New patch introduced in v3.
xen/arch/arm/arm64/head.S | 2 ++
Don't we need a similar change on the arm32 code?
I haven't looked at the arm32 code. My idea is to get the earlyboot
(ie the asm part) of Xen working on R82 and then do the similar
changes for R52 (ie arm32).
AFAIU, this change is not related to the MPU. So I would rather prefer
if we keep this change in sync. I am happy to send a patch for it if
you don't have time.
No worries, I can do it.
I will include the arm32 changes in this patch. So that we have a single
patch covering the issue for both arm64 and arm32.
- Ayan
