qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Kevin O'Connor <kevin@koconnor.net>
Cc: "seabios@seabios.org" <seabios@seabios.org>,
	ipxe-devel@ipxe.org, qemu-devel <qemu-devel@nongnu.org>,
	KVM list <kvm@vger.kernel.org>
Subject: Re: [Qemu-devel] Big real mode use in ipxe
Date: Sun, 19 Aug 2012 18:52:43 +0300	[thread overview]
Message-ID: <50310BCB.8000101@redhat.com> (raw)
In-Reply-To: <20120819154441.GB12794@morn.localdomain>

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

      reply	other threads:[~2012-08-19 15:52 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-19 15:07 [Qemu-devel] Big real mode use in ipxe Avi Kivity
2012-08-19 15:34 ` [Qemu-devel] [ipxe-devel] " Michael Brown
2012-08-19 15:42   ` Avi Kivity
2012-08-19 15:53   ` Kevin O'Connor
2012-08-19 15:44 ` [Qemu-devel] " Kevin O'Connor
2012-08-19 15:52   ` Avi Kivity [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50310BCB.8000101@redhat.com \
    --to=avi@redhat.com \
    --cc=ipxe-devel@ipxe.org \
    --cc=kevin@koconnor.net \
    --cc=kvm@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    --cc=seabios@seabios.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).