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

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

 



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"

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

[...]
> The PMM spec also has this to say (1.3):
> 
> "Big Real Mode
> 
> Big Real Mode is a modified version of the processor’s real mode
> with the segment limits changed from 1MB to 4GB. Big real mode
> allows the BIOS or an Option ROM to read and write extended memory
> without the overhead of protected mode. The BIOS puts the processor
> in big real mode during POST to allow simplified access to extended
> memory. The processor will be in big real mode while the PMM
> Services are callable."
> 
> This is more in line with the Intel spec, and means that the
> modification to %es must be avoided (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.

The SeaBIOS code is regularly used on a variety of real processors
(which do enforce segment limits).  This includes several different
AMD processors and Intel processors.  It has also been tested in the
past with other manufacturers (eg, Via).  We've never seen an issue
with the "big real mode" support.

> The whole thing is very unfortunate, as kvm is very slow while in
> big real mode, on certain processors.

Unfortunately, "big real mode" is a requirement for option roms.

-Kevin
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux