diff options
| author | David Woodhouse <dwmw@amazon.co.uk> | 2022-11-27 13:22:10 +0100 |
|---|---|---|
| committer | Paolo Bonzini <pbonzini@redhat.com> | 2022-11-30 16:59:37 +0100 |
| commit | d8ba8ba4c801b794f47852a6f1821ea48f83b5d1 (patch) | |
| tree | cf8743dc182b1ca2b49a8c619e834b4748b2639e /crypto/aead.c | |
| parent | KVM: x86/xen: Compatibility fixes for shared runstate area (diff) | |
| download | linux-d8ba8ba4c801b794f47852a6f1821ea48f83b5d1.tar.xz linux-d8ba8ba4c801b794f47852a6f1821ea48f83b5d1.zip | |
KVM: x86/xen: Allow XEN_RUNSTATE_UPDATE flag behaviour to be configured
Closer inspection of the Xen code shows that we aren't supposed to be
using the XEN_RUNSTATE_UPDATE flag unconditionally. It should be
explicitly enabled by guests through the HYPERVISOR_vm_assist hypercall.
If we randomly set the top bit of ->state_entry_time for a guest that
hasn't asked for it and doesn't expect it, that could make the runtimes
fail to add up and confuse the guest. Without the flag it's perfectly
safe for a vCPU to read its own vcpu_runstate_info; just not for one
vCPU to read *another's*.
I briefly pondered adding a word for the whole set of VMASST_TYPE_*
flags but the only one we care about for HVM guests is this, so it
seemed a bit pointless.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Message-Id: <20221127122210.248427-3-dwmw2@infradead.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'crypto/aead.c')
0 files changed, 0 insertions, 0 deletions