Re: [PATCH v3 18/23] KVM: s390: Switch to new gmap

[Claudio Imbrenda]

On Tue, 18 Nov 2025 16:14:38 +0100
Heiko Carstens <hca@xxxxxxxxxxxxx> wrote:

> On Thu, Nov 06, 2025 at 05:11:12PM +0100, Claudio Imbrenda wrote:
> > Switch KVM/s390 to use the new gmap code.
> > 
> > Remove includes to <gmap.h> and include "gmap.h" instead; fix all the
> > existing users of the old gmap functions to use the new ones instead.
> > 
> > Signed-off-by: Claudio Imbrenda <imbrenda@xxxxxxxxxxxxx>
> > ---
> >  arch/s390/Kconfig                   |   2 +-
> >  arch/s390/include/asm/kvm_host.h    |   5 +-
> >  arch/s390/include/asm/mmu_context.h |   4 -
> >  arch/s390/include/asm/tlb.h         |   3 -
> >  arch/s390/kvm/Makefile              |   2 +-
> >  arch/s390/kvm/diag.c                |   2 +-
> >  arch/s390/kvm/gaccess.c             | 552 +++++++++++----------
> >  arch/s390/kvm/gaccess.h             |  16 +-
> >  arch/s390/kvm/gmap-vsie.c           | 141 ------
> >  arch/s390/kvm/gmap.c                |   6 +-
> >  arch/s390/kvm/intercept.c           |  15 +-
> >  arch/s390/kvm/interrupt.c           |   2 +-
> >  arch/s390/kvm/kvm-s390.c            | 727 ++++++++--------------------
> >  arch/s390/kvm/kvm-s390.h            |  20 +-
> >  arch/s390/kvm/priv.c                | 207 +++-----
> >  arch/s390/kvm/pv.c                  |  64 +--
> >  arch/s390/kvm/vsie.c                | 117 +++--
> >  arch/s390/mm/gmap_helpers.c         |  29 --
> >  18 files changed, 710 insertions(+), 1204 deletions(-)
> >  delete mode 100644 arch/s390/kvm/gmap-vsie.c  
> 
> ...
> 
> > @@ -389,27 +358,13 @@ static int handle_sske(struct kvm_vcpu *vcpu)
> > +		scoped_guard(read_lock, &vcpu->kvm->mmu_lock) {
> > +			rc = dat_cond_set_storage_key(vcpu->arch.mc, vcpu->arch.gmap->asce,
> > +						      gpa_to_gfn(start), key, &oldkey,
> > +						      m3 & SSKE_NQ, m3 & SSKE_MR, m3 & SSKE_MC);  
> 
> ...
> 
> > @@ -1159,19 +1106,13 @@ static int handle_pfmf(struct kvm_vcpu *vcpu)
> > +			scoped_guard(read_lock, &vcpu->kvm->mmu_lock) {
> > +				rc = dat_cond_set_storage_key(vcpu->arch.mc, vcpu->arch.gmap->asce,
> > +							      gpa_to_gfn(start), key,
> > +							      NULL, nq, mr, mc);  
> 
> For the above two users I don't see any code which fills the arch.mc
> cache reliably. But chances are that I just missed it, since this
> patch is huge.

that's not necessarily a problem; if the cache is empty an atomic
allocation is attempted, which is allowed to fail. I have to check
whether we do handle the -ENOMEM case properly, though! otherwise it is
indeed a problem