diff options
| author |   Sean Christopherson <sean.j.christopherson@intel.com> | 2020-09-23 11:03:55 -0700 |
|---|---|---|
| committer |   Paolo Bonzini <pbonzini@redhat.com> | 2020-09-28 07:57:54 -0400 |
| commit | 7e34fbd05c6350b30161be84d4f8954c9d321292 (patch) | |
| tree | 529a1fcdff0ef112d2c7d4c9e83fde2cb6128c00 /tools/perf/scripts/python/export-to-postgresql.py | |
| parent | KVM: x86/mmu: Move individual kvm_mmu initialization into common helper (diff) | |
| download | wireguard-linux-7e34fbd05c6350b30161be84d4f8954c9d321292.tar.xz wireguard-linux-7e34fbd05c6350b30161be84d4f8954c9d321292.zip | |
KVM: x86: Rename "shared_msrs" to "user_return_msrs"
Rename the "shared_msrs" mechanism, which is used to defer restoring
MSRs that are only consumed when running in userspace, to a more banal
but less likely to be confusing "user_return_msrs".
The "shared" nomenclature is confusing as it's not obvious who is
sharing what, e.g. reasonable interpretations are that the guest value
is shared by vCPUs in a VM, or that the MSR value is shared/common to
guest and host, both of which are wrong.
"shared" is also misleading as the MSR value (in hardware) is not
guaranteed to be shared/reused between VMs (if that's indeed the correct
interpretation of the name), as the ability to share values between VMs
is simply a side effect (albiet a very nice side effect) of deferring
restoration of the host value until returning from userspace.
"user_return" avoids the above confusion by describing the mechanism
itself instead of its effects.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Message-Id: <20200923180409.32255-2-sean.j.christopherson@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'tools/perf/scripts/python/export-to-postgresql.py')
0 files changed, 0 insertions, 0 deletions