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. -- 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
