On 01.04.2025 10:58, Luca Fancellu wrote:
> From: Penny Zheng <penny.zh...@arm.com>
>
> ARM MPU system doesn't need to use paging memory pool, as MPU memory
> mapping table at most takes only one 4KB page, which is enough to
> manage the maximum 255 MPU memory regions, for all EL2 stage 1
> translation and EL1 stage 2 translation.
>
> Introduce ARCH_PAGING_MEMPOOL Kconfig common symbol, selected for Arm
> MMU systems and x86. Removed stubs from RISC-V now that the common code
> provide them and the functions are not gonna be used.
>
> Wrap the code inside 'construct_domU' that deal with p2m paging
> allocation in a new function 'domain_p2m_set_allocation', protected
> by ARCH_PAGING_MEMPOOL, this is done in this way to prevent polluting
> the former function with #ifdefs and improve readability
>
> Introduce arch_{get,set}_paging_mempool_size stubs for architecture
> with !ARCH_PAGING_MEMPOOL.
>
> Remove 'struct paging_domain' from Arm 'struct arch_domain' when the
> field is not required.
>
> Signed-off-by: Penny Zheng <penny.zh...@arm.com>
> Signed-off-by: Wei Chen <wei.c...@arm.com>
> Signed-off-by: Luca Fancellu <luca.fance...@arm.com>
> Reviewed-by: Michal Orzel <michal.or...@amd.com> # arm
> Reviewed-by: Oleksii Kurochko <oleksii.kuroc...@gmail.com> # riscv
Acked-by: Jan Beulich <jbeul...@suse.com>
> @@ -114,9 +115,25 @@ void arch_get_info_guest(struct vcpu *v,
> vcpu_guest_context_u c);
> int arch_initialise_vcpu(struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg);
> int default_initialise_vcpu(struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void)
> arg);
>
> +#ifdef CONFIG_ARCH_PAGING_MEMPOOL
> +
> int arch_get_paging_mempool_size(struct domain *d, uint64_t *size /* bytes
> */);
> int arch_set_paging_mempool_size(struct domain *d, uint64_t size /* bytes
> */);
>
> +#else /* !CONFIG_ARCH_PAGING_MEMPOOL */
> +
> +static inline int arch_get_paging_mempool_size(struct domain *d, uint64_t
> *size)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> +static inline int arch_set_paging_mempool_size(struct domain *d, uint64_t
> size)
> +{
> + return -EOPNOTSUPP;
> +}
Arguably while "set" will of course need to fail (perhaps unless size was zero),
"get" may be fine to uniformly succeed, reporting back a size of 0. But we can
switch to that alternative model whenever a need arises, I guess.
Jan
