Message-ID: <aO0G9Ycu_SlISBih@google.com>
Date: Mon, 13 Oct 2025 07:04:37 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Shivank Garg <shivankg@....com>
Cc: pbonzini@...hat.com, david@...hat.com, kvm@...r.kernel.org, 
	linux-coco@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH V3 kvm-x86/gmem 1/2] KVM: guest_memfd: move
 kvm_gmem_get_index() and use in kvm_gmem_prepare_folio()

FWIW, there's no need to put the base (target?) branch in the subject.  The
branch name is often incomplete information; by the time someone goes to apply
the patch, the branch may have changed significantly, or maybe have even been
deleted, e.g. I use ephemeral topic branch for kvm-x86 that get deleted once
their content is merge to kvm/next.

>From Documentation/process/maintainer-kvm-x86.rst, my strong preference is that
contributors always use kvm-x86/next as the base branch,

  Base Tree/Branch
  ~~~~~~~~~~~~~~~~
  Fixes that target the current release, a.k.a. mainline, should be based on
  ``git://git.kernel.org/pub/scm/virt/kvm/kvm.git master``.  Note, fixes do not
  automatically warrant inclusion in the current release.  There is no singular
  rule, but typically only fixes for bugs that are urgent, critical, and/or were
  introduced in the current release should target the current release.
  
  Everything else should be based on ``kvm-x86/next``, i.e. there is no need to
  select a specific topic branch as the base.  If there are conflicts and/or
  dependencies across topic branches, it is the maintainer's job to sort them
  out.
  
  The only exception to using ``kvm-x86/next`` as the base is if a patch/series
  is a multi-arch series, i.e. has non-trivial modifications to common KVM code
  and/or has more than superficial changes to other architectures' code.  Multi-
  arch patch/series should instead be based on a common, stable point in KVM's
  history, e.g. the release candidate upon which ``kvm-x86 next`` is based.  If
  you're unsure whether a patch/series is truly multi-arch, err on the side of
  caution and treat it as multi-arch, i.e. use a common base.

and then use the --base option with git format-patch to capture the exact hash.

  Git Base
  ~~~~~~~~
  If you are using git version 2.9.0 or later (Googlers, this is all of you!),
  use ``git format-patch`` with the ``--base`` flag to automatically include the
  base tree information in the generated patches.
  
  Note, ``--base=auto`` works as expected if and only if a branch's upstream is
  set to the base topic branch, e.g. it will do the wrong thing if your upstream
  is set to your personal repository for backup purposes.  An alternative "auto"
  solution is to derive the names of your development branches based on their
  KVM x86 topic, and feed that into ``--base``.  E.g. ``x86/pmu/my_branch_name``,
  and then write a small wrapper to extract ``pmu`` from the current branch name
  to yield ``--base=x/pmu``, where ``x`` is whatever name your repository uses to
  track the KVM x86 remote.

My pushes to kvm-x86/next are always --force pushes (it's rebuilt like linux-next,
though far less frequently), but when pushing, I also push a persistent tag so
that the exact object for each incarnation of kvm-x86/next is reachable.  Combined
with --base, that makes it easy to apply a patch/series even months/years after
the fact (assuming I didn't screw up or forget the tag).

Powered by blists - more mailing lists