Hi Jan,
On 09/08/2024 10:34, Jan Beulich wrote:
On 08.08.2024 17:50, Ayan Kumar Halder wrote:
On 08/08/2024 13:49, Jan Beulich wrote:
On 08.08.2024 14:09, Ayan Kumar Halder wrote:
@@ -58,9 +58,13 @@ config PADDR_BITS
default 40 if ARM_PA_BITS_40
default 48 if ARM_64
+config HAS_VMAP
+ def_bool y
With this being always enabled, ...
I had to define the config somewhere. It seemed this is the correct
place to define as HAS_VMAP will be turned off when MPU is introduced.
So, it will be
config HAS_VMAP
def_bool n
At that time, only MMU will select HAS_VMAP.
Well, but why is it not simply
config HAS_VMAP
bool
from the very beginning? (There should never be "def_bool n" imo, btw.)
--- a/xen/include/xen/vmap.h
+++ b/xen/include/xen/vmap.h
@@ -141,7 +141,9 @@ void *arch_vmap_virt_end(void);
/* Initialises the VMAP_DEFAULT virtual range */
static inline void vm_init(void)
{
+#ifdef CONFIG_MMU
vm_init_type(VMAP_DEFAULT, (void *)VMAP_VIRT_START,
arch_vmap_virt_end());
+#endif
}
What about non-Arm, which all have MMUs but no corresponding Kconfig
setting?
AFAICS , the only file that is of our concern xen/common/vmap.c It is
enclosed with VMAP_VIRT_START which is defined in mmu specific file
(xen/arch/arm/include/asm/mmu/layout.h).
So, it will not be compiled for Arm MPU arch.
Yet that wasn't my question. I asked about non-Arm, for all of which it
looks like you're changing behavior of vm_init() (by suddenly making it
do nothing).
Oh now I see what you mean. There is no CONFIG_MMU is x86 , yet it is
used to enclose a common code which is a mistake.
So, we should introduce HAS_VMAP in xen/common/Kconfig and select it
from X86, X86_64 and Arm.
Is my understanding correct ?
- Ayan
