From: Avi Kivity <avi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: "Kevin O'Connor" <kevin-BG7uPxbsK//k1uMJSBkQmQ@public.gmane.org>
Cc: "seabios-VcxPKcuBGKdAfugRpC6u6w@public.gmane.org"
<seabios-VcxPKcuBGKdAfugRpC6u6w@public.gmane.org>,
ipxe-devel-VUaoxwjD3yI@public.gmane.org,
qemu-devel <qemu-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org>,
KVM list <kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.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-gj0VCiUcOQ582hYKe6nXyg@public.gmane.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
WARNING: multiple messages have this Message-ID (diff)
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
next prev parent reply other threads:[~2012-08-19 15:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-19 15:07 Big real mode use in ipxe Avi Kivity
2012-08-19 15:07 ` [Qemu-devel] " Avi Kivity
[not found] ` <50310119.4070806-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2012-08-19 15:34 ` Michael Brown
2012-08-19 15:34 ` [Qemu-devel] [ipxe-devel] " Michael Brown
2012-08-19 15:42 ` Avi Kivity
2012-08-19 15:42 ` [Qemu-devel] " Avi Kivity
2012-08-19 15:53 ` Kevin O'Connor
2012-08-19 15:44 ` [Qemu-devel] " Kevin O'Connor
2012-08-19 15:44 ` Kevin O'Connor
[not found] ` <20120819154441.GB12794-gj0VCiUcOQ582hYKe6nXyg@public.gmane.org>
2012-08-19 15:52 ` Avi Kivity [this message]
2012-08-19 15:52 ` Avi Kivity
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-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
--cc=ipxe-devel-VUaoxwjD3yI@public.gmane.org \
--cc=kevin-BG7uPxbsK//k1uMJSBkQmQ@public.gmane.org \
--cc=kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=qemu-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org \
--cc=seabios-VcxPKcuBGKdAfugRpC6u6w@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.