Re: [PATCH V3 kvm-x86/gmem 1/2] KVM: guest_memfd: move kvm_gmem_get_index() and use in kvm_gmem_prepare_folio()

["Garg, Shivank" <shivankg@amd.com>]

On 10/13/2025 11:46 PM, Sean Christopherson wrote:
> 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).

Thanks for the detailed explanation on --base usage. I wasn't aware of this 
flag and will use it going forward.

I see you've already merged these changes into kvm-x86/gmem. Should I resend 
these patches with kvm-x86/next and --base, or is the current version sufficient?

Thank you,
Shivank