On 2017-03-17 14:42, [email protected] wrote: > Il giorno venerdì 17 marzo 2017 13:43:32 UTC+1, J. Kiszka ha scritto: >> On 2017-03-17 13:06, Claudio Scordino wrote: >>> Dear all, >>> >>> we are facing an unexpected exception when running the apic timer to >>> drive a GPIO as a software PWM. >>> >>> The platform is x86. The software runs in a bare-metal cell. The PWM >>> frequency is 5 KHz. >>> >>> When the duty cycle is very high or very low (i.e., two subsequent >>> interrupts get closer) we face the following unexpected exception: >>> >>> FATAL: Unhandled VM-Exit, reason 2 >>> qualification 0 >>> vectoring info: 0 interrupt info: 0 >>> RIP: 0x00000000000f15d6 RSP: 0x00000000000dff08 FLAGS: 10002 >> >> "objdump -dS inmate-linked.o" can tell you which instruction at RIP >> causes this fault. It's a triple fault, likely started off by a general >> protection or page fault. >> >> Jan > > Hi I'm Errico, Claudio's coworker, and I'm actually playing with this issue. > > The fault happens when we re-arm the apic timer > > 00000000000f15b5 <apic_timer_set>: > > void apic_timer_set(unsigned long timeout_ns) > { > unsigned long long ticks = > (unsigned long long)timeout_ns * divided_apic_freq; > write_msr(X2APIC_TMICT, ticks / NS_PER_SEC); > f15b5: 48 89 f8 mov %rdi,%rax > f15b8: b9 00 ca 9a 3b mov $0x3b9aca00,%ecx > f15bd: 31 d2 xor %edx,%edx > f15bf: 48 0f af 05 f1 10 ff imul -0xef0f(%rip),%rax # > e26b8 <divided_apic_freq> > f15c6: ff > f15c7: 48 f7 f1 div %rcx > f15ca: b9 38 08 00 00 mov $0x838,%ecx > f15cf: 48 89 c2 mov %rax,%rdx > f15d2: 48 c1 ea 20 shr $0x20,%rdx > f15d6: 0f 30 wrmsr > f15d8: c3 retq > > It is the *wrmsr* inside the apic_timer_set to generate the fault. > Since I'm not expert of x86 (I'm more an embedded guy), I'm asking for tips > and ideas.
Interesting. This writes to a 32-bit x2APIC register. The manual states: "The upper 32-bits of all x2APIC MSRs (except for the ICR) are reserved." But the timer value calculation let EDX (lower part of RDX) become non-zero. > RAX: 0x000000044b82f9d8 RBX: 0x00000000000f060f RCX: 0x0000000000000838 > RDX: 0x0000000000000004 RSI: 0x0000000000000a36 RDI: 0xffffffffffffe134 Never tested if hardware actually explodes over this, but it would have the right to do so. Simple check: confine ticks / NS_PER_SEC to 32 bits and see if that resolves the crash. But that may cause issues regarding the desired timeout. A careful analysis of what happens here /wrt timeout calculation will be needed. E.g. what is the timeout_ns value in those cases? As you copied from apic-demo and use the inmates library, those may share the issue. Jan -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
