Re: [PATCH v3 00/23] KVM: s390: gmap rewrite, the real deal

[Claudio Imbrenda <imbrenda@linux.ibm.com>]

On Tue, 18 Nov 2025 16:28:15 +0100
Heiko Carstens <hca@linux.ibm.com> wrote:

> On Thu, Nov 06, 2025 at 05:10:54PM +0100, Claudio Imbrenda wrote:
> > This series is the last big series of the gmap rewrite. It introduces
> > the new code and actually uses it. The old code is then removed.
> > 
> > The insertions/deletions balance is negative both for this series, and
> > for the whole rewrite, also considering all the preparatory patches.
> > 
> > KVM on s390 will now use the mmu_notifier, like most other
> > architectures. The gmap address space is now completely separate from
> > userspace; no level of the page tables is shared between guest mapping
> > and userspace.
> > 
> > One of the biggest advantages is that the page size of userspace is
> > completely independent of the page size used by the guest. Userspace
> > can mix normal pages, THPs, hugetlbfs, and more.
> > 
> > Patches 1 to 6 are mostly preparations; introducing some new bits and
> > functions, and moving code around.
> > 
> > Patch 7 to 16 is the meat of the new gmap code; page table management
> > functions and gmap management. This is the code that will be used to
> > manage guest memory.
> > 
> > Patch 18 is unfortunately big; the existing code is converted to use
> > the new gmap and all references to the old gmap are removed. This needs
> > to be done all at once, unfortunately, hence the size of the patch.
> > 
> > Patch 19 and 20 remove all the now unused code.
> > 
> > Patch 21 and 22 allow for 1M pages to be used to back guests, and add
> > some more functions that are useful for testing.
> > 
> > Patch 23 fixes storage key manipulation functions, which would
> > otherwise be broken by the new code.  
> 
> I would guess patch 23 also needs to go into the already huge patch which
> switches everything to the new gmap code, since otherwise bisect will not work
> for anything that is storage key related.

yeah I was thinking of that.... I don't like it, but I can't see a
nicer solution either

> 
> Anyway, I can imagine some addon cleanups, but that can wait after this series
> is upstream.
> 
> At least from a "core s390 code view", without considering kvm this looks good
> to me. There is at least one known bug hiding in this huge rewrite - but just
> wanted to let you know that my concerns with the previous version have been
> addressed.