[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Bug 1180923] [NEW] unused memory filled with 0x00 inst
From: |
Kevin O'Connor |
Subject: |
Re: [Qemu-devel] [Bug 1180923] [NEW] unused memory filled with 0x00 instead of 0xFF |
Date: |
Mon, 20 May 2013 21:31:49 -0400 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Fri, May 17, 2013 at 10:59:25AM -0500, Anthony Liguori wrote:
> Paolo Bonzini <address@hidden> writes:
> > So you can see it in three ways:
> >
> > 1) It's not a QEMU problem, but a firmware problem. You could initialize
> > the UMBs with 0xFF in SeaBIOS for example.
>
> SeaBIOS is not supposed to do any initialization. Once it's RAM,
> there's no guarantee of what the contents will be. The problem is that
> it's supposed to be ROM.
>
> I doubt it's still there, but BIOSes often had an option to disable
> ROM shadowing expressly because it breaks applications that assume that
> this space is ROM after BIOS loads.
>
> Perhaps SeaBIOS could support such an option but we can't support it in
> KVM at the moment.
It would not be easy to make SeaBIOS work with a truly read-only rom.
SeaBIOS is designed to store static settings in the f-segment (where
it can be accessed relative to %cs at runtime), and undoing that would
be quite difficult.
However, it is not too difficult to make SeaBIOS turn the
0xc0000-0x100000 area into read-only memory after initialization. The
biggest stumbling block is that SeaBIOS stores read/write variables in
the e-segment today, but it's possible to store them at the end of the
640k region instead (I posted a patch for this at:
http://www.seabios.org/pipermail/seabios/2013-February/005693.html ).
Once the memory 0xc0000-0x100000 ram can be read-only, setting the pam
registers to mark it as read-only and memset'ing the region to 0xff is
straight forward.
-Kevin
[Prev in Thread] |
Current Thread |
[Next in Thread] |