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

[Itaru Kitayama <itaru.kitayama@fujitsu.com>]

On Fri, Aug 14, 2026 at 11:42:24AM +0100, Wei-Lin Chang wrote:
> 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 <weilin.chang@arm.com>
> > > ---
> 
> [...]
> 
> > >  
> > > +/*
> > > + * 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?

Yes, makes sense. I was mostly wondering about the sturct name,
kvm_guest_s2_mapping you introduced, since this is only needed for a guest 
acting as a hypervisor. No strong opinion.

Thanks,
Itaru.

> 
> Thanks,
> Wei-Lin Chang
> 
> > 
> > Thanks,
> > Itaru.
> > 
> 
> [...]