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
prev parent 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).