On 21.08.2012, at 23:25, Marc Zyngier wrote: > On Tue, 21 Aug 2012 15:37:07 -0400, Christoffer Dall > <c.dall@xxxxxxxxxxxxxxxxxxxxxx> wrote: >> On Tue, Aug 21, 2012 at 1:49 PM, Marc Zyngier <marc.zyngier@xxxxxxx> > wrote: >>> On 21/08/12 15:24, Christoffer Dall wrote: >>>> On Tue, Aug 21, 2012 at 9:49 AM, Marc Zyngier <marc.zyngier@xxxxxxx> >>>> wrote: >>>>> On 21/08/12 12:47, Alexander Graf wrote: >>>>>> On 08/21/2012 01:39 PM, Marc Zyngier wrote: >>>>>>> On 20/08/12 21:45, Christoffer Dall wrote: >>>>>>>> On Mon, Aug 20, 2012 at 1:22 PM, Marc Zyngier >>>>>>>> <marc.zyngier@xxxxxxx> wrote: >>>>>>>>> Guys, >>>>>>>>> >>>>>>>>> I'm seeing weird regressions on v11 when running Thumb2 code: >>>>>>>>> >>>>>>>>> [ 315.637769] cyclictest (3319): undefined instruction: >>>>>>>>> pc=0000a2f4 >>>>>>>>> [ 315.637791] Code: 4640 4649 f002 fbc4 (ed95) 7b06 >>>>>>>>> [ 316.216214] cyclictest (3324): undefined instruction: >>>>>>>>> pc=0000a2f4 >>>>>>>>> [ 316.217515] Code: 4640 4649 f002 fbc4 (ed95) 7b06 >>>>>>>>> [ 325.854063] cyclictest (3444): undefined instruction: >>>>>>>>> pc=0000a2f4 >>>>>>>>> [ 325.854076] Code: 4640 4649 f002 fbc4 (ed95) 7b06 >>>>>>>>> >>>>>>>>> My previous work branch was quite solid (v10 based). Do we have a >>>>>>>>> clear >>>>>>>>> idea of what's changed in the exception handling path? Or should > I >>>>>>>>> consider doing the diff dance? >>>>>>>>> >>>>>>>>> I have the ugly feeling that we're adjusting the PC in a creative >>>>>>>>> way. >>>>>>>>> >>>>>>>> if that's the case, it's probably the kvm_skip_instr() thingy. > Which >>>>>>>> code are you running? simply a Thumb guest kernel or something in >>>>>>>> user >>>>>>>> space? If the latter, can you share? >>>>>>> This is a Thumb2 guest + userspace guest. The instruction is always >>>>>>> the >>>>>>> same VFP instruction, so it actually looks VFP related, not PC >>>>>>> adjusting >>>>>>> as I initially thought. Doing stuff on the host seems to easily >>>>>>> trigger >>>>>>> the problem on the gust. >>>>>>> >>>>>>> But there's very little difference between my two trees (at least > VFP >>>>>>> wise), hence my growing perplexity... >>>>>>> >>>>>>> I'll continue investigating. >>>>>> >>>>>> Did you maybe compile them with different config options? Like >>>>>> preemption? :) >>>>> >>>>> No, I'm quite careful to use the exact same config file. I also made >>>>> sure I was using 3.6-rc2 for both branches. I have a few additional > ARM >>>>> specific patches that I'm going to back out, so the two trees are >>>>> similar. >>>>> >>>>> Except for whatever comes from kvm/next, of course. But I can't see >>>>> anything there that would have such an weird impact. >>>>> >>>> I changed the allocation of the vfp_struct to support module >>>> loading/unloading. The vfp structs now get kmalloc'ed and memset (see >>>> init_hyp_mode). Maybe I messed something up there? >>> >>> >>> Right. Disabling debug trapping through HDCR seem to fix the issue. > This >>> doesn't make *any* sense! >>> >>> I'll try to understand this tomorrow. >> >> do you actually see the traps when they're not disabled? > > No, I don't see any trap being actually taken (I've put a panic() in > kvm_inject_undefined() to be absolutely sure). > > It's like some side effect would disable VFP, and generate an UNDEF at > some random point. What has helped me before to debug these type of things were trace points. I usually have one on every exit, telling me why the guest went out of guest context. If you put the register that indicates VFP enabled to the guest (no idea what it's called on ARM) in there, you might be able to see a pattern. Alex _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
