Re: [PATCH v4 13/27] KVM: s390: Prepare KVM/s390 for a second KVM module

[Steffen Eiden <seiden@linux.ibm.com>]

On Fri, Jul 10, 2026 at 11:22:29AM +0200, Christian Borntraeger wrote:
> 
> 
> Am 06.07.26 um 10:52 schrieb Steffen Eiden:
> > Lay the groundwork for a second KVM module. Guard KVM/s390 behind the
> > KVM_S390 config and turn CONFIG_KVM on if selected. Move all the
> > kvm_host definitions to _s390 postfixed headers. Prepare local header
> > include guards for a new location. Move gamp related tracing into a
> > separate file. While at it, rename the main KVM/s390 files from
> > s390-kvm.{c,h} to just s390.{c,h} to match the naming scheme of other
> > architectures.
> > 
> > No functional change.
> 
> [...]
> >   arch/s390/include/asm/kvm_host.h              | 774 +-----------------
> >   .../asm/{kvm_host.h => kvm_host_s390.h}       |   6 +-
> >   arch/s390/include/asm/kvm_host_types.h        | 347 +-------
> [...]
> >   copy arch/s390/include/asm/{kvm_host.h => kvm_host_s390.h} (99%)
> >   copy arch/s390/include/asm/{kvm_host_types.h => kvm_host_s390_types.h} (98%)
> This is just an "almost" rename only in the end. Maybe we can convince git to show a better diffstat to reflect that?
> 

The rename only part worked quite well (6 lined diff). I used
--find-copies / --break-rewrites with format-patch when creating this
patchfile to reduce the diff. Otherwhise we get a diff like: 

...
 arch/s390/include/asm/kvm_host.h            | 774 +------------------
 arch/s390/include/asm/kvm_host_s390.h       | 778 ++++++++++++++++++++
 arch/s390/include/asm/kvm_host_s390_types.h | 347 +++++++++
 arch/s390/include/asm/kvm_host_types.h      | 347 +--------
...

Which I think is more confusing and bloats the diff unessecary.

But I cannot find an option to convince git that kvm_host.h should be
treated as a new file. This problem seems to be out of scope for gits
heuristics.

The only way to get this smaller is to split up the patch but then the
first of the two patches will not compile.

> In any case, I guess we can handle patch 13 and patch 14 pretty soon upfront so that the patch series gets smaller and is easier to review.

yes +1.
I would argue that the gmap refactorings (PATCH 15-17) can get handled upfront as
well. They also have no functional changes as well.

FYI: I made some smaller cleanups on those refactrrings since monday.

	Steffen