qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

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