KVM: x86/xen: allow vcpu_info content to be 'safely' copied
authorPaul Durrant <pdurrant@amazon.com>
Thu, 15 Feb 2024 15:29:15 +0000 (15:29 +0000)
committerSean Christopherson <seanjc@google.com>
Thu, 22 Feb 2024 15:01:21 +0000 (07:01 -0800)
commit003d914220c97ef93cabfe3ec4e245e2383e19e9
tree4f4c8c46ebba1ed50246dbc308279e89c4c9af69
parent9fa336e343b2c7f6bad6fd5fa2e1cf55e80d3ed1
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),
event delivery needs to be deferred 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).

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(), and let the existing
kvm_gpc_check() fail and kick the vCPU (if necessary).

Signed-off-by: Paul Durrant <pdurrant@amazon.com>
Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Link: https://lore.kernel.org/r/20240215152916.1158-21-paul@xen.org
[sean: add a bit of verbosity to the changelog]
Signed-off-by: Sean Christopherson <seanjc@google.com>
arch/x86/kvm/xen.c