> >> +The "reason" field specifies why the MSR trap occurred. User space will
> >> only
> >> +receive MSR exit traps when a particular reason was requested during
> >> through
> >> +ENABLE_CAP. Currently valid exit reasons are:
> >> +
> >> + KVM_MSR_EXIT_REASON_INVAL - access to invalid
On Wed, Sep 16, 2020 at 11:31:30AM +0200, Alexander Graf wrote:
> On 03.09.20 21:27, Aaron Lewis wrote:
> > > @@ -412,6 +414,15 @@ struct kvm_run {
> > > __u64 esr_iss;
> > > __u64 fault_ipa;
> > > } arm_nisv;
> > > +
On 16.09.20 19:08, Sean Christopherson wrote:
On Wed, Sep 16, 2020 at 11:31:30AM +0200, Alexander Graf wrote:
On 03.09.20 21:27, Aaron Lewis wrote:
@@ -412,6 +414,15 @@ struct kvm_run {
__u64 esr_iss;
__u64 fault_ipa;
}
Hi Aaron,
Thanks a lot for the amazing review! I've been caught in some other
things recently, so sorry for the delayed response.
On 03.09.20 21:27, Aaron Lewis wrote:
+::
+
+ /* KVM_EXIT_X86_RDMSR / KVM_EXIT_X86_WRMSR */
+ struct {
+ __u8
> +::
> +
> + /* KVM_EXIT_X86_RDMSR / KVM_EXIT_X86_WRMSR */
> + struct {
> + __u8 error; /* user -> kernel */
> + __u8 pad[3];
> + __u32 reason; /* kernel -> user */
> + __u32 index;
MSRs are weird. Some of them are normal control registers, such as EFER.
Some however are registers that really are model specific, not very
interesting to virtualization workloads, and not performance critical.
Others again are really just windows into package configuration.
Out of these MSRs,
MSRs are weird. Some of them are normal control registers, such as EFER.
Some however are registers that really are model specific, not very
interesting to virtualization workloads, and not performance critical.
Others again are really just windows into package configuration.
Out of these MSRs,
7 matches
Mail list logo
