On host (UEFI legacy mode):
lkd> !pfn 0xf0
PFN 000000F0 at address FFFFFA8000002D00
flink FFFFFFFFFFFFFFFF blink / share count FFFFFFFFFFFFFFFF pteaddress FFFFFFFFFFFFFFFF
reference count FFFF used entry count FFFF NotMapped color 3F Priority 7
restore pte FFFFFFFFFFFFFFFF containing page FFFFFFFFFFFFF Trans MPRWEXY
Modified Shared ReadInProgress WriteInProgress InPageError ParityError RemovalRequested
On VM (legacy BIOS):
kd> !pfn 0xf0
PFN 000000F0 at address FFFFFA8000002D00
flink 00000000 blink / share count 00000000 pteaddress 00000000
reference count 0000 used entry count 0000 NonCached color 0 Priority 0
restore pte 00000000 containing page 000000 Zeroed
For the record !db 0xf0000 works correctly on both machines, and the PFN entry is the same before and after the momentary mapping performed by !db on both machines. Could the first one be a stupid kd -kl / livekd issue again?
Curious. I thought it could be that 0xf0 has never been mapped as opposed to mapped then unmapped, and for some reason left as MiNonCached and not MiNotMapped (and it may or may not return it to MiNotMapped when unmapping a cached area, but I don't know). I would have thought that this range would never have been mapped on ntoskrnl because it's not supposed to be using BIOS services.
On the host:
lkd> !pfn 0xf1
PFN 000000F1 at address FFFFFA8000002D30
flink FFFFFFFFFFFFFFFF blink / share count FFFFFFFFFFFFFFFF pteaddress B47756FFFFE9FFFF
reference count 517C used entry count B4E9 Cached color 2D Priority 7
restore pte FFFFFFFFFFFFFFFF containing page 756FFFFE9FFFF Bad WEXY
WriteInProgress InPageError ParityError RemovalRequested
This time it's 'Cached', and clearly contains garbage, so the MiNotMapped part of the question may be irrelevant, and should have perhaps been whats the difference between a garbage PFN entry and a zero intialised one?
