[PATCH] MAINTAINERS: name the kvmarm/kvmarm next branch

[PATCH] MAINTAINERS: name the kvmarm/kvmarm next branch

[Matthias Goergens]

The T: entry for KERNEL VIRTUAL MACHINE FOR ARM64 (KVM/arm64) names
kvmarm/kvmarm without a branch.  The repository's HEAD (master,
0225fd5e0a6a) is a commit from 2020-05-01 that mainline already
contains.  linux-next pulls next from this repository (Next/Trees,
next-20260923), and on 2026-09-24 that branch carried work not yet in
mainline.  Name the branch so the entry identifies where development
happens.

Documentation/process/submitting-patches.rst sends contributors to the
T: entry to find the tree to prepare patches against, so a branch-less
entry whose HEAD is already in mainline points them at the wrong tree.

Signed-off-by: Matthias Goergens <matthias.goergens@gmail.com>
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index cc3cae2e378b..8394e0a1c149 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14301,7 +14301,7 @@ R:	Zenghui Yu <yuzenghui@huawei.com>
 L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
 L:	kvmarm@lists.linux.dev
 S:	Maintained
-T:	git git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git
+T:	git git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git next
 F:	Documentation/virt/kvm/arm/
 F:	Documentation/virt/kvm/devices/arm*
 F:	arch/arm64/include/asm/kvm*

base-commit: 40288c9206c17eb66a603262e06a58d300d0f279
-- 
2.55.0

Re: [PATCH] MAINTAINERS: name the kvmarm/kvmarm next branch

[Marc Zyngier]

On Thu, 24 Sep 2026 04:35:36 +0100,
Matthias Goergens <matthias.goergens@gmail.com> wrote:
> 
> The T: entry for KERNEL VIRTUAL MACHINE FOR ARM64 (KVM/arm64) names
> kvmarm/kvmarm without a branch.  The repository's HEAD (master,
> 0225fd5e0a6a) is a commit from 2020-05-01 that mainline already
> contains.  linux-next pulls next from this repository (Next/Trees,
> next-20260923), and on 2026-09-24 that branch carried work not yet in
> mainline.  Name the branch so the entry identifies where development
> happens.

But that's not reflecting the way we deal with this tree. No actual
development happens on that branch, as it is solely for integration.

Actually, no development happens in the kvmarm tree at all.

> 
> Documentation/process/submitting-patches.rst sends contributors to the
> T: entry to find the tree to prepare patches against, so a branch-less
> entry whose HEAD is already in mainline points them at the wrong tree.

Again, this is not how we work. We explicitly discourage patches
against -next. The only sane reference to base kvmarm patches on is a
published upstream tag from Linus' tree.

	M.

-- 
Jazz isn't dead. It just smells funny.

Re: [PATCH] MAINTAINERS: name the kvmarm/kvmarm next branch

[Matthias Goergens]

On Thu, 24 Sep 2026 07:59:21 +0100, Marc Zyngier wrote:
> But that's not reflecting the way we deal with this tree. No actual
> development happens on that branch, as it is solely for integration.
> [...]
> Again, this is not how we work. We explicitly discourage patches
> against -next. The only sane reference to base kvmarm patches on is a
> published upstream tag from Linus' tree.

Thanks for taking the time to explain; I'll drop this one and try to
leave out other integration-only trees.  The rest will say only which
branch linux-next merges, not that patches should be based on it.

It does leave a question I'd like your view on.  submitting-patches.rst
tells contributors to find the tree to base their work on through the
T: entry, and for KVM/arm64 that leads to a HEAD from 2020, while the
rule you describe isn't written down anywhere MAINTAINERS points to
(the entry has no P: profile).  Would it help if the MAINTAINERS header
said that T: names where a subsystem's tree lives, and that the base
for patches can differ and belongs in the P: profile?  I'm preparing
patches documenting T: anyway, so I could fold that in.

Thanks,
Matthias

Re: [PATCH] MAINTAINERS: name the kvmarm/kvmarm next branch

[Marc Zyngier]

On Thu, 24 Sep 2026 09:30:36 +0100,
Matthias Goergens <matthias.goergens@gmail.com> wrote:
> 
> On Thu, 24 Sep 2026 07:59:21 +0100, Marc Zyngier wrote:
> > But that's not reflecting the way we deal with this tree. No actual
> > development happens on that branch, as it is solely for integration.
> > [...]
> > Again, this is not how we work. We explicitly discourage patches
> > against -next. The only sane reference to base kvmarm patches on is a
> > published upstream tag from Linus' tree.
> 
> Thanks for taking the time to explain; I'll drop this one and try to
> leave out other integration-only trees.  The rest will say only which
> branch linux-next merges, not that patches should be based on it.

> It does leave a question I'd like your view on.  submitting-patches.rst
> tells contributors to find the tree to base their work on through the
> T: entry, and for KVM/arm64 that leads to a HEAD from 2020, while the

Well, we can forward master to -rc1 when it lands. That's no big deal.

> rule you describe isn't written down anywhere MAINTAINERS points to
> (the entry has no P: profile).  Would it help if the MAINTAINERS header
> said that T: names where a subsystem's tree lives, and that the base
> for patches can differ and belongs in the P: profile?  I'm preparing
> patches documenting T: anyway, so I could fold that in.

Sure. Though that wouldn't help for kvmarm, as we don't have such a
recorded profile.

Documentation/process/maintainer-kvm-x86.rst could be used as a
starting point, but there are some significant differences in the way
we manage the tree, such as the absence of topic branches, the
references to documentation, and of course the base for most patches.

If someone feels the urge to write some documentation...

	M.

-- 
Jazz isn't dead. It just smells funny.

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

[Matthias Goergens]

KVM/arm64 has no P: entry in MAINTAINERS, so nothing tells a contributor
that the kvmarm tree is used for integration only, or that most patches
are expected to be based on a tag from Linus' tree rather than on
kvmarm/next or linux-next.  Marc Zyngier said a profile would help and
pointed at the KVM x86 one as a starting point, noting where KVM/arm64
differs: the absence of topic branches, the references to documentation,
and the base for most patches.

Add a profile covering the trees and how changes flow through them, the
base for patches, recipients, subject prefixes, architecture references,
testing, key cycle dates and review cadence, and point the KVM/arm64
entry at it.

Link: https://lore.kernel.org/all/875wzu4vuv.wl-maz@kernel.org/
Signed-off-by: Matthias Goergens <matthias.goergens@gmail.com>
---
Marc, this is the profile you said would help, in the thread this
replies to.  Where you and Oliver haven't said anything on the list, it
follows the KVM x86 profile and general practice, so please correct
anything that doesn't match how you work.  Three things need your call
in particular; they are marked [?: ...] in the text:

- master: once it follows -rc1, should the profile mention it?

- Cross-tree changes: the draft says there are no standing topic
  branches for contributors, and that when a series also touches arm64
  code the maintainers may set up a shared stable branch on an -rc tag.
  Is that right?

- Cut-offs: which is the last -rc for new features, and when do you
  decide what goes into the merge window?

I've kept this RFC to the people in this thread.  Once you're happy
with it, I'll widen the circle to the documentation maintainers and
lists.

 .../process/maintainer-kvm-arm64.rst          | 163 ++++++++++++++++++
 MAINTAINERS                                   |   2 +
 2 files changed, 165 insertions(+)
 create mode 100644 Documentation/process/maintainer-kvm-arm64.rst

diff --git a/Documentation/process/maintainer-kvm-arm64.rst b/Documentation/process/maintainer-kvm-arm64.rst
new file mode 100644
index 000000000000..deba2f812cef
--- /dev/null
+++ b/Documentation/process/maintainer-kvm-arm64.rst
@@ -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.
diff --git a/MAINTAINERS b/MAINTAINERS
index 140eafcbbd78..129d7ef2c3ec 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -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*

base-commit: 62f4c998b297cf233997a2b4cd6fc2d2df0319c9
-- 
2.55.0

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] docs: unresolved draft placeholders in maintainer profile
--

commit dc2a38b3be99b9dc53f4e7a7537844707bf4e7ca
Author: Matthias Goergens <matthias.goergens@gmail.com>
Subject: Documentation/process: Add a maintainer entry profile for KVM/arm64

This commit introduces a new maintainer profile for the KVM/arm64 subsystem.
It details the development trees, patch bases, review cadence, and testing
requirements for contributors.

Link: https://lore.kernel.org/all/875wzu4vuv.wl-maz@kernel.org/

> diff --git a/Documentation/process/maintainer-kvm-arm64.rst b/Documentation/process/maintainer-kvm-arm64.rst
> new file mode 100644
> index 0000000000000..deba2f812cef3
> --- /dev/null
> +++ b/Documentation/process/maintainer-kvm-arm64.rst
[ ... ]
> +``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?]

[Severity: Low]
This isn't a bug, but should this draft placeholder regarding the master branch
be resolved and removed before the documentation is merged?

> +
> +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?]

[Severity: Low]
Should this question about topic branches and cross-tree changes be answered
and the text finalized rather than keeping the placeholder in the document?

> +
> +Base for patches
> +~~~~~~~~~~~~~~~~
[ ... ]
> +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?]

[Severity: Low]
Should this placeholder regarding merge window cut-offs be updated with the
actual deadlines before the patch is accepted?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260925085621.562448-1-matthias.goergens@gmail.com?part=1

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

[Marc Zyngier]

Hi Matthias,

On Fri, 25 Sep 2026 09:56:21 +0100,
Matthias Goergens <matthias.goergens@gmail.com> wrote:
> 
> KVM/arm64 has no P: entry in MAINTAINERS, so nothing tells a contributor
> that the kvmarm tree is used for integration only, or that most patches
> are expected to be based on a tag from Linus' tree rather than on
> kvmarm/next or linux-next.  Marc Zyngier said a profile would help and
> pointed at the KVM x86 one as a starting point, noting where KVM/arm64
> differs: the absence of topic branches, the references to documentation,
> and the base for most patches.
> 
> Add a profile covering the trees and how changes flow through them, the
> base for patches, recipients, subject prefixes, architecture references,
> testing, key cycle dates and review cadence, and point the KVM/arm64
> entry at it.
> 
> Link: https://lore.kernel.org/all/875wzu4vuv.wl-maz@kernel.org/
> Signed-off-by: Matthias Goergens <matthias.goergens@gmail.com>
> ---
> Marc, this is the profile you said would help, in the thread this
> replies to.  Where you and Oliver haven't said anything on the list, it
> follows the KVM x86 profile and general practice, so please correct
> anything that doesn't match how you work.  Three things need your call
> in particular; they are marked [?: ...] in the text:
> 
> - master: once it follows -rc1, should the profile mention it?
> 
> - Cross-tree changes: the draft says there are no standing topic
>   branches for contributors, and that when a series also touches arm64
>   code the maintainers may set up a shared stable branch on an -rc tag.
>   Is that right?
> 
> - Cut-offs: which is the last -rc for new features, and when do you
>   decide what goes into the merge window?
> 
> I've kept this RFC to the people in this thread.  Once you're happy
> with it, I'll widen the circle to the documentation maintainers and
> lists.

Thanks for starting this, much appreciated. See my remarks below.

> 
>  .../process/maintainer-kvm-arm64.rst          | 163 ++++++++++++++++++
>  MAINTAINERS                                   |   2 +
>  2 files changed, 165 insertions(+)
>  create mode 100644 Documentation/process/maintainer-kvm-arm64.rst
> 
> diff --git a/Documentation/process/maintainer-kvm-arm64.rst b/Documentation/process/maintainer-kvm-arm64.rst
> new file mode 100644
> index 000000000000..deba2f812cef
> --- /dev/null
> +++ b/Documentation/process/maintainer-kvm-arm64.rst
> @@ -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.

I don't think we need this. This should directly point to MAINTAINERS,
and let that file be the reference. Maintainers and MLs have changed
over time, and are likely to change again.

> +
> +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?]

I've pushed 7.3-rc3 there already.

> +
> +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?]

Yes, this is correct. Topic branches are directly managed by the
maintainers in private trees, and only the result of the integration
is pushed out. The exception to this is of course shared branches that
are published when necessary.

As for the impact on arch code, we are about to have extended
dependencies with other architectures (s390). Steffen, can you have a
look and prepare a short addition to this text that would apply to the
KVM/arm64-on-S390 contraption?

> +
> +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.

It is best to base the work on -rc1 to -rc3. If you rely on something
past -rc3, please explain why (dependency on fixes merged in-rc4, for
example).

> +
> +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.

It is extremely rare that we'd ask for something of the sort. For a
start, the -next branch is rebuilt very regularly, so picking a
kvmarm/next commit is generally wrong. And we actually want to see
conflicts, because this is a good indication that we need to dig a bit
deeper. On the other hand, we welcome a proposed resolution of the
conflicts.

The only exception I can think of is when a series is a strict
continuation of another one that has already been queued.

> +
> +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.

The "new thread" is quite important, at least to me. I nearly missed
this patch as you didn't follow this recommendation! :-/

> +
> +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.

nit: whatever comes out of the prefix list should start with a capital
letter ("KVM: arm64: nv: Fix inverted frobinator polarity"). Yes, I
have OCD... ;-)

> +
> +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``.

Even better: when available, quote the rule identifier ("R_WXYZT")
instead of the section. Such ids are immutable across versions, while
the section numbers aren't. This also applies to other architecture
documents (the ARM ARM is not the only one).

> +
> +This differs from KVM x86, whose profile asks contributors not to cite
> +section numbers.

I don't think we need to name "the other architecture"... ;-)

> +
> +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.

... and usually at the end of the series.

> +
> +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.

If you submit a patch that aims to improve performance, describe the
exact methodology you used to evaluate the performance, and provide
enough information so that others can reproduce your findings.

> +
> +Changes to nested virtualization in particular are unlikely to be merged
> +without test coverage.

That's not really true. Our NV coverage is incredibly poor, and yet we
take patches for it. It is encouraged though.

> 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?]

We usually stop merging new features once -rc6 is published, and only
queue fixes from that point onward. This is not a hard rule, but one
that we try to follow for our own sanity. Obviously, posting patches
for a new feature just before -rc6 doesn't guarantee anything other
than a French shrug...

For fixes that are not part of the initial drop for a release, they
are accumulated and sent upstream on a semi-regular basis, depending
on the severity of the bugs that are being fixed. There is no cut-off
for those, but maintainers may decide to defer a low priority fix to
the following 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.

They can change, but we try hard not to. However, note that commit IDs
for merges are almost guaranteed to change, even if the commit IDs for
individual patches are stable.

I'd like to also add that reviews performed by bots (sashiko and co)
are expected to be answered, even if it is to point out that they are
plain wrong.

However, for pre-existing problems outlined by these bots, we
generally don't expect them to be addressed as part of the initial
posting if they are unrelated issues. Yes, this is a fine line...

> +
> +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.
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 140eafcbbd78..129d7ef2c3ec 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -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*
> 
> base-commit: 62f4c998b297cf233997a2b4cd6fc2d2df0319c9

This otherwise looks pretty good to me. Let's see what Oliver says,
but I'm otherwise inclined to take something like this in 7.4.

Thanks again,

	M.

-- 
Jazz isn't dead. It just smells funny.

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

[Oliver Upton]

On Sun, Sep 27, 2026 at 11:22:57AM +0100, Marc Zyngier wrote:
> This otherwise looks pretty good to me. Let's see what Oliver says,
> but I'm otherwise inclined to take something like this in 7.4.

I haven't had time to review this in detail but I'm not generally
opposed to better documentation. Post as a patch and I'll make an
effort to review.

Thanks,
Oliver