SVM: re-work VMCB sync-ing
authorJan Beulich <jbeulich@suse.com>
Mon, 7 May 2018 07:11:15 +0000 (09:11 +0200)
committerJan Beulich <jbeulich@suse.com>
Mon, 7 May 2018 07:11:15 +0000 (09:11 +0200)
commitcb6ff207f7e0bbfe2d9ab3cb1a0866962cf17169
treecf6f6d0c674f02f158f104a90d7a666684ce6266
parente38e285a51c805cfeee4693962df23e39b3c3bd7
SVM: re-work VMCB sync-ing

While the main problem to be addressed here is the issue of what so far
was named "vmcb_in_sync" starting out with the wrong value (should have
been true instead of false, to prevent performing a VMSAVE without ever
having VMLOADed the vCPU's state), go a step further and make the
sync-ed state a tristate: CPU and memory may be in sync or an update
may be required in either direction. Rename the field and introduce an
enum. Callers of svm_sync_vmcb() now indicate the intended new state
(with a slight "anomaly" when requesting VMLOAD: we could store
vmcb_needs_vmsave in those cases as the callers request, but the VMCB
really is in sync at that point, and hence there's no need to VMSAVE in
case we don't make it out to guest context), and all syncing goes
through that function.

With that, there's no need to VMLOAD the state perhaps multiple times;
all that's needed is loading it once before VM entry.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Release-acked-by: Juergen Gross <jgross@suse.com>
xen/arch/x86/hvm/svm/entry.S
xen/arch/x86/hvm/svm/svm.c
xen/arch/x86/hvm/svm/vmcb.c
xen/arch/x86/x86_64/asm-offsets.c
xen/include/asm-x86/hvm/svm/vmcb.h