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 <[email protected]>
> > >
> > > Currently we treat the shared_info page as guest memory and the VMM informs
> > > KVM of its location using a GFN. However it is not guest memory as such;
> > > it's an overlay page. So we pointlessly invalidate and re-cache a mapping
> > > to the *same page* of memory every time the guest requests that shared_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.
> > >
> > > 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.
> >
> > 1. Please Cc me on *all* patches if you Cc me on one patch. I belive this is
> > the preference of the vast majority of maintainers/reviewers/contributors.
> > Having to go spelunking to find the rest of a series is annoying.
> >
> > 2. Wait a reasonable amount of time between posting versions. 1 hour is not
> > reasonable. At an *absolute minimum*, wait 1 business day.
> >
> > 3. In the cover letter, summarize what's changed between versions. Lack of a
> > summary exacerbates the problems from #1 and #2, e.g. I have a big pile of
> > mails scattered across my mailboxes, and I am effectively forced to find and
> > read them all if I want to have any clue as to why I have a 12 patch series
> > on version 3 in less than two business days.
>
> I meant to mention that too.
>
> > P.S. I very much appreciate that y'all are doing review publicly, thank you!
>
> 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.
>
> 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. We try to set that example for those around us.
>
> (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.)
>
> 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?
>
> Unless you don't *want* those first rounds to be in public? But I don't
> think that's the right approach.
>
> Suggestions welcome.
>
> 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 letter,
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 cover
letter is *identical* from v1=>v2=>v3, how is anyone supposed to understand what
on earth is going on unless they happened to be in the same room as ya'll on
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 performance
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 right
now.
along with a summary of previous version and a transition from RFC => 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 view the
cover letter as a necessary evil to get people to care about your patches.
On 18/09/2023 18:12, Sean Christopherson wrote:
[snip]
>
> Tag them RFC, explain your expectations, goals, and intent in the cover letter,
> 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 cover
> letter is *identical* from v1=>v2=>v3, how is anyone supposed to understand what
> on earth is going on unless they happened to be in the same room as ya'll on
> Friday?
The cover letter is indeed identical because the purpose of the series
has not changed. Each individual patch has a commit comment summarizing
what changed from version to version or whether it is new in a
perticular version. I thought this would be enough for any reviewer to
be able to see what is going on. In future I will also roll these up
into the cover letter.
>
> 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 performance
> 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 right
> now.
>
> along with a summary of previous version and a transition from RFC => 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 view the
> cover letter as a necessary evil to get people to care about your patches.
That was not the intention at all; I put all the detailed explanation in
the commit comments because I thought that would make review *easier*.
Paul
On Tue, Sep 19, 2023, Paul Durrant wrote:
> On 18/09/2023 18:12, Sean Christopherson wrote:
> [snip]
> >
> > Tag them RFC, explain your expectations, goals, and intent in the cover letter,
> > 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 cover
> > letter is *identical* from v1=>v2=>v3, how is anyone supposed to understand what
> > on earth is going on unless they happened to be in the same room as ya'll on
> > Friday?
>
> The cover letter is indeed identical because the purpose of the series has
> not changed.
For anything out of the ordinary, e.g. posting v3 just a few hours after v2 is
definitely not normal, use the cover letter to call out why you're posting a
particular version of the series, not just the purpose of the series.
> > In other words, use tags and the cover letter to communicate, don't just view the
> > cover letter as a necessary evil to get people to care about your patches.
>
> That was not the intention at all; I put all the detailed explanation in the
> commit comments because I thought that would make review *easier*.
Per-patch comments *might* make individual patches easier to review, but (for me
at least) they are waaay less helpful for reviewing series as a whole, and all
but usless for initial triage. E.g. for a situation like this where a series
has reached v4 before I've so much as glanced at the patches, having the history
in the cover letter allows me to catch up and get a feel for how the series got
to v4 in ~20 seconds. With per-patch comments, I have to go find each comment
and then piece together the bigger picture.
Per-patch comments also don't work well if a version makes minor changes to a
large series (hunting through a 10+ patch series to figure out that only one patch
changed is not exactly efficient), if a patch is dropped, if there are changes to
the overall approach, etc.