Re: [Qemu-devel] [SeaBIOS] [edk2] (PAM stuff) reset doesn't work on OVMF + SeaBIOS CSM

[Laszlo Ersek]

On 02/14/13 22:27, David Woodhouse wrote:
> 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?

I meant that my reading of what x86_cpu_reset() [nee cpu_reset()] was
wrong, because the constant that it passes as argument in fact conforms
to what Peter says.

(
Also check the rom_add_file_fixed() call in pc_init1() / qemu:

    ret = rom_add_file_fixed(bios_name, (uint32_t)(-bios_size), -1);

("bios_size" is an "int"). I referred to this in my thread starter as

    When qemu-kvm starts, "OVMF.fd" is installed as ROM, such that the
    last address it occupies is "all-bits-one", independently of its
    size [...]

Namely, the value of (uint32_t)(-bios_size) is

    UINT32_MAX + 1 - bios_size

(the above is meant as a math formula, not as a C expression), hence the
last byte occupied is at UINT32_MAX. In my first post I silently thought
that this value would be truncated to fewer bits somewhere, but
apparently that's not the case.
)

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

After Peter emphasized that the code segment base was 0xffff0000, I went
back to wikipedia <http://en.wikipedia.org/wiki/Reset_vector>, and
finally managed to parse

    The reset vector for the 80386DX and later x86 processors is
    0xFFFF0, although the value of the CS register at reset is 0xF000
    and the value of the IP register at reset is 0xFFF0. In actuality,
    current x86 processors fetch from the physical address 0xFFFFFFF0.
    This is due to a hidden base address portion of the CS register in
    real mode which defaults to 0xFFFF0000 after reset.

This is again consistent with the 0xfffffff0 vector pointed out by Peter
(= 0xFFFF0000 + 0xFFF0), but I don't know how to match it to the data
sheet language...

Thanks
Laszlo