Message-ID: <aO1CGlKGso4LLtS5@google.com>
Date: Mon, 13 Oct 2025 11:16:58 -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()

On Mon, Oct 13, 2025, Sean Christopherson wrote:
> 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,

Oh, right, this is a funky situation though due to kvm-x86/gmem not yet being
folded into kvm-x86/next.  So yeah, calling out the base branch is helpful in
that case, but providing the --base commit is still preferred (and of course,
they don't have to be mutually exclusive).

>   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