Searched hist:"6 abe9c1386e5c86f360e4e8fde8eec95eee77aa3" (Results 1 – 2 of 2) sorted by relevance
/linux/arch/x86/kvm/ |
H A D | x86.h | diff 6abe9c1386e5c86f360e4e8fde8eec95eee77aa3 Tue Jun 23 00:04:41 CEST 2020 Peter Xu <peterx@redhat.com> KVM: X86: Move ignore_msrs handling upper the stack
MSR accesses can be one of:
(1) KVM internal access, (2) userspace access (e.g., via KVM_SET_MSRS ioctl), (3) guest access.
The ignore_msrs was previously handled by kvm_get_msr_common() and kvm_set_msr_common(), which is the bottom of the msr access stack. It's working in most cases, however it could dump unwanted warning messages to dmesg even if kvm get/set the msrs internally when calling __kvm_set_msr() or __kvm_get_msr() (e.g. kvm_cpuid()). Ideally we only want to trap cases (2) or (3), but not (1) above.
To achieve this, move the ignore_msrs handling upper until the callers of __kvm_get_msr() and __kvm_set_msr(). To identify the "msr missing" event, a new return value (KVM_MSR_RET_INVALID==2) is used for that.
Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20200622220442.21998-2-peterx@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
H A D | x86.c | diff 6abe9c1386e5c86f360e4e8fde8eec95eee77aa3 Tue Jun 23 00:04:41 CEST 2020 Peter Xu <peterx@redhat.com> KVM: X86: Move ignore_msrs handling upper the stack
MSR accesses can be one of:
(1) KVM internal access, (2) userspace access (e.g., via KVM_SET_MSRS ioctl), (3) guest access.
The ignore_msrs was previously handled by kvm_get_msr_common() and kvm_set_msr_common(), which is the bottom of the msr access stack. It's working in most cases, however it could dump unwanted warning messages to dmesg even if kvm get/set the msrs internally when calling __kvm_set_msr() or __kvm_get_msr() (e.g. kvm_cpuid()). Ideally we only want to trap cases (2) or (3), but not (1) above.
To achieve this, move the ignore_msrs handling upper until the callers of __kvm_get_msr() and __kvm_set_msr(). To identify the "msr missing" event, a new return value (KVM_MSR_RET_INVALID==2) is used for that.
Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20200622220442.21998-2-peterx@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|