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

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

[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, jreiser@BitWagon.com

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

[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.