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

Hi,

On Fri, Aug 14, 2026 at 10:04:57AM +0900, Itaru Kitayama wrote:
> On Mon, Aug 10, 2026 at 09:50:34PM +0100, Wei-Lin Chang wrote:
> > In order to avoid unmapping all shadow stage-2 mappings when KVM
> > receives a MMU notifier unmap call, we have to keep track of the
> > canonical IPA -> nested IPA relationship of the shadow mappings
> > created. This essentially means tracking the guest's stage-2.
> > 
> > To do this, represent each mapping by struct kvm_guest_s2_mapping. It
> > stores the mapping's canonical IPA range and the nested IPA range using
> > two interval tree nodes. Both nodes will be inserted into their
> > respective interval trees called guest_s2_mappings. The canonical IPA
> > ranges will be stored in the tree within the canonical MMU, and the
> > nested IPA ranges will be stored in the corresponding nested MMU's tree.
> > 
> > For example:
> > 
> > struct kvm_guest_s2_mapping mapping1, mapping2;
> > 
> >     ---------------------> mapping2.canonical
> >     |                      mapping1.canonical
> >     |                          ^   (both stored in canonical mmu's tree)
> >     |                          |
> > --*****-----------------------*****----------- CIPA
> >    \\\\\                      |||||                  mapping1.nested_mmu
> >     \\\\\                     \\\\\                            |
> >      \\\\\                     \\\\\                           v
> > ------\\\\\---------------------*****--------- NIPA #1 (nested mmu #1)
> >        \\\\\                      |
> >         \\\\\                     -> mapping1.nested
> >          \\\\\                       (stored in nested mmu #1's tree)
> >           \\\\\
> > -----------*****------------------------------ NIPA #2 (nested mmu #2)
> >              |                                                 ^
> >              -> mapping2.nested                                |
> >                 (stored in nested mmu #2's tree)   mapping2.nested_mmu
> > 
> > Using the trees we can look up nodes in either of the IPA spaces, and
> > for each node, find the corresponding range in the other IPA space from
> > the other node in the enclosing kvm_guest_s2_mapping.
> > 
> > Define kvm_guest_s2_mapping and the interval tree here. Guest stage-2
> > mapping tracking will come in subsequent patches.
> > 
> > Signed-off-by: Wei-Lin Chang <[email protected]>
> > ---

[...]

> >  
> > +/*
> > + * 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;
> > +};
> 
> Is this to be used for normal (L1) guests? I guess this series is for
> shadow stage 2 unmapping optimization, so not sure.

Sorry I don't totally understand your question. Yes this series is
optimizing cases where a GPA (L1's PA) range have to be unmapped, from
an MMU notifier unmap call.

When we want to unmap a GPA range, the corresponding L2PAs must also be
unmapped from the shadow page tables. Before this series there is no way
of knowing what L2PAs are affected, so the code just calls
kvm_nested_s2_unmap() to unmap all shadow mappings.

Each struct kvm_guest_s2_mapping instance keeps one L1PA <-> L2PA
mapping record. For example:

canonical (L1PA space): [x, x+4K)  <- node stored in canonical MMU tree
nested (L2PA space):    [y, y+4K)  <- node stored in nested MMU tree

Does this make sense?

Thanks,
Wei-Lin Chang

> 
> Thanks,
> Itaru.
> 

[...]