[PATCH] KVM: arm64: gic-v3: Only set ICH_HCR traps for v2-on-v3 or v3 guests

[Mark Brown]

On Tue, Oct 21, 2025 at 08:50:22AM +0100, Marc Zyngier wrote:
> Mark Brown <broonie at kernel.org> wrote:

> > It didn't appear in -next since the arm64 KVM fixes tree is not directly
> > in -next and it was only pulled into Paolo's tree on Saturday, a few
> > hours before Paolo sent his pull request to Linus, so there was no
> > opportunity for it to be picked up.  As I've previously suggested it
> > does seem like it would be a good idea to include the fixes branches for
> > the KVM arch trees in -next (s390 is there, but I don't see the others),

> As I explained to you more than once, the answer is still no. We keep
> the two branches separate for good reasons -- for a start, they are
> manager by different people.

You do keep saying that but I am still unable to understand your
reasoning here.  Having two separate branches is very standard, it is
the normal pattern for fixes branches in -next and does not generally
present any problems that I am aware of.  A bit more than a third of the
branches merged by -next are fixes branches.  As I said in my earlier
reply to Sean it can be an advantage to have the fixes in -next
separately since this allows the fixes to go into pending-fixes, helping
spot unintended dependencies on work that's targeting the merge window
and ensure coverage continues even when there is breakage in development
code.

As I understand it the management of the KVM arm64 tree is very similar
to that for the arm64 architecture tree.  That has the separate feature and
fixes branches in -next, each managed by different people and both of
which are in -next.  So far as I am aware this hasn't been causing Will
and Catalin any problems, I don't know what would be different about the
KVM arm64 tree here.

The only thing I can think of is that you are objecting to the idea of
having the KVM arm64 tree merge it's fixes branch into it's development
branch.  That is not what I am suggesting, I am suggesting putting the
fixes branch itself directly into -next to be merged by Stephen.  I am
not proposing any change to the content of the KVM arm64 branches.

> If you want to manage a -fixes tree, go for it. If you want to take
> the -fixes branch in your CI, I have no objection.  Do I support this?
> Absolutely not.

There is no need for anyone to create a -fixes tree since we already
have pending-fixes, created as part of building -next.  The merge for
-next pulls in all the fixes branches first, publishes that as
next/pending-fixes, and then merges the new feature branches on top of
that to publish as next/master.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20251021/8eea863f/attachment.sig>