From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:34718) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T37o3-0007ga-Qi for qemu-devel@nongnu.org; Sun, 19 Aug 2012 11:52:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T37o2-0004LE-Od for qemu-devel@nongnu.org; Sun, 19 Aug 2012 11:52:51 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36345) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T37o2-0004LA-FR for qemu-devel@nongnu.org; Sun, 19 Aug 2012 11:52:50 -0400 Message-ID: <50310BCB.8000101@redhat.com> Date: Sun, 19 Aug 2012 18:52:43 +0300 From: Avi Kivity MIME-Version: 1.0 References: <50310119.4070806@redhat.com> <20120819154441.GB12794@morn.localdomain> In-Reply-To: <20120819154441.GB12794@morn.localdomain> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Big real mode use in ipxe List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin O'Connor Cc: "seabios@seabios.org" , ipxe-devel@ipxe.org, qemu-devel , KVM list 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