From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [Qemu-devel] Big real mode use in ipxe Date: Sun, 19 Aug 2012 18:52:43 +0300 Message-ID: <50310BCB.8000101@redhat.com> References: <50310119.4070806@redhat.com> <20120819154441.GB12794@morn.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: "seabios-VcxPKcuBGKdAfugRpC6u6w@public.gmane.org" , ipxe-devel-VUaoxwjD3yI@public.gmane.org, qemu-devel , KVM list To: "Kevin O'Connor" Return-path: In-Reply-To: <20120819154441.GB12794-gj0VCiUcOQ582hYKe6nXyg@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipxe-devel-bounces-Ajx3hB6KsW1nerjlECmc1w@public.gmane.org Errors-To: ipxe-devel-bounces-Ajx3hB6KsW1nerjlECmc1w@public.gmane.org List-Id: kvm.vger.kernel.org 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