Re: [PATCH v5 11/15] KVM: arm64: Reserve dirty ring space for the HDBSS buffer

[Leonardo Bras <leo.bras@arm.com>]

On Mon, Nov 09, 2026 at 06:03:03PM +0800, Tian Zheng wrote:
> 
> 
> On 9/29/2026 7:00 PM, sashiko-bot@kernel.org wrote:
> > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> > - [High] arm64: kvm: UAPI breakage for dirty ring size on 64KB page systems
> > --
> > 
> > commit 38dde0ab2f10c37402c620c7b1328624808205ad
> > Author: Tian Zheng <zhengtian10@huawei.com>
> > 
> > KVM: arm64: Reserve dirty ring space for the HDBSS buffer
> > 
> > This commit reserves space in the dirty ring for CPU-side dirty buffers by
> > implementing kvm_cpu_dirty_log_size(). It also pins the HDBSS buffer size to
> > PAGE_SIZE when the dirty ring is enabled.
> > 
> > > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> > > index 7bf82d65041c8..c1e09ba98d48a 100644
> > > --- a/arch/arm64/kvm/mmu.c
> > > +++ b/arch/arm64/kvm/mmu.c
> > [ ... ]
> > > @@ -2841,3 +2841,11 @@ void kvm_toggle_cache(struct kvm_vcpu *vcpu, bool was_enabled)
> > >   	trace_kvm_toggle_cache(*vcpu_pc(vcpu), was_enabled, now_enabled);
> > >   }
> > > +
> > > +int kvm_cpu_dirty_log_size(struct kvm *kvm)
> > > +{
> > > +	if (!system_supports_hdbss())
> > > +		return 0;
> > > +
> > > +	return kvm_hdbss_buffer_size(kvm) / sizeof(u64);
> > > +}
> > 
> > [Severity: High]
> > Does this calculation break the UAPI for standard dirty ring size requests on
> > 64KB page systems?
> > 
> > Since KVM_ARM_HDBSS_DEFAULT_SIZE is tied to PAGE_SIZE, this calculation scales
> > with the system page size. On a 64KB page system, kvm_hdbss_buffer_size() yields
> > 65536 bytes, returning 8192 reserved entries (65536 / 8).
> > 
> > When a userspace process requests a standard dirty ring size of 65536 bytes
> > (64KB) via KVM_ENABLE_CAP for KVM_CAP_DIRTY_LOG_RING, it seems the ioctl will
> > now fail:
> > 
> > virt/kvm/kvm_main.c:kvm_vm_ioctl_enable_cap() {
> >      ...
> > 	if (size < kvm_dirty_ring_get_rsvd_entries(kvm) *
> > 	    sizeof(struct kvm_dirty_gfn) || size < PAGE_SIZE)
> > 		return -EINVAL;
> >      ...
> > }
> > 
> > Because (8192 + 64) * 16 = 132096 bytes is greater than the requested 65536
> > bytes, the ioctl rejects previously valid userspace configurations with -EINVAL,
> > which would cause QEMU and other VMMs to fail to start VMs.
> > 
> > Could this buffer size be decoupled from PAGE_SIZE to avoid the entry inflation
> > and ABI breakage on 64KB page systems?
> > 
> 
> You were right, this is a real UAPI break on 64KB-page kernels. The
> PAGE_SIZE default made the ring reservation scale with the kernel page
> size, so a standard 64KB ring request got rejected there.
> 
> Leo, the PAGE_SIZE default goes back to your suggestion in the v4
> discussion at [1]:
> 
> > That means 512 entries in 4kB pagesize, an 8K entries in 64kB
> pagesize.
> 
> > I mean, yes, maybe we could allocate a 64k page, and set SZ=4K in
> HDBSSBR, but that would be a waste of memory, right?
> 
> If we keep PAGE_SIZE, the ring ABI stays broken on larger-page kernels,
> since the reservation keeps scaling with the page size. With SZ_4K there
> is still some breakage, the smallest ring sizes (4KB and 8KB), but that
> is the smallest scope we can get, because 4KB is the smallest buffer the
> hardware can encode. Defaulting to SZ_4K also brings our ring
> requirements in line with x86, where PML reserves the same fixed 576
> entries.
> 
> Do you think we should default to SZ_4K and accept the page waste you
> pointed out, or keep PAGE_SIZE?
> 

Maybe we should rethink the way of handling this, and maybe reserved 
entries is not the way out. 

(It was for x86, but it's a very different architecture, as I mentioned 
before)

Another approach could be to those reserved pages to not be counted in the 
ring size limit, but that could become really messy.

Thanks!
Leo