[ipxe-devel] [Qemu-devel] Big real mode use in ipxe

[Avi Kivity]

On 08/19/2012 06:44 PM, Kevin O'Connor wrote:
> On Sun, Aug 19, 2012 at 06:07:05PM +0300, Avi Kivity wrote:
>> ipxe contains the following snippet:
>> 
>> 	/* Copy ROM to image source PMM block */
>> 	pushw	%es
>> 	xorw	%ax, %ax
>> 	movw	%ax, %es
>> 	movl	%esi, %edi
>> 	xorl	%esi, %esi
>> 	movzbl	romheader_size, %ecx
>> 	shll	$9, %ecx
>> 	addr32 rep movsb	/* PMM presence implies flat real mode */
>> 
>> Which copies an image to %edi, with %edi >= 0x10000.  This is in accordance with the PMM spec:
> [...]
>> So far so good.  But the Intel SDM says (20.1.1):
>> 
>> "The IA-32 processors beginning with the Intel386 processor can generate 32-bit offsets using an address override prefix; however, in real-address mode, the value of
>> a 32-bit offset may not exceed FFFFH without causing an exception. For full compatibility with Intel 286 real-address mode, pseudo-protection faults (interrupt 12 or 13) occur if a 32-bit offset is generated outside the range 0 through FFFFH."
> 
> I interpretted the above to mean "however, in [normal real-mode where
> the segment registers are set to 0xffff] real-address mode, the value
> of a 32-bit offset may not exceed FFFFH without causing an exception"

I understood it the same way.

> 
>> Which is exactly what happens here.  My understanding of big real
>> mode is that to achieve a segment limit != 0xffff, you must go into
>> 32-bit protected mode, load a segment with a larger limit, and
>> return into real mode without touching the segment.  The next load
>> of the segment will reset the limit to 0xffff.
> 
> No, the segment limit is only changed when the protected mode bit is
> set and the segment register is loaded.  When the protected mode bit
> is not set, only the segment offset changes.

That's what I missed.  I always understood a segment reload in real mode
to reset the limit field, though I had no basis for it.  I'll fix kvm
not to do this.


-- 
error compiling committee.c: too many arguments to function