Hi Ayan,
> On 4 Feb 2025, at 19:23, Ayan Kumar Halder wrote:
>
> Secondary cpus initialization is not yet supported. Thus, we print an
> appropriate message and put the secondary cpus in WFE state.
>
> Signed-off-by: Ayan Kumar Halder
> ---
Reviewed-by: Luca Fancellu
Hi Ayan,
> On 4 Feb 2025, at 19:23, Ayan Kumar Halder wrote:
>
> Define enable_boot_cpu_mm() for the Armv8-R AArch64.
>
> Like boot-time page table in MMU system, we need a boot-time MPU protection
> region configuration in MPU system so Xen can fetch code and data from normal
> memory.
>
> To
Hi Ayan,
> On 4 Feb 2025, at 19:23, Ayan Kumar Halder wrote:
>
> For AArch32, refer to ARM DDI 0568A.c ID110520.
> MPU_REGION_SHIFT is same between AArch32 and AArch64 (HPRBAR).
> Also, NUM_MPU_REGIONS_SHIFT is same between AArch32 and AArch64
> (HMPUIR).
>
> Signed-off-by: Ayan Kumar Halder
>
0, HTCR)
> +#endif
I was wondering if here it was better, for readability, to have this part
defined in the arm32/mmu/head.S and
arm32/mpu/head.S could have implemented a stub, maybe the maintainer could help
with that.
Anyway this solution works for me.
Reviewed-by: Luca Fancellu
>
> mov_w r0, HSCTLR_SET
> mcr CP32(r0, HSCTLR)
> --
> 2.25.1
>
>
n line with what is done for arm64.
Reviewed-by: Luca Fancellu
k" are equally aligned */
> +BUILD_BUG_ON(alignof(struct membanks) != alignof(struct membank));
Apologies for not catching the issue for your v1, probably I didn't understand
very well the test itself,
why are we checking that the structure have the same alignment?
I see we c
virt()")
> Signed-off-by: Michal Orzel
> ---
I’ve tested this one and it fix the compilation issue on the above setup, I’ve
also tested
that it doesn’t introduce issues on other setup (e.g. arm64)
Reviewed-by: Luca Fancellu
Tested-by: Luca Fancellu
bank
> structures")
> Signed-off-by: Michal Orzel
> ---
Apart from Julien’s comments for which I’ll leave you both to agree on a
solution, I’ve reproduced
the issue and tested that your change is fixing it and it’s not breaking a
different setup (e.g. 64 bit).
Reviewed-by: Luca Fancellu
Tested-by: Luca Fancellu
14593e3995a ("xen/device-tree: Allow region overlapping with
/memreserve/ ranges")
Signed-off-by: Luca Fancellu
Reviewed-by: Michal Orzel
---
Changes from v2:
- Banks created by Xen should be MEMORY type. (Michal)
- Add R-by Michal
Changes from v1:
- Changed commit title and body msg
>>
>>>
---
---
xen/arch/arm/domain_build.c | 13 -
xen/arch/arm/include/asm/kernel.h | 5 -
xen/arch/arm/static-shmem.c | 3 ++-
xen/include/xen/bootfdt.h | 16
4 files changed, 26 insertions(+), 11 deletions(-)
Hi Michal,
> On 9 Jan 2025, at 10:00, Michal Orzel wrote:
>
> Hi Luca,
>
> Is this patch for 4.20? I would say so, therefore it should have "for-4.20"
> tag and Oleksii as release manager
> should be CCed. Doing it now.
Thanks, I forgot the procedure
>
>> ---
>> ---
>> xen/arch/arm/domain_b
14593e3995a ("xen/device-tree: Allow region overlapping with
/memreserve/ ranges")
Signed-off-by: Luca Fancellu
---
Changes from v1:
- Changed commit title and body msg
- initialised max_banks and type for all structures using 'struct membanks_hdr'
I didn't get why the fixe
> On 8 Jan 2025, at 09:01, Luca Fancellu wrote:
>
>
>
>> On 8 Jan 2025, at 07:57, Michal Orzel wrote:
>>
>> In the original patch e7a80636f16e ("xen/arm: add cache coloring support
>> for Xen image"), the stub was added under wrong assumption
mption is
> incorrect as we already rely on DCE for cases like this one. Therefore
> drop the stub, that otherwise would be a place potentially prone to
> errors in the future.
>
> Suggested-by: Julien Grall
> Signed-off-by: Michal Orzel
> ---
Reviewed-by: Luca Fancellu
Hi Julien and Michal,
> On 23 Dec 2024, at 10:45, Julien Grall wrote:
>
> Hi,
>
> On 23/12/2024 10:42, Michal Orzel wrote:
>> On 23/12/2024 11:06, Julien Grall wrote:
>>>
>>>
>>> Hi Michal,
>>>
>>> On 23/12/2024 07:58, Micha
tly
used while managing kernel_info structures, it's good to have it
for completeness.
Fixes: a14593e3995a ("xen/device-tree: Allow region overlapping with
/memreserve/ ranges")
Signed-off-by: Luca Fancellu
---
xen/arch/arm/include/asm/kernel.h | 5 -
1 file changed, 4 inser
s: add cppcheck tool to the xen-analysis.py
> script)
> Signed-off-by: Ariel Otilibili
> --
Reviewed-by: Luca Fancellu
pygrub understand default entry in
> string format")
> Fixes: 622e368758b ("Add ZFS libfsimage support patch")
> Fixes: 02b26c02c7c ("xen/scripts: add cppcheck tool to the xen-analysis.py
> script")
> Fixes: 56c0063f4e7 ("xen/misra: xen-analysis.py:
from init data bootinfo, as it will be needed
after destroying the init data section, rename it to using_static_heap
and use it to tell whether the Xen static heap feature is enabled.
Signed-off-by: Penny Zheng
Signed-off-by: Wei Chen
Signed-off-by: Luca Fancellu
Reviewed-by: Michal Orzel
from init data bootinfo, as it will be needed
after destroying the init data section, rename it to using_static_heap
and use it to tell whether the Xen static heap feature is enabled.
Signed-off-by: Penny Zheng
Signed-off-by: Wei Chen
Signed-off-by: Luca Fancellu
---
Changes from v5:
- Drop Jan
Hi Michal,
> On 11 Dec 2024, at 11:59, Michal Orzel wrote:
>
>
>
> On 11/12/2024 12:11, Luca Fancellu wrote:
>>
>>
>> From: Penny Zheng
>>
>> If the Xen heap is statically configured in Device Tree, its size is
>> definite, so
from init data bootinfo, as it will be needed
after destroying the init data section, rename it to using_static_heap
and use it to tell whether the Xen static heap feature is enabled.
Signed-off-by: Penny Zheng
Signed-off-by: Wei Chen
Signed-off-by: Luca Fancellu
Reviewed-by: Jan Beulich
_banks.
> ---
Hi Michal,
it looks good to me, I’ve also tested in our CI and no issues!
Reviewed-by: Luca Fancellu
Tested-by: Luca Fancellu
Hi Julien,
> On 6 Dec 2024, at 19:19, Julien Grall wrote:
>
> Hi Luca,
>
> On 03/12/2024 09:48, Luca Fancellu wrote:
>> diff --git a/xen/arch/arm/mmu/setup.c b/xen/arch/arm/mmu/setup.c
>> index 9664e85ee6c0..8c87649bc88e 100644
>> --- a/xen/arch/arm/mmu/
> On 3 Dec 2024, at 15:54, Luca Fancellu wrote:
>
> Hi Ayan,
>
> sorry for the separate message, I've spotted another thing where I’m in doubt
>
>> On 27 Nov 2024, at 18:39, Ayan Kumar Halder
>> wrote:
>>
>> CONFIG_EARLY_UART_SIZE is
Hi Ayan,
sorry for the separate message, I've spotted another thing where I’m in doubt
> On 27 Nov 2024, at 18:39, Ayan Kumar Halder wrote:
>
> CONFIG_EARLY_UART_SIZE is introduced to let user provide physical size of
> early UART. Unlike MMU where we map a page in the virtual address space,
>
HI,
> On 2 Dec 2024, at 20:38, Julien Grall wrote:
>
> Hi Jan,
>
> On 02/12/2024 07:52, Jan Beulich wrote:
>> On 30.11.2024 18:15, Julien Grall wrote:
>>> On 29/11/2024 22:12, Volodymyr Babchuk wrote:
Jan Beulich writes:
> On 29.11.2024 02:49, Volodymyr Babchuk wrote:
>> --- a/con
needs to be CONFIG_*
Once these are addressed and taking care also of Julien's comment:
Reviewed-by: Luca Fancellu mailto:luca.fance...@arm.com>>
Cheers,
Luca
1-penny.zh...@arm.com/
Changes between v2 and v3:
- New patch
- changes to previous patch are listed inside them
Luca Fancellu (4):
common/vmap: Fall back to simple allocator when !HAS_VMAP
arm/setup: Move MMU specific extern declarations to mmu/setup.h
xen/arm: Use vmap_contig instead
Move some extern declarations related to MMU structures and define
from asm/setup.h to asm/mmu/setup.h, in order to increase encapsulation
and allow the MPU part to build, since it has no clue about them.
Signed-off-by: Luca Fancellu
Acked-by: Julien Grall
---
CHanges from v3:
- add Ack-by
it is used only on MMU
systems.
Signed-off-by: Luca Fancellu
---
Changes to v3:
- changed SPDX to reflect original file
Changes to v2:
- New patch
---
---
xen/arch/arm/mm.c | 40 -
xen/arch/arm/mmu/Makefile | 1 +
xen/arch/arm/mmu/mm.c
ned-off-by: Luca Fancellu
---
Changes from v3:
- use #define-s instead of static inline functions
Changes from v2:
- Don't protect declarations.
Changes from v1:
- put back static inline iounmap
- changed commit message
- hide not used declaration for system with !HAS_VMAP
- correct funct
Currently the arm code uses __vmap function in few parts to map
physically contiguous pages, vmap_contig was introduced recently
and does the same because it's a wrapper for __vmap, so use the
latter instead of the direct __vmap function.
Signed-off-by: Luca Fancellu
Acked-by: Julien
from init data bootinfo, as it will be needed
after destroying the init data section, rename it to using_static_heap
and use it to tell whether the Xen static heap feature is enabled.
Signed-off-by: Penny Zheng
Signed-off-by: Wei Chen
Signed-off-by: Luca Fancellu
---
Changes from v3:
- Removed
tinfo = BOOTINFO_INIT;
>
> Fixes: a14593e3995a ("xen/device-tree: Allow region overlapping with
> /memreserve/ ranges")
> Signed-off-by: Michal Orzel
> ---
Thanks Michal, I realise our internal CI is not testing a configuration with
CONFIG_ACPI=y and
CONFIG_STATIC_SHM=y, this is why I missed it.
Reviewed-by: Luca Fancellu mailto:luca.fance...@arm.com>>
Cheers,
Luca
>>>
>>> Just to double check: Was it at least considered to use simple #define-s
>>> to effect the aliasing? Wrapper functions like the above ones have the
>>> downside of needing touching (easy to miss) when the wrapped function
>>> types change in whichever minor way. (And yes, I do understand
Hi Jan,
> On 29 Nov 2024, at 11:06, Jan Beulich wrote:
>
> On 29.11.2024 10:12, Luca Fancellu wrote:
>> --- a/xen/include/xen/xvmalloc.h
>> +++ b/xen/include/xen/xvmalloc.h
>> @@ -40,20 +40,46 @@
>> ((typeof(ptr))_xvrealloc(ptr,
Currently the arm code uses __vmap function in few parts to map
physically contiguous pages, vmap_contig was introduced recently
and does the same because it's a wrapper for __vmap, so use the
latter instead of the direct __vmap function.
Signed-off-by: Luca Fancellu
Acked-by: Julien
it is used only on MMU
systems.
Signed-off-by: Luca Fancellu
---
Changes to v2:
- New patch
---
---
xen/arch/arm/mm.c | 40 -
xen/arch/arm/mmu/Makefile | 1 +
xen/arch/arm/mmu/mm.c | 61 +++
3 files changed, 62 insertions(+
1-penny.zh...@arm.com/
Changes between v2 and v3:
- New patch
- changes to previous patch are listed inside them
Luca Fancellu (4):
common/vmap: Fall back to simple allocator when !HAS_VMAP
arm/setup: Move MMU specific extern declarations to mmu/setup.h
xen/arm: Use vmap_contig instead
ned-off-by: Luca Fancellu
---
Changes from v2:
- Don't protect declarations.
Changes from v1:
- put back static inline iounmap
- changed commit message
- hide not used declaration for system with !HAS_VMAP
- correct function declared in xvmalloc.h to be static inline
- prefer '#if
from init data bootinfo, as it will be needed
after destroying the init data section.
Introduce a new helper using_static_heap() to tell whether Xen Heap
is statically configured in the Device Tree.
Signed-off-by: Penny Zheng
Signed-off-by: Wei Chen
Signed-off-by: Luca Fancellu
---
Changes from
Move some extern declarations related to MMU structures and define
from asm/setup.h to asm/mmu/setup.h, in order to increase encapsulation
and allow the MPU part to build, since it has no clue about them.
Signed-off-by: Luca Fancellu
---
Changes from v2:
- No changes
Changes from v1:
- Moved
> On 26 Nov 2024, at 13:29, Jan Beulich wrote:
>
> On 26.11.2024 14:25, Luca Fancellu wrote:
>>> This reads better, thanks. Follow-on question: Is what is statically
>>> configured for the heap guaranteed to never overlap with anything passed
>>> to init_
Hi Jan,
>
> This reads better, thanks. Follow-on question: Is what is statically
> configured for the heap guaranteed to never overlap with anything passed
> to init_domheap_pages() in those places that you touch?
I think so, the places of the check are mainly memory regions related to boot
mod
Hi Jan,
thanks for your review
> On 25 Nov 2024, at 16:32, Jan Beulich wrote:
>
> On 19.11.2024 09:58, Luca Fancellu wrote:
>> From: Penny Zheng
>>
>> If Xenheap is statically configured in Device Tree, its size is
>> definite. So, the memory shall not be
Hi Jan,
> On 25 Nov 2024, at 16:21, Jan Beulich wrote:
>
> On 19.11.2024 09:58, Luca Fancellu wrote:
>> --- a/xen/include/xen/vmap.h
>> +++ b/xen/include/xen/vmap.h
>> @@ -5,12 +5,19 @@
>> * purpose area (VMAP_DEFAULT) and a livepatch-specific area (VMAP_XE
print
> all the endpoints as inclusive.
>
> Signed-off-by: Michal Orzel
> ---
Looks good to me!
Reviewed-by: Luca Fancellu
Outside early boot there are other places where we print exclusive ranges,
do you know if there is any general style we should apply or does it depend on
case by case?
Cheers,
Luca
1-penny.zh...@arm.com/
Luca Fancellu (3):
common/vmap: Fall back to simple allocator when !HAS_VMAP
arm/setup: Move MMU specific extern declarations to mmu/setup.h
xen/arm: Use vmap_contig instead of __vmap where it's possible
Penny Zheng (1):
xen/arm: do not give memory back to st
Move some extern declarations related to MMU structures and define
from asm/setup.h to asm/mmu/setup.h, in order to increase encapsulation
and allow the MPU part to build, since it has no clue about them.
Signed-off-by: Luca Fancellu
---
Changes from v1:
- Moved extern to mmu/setup.h instead of
as it will be needed
after destroying the init data section.
Introduce a new helper xen_is_using_staticheap() to tell whether Xenheap
is statically configured in the Device Tree.
Signed-off-by: Penny Zheng
Signed-off-by: Wei Chen
Signed-off-by: Luca Fancellu
---
Changes from v1:
- moved static_he
otect with #ifdef
CONFIG_HAS_VMAP all the declaration that won't be used in a
MPU system built without HAS_VMAP.
Signed-off-by: Luca Fancellu
---
Changes from v1:
- put back static inline iounmap
- changed commit message
- hide not used declaration for system with !HAS_VMAP
- correct fu
Currently the arm code uses __vmap function in few parts to map
physically contiguous pages, vmap_contig was introduced recently
and does the same because it's a wrapper for __vmap, so use the
latter instead of the direct __vmap function.
Signed-off-by: Luca Fancellu
Acked-by: Julien
Hi Julien,
> On 17 Nov 2024, at 17:58, Julien Grall wrote:
>
> Hi Luca,
>
> On 15/11/2024 10:50, Luca Fancellu wrote:
>> From: Penny Zheng
>> In free_init_memory, we do not need to map the whole init section RW,
>> as only init text section is mapped RO in bo
Hi Julien,
> On 17 Nov 2024, at 17:46, Julien Grall wrote:
>
> Hi Luca,
>
> On 15/11/2024 10:50, Luca Fancellu wrote:
>> Move some extern declarations related to MMU structures and define
>> from asm/setup.h to asm/mm.h, in order to increase encapsulation and
>
Hi Julien,
>> -fw_unreserved_regions(addr, addr + size, init_domheap_pages, 0);
>> +if ( !xen_is_using_staticheap() )
>
> The comment on top needs to be updated.
I’ll update, is this ok:
/*
* In case Xen is not using the static heap feature, free the original
* kernel, update the poin
Hi Andrew,
+
+void *_xvrealloc(void *va, size_t size, unsigned int align)
+{
+return _xrealloc(va, size, align);
+}
+
+#endif
>>> Does this really compile with the wrappers not being static inline ?
>>>
>>> That aside, could we not do this using conditional
>>
>> Sure, I’ll wrap what can’t be used in MPU case with HAS_VMAP, I would like
>> to keep out:
>>
>> void *vmap_contig(mfn_t mfn, unsigned int nr);
>>
>> void vunmap(const void *va);
>>
>> void __iomem *ioremap(paddr_t pa, size_t len);
>>
>> static inline void iounmap(void __iomem *va)
>>
> On 15 Nov 2024, at 11:12, Jan Beulich wrote:
>
> On 15.11.2024 11:50, Luca Fancellu wrote:
>> --- a/xen/common/vmap.c
>> +++ b/xen/common/vmap.c
>> @@ -426,3 +426,10 @@ void *_xvrealloc(void *va, size_t size, unsigned int
>> align)
>>
>>
> On 15 Nov 2024, at 12:00, Andrew Cooper wrote:
>
> On 15/11/2024 10:50 am, Luca Fancellu wrote:
>> diff --git a/xen/include/xen/xvmalloc.h b/xen/include/xen/xvmalloc.h
>> index 440d85a284bb..802be6687085 100644
>> --- a/xen/include/xen/xvmalloc.h
>>
> On 15 Nov 2024, at 12:00, Andrew Cooper wrote:
>
> On 15/11/2024 10:50 am, Luca Fancellu wrote:
>> diff --git a/xen/include/xen/xvmalloc.h b/xen/include/xen/xvmalloc.h
>> index 440d85a284bb..802be6687085 100644
>> --- a/xen/include/xen/xvmalloc.h
>>
From: Penny Zheng
In free_init_memory, we do not need to map the whole init section RW,
as only init text section is mapped RO in boot time.
Signed-off-by: Luca Fancellu
---
This is this one:
https://patchwork.kernel.org/project/xen-devel/patch/20230626033443.2943270-19-penny.zh...@arm.com
as it will be needed
after destroying the init data section.
Introduce a new helper xen_is_using_staticheap() to tell whether Xenheap
is statically configured in the Device Tree.
Signed-off-by: Luca Fancellu
---
This is a rebase of this one:
https://patchwork.kernel.org/project/xen-devel/
ve iounmap function
to the vmap.c file, because it uses the vunmap function that
won't be compiled in when !HAS_VMAP.
Signed-off-by: Luca Fancellu
---
This is a rework of this one:
https://patchwork.kernel.org/project/xen-devel/patch/20230626033443.2943270-16-penny.zh...@arm.com/
wh
Move some extern declarations related to MMU structures and define
from asm/setup.h to asm/mm.h, in order to increase encapsulation and
allow the MPU part to build, since it has no clue about them.
Signed-off-by: Luca Fancellu
---
xen/arch/arm/include/asm/mmu/mm.h | 11 +++
xen/arch/arm
Currently the arm code uses __vmap function in few parts to map
physically contiguous pages, vmap_contig was introduced recently
and does the same because it's a wrapper for __vmap, so use the
latter instead of the direct __vmap function.
Signed-off-by: Luca Fancellu
---
xen/arc
1-penny.zh...@arm.com/
Luca Fancellu (3):
common/vmap: Fall back to simple allocator when !HAS_VMAP
arm/setup: Move MMU specific extern declarations to mmu/mm.h
xen/arm: Use vmap_contig instead of __vmap where it's possible
Penny Zheng (2):
xen/arm: only map the init tex
on_type type' field in order
to be able to identify static shared memory banks in meminfo_overlap_check(...).
While there, set a type for the memory recorded using meminfo_add_bank()
from efi-boot.h.
Fixes: 53dc37829c31 ("xen/arm: Add DT reserve map regions to
bootinfo.reserved_mem")
R
Hi Julien,
-}
+
+if ( (allow_match_type != MEMBANK_NONE) &&
+ (region_start == bank_start) && (region_end == bank_end) &&
>>>
>>> Why is this only an exact match?
>> Apparently what we are fixing is only a case where memreserve regions
>> matches
Hi Julien,
> On 13 Nov 2024, at 14:01, Julien Grall wrote:
>
> Hi Luca,
>
> On 06/11/2024 13:41, Luca Fancellu wrote:
>> There are some cases where the device tree exposes a memory range
>> in both /memreserve/ and reserved-memory node, in this case the
>> c
Hi all,
On 12 Nov 2024, at 16:11, Julien Grall wrote:
Hi,
On 12/11/2024 16:00, Stewart Hildebrand wrote:
On 11/12/24 08:00, Jan Beulich wrote:
All,
the release is due by the end of the month. Please point out backports you find
missing from the respective staging branch, but which you consider
Hi Ayan,
> On 11 Nov 2024, at 16:00, Ayan Kumar Halder wrote:
>
>
> On 11/11/2024 13:45, Julien Grall wrote:
>> Hi Ayan,
> Hi Julien,
>>
>> On 11/11/2024 13:24, Ayan Kumar Halder wrote:
>>> On 11/11/2024 11:12, Julien Grall wrote:
Hi,
>>> Hi Julien,
On 08/11/2024 19:59, Ayan K
enny Zheng
> Signed-off-by: Ayan Kumar Halder
> —
Reviewed-by: Luca Fancellu
;---0100 Device memory nGnRE") and Doc ID - 102670_0101_02_en
> Table 4-3, Armv8 architecture memory types (nGnRE - Corresponds to Device in
> Armv7 architecture). Also, it is mapped as outer shareable, RW at EL2 only
> and execution of instructions from the region is not permitted.
/xen/arch/arm/include/asm/mm.h
+++ b/xen/arch/arm/include/asm/mm.h
@@ -16,7 +16,7 @@
#if defined(CONFIG_MMU)
# include
-#else
+#elif !defined(CONFIG_MPU)
# error "Unknown memory management layout"
#endif
^— maybe this change is not needed at this stage, it will be soon though
Anyway:
Hi Michal,
> So we have 2 separate issues. I don't particularly like the concept of
> introducing MEMBANK_NONE
> and the changes below look a bit too much for me, given that for boot modules
> we can only have
> /memreserve/ matching initrd.
>
> Shawn patch fixes the first issue. AFAICT the sec
modules to have an
exact match with ranges from /memreserve/.
While there, set a type for the memory recorded during ACPI boot.
Fixes: 53dc37829c31 ("xen/arm: Add DT reserve map regions to
bootinfo.reserved_mem")
Reported-by: Shawn Anastasio
Reported-by: Grygorii Strashko
Signed-off-by
t;xen/misra: xen-analysis.py: fix parallel analysis
> Cppcheck errors")
> Fixes: db8acf31f96b ("x86/boot: Reuse code to relocate trampoline")
> Suggested-by: Luca Fancellu
> Signed-off-by: Andrew Cooper
> —
Looks good to me!
I’ve also checked with and without the patch and I can’t see any regression in
terms of cppcheck
issues report.
Reviewed-by: Luca Fancellu
Tested-by: Luca Fancellu
Hi Julien,
> On 30 Oct 2024, at 10:32, Julien Grall wrote:
>
> On 30/10/2024 10:08, Luca Fancellu wrote:
>> Hi Julien,
>>> On 30 Oct 2024, at 09:52, Julien Grall wrote:
>>>
>>> On Wed, 30 Oct 2024 at 09:17, Luca Fancellu wrote:
>>>>
>
Hi Julien,
> On 30 Oct 2024, at 09:52, Julien Grall wrote:
>
> On Wed, 30 Oct 2024 at 09:17, Luca Fancellu wrote:
>>
>> Hi Ayan,
>>
>> While I rebased the branch on top of your patches, I saw you’ve changed the
>> number of regions
>> mapped a
Hi Ayan,
While I rebased the branch on top of your patches, I saw you’ve changed the
number of regions
mapped at boot time, can I ask why?
Compared to
https://patchwork.kernel.org/project/xen-devel/patch/20230626033443.2943270-25-penny.zh...@arm.com/:
> +FUNC(enable_boot_cpu_mm)
> +
> +/*
Hi Ayan,
I forgot another thing:
> diff --git a/xen/arch/arm/arm64/mpu/head.S b/xen/arch/arm/arm64/mpu/head.S
> new file mode 100644
> index 00..9377ae778c
> --- /dev/null
> +++ b/xen/arch/arm/arm64/mpu/head.S
> @@ -0,0 +1,122 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + *
Hi Jan,
> On 29 Oct 2024, at 08:08, Jan Beulich wrote:
>
> On 28.10.2024 18:38, Ayan Kumar Halder wrote:
>> On 28/10/2024 15:01, Jan Beulich wrote:
>>> On 28.10.2024 15:39, Ayan Kumar Halder wrote:
On 28/10/2024 12:55, Jan Beulich wrote:
> On 28.10.2024 13:45, Ayan Kumar Halder wrote:
>
> On 29 Oct 2024, at 09:41, Jan Beulich wrote:
>
> On 29.10.2024 10:30, Luca Fancellu wrote:
>> Hi Jan,
>>
>>> On 29 Oct 2024, at 08:08, Jan Beulich wrote:
>>>
>>> On 28.10.2024 18:38, Ayan Kumar Halder wrote:
>>>> On 28/10/20
executable and the data cache is
> enabled.
>
> As enable_mpu() is invoked from enable_boot_cpu_mm(), one needs to save and
> restore the lr.
>
> Signed-off-by: Ayan Kumar Halder
> ---
>
It looks good to me:
Reviewed-by: Luca Fancellu
Hy Ayan,
>> +
>> +#define REGION_TEXT_PRBAR 0x38/* SH=11 AP=10 XN=00 */
>> +#define REGION_RO_PRBAR 0x3A/* SH=11 AP=10 XN=10 */
>> +#define REGION_DATA_PRBAR 0x32/* SH=11 AP=00 XN=10 */
>
> NIT: alignment
>
>> +
>> +#define REGION_NORMAL_PRLAR 0x0f/* NS=0
Hi Ayan,
> On 28 Oct 2024, at 12:45, Ayan Kumar Halder wrote:
>
> Define enable_boot_cpu_mm() for the AArch64-V8R system.
Could you use here "Armv8-R AArch64” instead of “AArch64-V8R"
>
> Like boot-time page table in MMU system, we need a boot-time MPU protection
> region configuration in MPU
.h so that it includes mpu/layout.h when CONFIG_MPU is
> defined.
>
> Signed-off-by: Wei Chen
> Signed-off-by: Jiamei.Xie
> Signed-off-by: Ayan Kumar Halder
> —
Looks good to me
Reviewed-by: Luca Fancellu
n critical data).
>
> Fixes: dac84b66cc9a ("xen: arm64: initial build + config changes, start of
> day code")
> Signed-off-by: Ayan Kumar Halder
> —
Looks good to me
Reviewed-by: Luca Fancellu
gt;>>>
>>>>
>>>> On 23/10/2024 17:06, Ayan Kumar Halder wrote:
>>>>> Hi Luca/Julien,
>>>>>
>>>>> On 22/10/2024 17:31, Luca Fancellu wrote:
>>>>>> Hi Julien,
>>>>>>
>>&g
Hi Julien,
> On 22 Oct 2024, at 14:13, Julien Grall wrote:
>
>
>
> On 22/10/2024 10:56, Luca Fancellu wrote:
>>> On 22 Oct 2024, at 10:47, Julien Grall wrote:
>>>
>>> Hi Luca,
>>>
>>> On 22/10/2024 10:41, Luca Fancellu wrote:
>
> On 22 Oct 2024, at 10:47, Julien Grall wrote:
>
> Hi Luca,
>
> On 22/10/2024 10:41, Luca Fancellu wrote:
>>> On 21 Oct 2024, at 17:27, Julien Grall wrote:
>> 2) dsb+isb barrier after enabling the MPU, since we are enabling the MPU but
>> also because we
Hi Julien,
> On 21 Oct 2024, at 17:27, Julien Grall wrote:
>
>
>
> On 21/10/2024 17:24, Luca Fancellu wrote:
>> Hi Ayan,
>>>>> + */
>>>>> +FUNC_LOCAL(enable_mpu)
>>>>> +mrs x0, SCTLR_EL2
>>>>> +bic x0
Hi Ayan,
>>> + */
>>> +FUNC_LOCAL(enable_mpu)
>>> +mrs x0, SCTLR_EL2
>>> +bic x0, x0, #SCTLR_ELx_BR /* Disable Background region */
>>> +orr x0, x0, #SCTLR_Axx_ELx_M/* Enable MPU */
>>> +orr x0, x0, #SCTLR_Axx_ELx_C/* Enable D-cache */
>>> +orr x0, x0, #
of the changes to the arch/arm part looks ok
to me:
Reviewed-by: Luca Fancellu
ov lr, x6
Shall these changes to enable_boot_cpu_mm be part of the previous commit?
The rest looks good to me:
Reviewed-by: Luca Fancellu
Hi Ayan,
> diff --git a/xen/arch/arm/arm64/mpu/head.S b/xen/arch/arm/arm64/mpu/head.S
> new file mode 100644
> index 00..4a21bc815c
> --- /dev/null
> +++ b/xen/arch/arm/arm64/mpu/head.S
> @@ -0,0 +1,130 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Start-of-day code for an
address at which Xen is loaded.
> + */
> +#define XEN_VIRT_START _AT(paddr_t, XEN_START_ADDRESS)
> +
> +#endif /* __ARM_MPU_LAYOUT_H__ */
^-- ASM___ARM__MPU__LAYOUT_H ?
Apart from that, the rest looks ok to me:
Reviewed-by: Luca Fancellu
Hi Ayan,
> On 10 Oct 2024, at 15:03, Ayan Kumar Halder wrote:
>
> If the BSS section is empty, then the function can just return.
>
> Signed-off-by: Ayan Kumar Halder
Reviewed-by: Luca Fancellu mailto:luca.fance...@arm.com>>
when MPU is supported?
In this case we are just having the Kconfig setting.
Apart from that, the rest looks good to me:
Reviewed-by: Luca Fancellu
1 - 100 of 1043 matches
Mail list logo
