Messages in this thread | | | Date | Tue, 3 Mar 2020 09:42:42 -0800 | From | Sean Christopherson <> | Subject | Re: [PATCH v2 06/13] KVM: x86: Refactor emulate tracepoint to explicitly take context |
| |
On Tue, Mar 03, 2020 at 06:29:30PM +0100, Paolo Bonzini wrote: > On 03/03/20 17:48, Sean Christopherson wrote: > >>> TP_fast_assign( > >>> __entry->csbase = kvm_x86_ops->get_segment_base(vcpu, VCPU_SREG_CS); > >> This seems the only usage of 'vcpu' parameter now; I checked and even > >> after switching to dynamic emulation context allocation we still set > >> ctxt->vcpu in alloc_emulate_ctxt(), can we get rid of 'vcpu' parameter > >> here then (and use ctxt->vcpu instead)? > > Hmm, ya, not sure what I was thinking here. > > > > As long as we have one use of vcpu, I'd rather skip this patch and > adjust patch 8 to use "->". Even the other "explicitly take context" > parts are kinda debatable since you still have to do emul_to_vcpu. > Throwing a handful of > > - struct x86_emulate_ctxt *ctxt = &vcpu->arch.emulate_ctxt; > + struct x86_emulate_ctxt *ctxt = vcpu->arch.emulate_ctxt; > > into patch 8 is not bad at all and limits the churn.
Hmm, I'd prefer to explicitly pass @ctxt, even for the tracepoint. I get that it's technically unnecessary churn, but explicitly passing @ctxt means that every funcition that grabs arch.emulate_ctxt (all three of 'em) checks for a NULL ctxt. That makes it trivial to visually audit that there's no risk of a bad pointer dereference, and IMO having @ctxt in the prototype is helpful to see "oh, this helper is called from within the emulator".
| |