Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) client-ip=23.128.96.31;
Date:   Mon, 18 Sep 2023 10:12:13 -0700
In-Reply-To: <8527f707315812d9ac32201b37805256fab4a0a1.camel@infradead.org>
Mime-Version: 1.0
References: <20230918144111.641369-1-paul@xen.org> <ZQh4Zi5Rj3RP9Niw@google.com>
 <8527f707315812d9ac32201b37805256fab4a0a1.camel@infradead.org>
Message-ID: <ZQiE7SExjbCVffAE@google.com>
Subject: Re: [PATCH v3 00/13] KVM: xen: update shared_info and vcpu_info handling
From:   Sean Christopherson <seanjc@google.com>
To:     David Woodhouse <dwmw2@infradead.org>
Cc:     Paul Durrant <paul@xen.org>, kvm@vger.kernel.org,
        linux-kernel@vger.kernel.org, Paul Durrant <pdurrant@amazon.com>,
        "H. Peter Anvin" <hpa@zytor.com>, Borislav Petkov <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Ingo Molnar <mingo@redhat.com>,
        Paolo Bonzini <pbonzini@redhat.com>,
        Thomas Gleixner <tglx@linutronix.de>, x86@kernel.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Mon, Sep 18, 2023, David Woodhouse wrote:
> On Mon, 2023-09-18 at 09:18 -0700, Sean Christopherson wrote:
> > On Mon, Sep 18, 2023, Paul Durrant wrote:
> > > From: Paul Durrant <pdurrant@amazon.com>
> > >=20
> > > Currently we treat the shared_info page as guest memory and the VMM i=
nforms
> > > KVM of its location using a GFN. However it is not guest memory as su=
ch;
> > > it's an overlay page. So we pointlessly invalidate and re-cache a map=
ping
> > > to the *same page* of memory every time the guest requests that share=
d_info
> > > be mapped into its address space. Let's avoid doing that by modifying=
 the
> > > pfncache code to allow activation using a fixed userspace HVA as well=
 as
> > > a GPA.
> > >=20
> > > Also, if the guest does not hypercall to explicitly set a pointer to =
a
> > > vcpu_info in its own memory, the default vcpu_info embedded in the
> > > shared_info page should be used. At the moment the VMM has to set up =
a
> > > pointer to the structure explicitly (again treating it like it's in
> > > guest memory, despite being in an overlay page). Let's also avoid the
> > > need for that. We already have a cached mapping for the shared_info
> > > page so just use that directly by default.
> >=20
> > 1. Please Cc me on *all* patches if you Cc me on one patch.=C2=A0 I bel=
ive this is
> > =C2=A0=C2=A0 the preference of the vast majority of maintainers/reviewe=
rs/contributors.
> > =C2=A0=C2=A0 Having to go spelunking to find the rest of a series is an=
noying.
> >=20
> > 2. Wait a reasonable amount of time between posting versions.=C2=A0 1 h=
our is not
> > =C2=A0=C2=A0 reasonable.=C2=A0 At an *absolute minimum*, wait 1 busines=
s day.
> >=20
> > 3. In the cover letter, summarize what's changed between versions.=C2=
=A0 Lack of a
> > =C2=A0=C2=A0 summary exacerbates the problems from #1 and #2, e.g. I ha=
ve a big pile of
> > =C2=A0=C2=A0 mails scattered across my mailboxes, and I am effectively =
forced to find and
> > =C2=A0=C2=A0 read them all if I want to have any clue as to why I have =
a 12 patch series
> > =C2=A0=C2=A0 on version 3 in less than two business days.
>=20
> I meant to mention that too.
>=20
> > P.S. I very much appreciate that y'all are doing review publicly, thank=
 you!
>=20
> Well, to a certain extent you can't have both #2 and the P.S. Or at
> least doesn't work very well if we try.
>=20
> Paul and I were literally sitting in the same room last Friday talking
> about this, and of course you saw the very first iteration of it on the
> mailing list rather than it being done in private and then presented as
> a fait accompli.=C2=A0We try to set that example for those around us.
>=20
> (Just as you saw the very first attempt at the exit-on-hlt thing, and
> the lore.kernel.org link was what I gave to my engineers to tell them
> to see what happens if they try that.)
>=20
> And there *are* going to be a couple of rounds of rapid review and
> adjustment as we start from scratch in the open, as I firmly believe
> that we should. I *want* to do it in public and I *want* you to be able
> to see it, but I don't necessarily think it works for us to *wait* for
> you. Maybe it makes more sense for you to dive deep into the details
> only after the rapid fire round has finished?
>=20
> Unless you don't *want* those first rounds to be in public? But I don't
> think that's the right approach.
>=20
> Suggestions welcome.
>=20
> Maybe in this particular case given that I said something along the
> lines of "knock something up and let's see how I feel about it when I
> see it", it should be using an 'RFC' tag until I actually approve it?
> Not sure how to extrapolate that to the general case, mind you.

Tag them RFC, explain your expectations, goals, and intent in the cover let=
ter,
don't copy+paste cover letters verbatim between versions, and summarize the=
 RFC(s)
when you get to a point where you're ready for others to jump in.  The cove=
r
letter is *identical* from v1=3D>v2=3D>v3, how is anyone supposed to unders=
tand what
on earth is going on unless they happened to be in the same room as ya'll o=
n
Friday?

Doing rapid-fire, early review on beta-quality patches is totally fine, so =
long
as it's clear that others can effectively ignore the early versions unless =
they
are deeply interested or whatever.

A disclaimer at the top of the cover letter, e.g.

  This series is a first attempt at an idea David had to improve performanc=
e
  of the pfncache when KVM is emulating Xen.  David and I are still working=
 out
  the details, it's probably not necessary for other folks to review this r=
ight
  now.

along with a summary of previous version and a transition from RFC =3D> non=
-RFC
makes it clear when I and others are expected to get involved.

In other words, use tags and the cover letter to communicate, don't just vi=
ew the
cover letter as a necessary evil to get people to care about your patches.