[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-discuss] sti triggers strange behavior

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:
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?

First the obvious possibility: Are you handling the debug exceptions,
(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.


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 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]