From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56383) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T375u-0007C7-5r for qemu-devel@nongnu.org; Sun, 19 Aug 2012 11:07:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T375s-0002Du-V7 for qemu-devel@nongnu.org; Sun, 19 Aug 2012 11:07:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:27012) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T375s-0002Dn-Mg for qemu-devel@nongnu.org; Sun, 19 Aug 2012 11:07:12 -0400 Message-ID: <50310119.4070806@redhat.com> Date: Sun, 19 Aug 2012 18:07:05 +0300 From: Avi Kivity MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] Big real mode use in ipxe List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: ipxe-devel@ipxe.org Cc: "seabios@seabios.org" , qemu-devel , KVM list 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 >=3D 0x10000. This is in accord= ance with the PMM spec: "3.2.4 Accessing Extended Memory This section specifies how clients should access extended memory blocks a= llocated by the PMM. When control is passed to an option ROM from a BIOS = that supports PMM, the processor will be in big real mode, and Gate A20 w= ill be disabled (segment wrap turned off). This allows access to extended= memory blocks using real mode addressing. In big real mode, access to memory above 1MB can be accomplished by using= a 32-bit extended index register (EDI, etc.) and setting the segment reg= ister to 0000h. The following code example assumes that the pmmAllocate f= unction was just called to allocate a block of extended memory, and DX:AX= returned the 32-bit buffer address. ; Assume here that DX:AX contains the 32-bit address of our allocated buf= fer. ; Clear the DS segment register. push 0000h pop ds ; Put the DX:AX 32-bit buffer address into EDI. mov di, dx ; Get the upper word. shl edi, 16 ; Shift it to upper EDI. mov di, ax ; Get the lower word. ; Example: clear the first four bytes of the extended memory buffer. mov [edi], 00000000h ; DS:EDI is used as the memory pointer. In a similar way, the other segment registers and 32-bit index registers = can be used for extended memory accessing." 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 fu= ll compatibility with Intel 286 real-address mode, pseudo-protection faul= ts (interrupt 12 or 13) occur if a 32-bit offset is generated outside the= range 0 through FFFFH." Which is exactly what happens here. My understanding of big real mode is= that to achieve a segment limit !=3D 0xffff, you must go into 32-bit pro= tected mode, load a segment with a larger limit, and return into real mod= e without touching the segment. The next load of the segment will reset = the limit to 0xffff. Due to bugs in both qemu tcg and kvm, limit checks are not enforced in re= al mode, but once this bugs are fixed, the code above will break. The PMM spec also has this to say (1.3): "Big Real Mode Big Real Mode is a modified version of the processor=E2=80=99s 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 over= head of protected mode. The BIOS puts the processor in big real mode duri= ng 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 ret= urning from a PMM service. The whole thing is very unfortunate, as kvm is very slow while in big rea= l mode, on certain processors. --=20 error compiling committee.c: too many arguments to function