qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Page alignment & memory regions expectations


From: David Hildenbrand
Subject: Re: Page alignment & memory regions expectations
Date: Wed, 24 Aug 2022 18:42:01 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]