qemu-devel
[Top][All Lists]
Advanced

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

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


From: Avi Kivity
Subject: Re: [Qemu-devel] Big real mode use in ipxe
Date: Sun, 19 Aug 2012 18:52:43 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0

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



reply via email to

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