[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [SeaBIOS] [Qemu-devel] QEMU regression problems
From: |
Kevin O'Connor |
Subject: |
Re: [SeaBIOS] [Qemu-devel] QEMU regression problems |
Date: |
Wed, 21 Apr 2010 19:02:03 -0400 |
User-agent: |
Mutt/1.5.20 (2009-08-17) |
On Wed, Apr 21, 2010 at 09:16:54PM +0200, Gerhard Wiesinger wrote:
> On Mon, 19 Apr 2010, Kevin O'Connor wrote:
> >SeaBIOS will lock parts of ram from 0xc0000-0xfffff so that the option
> >roms aren't writable. I wonder if that is confusing qemm when it
> >tries to locate the ebda into that area.
>From your initial log, it looks like QEMM tried to relocate the ebda
to CEB5h-D035h. However, the seabios log shows the last rom
(genroms/vapic.bin) at 0xce800-0xd0a00. So, SeaBIOS would have locked
that ram. Can you see if the patch below shows a different result for
you?
> Is the area from 0xc0000-0xfffff only read only when an option ROM
> is installed at some part of the memory area (e.g. option ROM at
> 0xD0000 to 0xDFFFF only 0xD0000 to 0xDFFFF is made read only) or the
> comple area is made read only?
SeaBIOS will lock only those areas it deployed option roms into.
However, the chipset only allows locking of 16K chunks - so SeaBIOS
will round up the option rom storage to the nearest 16K block. For
example, should the last rom end at 0xd0a00, then SeaBIOS would lock
up to 0xd4000.
-Kevin
--- a/src/shadow.c
+++ b/src/shadow.c
@@ -104,6 +104,8 @@ make_bios_readonly(void)
// Flush any pending writes before locking memory.
wbinvd();
+ dprintf(1, "RomEnd=%x\n", RomEnd);
+#if 0
// Write protect roms from 0xc0000-0xf0000
int i;
for (i=0; i<6; i++) {
@@ -115,6 +117,7 @@ make_bios_readonly(void)
}
pci_config_writeb(bdf, 0x5a + i, 0x11);
}
+#endif
// Write protect 0xf0000-0x100000
pci_config_writeb(bdf, 0x59, 0x10);