Aw: Re: Questions about PVH memory layout

[joshua_peter@xxxxxx]

Hi Roger,

thank you very much for your help. Further replies are inline.

> Gesendet: Montag, 29. Juni 2020 um 10:57 Uhr
> Von: "Roger Pau Monné" <roger.pau@xxxxxxxxxx>
> An: joshua_peter@xxxxxx
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx
> Betreff: Re: Questions about PVH memory layout
>
> > The other
> > thing is, the first 512 pages at the beginning of the address space are
> > mapped linearly, which usually leads to them being mapped as a single
> > 2MB pages. But there is this one page at 0x00001000 that sticks out
> > completely. By that I mean (to make things more concrete), in my PVH
> > guest the page at 0x00000000 maps to 0x13C200000, 0x00002000 maps to
> > 0x13C202000, 0x00003000 maps to 0x13C203000, etc. But 0x00001000 maps
> > to 0xB8DBD000, which seems very odd to me (at least from simply looking
> > at the addresses).
> 
> Are you booting some OS on the guest before dumping the memory map?
> Keep in mind guest have the ability to modify the physmap, either by
> mapping Xen shared areas (like the shared info page) or just by using
> ballooning in order to poke holes into it (which can be populated
> later). It's either that or some kind of bug/missoptimization in
> meminit_hvm (also part of tools/libxc/xc_dom_x86.c).

Yes, my bad. I'm booting into Arch Linux. This must have been lost while I
was editing my e-mail.

> Can you check if this 'weird' mapping at 0x1000 is also present if you
> boot the guest with 'xl create -p foo.cfg'? (that will prevent the
> guests from running, so that you can get the memory map before the
> guest has modified it in any way).

Yeah, starting with the "-p" flag does get rid of this 'weird' mapping.

Thank you again. This cleared up a bunch of things.

Best regards,
Peter