Re: [PATCH] x86/PV: assert page state in mark_pv_pt_pages_rdonly()

[Jan Beulich <jbeulich@xxxxxxxx>]

On 17.08.2021 12:30, Andrew Cooper wrote:
> On 17/08/2021 09:54, Jan Beulich wrote:
>> On 16.08.2021 21:25, Andrew Cooper wrote:
>>> On 16/08/2021 16:29, Jan Beulich wrote:
>>>> and an apparently wrong comment stating
>>>> that not only v_end but also v_start would be superpage aligned
>>> Which comment?  The only one I see about 4M has nothing to do with
>>> superpages.
>> The one immediately ahead of the related variable declarations:
>>
>>     /*
>>      * This fully describes the memory layout of the initial domain. All
>>      * *_start address are page-aligned, except v_start (and v_end) which are
>>      * superpage-aligned.
>>      */
>>
>> I see nothing forcing v_start to be superpage-aligned, while I
>> do suspect that the "calculation" of the number of page tables
>> will be wrong when it isn't.
> 
> This is an XTF test booting as dom0
> 
> (d2) (XEN) *** Building a PV Dom0 ***
> (d2) (XEN) ELF: phdr: paddr=0x100000 memsz=0x12000
> (d2) (XEN) ELF: memory: 0x100000 -> 0x112000
> (d2) (XEN) ELF: note: GUEST_OS = "XTF"
> (d2) (XEN) ELF: note: GUEST_VERSION = "0"
> (d2) (XEN) ELF: note: LOADER = "generic"
> (d2) (XEN) ELF: note: HYPERCALL_PAGE = 0x106000
> (d2) (XEN) ELF: note: XEN_VERSION = "xen-3.0"
> (d2) (XEN) ELF: note: FEATURES = "!writable_page_tables|pae_pgdir_above_4gb"
> (d2) (XEN) ELF: note: PAE_MODE = "yes"
> (d2) (XEN) ELF: using notes from SHT_NOTE section
> (d2) (XEN) ELF: VIRT_BASE unset, using 0
> (d2) (XEN) ELF_PADDR_OFFSET unset, using 0
> (d2) (XEN) ELF: addresses:
> (d2) (XEN)     virt_base        = 0x0
> (d2) (XEN)     elf_paddr_offset = 0x0
> (d2) (XEN)     virt_offset      = 0x0
> (d2) (XEN)     virt_kstart      = 0x100000
> (d2) (XEN)     virt_kend        = 0x112000
> (d2) (XEN)     virt_entry       = 0x100000
> (d2) (XEN)     p2m_base         = 0xffffffffffffffff
> (d2) (XEN)  Xen  kernel: 64-bit, lsb, compat32
> (d2) (XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x100000 -> 0x112000
> (d2) (XEN) PHYSICAL MEMORY ARRANGEMENT:
> (d2) (XEN)  Dom0 alloc.:   000000003e800000->000000003ec00000 (240731
> pages to be allocated)
> (d2) (XEN) VIRTUAL MEMORY ARRANGEMENT:
> (d2) (XEN)  Loaded kernel: 0000000000100000->0000000000112000
> (d2) (XEN)  Init. ramdisk: 0000000000112000->0000000000112000
> (d2) (XEN)  Phys-Mach map: 0000000000112000->00000000002ea2d8
> (d2) (XEN)  Start info:    00000000002eb000->00000000002eb4b8
> (d2) (XEN)  Xenstore ring: 0000000000000000->0000000000000000
> (d2) (XEN)  Console ring:  0000000000000000->0000000000000000
> (d2) (XEN)  Page tables:   00000000002ec000->00000000002f1000
> (d2) (XEN)  Boot stack:    00000000002f1000->00000000002f2000
> (d2) (XEN)  TOTAL:         0000000000000000->0000000000400000
> (d2) (XEN)  ENTRY ADDRESS: 0000000000100000
> 
> It would appear that v_start comes directly and unmodified from the
> VIRT_BASE ELF note.
> 
> Other observations:  The ramdisk start/end aren't zero despite one being
> absent, and the M2P and start info ends aren't aligned.

I've already dealt with this ramdisk aspect in the v2 patch altering
the printing. For *_end there's nothing wrong to be misaligned (as
per the comment in question) - only v_end has a statement.

Jan