On 24.08.22 14:43, Marc-André Lureau wrote: > Hi, Hi!
> > tpm-crb creates a "tpm-crb-cmd" RAM memory region that is not page > aligned. Apparently, this is not a problem for QEMU in general. However, > it crashes kdump'ing in dump.c:get_next_page, as it expects I assume you mean "dumping in kdump format". > GuestPhysBlock to be page-aligned. (see also bug > https://bugzilla.redhat.com/show_bug.cgi?id=2120480 > <https://bugzilla.redhat.com/show_bug.cgi?id=2120480>) > > Here is some relevant DEBUG_GUEST_PHYS_REGION_ADD log: > guest_phys_block_add_section: target_start=00000000fd000000 > target_end=00000000fe000000: added (count: 3) > guest_phys_block_add_section: target_start=00000000fed40080 > target_end=00000000fed41000: added (count: 4) > guest_phys_block_add_section: target_start=00000000fffc0000 > target_end=0000000100000000: added (count: 5) > > I am looking for ideas on how to solve this crash. Do we care if we don't include everything in the dump? I recall that e.g., vfio will simply align and not care about such partial RAM blocks. One idea is doing another pass over the list at the end (after possible merging of sections) and making sure everything is page-aligned. Another idea is specifying somehow that that memory region should simply not be dumped ... But I do wonder why the ram memory region that's mapped into the guest physical address space has such a weird alignment/size ... > > Should qemu enforce that memory regions are target page-aligned? In ... can we simply fixup tpm-crb-cmd? > which case, TPM CRB MMIO region would overlap with the RAM region, and I > wonder how that turns out to be, and if other devices would be impacted etc > > Or should kdump learn to handle non-aligned blocks somehow? I think that > option should make a reasonable solution, as long as we only have > empty/zero-memory "gaps". Handling other cases of joint or overlapping > regions seems more difficult. Right, you'd actually have to pad the remainder with zeroes. -- Thanks, David / dhildenb
