> -----Original Message----- > From: kvm-owner@xxxxxxxxxxxxxxx <kvm-owner@xxxxxxxxxxxxxxx> On Behalf > Of Babu Moger > Sent: Thursday, July 30, 2020 11:38 AM > To: Paolo Bonzini <pbonzini@xxxxxxxxxx>; Jim Mattson > <jmattson@xxxxxxxxxx> > Cc: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx>; Wanpeng Li > <wanpengli@xxxxxxxxxxx>; Sean Christopherson > <sean.j.christopherson@xxxxxxxxx>; kvm list <kvm@xxxxxxxxxxxxxxx>; Joerg > Roedel <joro@xxxxxxxxxx>; the arch/x86 maintainers <x86@xxxxxxxxxx>; LKML > <linux-kernel@xxxxxxxxxxxxxxx>; Ingo Molnar <mingo@xxxxxxxxxx>; Borislav > Petkov <bp@xxxxxxxxx>; H . Peter Anvin <hpa@xxxxxxxxx>; Thomas Gleixner > <tglx@xxxxxxxxxxxxx> > Subject: RE: [PATCH v3 03/11] KVM: SVM: Change intercept_dr to generic > intercepts > > > > > -----Original Message----- > > From: Paolo Bonzini <pbonzini@xxxxxxxxxx> > > Sent: Wednesday, July 29, 2020 6:12 PM > > To: Jim Mattson <jmattson@xxxxxxxxxx>; Moger, Babu > > <Babu.Moger@xxxxxxx> > > Cc: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx>; Wanpeng Li > > <wanpengli@xxxxxxxxxxx>; Sean Christopherson > > <sean.j.christopherson@xxxxxxxxx>; kvm list <kvm@xxxxxxxxxxxxxxx>; > > Joerg Roedel <joro@xxxxxxxxxx>; the arch/x86 maintainers > > <x86@xxxxxxxxxx>; LKML <linux-kernel@xxxxxxxxxxxxxxx>; Ingo Molnar > > <mingo@xxxxxxxxxx>; Borislav Petkov <bp@xxxxxxxxx>; H . Peter Anvin > > <hpa@xxxxxxxxx>; Thomas Gleixner <tglx@xxxxxxxxxxxxx> > > Subject: Re: [PATCH v3 03/11] KVM: SVM: Change intercept_dr to generic > > intercepts > > > > On 29/07/20 01:59, Jim Mattson wrote: > > >> case SVM_EXIT_READ_DR0 ... SVM_EXIT_WRITE_DR7: { > > >> - u32 bit = 1U << (exit_code - SVM_EXIT_READ_DR0); > > >> - if (svm->nested.ctl.intercept_dr & bit) > > >> + if (__is_intercept(&svm->nested.ctl.intercepts, > > >> + exit_code)) > > > Can I assume that all of these __<function> calls will become > > > <function> calls when the grand unification is done? (Maybe I should > > > just look ahead.) > > > > > > > The <function> calls are reserved for the active VMCB while these take a > vector. > > Probably it would be nicer to call them vmcb_{set,clr,is}_intercept > > and make them take a struct vmcb_control_area*, but apart from that > > the concept is fine > > > > Once we do the vmcb01/vmcb02/vmcb12 work, there will not be anymore > > &svm->nested.ctl (replaced by &svm->nested.vmcb12->ctl) and we will be > > able to change them to take a struct vmcb*. Then is_intercept would > > for example be > > simply: > Yea. True. It makes the code even cleaner. Also we can avoid calling > recalc_intercepts every time we set or clear a bit inside the same function(like > init_vmcb). > > Let me try to understand. > > vmcb01 is &svm->vmcb->control;l > vmcb02 is &svm->nested.hsave->control > vmcb12 is &svm->nested.ctl; > > The functions set_intercept and clr_intercept calls get_host_vmcb to get the > vmcb address. I will move the get_host_vmcb inside the caller and then call vmcb_set_intercept/vmcb_clr_intercept/vmcb_is_intercept directly. I will re post the series. This will change the whole series a little bit. Jim has already reviewed some of the patches. But I probably cannot use "Reviewed-by" if I change the patches too much. thanks > > static inline struct vmcb *get_host_vmcb(struct vcpu_svm *svm) { > if (is_guest_mode(&svm->vcpu)) > return svm->nested.hsave; > else > return svm->vmcb; > } > > I need to study little bit when is_guest_mode Is on or off. Let me take a look at. > > Thanks > > > > > return vmcb_is_intercept(svm->vmcb, nr); > > > > as expected. > > > > Paolo