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.
M.
--
Fast, cheap, reliable. Pick two.
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
