]> xenbits.xensource.com Git - people/pauldu/linux.git/commit
KVM: xen: allow vcpu_info content to be 'safely' copied shared-info5
authorPaul Durrant <pdurrant@amazon.com>
Tue, 26 Sep 2023 10:52:37 +0000 (10:52 +0000)
committerPaul Durrant <pdurrant@amazon.com>
Thu, 2 Nov 2023 18:03:09 +0000 (18:03 +0000)
commit3a045690c3bd73af001f638e8671f56a7df8540c
tree785f8f66e6e2ad65cde400d32d587dc92b5dec2c
parent329ec40b45c408db1d6339e56791f5447fff7bf0
KVM: xen: allow vcpu_info content to be 'safely' copied

If the guest sets an explicit vcpu_info GPA then, for any of the first 32
vCPUs, the content of the default vcpu_info in the shared_info page must be
copied into the new location. Because this copy may race with event
delivery (which updates the 'evtchn_pending_sel' field in vcpu_info) we
need a way to defer that until the copy is complete.
Happily there is already a shadow of 'evtchn_pending_sel' in kvm_vcpu_xen
that is used in atomic context if the vcpu_info PFN cache has been
invalidated so that the update of vcpu_info can be deferred until the
cache can be refreshed (on vCPU thread's the way back into guest context).
So let's also use this shadow if the vcpu_info cache has been
*deactivated*, so that the VMM can safely copy the vcpu_info content and
then re-activate the cache with the new GPA. To do this, all we need to do
is stop considering an inactive vcpu_info cache as a hard error in
kvm_xen_set_evtchn_fast().

Signed-off-by: Paul Durrant <pdurrant@amazon.com>
Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
---
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
v6:
 - New in this version.
arch/x86/kvm/xen.c