| Message ID | 20221129193717.513824-2-mlevitsk@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | SVM: vNMI (with my fixes) | expand |
Hi Maxim, On 11/30/2022 1:07 AM, Maxim Levitsky wrote: > The CPU doesn't change TLB_CTL value as stated in the PRM (15.16.2): > nits: s / PRM (15.16.2) / APM (15.16.1 - TLB Flush) > "The VMRUN instruction reads, but does not change, the > value of the TLB_CONTROL field" > > Therefore the KVM shouldn't do that either. > > Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> > --- > arch/x86/kvm/svm/nested.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c > index bc9cd7086fa972..37af0338da7c32 100644 > --- a/arch/x86/kvm/svm/nested.c > +++ b/arch/x86/kvm/svm/nested.c > @@ -1010,7 +1010,6 @@ int nested_svm_vmexit(struct vcpu_svm *svm) > vmcb12->control.next_rip = vmcb02->control.next_rip; > > vmcb12->control.int_ctl = svm->nested.ctl.int_ctl; > - vmcb12->control.tlb_ctl = svm->nested.ctl.tlb_ctl; > vmcb12->control.event_inj = svm->nested.ctl.event_inj; > vmcb12->control.event_inj_err = svm->nested.ctl.event_inj_err; >
On Mon, 2022-12-05 at 19:35 +0530, Santosh Shukla wrote: > Hi Maxim, > > On 11/30/2022 1:07 AM, Maxim Levitsky wrote: > > The CPU doesn't change TLB_CTL value as stated in the PRM (15.16.2): > > > nits: > s / PRM (15.16.2) / APM (15.16.1 - TLB Flush) True for both changes, thanks! Best regards, Maxim Levitsky > > > "The VMRUN instruction reads, but does not change, the > > value of the TLB_CONTROL field" > > > > Therefore the KVM shouldn't do that either. > > > > Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> > > --- > > arch/x86/kvm/svm/nested.c | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c > > index bc9cd7086fa972..37af0338da7c32 100644 > > --- a/arch/x86/kvm/svm/nested.c > > +++ b/arch/x86/kvm/svm/nested.c > > @@ -1010,7 +1010,6 @@ int nested_svm_vmexit(struct vcpu_svm *svm) > > vmcb12->control.next_rip = vmcb02->control.next_rip; > > > > vmcb12->control.int_ctl = svm->nested.ctl.int_ctl; > > - vmcb12->control.tlb_ctl = svm->nested.ctl.tlb_ctl; > > vmcb12->control.event_inj = svm->nested.ctl.event_inj; > > vmcb12->control.event_inj_err = svm->nested.ctl.event_inj_err; > >
diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c index bc9cd7086fa972..37af0338da7c32 100644 --- a/arch/x86/kvm/svm/nested.c +++ b/arch/x86/kvm/svm/nested.c @@ -1010,7 +1010,6 @@ int nested_svm_vmexit(struct vcpu_svm *svm) vmcb12->control.next_rip = vmcb02->control.next_rip; vmcb12->control.int_ctl = svm->nested.ctl.int_ctl; - vmcb12->control.tlb_ctl = svm->nested.ctl.tlb_ctl; vmcb12->control.event_inj = svm->nested.ctl.event_inj; vmcb12->control.event_inj_err = svm->nested.ctl.event_inj_err;
The CPU doesn't change TLB_CTL value as stated in the PRM (15.16.2): "The VMRUN instruction reads, but does not change, the value of the TLB_CONTROL field" Therefore the KVM shouldn't do that either. Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> --- arch/x86/kvm/svm/nested.c | 1 - 1 file changed, 1 deletion(-)