|
From: | Jakob Bohm |
Subject: | Re: [Qemu-discuss] sti triggers strange behavior |
Date: | Thu, 22 Jan 2015 09:08:01 +0100 |
User-agent: | Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 |
On 19/01/2015 23:03, address@hidden
wrote:
First the obvious possibility: Are you handling the debug exceptions,I've been working on a small kernel, but I've found that any useage of the sti instruction makes the virtual system restart endlessly very quickly running the same program over and over. When I have an IDT installed it registers interrupt 1. I posted a question here https://stackoverflow.com/questions/27994889/sti-triggers-debug-exception-in-qemu , but got nothing. Does anyone know what could cause this behavior? (on x86: IDT entries 1 and 3, possibly also other entries from 0 to 0x0F). If not, emulating simple debugging of your code would trigger emulated calls to those exceptions, which then degenerate to double faults or triple faults, which would crash or reset real CPUs. Next the more tricky case: What interrupts are the virtual hardware generating?, and are any of the corresponding IDT entries left blank/disabled/invalid? If so, even a real machine would reboot (actually, crash) every time the CPU (with interrupts enabled) receives an interrupt for which the IDT does not tell it what to do. On a real machine, this is avoided by first (before the first sti) programming some piece of real/virtual hardware to not pass the unwanted interrupts to the real/virtual CPU, thus avoiding the problem. On historic PCs, these were one or two 8259 8-input interrupt controller chips. On modern x86/x64 CPUs this would be the APIC "chip" (physically on the CPU die). On non-x86 architectures, there are often similar interrupt controller devices on the mainboard or inside the SoC. As an additional complication, I am unsure if qemu fully emulates unusual configurations of the virtual interrupt controller, for example, qemu might be passing on some rarely disabled interrupt sources unconditionally. One way around this (for debugging) would be to fill your IDT with dummy handlers that tell you which one was called. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded |
[Prev in Thread] | Current Thread | [Next in Thread] |