Re: [PATCH v5 2/6] KVM: arm64: nv: Introduce guest stage-2 tracking structures

[Wei-Lin Chang]

On Sun, Sep 06, 2026 at 04:47:02PM +0100, Marc Zyngier wrote:

[...]

> > +/*
> > + * Record of a guest stage-2 mapping, storing canonical and nested IPA
> > + * ranges. Both ranges have the same size.
> > + */
> > +struct kvm_guest_s2_mapping {
> > +	struct interval_tree_node canonical;
> > +	struct interval_tree_node nested;
> > +	struct kvm_s2_mmu *nested_mmu;
> > +};
> > +
> 
> I'm trying hard to find a way to reduce the size of this structure,
> because this is IMO the only real problem with this approach.
> 
> Obviously, the only thing we could kill is this nested_mmu field, as
> everything else is used by the interval trees. I can see two ugly ways
> to do that:
> 
> - either we iterate over all shadow MMUs to find the corresponding
>   'nested' node: really costly if we have a lot of mappings and/or a
>   lot of shadow MMUs
> 
> - or we steal bits from the interval_tree_node to encode extra
>   information. One realisation is that all addresses are PAGE_SIZE
>   aligned, meaning that we have at least 12 bits that are always 0. We
>   could, for example, encode an index in the bottom bits of the
>   nested.start field. Probably easy enough, but may require some
>   careful masking (and the addition of an index in the s2_mmu
>   structure).
> 
> The result would be significant, as we could then use a 96 byte slab,
> which means the cost of a 1GB @4k granularity could fall to 24MB.

One way of meeting in the middle is to keep the nested_mmu pointer, and
use a dedicated kmem cache. That cache will then hand out exact 104-byte
objects.

That's 26MB for 1GB @4K.

This is a nice improvement from the current 128-byte allocations.
Although it's not as good as 96-byte allocations, the code logic can
remain simple. Would you take this approach?

Thanks,
Wei-Lin Chang

[...]