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