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. M. -- Jazz is not dead. It just smells funny... _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
