From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Ehrhardt Date: Tue, 15 Apr 2008 06:20:48 +0000 Subject: Re: [kvm-ppc-devel] [PATCH] [2/3] kvmppc: full instruction Message-Id: <48044940.4070403@linux.vnet.ibm.com> List-Id: References: <200804141545.27659.hollisb@us.ibm.com> In-Reply-To: <200804141545.27659.hollisb@us.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: kvm-ppc@vger.kernel.org Hollis Blanchard wrote: > On Monday 14 April 2008 07:23:57 ehrhardt@linux.vnet.ibm.com wrote: >> From: Christian Ehrhardt >> >> 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. >=20 > I'm not sure how I feel about logging *every* faulting instruction, rathe= r=20 > than aggregating statistics about them. Actually, I know how I feel, and = it's=20 > uncomfortable. :) >=20 > It's a userspace process that must be extracting this data from the relay= =20 > 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=20 > 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 yo= u a full trace which can be used e.g. to completely see "what exactly is th= e 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; >> +}; >=20 > In addition to the instruction itself, I can see how the PC would be usef= ul,=20 > and maybe also the time when we have multiple cores. (Well, or maybe it w= ould=20 > be better to have one channel per core anyways.) But I think RS/RA/RB are= way=20 > overkill here. What would a userspace tool do with this data anyways? >=20 The decoding scripts shows you what values are used e.g. for a mtmsr you se= e 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 instruction= s. I will change the patch and resend it. --=20 Gr=FCsse / regards,=20 Christian Ehrhardt IBM Linux Technology Center, Open Virtualization ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference=20 Don't miss this year's exciting event. There's still time to save $100.=20 Use priority code J8TL2D2.=20 http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/java= one _______________________________________________ kvm-ppc-devel mailing list kvm-ppc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel