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".
