On 11/3/2023 2:26 AM, Maxim Levitsky wrote:
On Wed, 2023-11-01 at 12:32 -0700, Sean Christopherson wrote:
On Tue, Oct 31, 2023, Maxim Levitsky wrote:
On Thu, 2023-09-14 at 02:33 -0400, Yang Weijiang wrote:
Wrap __kvm_{get,set}_msr() into two new helpers for KVM usage and use the
helpers to replace existing usage of the raw functions.
kvm_msr_{read,write}() are KVM-internal helpers, i.e. used when KVM needs
to get/set a MSR value for emulating CPU behavior.
I am not sure if I like this patch or not. On one hand the code is cleaner
this way, but on the other hand now it is easier to call kvm_msr_write() on
behalf of the guest.
For example we also have the 'kvm_set_msr()' which does actually set the msr
on behalf of the guest.
How about we call the new function kvm_msr_set_host() and rename
kvm_set_msr() to kvm_msr_set_guest(), together with good comments explaning
what they do?
LOL, just call me Nostradamus[*] ;-)
: > SSP save/load should go to enter_smm_save_state_64() and rsm_load_state_64(),
: > where other fields of SMRAM are handled.
:
: +1. The right way to get/set MSRs like this is to use __kvm_get_msr() and pass
: %true for @host_initiated. Though I would add a prep patch to provide wrappers
: for __kvm_get_msr() and __kvm_set_msr(). Naming will be hard, but I think we
^^^^^^^^^^^^^^^^^^^
: can use kvm_{read,write}_msr() to go along with the KVM-initiated register
: accessors/mutators, e.g. kvm_register_read(), kvm_pdptr_write(), etc.
[*] https://lore.kernel.org/all/ZM0YZgFsYWuBFOze@xxxxxxxxxx
Also functions like kvm_set_msr_ignored_check(), kvm_set_msr_with_filter() and such,
IMHO have names that are not very user friendly.
I don't like the host/guest split because KVM always operates on guest values,
e.g. kvm_msr_set_host() in particular could get confusing.
That makes sense.
IMO kvm_get_msr() and kvm_set_msr(), and to some extent the helpers you note below,
are the real problem.
What if we rename kvm_{g,s}et_msr() to kvm_emulate_msr_{read,write}() to make it
more obvious that those are the "guest" helpers? And do that as a prep patch in
this series (there aren't _that_ many users).
Makes sense.
Then I'll modify related code and add the pre-patch in next version, thanks!
I'm also in favor of renaming the "inner" helpers, but I think we should tackle
those separately.separately
OK.
Best regards,
Maxim Levitsky
