[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <78b0297c-4622-4b75-bcae-45c144c92c45@sirena.org.uk>
Date: Tue, 21 Oct 2025 15:00:30 +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 08:50:22AM +0100, Marc Zyngier wrote:
> Mark Brown <broonie@...nel.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.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists