On Thu, Nov 28, 2024, Borislav Petkov wrote: > On Wed, Nov 27, 2024 at 01:57:54PM -0800, Sean Christopherson wrote: > > The attached patch is compile-tested only (the nested interactions in particular > > need a bit of scrutiny) and needs to be chunked into multiple patches, but I don't > > see any obvious blockers, and the diffstats speak volumes: > > I'd like to apply this and take a closer look but I don't know what it goes > against. It applies cleanly on my tree (github.com/kvm-x86/linux.git next) or Paolo's (git://git.kernel.org/pub/scm/virt/kvm/kvm.git next). > Btw, you could point me to some documentation explaining which branches in > the kvm tree people should use to base off work ontop. For KVM x86, from Documentation/process/maintainer-kvm-x86.rst: 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. where kvm-x86 is the aforementioned github.com/kvm-x86/linux.git.
