[Qemu-devel] qemu-0.8.2 i386 -kernel hangs when gdt and idt are zero length

2006-10-14 Thread John Reiser
Hi,

Under qemu-0.8.2 when emulating i386 -kernel in protected mode,
and if both the idt and gdt have length zero, then trying
to load a segment register loops for a very long time.

cli
lidtl  empty_idt
lgdtl  empty_gdt  # %cs info persists in internal registers
movl $0x18,%eax
movl %eax,%ds  # qemu-0.8.2 hangs here

.data
  empty_idt:
.short 0  # length is zero
.long 0
  empty_gdt:
.short 0  # length is zero
.long 0

Because the gdt has length 0, then the descriptor for segment
0x18>>3 does not exist in memory.  The Intel manual claims the
hardware gives "#GP(selector)" fault for loading the segment
register when the selector index is not within limits, but
delivery of the exception depends on the idt.  When the idt
also has zero length, then real hardware enters double-fault
territory (perhaps triple-fault?) and shuts down.

It would be nice if qemu emulation detected such a situation,
then issued an informative message, in addition to
looping forever as an "emulation" of hardware shutdown.

-- 
John Reiser, [EMAIL PROTECTED]


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


Re: [Qemu-devel] qemu-0.8.2 i386 -kernel hangs when gdt and idt are zero length

2006-10-15 Thread Fabrice Bellard

John Reiser wrote:

Hi,

Under qemu-0.8.2 when emulating i386 -kernel in protected mode,
and if both the idt and gdt have length zero, then trying
to load a segment register loops for a very long time.

cli
lidtl  empty_idt
lgdtl  empty_gdt  # %cs info persists in internal registers
movl $0x18,%eax
movl %eax,%ds  # qemu-0.8.2 hangs here

.data
  empty_idt:
.short 0  # length is zero
.long 0
  empty_gdt:
.short 0  # length is zero
.long 0

Because the gdt has length 0, then the descriptor for segment
0x18>>3 does not exist in memory.  The Intel manual claims the
hardware gives "#GP(selector)" fault for loading the segment
register when the selector index is not within limits, but
delivery of the exception depends on the idt.  When the idt
also has zero length, then real hardware enters double-fault
territory (perhaps triple-fault?) and shuts down.

It would be nice if qemu emulation detected such a situation,
then issued an informative message, in addition to
looping forever as an "emulation" of hardware shutdown.


The first step could be to avoid the infinite loop in the CPU code (it 
prevents exiting the main loop and it is a serious bug).


Emulating double faults could be done, but it is not my priority yet.

Perhaps adding a counter to indicate the number of recursions in the 
interrupt code could suffice to monitor the shutdown conditions.


Regards,

Fabrice.


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel