On Thu, Sep 16, 2010 at 08:34:40AM +0200, Gleb Natapov wrote:
On Wed, Sep 15, 2010 at 11:34:31PM -0400, Kevin O'Connor wrote:
Yeah. It looks like kvm is updating the ram at 0xffff0000 when writes are done to 0xf0000. It's not ideal.
AFAIK immediately after reset memory accesses to 0xffff0000 and 0xf0000 are directed to exactly same ROM chip. Are you saying that after shadowing BIOS at location 0xf0000 and modifying it in memory BIOS copy as seeing at 0xffff0000 changes too?
It appears that way. I added the following code to seabios' ram_probe (you could add it just about anywhere):
{ static u32 myvar; u32 *myvardelta = (void*)&myvar + 0xfff00000; dprintf(1, "1: myvar=%d/%d\n", myvar, *myvardelta); barrier(); myvar = 99; dprintf(1, "2: myvar=%d/%d\n", myvar, *myvardelta); barrier(); myvar = 13; dprintf(1, "3: myvar=%d/%d\n", myvar, *myvardelta); }
On qemu I get:
1: myvar=0/0 2: myvar=99/0 3: myvar=13/0
On kvm I get:
1: myvar=0/0 2: myvar=99/99 3: myvar=13/13
Static variables are placed in the f-segment, so it looks like writes are going to both places on kvm. The 0xfff00000 should basically never change (on a real machine you'd need to send erase/write sequences to the flash chip to change the contents). This is qemu-kvm that ships with FC13: qemu-kvm-0.12.5
-Kevin