Re: [PATCH v6 1/5] KVM: arm64: Share all userspace hardened thread data with the hypervisor

From: Marc Zyngier <maz@kernel.org>
To: Mark Brown <broonie@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Oliver Upton <oliver.upton@linux.dev>,
	James Morse <james.morse@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Jonathan Corbet <corbet@lwn.net>, Shuah Khan <shuah@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, Dave Martin <Dave.Martin@arm.com>,
	kvmarm@lists.linux.dev, linux-doc@vger.kernel.org,
	linux-kselftest@vger.kernel.org
Subject: Re: [PATCH v6 1/5] KVM: arm64: Share all userspace hardened thread data with the hypervisor
Date: Wed, 10 Apr 2024 08:27:07 +0100	[thread overview]
Message-ID: <87a5m1smno.wl-maz@kernel.org> (raw)
In-Reply-To: <562e1ddb-75e5-4c02-83ea-b946b88d35c8@sirena.org.uk>

On Tue, 02 Apr 2024 17:20:36 +0100,
Mark Brown <broonie@kernel.org> wrote:
> 
> On Tue, Apr 02, 2024 at 03:53:33PM +0100, Marc Zyngier wrote:
> > Mark Brown <broonie@kernel.org> wrote:
> 
> > > Sure, those patches are still in flight though.  It does seem reasonable
> > > to target the current code.
> 
> > Sure, if your intent is for this code not to be merged.
> 
> > Because it means this series assumes a different data life cycle, and
> > the review effort spent on it will be invalidated once you move to the
> > per-CPU state.
> 
> I don't have any visibility on when those patches are likely to get
> merged or the general practices with in flight serieses here, last time
> around with some of the serieses that were in flight it was quite late
> which did make it unclear if things would go in during that release
> cycle at all.

Here's a trick: you could ask. Other people do.

> The amount of churn in KVM recently and long periods where the relevant
> patches are apparently pre accepted but for various not always clear

Nothing is "pre accepted". Everything gets discussed and reviewed.
Specially when it comes to what you call "churn", which I call "crap
removal".

> reasons not actually merged is making it quite hard to target, you're

Things get merged when they are reviewed and ready. Not before.

> obviously going to be a lot more in the loop so this is doubtless
> clearer to you than to me.  It's also been a little unclear what the
> expectations are for basing things on - some people do prefer to do
> their own merging for example, and while you have mentioned your in

This isn't about resolving a simple conflict. This is a fundamental
change in the way the state is tracked. We have argued about this for
months now, you were Cc'd on the patches addressing this problem, and
you even reviewed them. What other hint do you need?

> flight serieses your communication style means that it's not been
> entirely clear if you're just noting the overlap.

Not clear? That's a first. I'm usually seen as "blunt and assertive".
But I'll keep that in mind and aspire to greater clarity in the future.

> Is it just that
> refactoring series you want taking into account here or are there other
> in flight serieses that should be rolled into a base?

That, and the already merged feature enforcement framework which you
keep ignoring. I'll push out a rc3-based branch in to -next shortly so
that it is crystal clear what you need to base things on.

	M.

-- 
Without deviation from the norm, progress is not possible.