On Tue, Aug 06, 2013 at 05:31:29PM +0200, Laszlo Ersek wrote:
> Can you capture the OVMF debug output? Do you see
> 
>   ConvertPages: Incompatible memory types
> 
> there?
> 
> Can you set the following bits too in the debug mask?
> 
> #define DEBUG_POOL      0x00000010  // Alloc & Free's
> #define DEBUG_PAGE      0x00000020  // Alloc & Free's

Ok, I got debug output; I have to be careful now of not missing
anything. Ok, so here we go:

First of all, I changed debugging mask to:

  gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x8010007F

(I just set all three bits you requested).

Using the new OVMF.id changed the addresses, of course, so we're looking
at 0x7dc59XXX ones now.

[    0.000000] memblock_reserve: [0x0000007dc59018-0x0000007dc59618] efi_memblock_x86_reserve_range+0x70/0x75

So, I've attached an archive of the debug logs. The initial observations
I could do is that the region still gets "squashed" to:

[    0.014041] efi: mem11: type=4, attr=0xf, range=[0x000000007dc59000-0x000000007dc59000) (0MB)

from

[    0.000000] efi: mem11: type=4, attr=0xf, range=[0x000000007dc59000-0x000000007e146000) (4MB)

And the interesting stuff in the OVMF output is right at the end:

ConvertRange: 7DC59000-7DC5AFFF to 4
AddRange: 7DC59000-7DC5AFFF to 4
AllocatePoolI: Type 4, Addr 7DC59018 (len 16F0) 26,735,072
Jumping to kernel

We get that same output no matter if I boot it with "-enable-kvm" or
not.

If the order of the debug messages is the same as the calls actually
happen, we AllocatePoolI to address 7DC59018 which we already have added
as a range. But I'm not going to pretend I even know the code so I'll
let you comment instead :).

Thanks.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--