* [PATCH] KVM: arm64: Use consistent type for pool size
@ 2026-07-15 15:01 Mostafa Saleh
2026-07-26 14:01 ` Will Deacon
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: Mostafa Saleh @ 2026-07-15 15:01 UTC (permalink / raw)
To: linux-kernel, kvmarm, linux-arm-kernel
Cc: maz, oupton, seiden, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will, vdonnefort, tabba, Mostafa Saleh
All the pool sizes in the hypervisor are "unsigned long" but when
they get passed to hyp_early_alloc_contig() or hyp_pool_init() they get
truncated to 32-bits.
That is not a big problem at the moment as to overflow this we need
4G bytes of carveout (2 TB of host or guest system memory).
However when new users are added (as IOMMU) it is hard to reason
about the carveout size anymore.
Signed-off-by: Mostafa Saleh <smostafa@google.com>
---
For example in the SMMUv3 to avoid this overflow, I add a cap
for the pools size to UINT_MAX to work around this:
https://lore.kernel.org/linux-iommu/20260715115906.2664882-9-smostafa@google.com/
---
arch/arm64/kvm/hyp/include/nvhe/early_alloc.h | 2 +-
arch/arm64/kvm/hyp/include/nvhe/gfp.h | 4 ++--
arch/arm64/kvm/hyp/nvhe/early_alloc.c | 2 +-
arch/arm64/kvm/hyp/nvhe/page_alloc.c | 6 +++---
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/kvm/hyp/include/nvhe/early_alloc.h b/arch/arm64/kvm/hyp/include/nvhe/early_alloc.h
index dc61aaa56f31..462883c4e325 100644
--- a/arch/arm64/kvm/hyp/include/nvhe/early_alloc.h
+++ b/arch/arm64/kvm/hyp/include/nvhe/early_alloc.h
@@ -7,7 +7,7 @@
void hyp_early_alloc_init(void *virt, unsigned long size);
unsigned long hyp_early_alloc_nr_used_pages(void);
void *hyp_early_alloc_page(void *arg);
-void *hyp_early_alloc_contig(unsigned int nr_pages);
+void *hyp_early_alloc_contig(unsigned long nr_pages);
extern struct kvm_pgtable_mm_ops hyp_early_alloc_mm_ops;
diff --git a/arch/arm64/kvm/hyp/include/nvhe/gfp.h b/arch/arm64/kvm/hyp/include/nvhe/gfp.h
index 3766333bace9..3a428dc40b14 100644
--- a/arch/arm64/kvm/hyp/include/nvhe/gfp.h
+++ b/arch/arm64/kvm/hyp/include/nvhe/gfp.h
@@ -29,6 +29,6 @@ void hyp_get_page(struct hyp_pool *pool, void *addr);
void hyp_put_page(struct hyp_pool *pool, void *addr);
/* Used pages cannot be freed */
-int hyp_pool_init(struct hyp_pool *pool, u64 pfn, unsigned int nr_pages,
- unsigned int reserved_pages);
+int hyp_pool_init(struct hyp_pool *pool, u64 pfn, unsigned long nr_pages,
+ unsigned long reserved_pages);
#endif /* __KVM_HYP_GFP_H */
diff --git a/arch/arm64/kvm/hyp/nvhe/early_alloc.c b/arch/arm64/kvm/hyp/nvhe/early_alloc.c
index 00de04153cc6..9fef0c7d2185 100644
--- a/arch/arm64/kvm/hyp/nvhe/early_alloc.c
+++ b/arch/arm64/kvm/hyp/nvhe/early_alloc.c
@@ -21,7 +21,7 @@ unsigned long hyp_early_alloc_nr_used_pages(void)
return (cur - base) >> PAGE_SHIFT;
}
-void *hyp_early_alloc_contig(unsigned int nr_pages)
+void *hyp_early_alloc_contig(unsigned long nr_pages)
{
unsigned long size = (nr_pages << PAGE_SHIFT);
void *ret = (void *)cur;
diff --git a/arch/arm64/kvm/hyp/nvhe/page_alloc.c b/arch/arm64/kvm/hyp/nvhe/page_alloc.c
index 57f86aa0f82f..51460d420c94 100644
--- a/arch/arm64/kvm/hyp/nvhe/page_alloc.c
+++ b/arch/arm64/kvm/hyp/nvhe/page_alloc.c
@@ -229,12 +229,12 @@ void *hyp_alloc_pages(struct hyp_pool *pool, u8 order)
return hyp_page_to_virt(p);
}
-int hyp_pool_init(struct hyp_pool *pool, u64 pfn, unsigned int nr_pages,
- unsigned int reserved_pages)
+int hyp_pool_init(struct hyp_pool *pool, u64 pfn, unsigned long nr_pages,
+ unsigned long reserved_pages)
{
phys_addr_t phys = hyp_pfn_to_phys(pfn);
struct hyp_page *p;
- int i;
+ unsigned long i;
hyp_spin_lock_init(&pool->lock);
pool->max_order = min(MAX_PAGE_ORDER,
--
2.55.0.141.g00534a21ce-goog
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH] KVM: arm64: Use consistent type for pool size
2026-07-15 15:01 [PATCH] KVM: arm64: Use consistent type for pool size Mostafa Saleh
@ 2026-07-26 14:01 ` Will Deacon
2026-07-26 15:11 ` Fuad Tabba
2026-09-22 14:35 ` Mostafa Saleh
2 siblings, 0 replies; 4+ messages in thread
From: Will Deacon @ 2026-07-26 14:01 UTC (permalink / raw)
To: Mostafa Saleh
Cc: linux-kernel, kvmarm, linux-arm-kernel, maz, oupton, seiden,
joey.gouly, suzuki.poulose, yuzenghui, catalin.marinas,
vdonnefort, tabba
On Wed, Jul 15, 2026 at 03:01:25PM +0000, Mostafa Saleh wrote:
> All the pool sizes in the hypervisor are "unsigned long" but when
> they get passed to hyp_early_alloc_contig() or hyp_pool_init() they get
> truncated to 32-bits.
>
> That is not a big problem at the moment as to overflow this we need
> 4G bytes of carveout (2 TB of host or guest system memory).
>
> However when new users are added (as IOMMU) it is hard to reason
> about the carveout size anymore.
>
> Signed-off-by: Mostafa Saleh <smostafa@google.com>
> ---
> For example in the SMMUv3 to avoid this overflow, I add a cap
> for the pools size to UINT_MAX to work around this:
> https://lore.kernel.org/linux-iommu/20260715115906.2664882-9-smostafa@google.com/
> ---
> arch/arm64/kvm/hyp/include/nvhe/early_alloc.h | 2 +-
> arch/arm64/kvm/hyp/include/nvhe/gfp.h | 4 ++--
> arch/arm64/kvm/hyp/nvhe/early_alloc.c | 2 +-
> arch/arm64/kvm/hyp/nvhe/page_alloc.c | 6 +++---
> 4 files changed, 7 insertions(+), 7 deletions(-)
Acked-by: Will Deacon <will@kernel.org>
Will
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] KVM: arm64: Use consistent type for pool size
2026-07-15 15:01 [PATCH] KVM: arm64: Use consistent type for pool size Mostafa Saleh
2026-07-26 14:01 ` Will Deacon
@ 2026-07-26 15:11 ` Fuad Tabba
2026-09-22 14:35 ` Mostafa Saleh
2 siblings, 0 replies; 4+ messages in thread
From: Fuad Tabba @ 2026-07-26 15:11 UTC (permalink / raw)
To: Mostafa Saleh
Cc: linux-kernel, kvmarm, linux-arm-kernel, maz, oupton, seiden,
joey.gouly, suzuki.poulose, yuzenghui, catalin.marinas, will,
vdonnefort
On Wed, 15 Jul 2026 at 16:01, Mostafa Saleh <smostafa@google.com> wrote:
>
> All the pool sizes in the hypervisor are "unsigned long" but when
> they get passed to hyp_early_alloc_contig() or hyp_pool_init() they get
> truncated to 32-bits.
>
> That is not a big problem at the moment as to overflow this we need
> 4G bytes of carveout (2 TB of host or guest system memory).
>
> However when new users are added (as IOMMU) it is hard to reason
> about the carveout size anymore.
>
> Signed-off-by: Mostafa Saleh <smostafa@google.com>
Reviewed-by: Fuad Tabba <fuad.tabba@linux.dev>
Cheers,
/fuad
> ---
> For example in the SMMUv3 to avoid this overflow, I add a cap
> for the pools size to UINT_MAX to work around this:
> https://lore.kernel.org/linux-iommu/20260715115906.2664882-9-smostafa@google.com/
> ---
> arch/arm64/kvm/hyp/include/nvhe/early_alloc.h | 2 +-
> arch/arm64/kvm/hyp/include/nvhe/gfp.h | 4 ++--
> arch/arm64/kvm/hyp/nvhe/early_alloc.c | 2 +-
> arch/arm64/kvm/hyp/nvhe/page_alloc.c | 6 +++---
> 4 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/kvm/hyp/include/nvhe/early_alloc.h b/arch/arm64/kvm/hyp/include/nvhe/early_alloc.h
> index dc61aaa56f31..462883c4e325 100644
> --- a/arch/arm64/kvm/hyp/include/nvhe/early_alloc.h
> +++ b/arch/arm64/kvm/hyp/include/nvhe/early_alloc.h
> @@ -7,7 +7,7 @@
> void hyp_early_alloc_init(void *virt, unsigned long size);
> unsigned long hyp_early_alloc_nr_used_pages(void);
> void *hyp_early_alloc_page(void *arg);
> -void *hyp_early_alloc_contig(unsigned int nr_pages);
> +void *hyp_early_alloc_contig(unsigned long nr_pages);
>
> extern struct kvm_pgtable_mm_ops hyp_early_alloc_mm_ops;
>
> diff --git a/arch/arm64/kvm/hyp/include/nvhe/gfp.h b/arch/arm64/kvm/hyp/include/nvhe/gfp.h
> index 3766333bace9..3a428dc40b14 100644
> --- a/arch/arm64/kvm/hyp/include/nvhe/gfp.h
> +++ b/arch/arm64/kvm/hyp/include/nvhe/gfp.h
> @@ -29,6 +29,6 @@ void hyp_get_page(struct hyp_pool *pool, void *addr);
> void hyp_put_page(struct hyp_pool *pool, void *addr);
>
> /* Used pages cannot be freed */
> -int hyp_pool_init(struct hyp_pool *pool, u64 pfn, unsigned int nr_pages,
> - unsigned int reserved_pages);
> +int hyp_pool_init(struct hyp_pool *pool, u64 pfn, unsigned long nr_pages,
> + unsigned long reserved_pages);
> #endif /* __KVM_HYP_GFP_H */
> diff --git a/arch/arm64/kvm/hyp/nvhe/early_alloc.c b/arch/arm64/kvm/hyp/nvhe/early_alloc.c
> index 00de04153cc6..9fef0c7d2185 100644
> --- a/arch/arm64/kvm/hyp/nvhe/early_alloc.c
> +++ b/arch/arm64/kvm/hyp/nvhe/early_alloc.c
> @@ -21,7 +21,7 @@ unsigned long hyp_early_alloc_nr_used_pages(void)
> return (cur - base) >> PAGE_SHIFT;
> }
>
> -void *hyp_early_alloc_contig(unsigned int nr_pages)
> +void *hyp_early_alloc_contig(unsigned long nr_pages)
> {
> unsigned long size = (nr_pages << PAGE_SHIFT);
> void *ret = (void *)cur;
> diff --git a/arch/arm64/kvm/hyp/nvhe/page_alloc.c b/arch/arm64/kvm/hyp/nvhe/page_alloc.c
> index 57f86aa0f82f..51460d420c94 100644
> --- a/arch/arm64/kvm/hyp/nvhe/page_alloc.c
> +++ b/arch/arm64/kvm/hyp/nvhe/page_alloc.c
> @@ -229,12 +229,12 @@ void *hyp_alloc_pages(struct hyp_pool *pool, u8 order)
> return hyp_page_to_virt(p);
> }
>
> -int hyp_pool_init(struct hyp_pool *pool, u64 pfn, unsigned int nr_pages,
> - unsigned int reserved_pages)
> +int hyp_pool_init(struct hyp_pool *pool, u64 pfn, unsigned long nr_pages,
> + unsigned long reserved_pages)
> {
> phys_addr_t phys = hyp_pfn_to_phys(pfn);
> struct hyp_page *p;
> - int i;
> + unsigned long i;
>
> hyp_spin_lock_init(&pool->lock);
> pool->max_order = min(MAX_PAGE_ORDER,
> --
> 2.55.0.141.g00534a21ce-goog
>
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH] KVM: arm64: Use consistent type for pool size
2026-07-15 15:01 [PATCH] KVM: arm64: Use consistent type for pool size Mostafa Saleh
2026-07-26 14:01 ` Will Deacon
2026-07-26 15:11 ` Fuad Tabba
@ 2026-09-22 14:35 ` Mostafa Saleh
2 siblings, 0 replies; 4+ messages in thread
From: Mostafa Saleh @ 2026-09-22 14:35 UTC (permalink / raw)
To: linux-kernel, kvmarm, linux-arm-kernel
Cc: maz, oupton, seiden, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will, vdonnefort, tabba
On Wed, Jul 15, 2026 at 4:01 PM Mostafa Saleh <smostafa@google.com> wrote:
>
> All the pool sizes in the hypervisor are "unsigned long" but when
> they get passed to hyp_early_alloc_contig() or hyp_pool_init() they get
> truncated to 32-bits.
>
> That is not a big problem at the moment as to overflow this we need
> 4G bytes of carveout (2 TB of host or guest system memory).
>
> However when new users are added (as IOMMU) it is hard to reason
> about the carveout size anymore.
>
> Signed-off-by: Mostafa Saleh <smostafa@google.com>
Ping, as Sashiko reminded me about this:
https://lore.kernel.org/all/20260922132359.BB0381F000FF@smtp.kernel.org/
This has already been reviewed.
Thanks,
Mostafa
> ---
> For example in the SMMUv3 to avoid this overflow, I add a cap
> for the pools size to UINT_MAX to work around this:
> https://lore.kernel.org/linux-iommu/20260715115906.2664882-9-smostafa@google.com/
> ---
> arch/arm64/kvm/hyp/include/nvhe/early_alloc.h | 2 +-
> arch/arm64/kvm/hyp/include/nvhe/gfp.h | 4 ++--
> arch/arm64/kvm/hyp/nvhe/early_alloc.c | 2 +-
> arch/arm64/kvm/hyp/nvhe/page_alloc.c | 6 +++---
> 4 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/kvm/hyp/include/nvhe/early_alloc.h b/arch/arm64/kvm/hyp/include/nvhe/early_alloc.h
> index dc61aaa56f31..462883c4e325 100644
> --- a/arch/arm64/kvm/hyp/include/nvhe/early_alloc.h
> +++ b/arch/arm64/kvm/hyp/include/nvhe/early_alloc.h
> @@ -7,7 +7,7 @@
> void hyp_early_alloc_init(void *virt, unsigned long size);
> unsigned long hyp_early_alloc_nr_used_pages(void);
> void *hyp_early_alloc_page(void *arg);
> -void *hyp_early_alloc_contig(unsigned int nr_pages);
> +void *hyp_early_alloc_contig(unsigned long nr_pages);
>
> extern struct kvm_pgtable_mm_ops hyp_early_alloc_mm_ops;
>
> diff --git a/arch/arm64/kvm/hyp/include/nvhe/gfp.h b/arch/arm64/kvm/hyp/include/nvhe/gfp.h
> index 3766333bace9..3a428dc40b14 100644
> --- a/arch/arm64/kvm/hyp/include/nvhe/gfp.h
> +++ b/arch/arm64/kvm/hyp/include/nvhe/gfp.h
> @@ -29,6 +29,6 @@ void hyp_get_page(struct hyp_pool *pool, void *addr);
> void hyp_put_page(struct hyp_pool *pool, void *addr);
>
> /* Used pages cannot be freed */
> -int hyp_pool_init(struct hyp_pool *pool, u64 pfn, unsigned int nr_pages,
> - unsigned int reserved_pages);
> +int hyp_pool_init(struct hyp_pool *pool, u64 pfn, unsigned long nr_pages,
> + unsigned long reserved_pages);
> #endif /* __KVM_HYP_GFP_H */
> diff --git a/arch/arm64/kvm/hyp/nvhe/early_alloc.c b/arch/arm64/kvm/hyp/nvhe/early_alloc.c
> index 00de04153cc6..9fef0c7d2185 100644
> --- a/arch/arm64/kvm/hyp/nvhe/early_alloc.c
> +++ b/arch/arm64/kvm/hyp/nvhe/early_alloc.c
> @@ -21,7 +21,7 @@ unsigned long hyp_early_alloc_nr_used_pages(void)
> return (cur - base) >> PAGE_SHIFT;
> }
>
> -void *hyp_early_alloc_contig(unsigned int nr_pages)
> +void *hyp_early_alloc_contig(unsigned long nr_pages)
> {
> unsigned long size = (nr_pages << PAGE_SHIFT);
> void *ret = (void *)cur;
> diff --git a/arch/arm64/kvm/hyp/nvhe/page_alloc.c b/arch/arm64/kvm/hyp/nvhe/page_alloc.c
> index 57f86aa0f82f..51460d420c94 100644
> --- a/arch/arm64/kvm/hyp/nvhe/page_alloc.c
> +++ b/arch/arm64/kvm/hyp/nvhe/page_alloc.c
> @@ -229,12 +229,12 @@ void *hyp_alloc_pages(struct hyp_pool *pool, u8 order)
> return hyp_page_to_virt(p);
> }
>
> -int hyp_pool_init(struct hyp_pool *pool, u64 pfn, unsigned int nr_pages,
> - unsigned int reserved_pages)
> +int hyp_pool_init(struct hyp_pool *pool, u64 pfn, unsigned long nr_pages,
> + unsigned long reserved_pages)
> {
> phys_addr_t phys = hyp_pfn_to_phys(pfn);
> struct hyp_page *p;
> - int i;
> + unsigned long i;
>
> hyp_spin_lock_init(&pool->lock);
> pool->max_order = min(MAX_PAGE_ORDER,
> --
> 2.55.0.141.g00534a21ce-goog
>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2026-09-22 14:35 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-07-15 15:01 [PATCH] KVM: arm64: Use consistent type for pool size Mostafa Saleh
2026-07-26 14:01 ` Will Deacon
2026-07-26 15:11 ` Fuad Tabba
2026-09-22 14:35 ` Mostafa Saleh
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®