diff options
author | Paul Durrant <pdurrant@amazon.com> | 2024-02-15 18:29:15 +0300 |
---|---|---|
committer | Sean Christopherson <seanjc@google.com> | 2024-02-22 18:01:21 +0300 |
commit | 003d914220c97ef93cabfe3ec4e245e2383e19e9 (patch) | |
tree | 4f4c8c46ebba1ed50246dbc308279e89c4c9af69 /arch/x86/kvm/kvm_onhyperv.c | |
parent | 9fa336e343b2c7f6bad6fd5fa2e1cf55e80d3ed1 (diff) | |
download | linux-003d914220c97ef93cabfe3ec4e245e2383e19e9.tar.xz |
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>
Diffstat (limited to 'arch/x86/kvm/kvm_onhyperv.c')
0 files changed, 0 insertions, 0 deletions