]> xenbits.xensource.com Git - people/pauldu/linux.git/commit
KVM: x86/xen: allow vcpu_info content to be 'safely' copied
authorPaul Durrant <pdurrant@amazon.com>
Tue, 26 Sep 2023 10:52:37 +0000 (10:52 +0000)
committerPaul Durrant <pdurrant@amazon.com>
Thu, 15 Feb 2024 09:56:37 +0000 (09:56 +0000)
commit76736f80c0e43d8b969989e9a1ca0c82d70d6b5b
tree286a8ea8a33bfef9d8a9ecda7407cacb60cfb443
parent951c1d82817d9076fbfd174e2c9012078cc0c6a8
KVM: x86/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) there
needs to be 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).

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, 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
v13:
 - Patch title change.

v8:
 - Update commit comment.

v6:
 - New in this version.
arch/x86/kvm/xen.c