Messages in this thread | | | Date | Mon, 18 Sep 2023 09:18:46 -0700 | Subject | Re: [PATCH v3 00/13] KVM: xen: update shared_info and vcpu_info handling | From | Sean Christopherson <> |
| |
On Mon, Sep 18, 2023, Paul Durrant wrote: > From: Paul Durrant <pdurrant@amazon.com> > > 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.
P.S. I very much appreciate that y'all are doing review publicly, thank you!
| |