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

[Christian E. <ehr...@li...>]

Hollis Blanchard wrote:
> On Monday 14 April 2008 07:23:57 ehr...@li... wrote:
>> From: Christian Ehrhardt <ehr...@li...>
>>
>> This adds a relayfs based kernel interface that allows tracing of all
>> emulated guest instructions. It is based on Hollis tracing of tlb
>> activities. A suitable userspace program to read from that interface and a
>> post processing script that give users a readable output follow.
>> This feature is configurable in .config under the kvmppc virtualization
>> itself.
> 
> 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.

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

-- 

Grüsse / regards, 
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization