lkml.org 
[lkml]   [2020]   [Mar]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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".

\
 
 \ /
  Last update: 2020-03-03 18:42    [W:0.430 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site