On 19/08/2024 10:55, Julien Grall wrote:
Hi Ayan,
On 19/08/2024 10:45, Ayan Kumar Halder wrote:
I am ok with this. This has the benefit that the change can be
contained within arch/arm if we do the following :-
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index cb2c0a16b8..26f7406278 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -329,7 +329,9 @@ void asmlinkage __init start_xen(unsigned long
boot_phys_offset,
setup_mm();
+#ifdef CONFIG_MMU
vm_init();
+#endif
/* Parse the ACPI tables for possible boot-time configuration */
acpi_boot_table_init();
Are we ok with this ?
The definition of vm_init() is in xen/include/xen/vmap.h. If I enclose
it using any CONFIG_XXX (like I have done in the current patch), then
I need to introduce it in common/Kconfig and define it for x86 and
PPC. I would prefer to contain the change within arch/arm only if
possible.
Just to clarify, are you suggesting to just protect the call vm_init().
In other word, common/vmap.c would still be included in the final binary
for the MPU?
If yes, then I think it would be a bit odd... Someone could still call
vmap() and this would not break until runtime.
So I don't see how we could get away from modifying the common code.
Readying my previous reply again. I think the confusion comes from:
> But maybe ARCH_VMAP was an incorrect suggestion. It might be better
to gate with the !MMU (IIRC this would imply MPU).
This was specifically referring to the branch predictor Kconfig. This
was not a suggestion to avoid introducing ARCH_VMAP.
Cheers,
--
Julien Grall
