qemu-devel
[Top][All Lists]
Advanced

[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);




reply via email to

[Prev in Thread] Current Thread [Next in Thread]