On 08/19/2012 06:34 PM, Michael Brown wrote:
On Sunday 19 Aug 2012 16:07:05 Avi Kivity wrote:
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.
Not quite. You can't "return into real mode without touching the segment", since part of the process of returning to real mode is to reload the segment registers with real-mode values, and this happens _after_ setting CR0.PE=0.
Whenever CR0.PE=0, loading a segment register with value N will load the literal value (N<<4) into the base address for that segment, without changing the limit. This is the trick that allows flat real mode (aka big real mode) to work; the limit remains at 4G even after loading the segment register with a real-mode value.
So I see, from looking at the Xen source. I'll also double-check with bochs. Looks like I'll need to fix kvm not to reset the segment limit when reloading a segment in real mode.
(and that seabios needs changes to either work in big real mode, or to put the processor back into big real mode after returning from a PMM service.
If seabios switches into protected mode when performing a PMM service, then it _must_ leave the segment limits at 4G when returning to real mode. To do otherwise will violate the PMM spec, and will break conforming clients such as iPXE.
This probably works, since iPXE works on kvm on AMD and on Intel processors with "unrestricted guest" support.