Message-ID: <df6eddc8-8d47-4feb-aa9f-50d16835860b@sirena.org.uk>
Date: Wed, 10 Apr 2024 22:43:37 +0100
From: Mark Brown <broonie@...nel.org>
To: Marc Zyngier <maz@...nel.org>
Cc: Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>,
	Oliver Upton <oliver.upton@...ux.dev>,
	James Morse <james.morse@....com>,
	Suzuki K Poulose <suzuki.poulose@....com>,
	Jonathan Corbet <corbet@....net>, Shuah Khan <shuah@...nel.org>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Dave Martin <Dave.Martin@....com>, kvmarm@...ts.linux.dev,
	linux-doc@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH v6 1/5] KVM: arm64: Share all userspace hardened thread
 data with the hypervisor

On Wed, Apr 10, 2024 at 08:27:07AM +0100, Marc Zyngier wrote:
> Mark Brown <broonie@...nel.org> wrote:
> > On Tue, Apr 02, 2024 at 03:53:33PM +0100, Marc Zyngier wrote:
> > > Mark Brown <broonie@...nel.org> wrote:

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

I do ask questions from time to time, and you do respond to some of
them, but in particular with "what's the status" type questions you have
given the impression that they're not super welcome.  TBH my thinking
was just the standard submit against whatever is merged, rebase as
needed approach - I was of course aware of your series but also aware
that it was still in review.

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

Sure, but then there's some things like your cleanup series which are
still in the discussion and review phase (or at least not applied) but
where you are saying you've got a strong expectation that other work
should be based on them.  Most if not all of those are clearly going to
go in (as you indicate below with this one) but for whatever reason
haven't actually done so yet, it's them that I'm referring to here.

> Specially when it comes to what you call "churn", which I call "crap
> removal".

Indeed, a lot of things get churned for good reasons - the point here is
not that there aren't valuable improvements being made (there definitely
are here) but rather that it does make for a bit of a moving target.

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

I was on balance expecting to need to do the rebase at some point but
unclear what approach you and your comaintainers would want.  TBH I
don't really see it as a huge update, refactoring with the current
approach in this series should be a *broadly* mechanical operation.  

> months now, you were Cc'd on the patches addressing this problem, and
> you even reviewed them. What other hint do you need?

Honestly, them actually landing in git or a positive statement to the
effect of "these will go in after whatever, please base your work on
it" or whatever.  It's not that I can't tell they're likely to go in at
some point, it's just that I'm targetting the current tree.  This is a
fairly standard approach which many maintainers prefer.

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

Those aren't quite the words I would use though I do understand the
sentiment.  One consequence of this style is that while it's obvious
that you don't like something it's not always quite so obvious what the
practical suggestion is, and since the general affect is so strong any
emphasis is not really visible.

More generally to this particular issue with rebasing on your series you
will have noticed that I have submitted a number of serieses which aimed
to address some of your review comments which you've rejected as not in
fact being things you were looking for.

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

I really thought when I submitted this that I'd updated everything for
the feature enforcement framework now that it has actually landed, and
as I said in reply to the other patch apart from the nested idregs
(which I had missed) and the exposure of CPA (which did actually
introduce traps that I'd missed so I've updated to not expose CPA) I'm
still unclear what exactly it is that I have missed there.

Prior to that work landing this was all the same thing as I was
mentioning above with submitting against what's actually applied,
especially for serieses that aren't KVM specific where there's a higher
cost for pulling in extra dependencies early.  I was aware that there
were changes coming but also aware that they were still not there yet.

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

Powered by blists - more mailing lists