Re: [kvm-ppc-devel] [PATCH] [2/3] kvmppc: full instruction emulation tracing

[Hollis B. <ho...@us...>]

On Tuesday 15 April 2008 01:20:48 Christian Ehrhardt wrote:
> > I'm not sure how I feel about logging *every* faulting instruction,
> > rather than aggregating statistics about them. Actually, I know how I
> > feel, and it's uncomfortable. :)
> >
> > It's a userspace process that must be extracting this data from the relay
> > buffers, and that only happens when it's scheduled. How many instruction
> > exits could we get in a few timeslices? I think we could easily overflow
> > the relay buffers, especially if the host is under load.
>
> The patch series intentionally has two instruction statistics.
> One for low overhead giving you just some counters, and additionally we can
> extend these counters as we want e.g. with sprn numbers. The other is to
> enable knowingly a high overhead profiling, but it gives you a full trace
> which can be used e.g. to completely see "what exactly is the guest doing
> there" by looking at which instructions are emulated in which order. So
> both have there right to exist, because there are use scenarios for both of
> them. By making them configurable it is developers choice what to use.

I guess it can be useful to see what's happening when a guest is 
getting "stuck".

However, there are other interesting events to account for in this case as 
well, such as the TLB tracing I posted earlier. I think it makes sense to 
include all of those events in the same relay channel, rather than having one 
channel for instructions, one for TLB, etc.

> >> +struct instr_record {
> >> +       u32 time;
> >> +       u32 pc;
> >> +       u32 instr;
> >> +       u32 rsval;
> >> +       u32 raval;
> >> +       u32 rbval;
> >> +};
> >
> > In addition to the instruction itself, I can see how the PC would be
> > useful, and maybe also the time when we have multiple cores. (Well, or
> > maybe it would be better to have one channel per core anyways.) But I
> > think RS/RA/RB are way overkill here. What would a userspace tool do with
> > this data anyways?
>
> The decoding scripts shows you what values are used e.g. for a mtmsr you
> see what value was moved to the register. But I agree that the value of
> r*val is much smaller than time,pc,instr. Removing these three should speed
> it up to allow us tracing all instructions. I will change the patch and
> resend it.

Does that really speed it up? I wouldn't expect a measurable difference.

-- 
Hollis Blanchard
IBM Linux Technology Center