On 02.07.2012, at 21:03, Jimi Xenidis wrote: > > On Jul 2, 2012, at 10:34 AM, Fei K Chen wrote: > >> We are debuging kvm on IBM poweren chip by RSICWatch tool. > > So for those of you who don't know, the "RISCWatch tool" (RW) is a JTAG > based HW probe debugger. > >> An unexpected data TLB miss happened and we can not explain why. Any one >> have met this before? >> >> 1. Guest OS executes a "bl" instruction with PC=0xC0000000005A49CC. >> According to the guest linux kernel objdump file, the next instruction will >> be "mflr r0" with PC=0xC000000000599CC0. > > Normally, if you were debugging the host, you could strip off the 0xC and > read the location from memory to verify this. > However, since you are debugging the guest, you probably can't figure out the > machine physical address. > >> >> 2. By single-step execution in RISCWatch, guest OS does jump to an >> instruction with PC=0xC000000000599CC0. At this time, RISCWatch tool can not >> display what the instruction is. We guess this is because there is no >> instruction TLB entry in hardware TLB for PC=0xC000000000599CC0. Thus an >> instruction TLB miss is expected if we press the "Asmstep" to execute the >> next instruction. >> >> 3. Unfortunately, poweren jumps an instruction with PC=0xC000000000051FF4 >> which is the beginning of data TLB miss entry in kvm. We read the values in >> spr SRR0 and DEAR. Both of them are 0xC000000000599CC0. We even can not >> imagine why this happens. > > So when RW decides to look at memory it uses "instruction stuffing/ramming" > where it is able to insert instructions into the thread's instruction "port", > this way it can perform loads and stores using translation in the same way > that software does. > Since you are using the ASM window, it is trying to read the instruction > (before it is executed) and this causes your data fault. > So this is normal and completely expect. > > Instead of using the ASM window use the "command line window" to "step" and > "read iar" then you will get the correct instruction fault you are looking > for. > Note: It may also be the case that you can uncheck the "track IAR" box in > the asm windows if you insist on doing that. > >> >> 4. As external interrupt will happen during single-step debugging, we set a >> hardware breakpoint at PC=0xC000000000599CC0, and let poweren directly run >> to that point. > > Yes, hardware probes become difficult with any interrupts active and, IMNSHO, > should really only be used to debug bootstrap or exception level code. > It would be way easier to instrument the host fault handlers to help you > debug this case.
Right. Please check out how we do trace points on book3s_pr. You probably want the same thing for your implementation and then just trace what exactly is going on, without using explicit debuggers that might mess up your execution flow. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
