Message-ID: <2505ae61-c7a4-4756-a239-12d4a6653780@sirena.org.uk>
Date: Tue, 21 Oct 2025 19:47:50 +0100
From: Mark Brown <broonie@...nel.org>
To: Marc Zyngier <maz@...nel.org>
Cc: Sascha Bischoff <Sascha.Bischoff@....com>,
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
	"kvmarm@...ts.linux.dev" <kvmarm@...ts.linux.dev>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>, nd <nd@....com>,
	"oliver.upton@...ux.dev" <oliver.upton@...ux.dev>,
	Joey Gouly <Joey.Gouly@....com>,
	Suzuki Poulose <Suzuki.Poulose@....com>,
	"yuzenghui@...wei.com" <yuzenghui@...wei.com>,
	Paolo Bonzini <pbonzini@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Aishwarya.TCV@....com
Subject: Re: [PATCH] KVM: arm64: gic-v3: Only set ICH_HCR traps for v2-on-v3
 or v3 guests

On Tue, Oct 21, 2025 at 03:37:59PM +0100, Marc Zyngier wrote:
> Mark Brown <broonie@...nel.org> wrote:

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

> Then I don't know why you even involve me here.

> You can pull anything you want in -next, and you don't need my
> approval for it. I still don't think this is a good idea because the
> life cycles are totally different, but if you like making your own
> life complicated, go ahead, I'm not going to stop you.

Generally any branch in -next is included at the request of the
maintainer, and one of the things that's attached to a branch in -next
is a set of contacts to report any merge issues - generally whoever
maintains the branch.  I *could* ask Stephen to add the fixes tree but
it'd be very weird for me to do that, and if you are actively hostile
I'm not sure what to do about contacts since I would have expected that
to be you and Oliver.  Oliver, I don't know if you have thoughts here?

I really do not understand your objection here, including fixes branches
in -next is a totally standard thing which as I have mentioned does not
seem to be causing issues for the other trees that do it.  It is true
that fixes get sent upstream faster (I think that's what you mean when
you say the life cycles are different?) but I don't see why this would
be a problem, if anything it is normally helpful to get test coverage
sooner so there's more time for any issues to be noticed.

The current situation creates work, and I would expect including the
fixes branch in -next to reduce that work and generally make things less
stressful.  Currently we get test issues like the one that started this
thread getting caught only when they hit an upstream tree, this tends to
make them more of an emergency.  We also get issues when a problem is
detected in -next where the fix should be sent as a fix, even after the
fix is applied it does not appear in -next until it has been pulled by
Paolo.  In both cases even people doing testing still have whatever was
failing showing as a failure in the the time between the fix being
applied and it showing up in Paolo's tree which adds to their workload
and can obscure other issues.  Reducing the latency on getting fixes
visible in -next solves actual problems with the testing workflow.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists