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

[Avi Kivity <avi@redhat.com>]

On 08/19/2012 06:34 PM, Michael Brown wrote:
> On Sunday 19 Aug 2012 16:07:05 Avi Kivity wrote:
>> 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.
> 
> Not quite.  You can't "return into real mode without touching the segment", 
> since part of the process of returning to real mode is to reload the segment 
> registers with real-mode values, and this happens _after_ setting CR0.PE=0.
> 
> Whenever CR0.PE=0, loading a segment register with value N will load the 
> literal value (N<<4) into the base address for that segment, without changing 
> the limit.  This is the trick that allows flat real mode (aka big real mode) to 
> work; the limit remains at 4G even after loading the segment register with a 
> real-mode value.

So I see, from looking at the Xen source.  I'll also double-check with
bochs.  Looks like I'll need to fix kvm not to reset the segment limit
when reloading a segment in real mode.

> 
>> (and that seabios needs changes to either work in
>> big real mode, or to put the processor back into big real mode after
>> returning from a PMM service.
> 
> If seabios switches into protected mode when performing a PMM service, then it 
> _must_ leave the segment limits at 4G when returning to real mode.  To do 
> otherwise will violate the PMM spec, and will break conforming clients such as 
> iPXE.

This probably works, since iPXE works on kvm on AMD and on Intel
processors with "unrestricted guest" support.

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