Re: [Qemu-devel] [Bug 1180923] [NEW] unused memory filled with 0x00 instead of 0xFF

[Anthony Liguori]

Paolo Bonzini <address@hidden> writes:

> Il 16/05/2013 22:00, Peter Maydell ha scritto:
>>> > Sounds like (risky) memory probing.  On a PC the memory regions that
>>> > are unpopulated produce 0xff.
>> Presumably you could fix the PC model to do that by putting a big
>> background (overlappable) MemoryRegion across the whole of the
>> system address space which returned -1 for every access?
>
> On a modern PC, there is really no non-present memory region where UMBs
> used to be.  Memory between 0xc0000 and 0x100000 will be mostly unused,
> but it is not mentioned in the firmware ("e820") memory map.

It's not memory (at least not by default).

> For example on KVM the memory map is:
>
> [    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
> [    0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
> [    0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
> [    0.000000] BIOS-e820: [mem 0x0000000000100000-0x0000000007ffdfff] usable
> [    0.000000] BIOS-e820: [mem 0x0000000007ffe000-0x0000000007ffffff] reserved
> [    0.000000] BIOS-e820: [mem 0x00000000feffc000-0x00000000feffffff] reserved
> [    0.000000] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
>
> but SeaBIOS says:
>
> Copying option rom (size 36352) from 0xfebc0000 to 0x000c0000
> Copying option rom (size 65536) from 0xfebd0000 to 0x000c9000
> Copying option rom (size 1024) from genroms/linuxboot.bin to 0x000ca000
> Copying option rom (size 9216) from genroms/kvmvapic.bin to 0x000ca800
> Space available for UMB: cd000-ee800, f0000-f1c20

There are a couple things happening here.

Long before the PCI roms are moved to the option rom space, that space
is made writable via PAM.  PAM is a more modern feature that was
introduced to make firmware execution much faster.

Without PAM, this whole range is mapped to ROM memory which means it's
going to get put out on a bus.  If there isn't a ROM mapped, the result
is going to be 0xFF.

We don't emulate this correctly because we don't emulate execute from
ROM which means that we always treat the option rom space as RAM even
though is it not at start of day.

> 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.

> However, it is probably
> necessary to round the UMBs somehow, because emm386 probably probes
> memory with a larger granularity than 32 bytes.  For example, in the case
> above you may want to leave 0x00 outside 0xD0000-0xEC000 (16kb granularity).
> You also need to ensure the UMBs are write-protected (I do not remember if
> that's already the case).
>
> 2) It's not a QEMU prablem, but an EMM386 problem.  Simply, EMM386
> does not support chipsets that have RAM at 0xc0000-0x100000.  I found
> some information about a program called UMBPCI that you can use instead
> of EMM386.

Ack, but this is why it was possible to disable ROM shadowing....

> 3) It's a QEMU problem, but it should only work with "-M isapc".  This
> would be similar to what Peter suggested, but it would give you very
> small UMBs (something like 0xD0000-0xE0000).  To go beyond that you
> need to recompile SeaBIOS so that it fits in a 64kb ROM.  It's probably
> possible to make it fit, but you may encounter SeaBIOS bugs because no
> one uses it with such a small ROM.  Having a more useful ISA PC emulation
> in QEMU would be a nice project, but no one really has time for that
> among the most active developers.

I think the first step is to get execute from ROM working and then
implement PAM correctly.  Then it wouldn't be that hard to implement
SeaBIOS changes to only conditionally shadow ROMs.

Regards,

Anthony Liguori

>
> Paolo