Kevin O'Connor wrote:
On Mon, Mar 15, 2010 at 04:28:02PM +0100, Antoine Leca wrote:
3660 ;; make sure DS and ES limits are 64KB 3661 mov ax, #0x28 3662 mov ds, ax 3663 mov es, ax
[...]
Note that while the basic scheme is the same, the "cleaning up" of lines 3660-3663 "make sure DS and ES limits are 64KB" is not present.
That does appear to be a SeaBIOS error. I'll commit a fix
Thanks.
(qemu) info registers SS =9492 00094920 0000ffff 0000f300 DS =97ce 00097cec 0000ffff 0000f300
A ds.base of 0x97cec cannot be translated to a real mode segment.
However, it's not clear why it would make a difference.
Because when you return to real mode, if you do not clean up DS (and ES) beforehand, you end up with the previous (cached) bases and limits, the ones used for the move; the problem occurs with KVM (hardware virtualization) on Intel VT, because on that platform real mode is not really possible, so it is faked... and they have no good way to fake a mis-aligned segment (not present segment is not available in V8086, for example.)
The segment limit is shown as 0xffff here - it's the segment base which is not aligned.
You are correct: the comment in Bochs BIOS is slightly misleading here. It is my guess they had a similar problem with big segments (so-called unreal mode) which caused some overflow or something: so they implemented that "fix", which is also curing our problem with mis-aligned base (and appears a Good Move, IMHO.)
On return to real mode, the segment base should have been reloaded..
No: it is well known (and used here and there) that on return from PM to RM, the segment caches are not cleared; and I believe it is even documented in Intel manuals that it is up to the application programmer to reload the segments.
Now, what we are making here is to reload _before_ the mode change, because kvm is unable to "reload" the CPU segment caches with the adequate values.
Antoine