[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 6/7] xen: introduce Kconfig ARCH_PAGING_MEMPOOL




On 3/19/25 12:35 PM, Jan Beulich wrote:
On 18.03.2025 14:05, Oleksii Kurochko wrote:
On 3/17/25 9:07 PM, Luca Fancellu wrote:
From: Penny Zheng<Penny.Zheng@xxxxxxx>

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, x86 and RISC-V.

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.zheng@xxxxxxx>
Signed-off-by: Wei Chen<wei.chen@xxxxxxx>
Signed-off-by: Luca Fancellu<luca.fancellu@xxxxxxx>
---
v3 changes:
  - Introduced ARCH_PAGING_MEMPOOL instead of HAS_PAGING_MEMPOOL
v2 changes:
  - make Kconfig HAS_PAGING_MEMPOOL common
  - protect also "xen,domain-p2m-mem-mb" reading with HAS_PAGING_MEMPOOL
  - do not define p2m_teardown{_allocation} in this patch
  - change commit message
---
  xen/arch/arm/Kconfig              |  1 +
  xen/arch/arm/dom0less-build.c     | 74 ++++++++++++++++++++-----------
  xen/arch/arm/include/asm/domain.h |  2 +
  xen/arch/riscv/Kconfig            |  1 +
  xen/arch/x86/Kconfig              |  1 +
  xen/common/Kconfig                |  3 ++
  xen/include/xen/domain.h          | 17 +++++++
  7 files changed, 73 insertions(+), 26 deletions(-)
For RISC-V:
  Reviewed-by: Oleksii Kurochko<oleksii.kurochko@xxxxxxxxx>
Mind me asking then why RISC-V needs this at this point? The stubs surely
were added to address some build issue, not because they are actively
meaningful?
Only because we have stubs and not to have redefinition compilation error.
And, yes, they are not actively meaningful now, at least.

I am okay with not enabling of this config for RISC-V but then seems to me
we have to drop stubs in riscv/stubs.c.

~ Oleksii





 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.