[v3,00/13] KVM: xen: update shared_info and vcpu_info handling

  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.

Paul Durrant (13):
  KVM: pfncache: add a map helper function
  KVM: pfncache: add a mark-dirty helper
  KVM: pfncache: add a helper to get the gpa
  KVM: pfncache: base offset check on khva rather than gpa
  KVM: pfncache: allow a cache to be activated with a fixed (userspace)
    HVA
  KVM: xen: allow shared_info to be mapped by fixed HVA
  KVM: xen: prepare for using 'default' vcpu_info
  KVM: xen: prevent vcpu_id from changing whilst shared_info is valid
  KVM: xen: automatically use the vcpu_info embedded in shared_info
  KVM: selftests / xen: set KVM_XEN_VCPU_ATTR_TYPE_VCPU_ID
  KVM: selftests / xen: map shared_info using HVA rather than GFN
  KVM: selftests / xen: don't explicitly set the vcpu_info address
  KVM: xen: advertize the KVM_XEN_HVM_CONFIG_SHARED_INFO_HVA capability

 Documentation/virt/kvm/api.rst                |  49 ++++--
 arch/x86/include/asm/kvm_host.h               |   4 +
 arch/x86/kvm/x86.c                            |  17 +--
 arch/x86/kvm/xen.c                            | 139 +++++++++++++-----
 arch/x86/kvm/xen.h                            |   6 +-
 include/linux/kvm_host.h                      |  43 ++++++
 include/linux/kvm_types.h                     |   3 +-
 include/uapi/linux/kvm.h                      |   6 +-
 .../selftests/kvm/x86_64/xen_shinfo_test.c    |  75 ++++++++--
 virt/kvm/pfncache.c                           | 129 +++++++++++-----
 10 files changed, 360 insertions(+), 111 deletions(-)
---
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Sean Christopherson <seanjc@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: x86@kernel.org
  

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.