[RFC PATCH] Documentation/process: Add a maintainer entry profile for KVM/arm64

@@ -0,0 +1,163 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+KVM/arm64
+=========
+
+This document describes how KVM/arm64 (``arch/arm64/kvm/`` and the other
+files listed under "KERNEL VIRTUAL MACHINE FOR ARM64 (KVM/arm64)" in
+MAINTAINERS) is maintained.  It supplements
+Documentation/process/submitting-patches.rst.
+
+Overview
+--------
+
+KVM/arm64 is maintained by Marc Zyngier and Oliver Upton, assisted by the
+reviewers listed in MAINTAINERS.  Patches are discussed on
+kvmarm@lists.linux.dev, and linux-arm-kernel@lists.infradead.org is Cc'd as
+well.
+
+Trees
+~~~~~
+
+The KVM/arm64 tree is::
+
+  git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git
+
+This tree is used for integration only: no development happens in it, and
+most patches should not be based on it (see `Base for patches`_).  Its
+branches are:
+
+``next``
+  Changes queued for the next merge window.  linux-next merges this branch.
+
+``fixes``
+  Fixes for the release currently in its -rc phase.  linux-next merges this
+  branch too.
+
+[?: ``master`` still points at a 2020 commit.  Once it follows -rc1, should
+this document mention it?]
+
+Changes leave the tree as signed tags, which are pulled into the main KVM tree
+(``git://git.kernel.org/pub/scm/virt/kvm/kvm.git``) and from there reach Linus
+Torvalds.
+
+Unlike the KVM x86 tree, KVM/arm64 has no standing topic branches for
+contributors to base their work on.  Where a series also touches code
+maintained elsewhere, most often the arm64 architecture code, the maintainers
+may set up a shared stable branch, based on an -rc tag, that both trees merge.
+Say in the cover letter which parts of a series touch other subsystems.
+[?: Is this an accurate description of topic branches and of how
+cross-tree changes are handled?]
+
+Base for patches
+~~~~~~~~~~~~~~~~
+
+Base your patches on a tag published in Linus Torvalds' tree.  Patches based
+on linux-next or on ``kvmarm/next`` are discouraged.
+
+If your series depends on something that is not yet in mainline, such as
+another series under review or work already queued in ``kvmarm/next``, say so
+in the cover letter and name exactly what it applies on top of.  The
+maintainers may also ask for a series to be rebased onto ``kvmarm/next`` when
+it conflicts with work queued there.
+
+Use ``git format-patch --base`` so that the base commit is recorded in the
+patches.
+
+Submit Checklist Addendum
+-------------------------
+
+Recipients and threading
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+Send the whole series to all of the maintainers and reviewers listed for
+KVM/arm64, not a selection of them.  Post each new version as a new thread,
+with a cover letter for anything longer than a single patch.
+
+Subject lines
+~~~~~~~~~~~~~
+
+Changes to KVM/arm64 use the ``KVM: arm64:`` prefix, often followed by a
+sub-topic such as ``nv:`` or ``vgic:``.  Selftest changes use ``KVM: arm64:
+selftests:`` or ``KVM: selftests:``.
+``git log --oneline`` on the files you touch shows what is in use.
+
+Architecture references
+~~~~~~~~~~~~~~~~~~~~~~~
+
+KVM/arm64 code tracks the Arm Architecture Reference Manual (the "Arm ARM",
+document DDI0487) closely.  Where a change depends on architected behavior,
+explain why the change is needed and cite the Arm ARM in the commit message
+or in a comment.  Section numbers change between revisions of the Arm ARM,
+so give the revision along with the section, for example ``DDI0487L.a
+D24.2.70``.
+
+This differs from KVM x86, whose profile asks contributors not to cite
+section numbers.
+
+Testing
+~~~~~~~
+
+Say in the cover letter how the series was tested: which tests, and on which
+hardware or model.  The KVM selftests (``tools/testing/selftests/kvm/``) and
+kvm-unit-tests are the usual test suites.  Put selftest changes in patches of
+their own, separate from the KVM changes.
+
+KVM/arm64 can run in several modes, which are described under
+``kvm-arm.mode=`` in Documentation/admin-guide/kernel-parameters.txt.  Test
+the modes your change can affect.
+
+Do not draw conclusions about performance on hardware from measurements made
+on a software model such as QEMU or the Arm FVP.
+
+Changes to nested virtualization in particular are unlikely to be merged
+without test coverage.  Depending on the change, selftests may not be enough;
+the maintainers may ask for testing with a VMM, for example.
+
+Userspace API
+~~~~~~~~~~~~~
+
+Document changes to the userspace API, usually in
+Documentation/virt/kvm/api.rst or in the files under
+Documentation/virt/kvm/devices/ and Documentation/virt/kvm/arm/.
+
+Fixes
+~~~~~
+
+Add a ``Fixes:`` tag for bug fixes.  If the fix should go to stable kernels,
+add ``Cc: stable@vger.kernel.org``; the maintainers may add it when applying
+if the bug calls for it.
+
+Key Cycle Dates
+---------------
+
+Fixes for the current release are queued on ``fixes`` and sent throughout
+the -rc phase.  Changes for the next merge window are queued on ``next``.
+
+[?: What are the cut-offs: the last -rc for submitting new features, and the
+last -rc at which the maintainers decide what goes into the next merge
+window?]
+
+Review Cadence
+--------------
+
+Unless the maintainers ask for a new version sooner, allow at least a week
+between versions of a series, and only post a new version once there has
+been enough review to justify it.  Posting more often
+delays review rather than speeding it up.
+
+Pinging a series that has had no response is fine.
+
+Applied patches are normally acknowledged in reply to the posting, naming the
+branch (``next`` or ``fixes``) and the commits.  Commit IDs can still change
+before they reach mainline.
+
+Minor problems are often fixed up by the maintainers when applying; if they
+say "no need to resend", don't.
+
+Security issues
+---------------
+
+Bugs that let a guest attack its host, or a nested guest attack its guest
+hypervisor, should be reported as described in
+Documentation/process/security-bugs.rst.

@@ -14301,7 +14301,9 @@ R:	Zenghui Yu <yuzenghui@huawei.com>
 L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
 L:	kvmarm@lists.linux.dev
 S:	Maintained
+P:	Documentation/process/maintainer-kvm-arm64.rst
 T:	git git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git
+F:	Documentation/process/maintainer-kvm-arm64.rst
 F:	Documentation/virt/kvm/arm/
 F:	Documentation/virt/kvm/devices/arm*
 F:	arch/arm64/include/asm/kvm*