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? _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
