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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
