On Thu, 2013-02-14 at 22:14 +0100, Laszlo Ersek wrote:
On 02/14/13 21:54, H. Peter Anvin wrote:
On 02/14/2013 12:41 PM, Laszlo Ersek wrote:
). cpu_reset() [target-i386/helper.c] sets CS:IP to f000:fff0, which is the exact address of... reset_vector() in SeaBIOS.
This would be a bug, but it isn't quite true.
If you look at x86_cpu_reset() you will note that it sets the code segment base to 0xffff0000, not 0xf0000 as one could expect from the above. This is also true of a physical x86.
As such, the *real* reset vector is at 0xfffffff0 as opposed to the SeaBIOS vector at 0xffff0 -- this is a backwards compatibility vector which typically just issues a real reset.
Now, if Qemu doesn't handle the distinction here correctly, that is a bug.
I think I was simply wrong :)
So it *is* jumping to 0xfffffff0 but the memory at that location isn't what we expect? Do the PAM registers affect *that* too, or only the region from 0xc0000-0xfffff? Surely the contents at 4GiB-δ should be unchanged by *anything* we do with the PAM registers?
Or maybe not... after also downloading the i440fx data sheet, I'm even more confused. There's some aliasing with... not the region at 1MiB-δ but the region at 16MiB-δ:
(From §4.1 System Address Map):
2. High BIOS Area (FFE0_0000h−− FFFF_FFFFh) The top 2 Mbytes of the Extended Memory Region is reserved for System BIOS (High BIOS), extended BIOS for PCI devices, and the A20 alias of the system BIOS. The CPU begins execution from the High BIOS after reset. This region is mapped to the PCI so that the upper subset of this region is aliased to 16 Mbytes minus 256-Kbyte range.