Re: [PATCH v3 0/4] x86/mm: miscellaneous fixes

[Jan Beulich <jbeulich@xxxxxxxx>]

On 15.11.2024 01:55, Andrew Cooper wrote:
> On 14/11/2024 2:57 pm, Roger Pau Monne wrote:
>> Hello,
>>
>> The attempt to fix destroy_xen_mappings() so that L2 tables are
>> consistently freed uncovered some errors in the memory management code.
>> The following series attempts to fix them.
>>
>> All patches except for 4/4 are new in v2, and 4/4 has no change from v1,
>> hence kept Jan's Reviewed-by tag in 4/4.
>>
>> Thanks, Roger.
>>
>> Roger Pau Monne (4):
>>   x86/mm: introduce helpers to detect super page alignment
>>   x86/mm: skip super-page alignment checks for non-present entries
>>   x86/setup: remove bootstrap_map_addr() usage of destroy_xen_mappings()
>>   x86/mm: ensure L2 is always freed if empty
> 
> Still broken.  This happened to be a Cascade Lake:
> 
> (XEN) 3... 2... 1...
> (XEN) Xen is relinquishing VGA console.
> (XEN) ----[ Xen-4.20.0-4-d  x86_64  debug=y  Not tainted ]----
> (XEN) CPU:    0
> (XEN) RIP:    e008:[<ffff82d04022cdc8>]
> common/page_alloc.c#free_heap_pages+0x52/0x753
> <snip>
> (XEN) Xen call trace:
> (XEN)    [<ffff82d04022cdc8>] R
> common/page_alloc.c#free_heap_pages+0x52/0x753
> (XEN)    [<ffff82d04022e98f>] F free_domheap_pages+0x445/0x447
> (XEN)    [<ffff82d040320f88>] F free_xen_pagetable+0x2f/0x31
> (XEN)    [<ffff82d04032193d>] F map_pages_to_xen+0x5df/0x1028
> (XEN)    [<ffff82d040238ab1>] F vunmap+0x27/0xde
> (XEN)    [<ffff82d040624b61>] F vesa_endboot+0x86/0xb3
> (XEN)    [<ffff82d0406244c1>] F video_endboot+0x93/0x261
> (XEN)    [<ffff82d040616e3d>] F console_endboot+0x92/0x120
> (XEN)    [<ffff82d0406407e2>] F __start_xen+0x2139/0x2307
> (XEN)    [<ffff82d0402033ae>] F __high_start+0x8e/0x90
> (XEN)
> (XEN) Pagetable walk from ffff82c000205001:
> (XEN)  L4[0x105] = 0000000060431063 ffffffffffffffff
> (XEN)  L3[0x100] = 000000006fffd063 ffffffffffffffff
> (XEN)  L2[0x001] = fffffffffffff000 ffffffffffffffff
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) FATAL PAGE FAULT
> (XEN) [error_code=0000]
> (XEN) Faulting linear address: ffff82c000205001
> (XEN) ****************************************
> 
> Note the definitely bogus L2e, which I'm guessing is an issue with the
> use of INVALID_MFN.

Why bogus? That's precisely what vunmap() requests:

    map_pages_to_xen(addr, INVALID_MFN, pages, _PAGE_NONE);

What I agree with is that INVALID_MFN better wouldn't spill into the
upper non-address part of the PTE, but that doesn't look to be important
here.

I can't, however, explain why free_heap_pages() would access VMAP space.
It's all page / MFN based and shouldn't even have a notion of the VA
space underlying vmap(). Is that address in CR2 inside the range that
was mapping the frame buffer (i.e. part of what vunmap() is in the
process of removing)?

What I also don't understand: How did this pass CI then? Are all tests
there perhaps done without vga= designating a VESA mode to use?

Jan