Wei Liu <[email protected]> writes:
> On Thu, Aug 28, 2025 at 12:16:18PM +0300, Vitaly Kuznetsov wrote:
>> Azure CVM instance types featuring a paravisor hang upon kdump. The
>> investigation shows that makedumpfile causes a hang when it steps on a page
>> which was previously share with the host
>> (HVCALL_MODIFY_SPARSE_GPA_PAGE_HOST_VISIBILITY). The new kernel has no
>> knowledge of these 'special' regions (which are Vmbus connection pages,
>> GPADL buffers, ...). There are several ways to approach the issue:
>> - Convey the knowledge about these regions to the new kernel somehow.
>> - Unshare these regions before accessing in the new kernel (it is unclear
>> if there's a way to query the status for a given GPA range).
>> - Unshare these regions before jumping to the new kernel (which this patch
>> implements).
>>
>> To make the procedure as robust as possible, store PFN ranges of shared
>> regions in a linked list instead of storing GVAs and re-using
>> hv_vtom_set_host_visibility(). This also allows to avoid memory allocation
>> on the kdump/kexec path.
>>
>> Signed-off-by: Vitaly Kuznetsov <[email protected]>
>
> No fixes tag for this one?
>
Personally, I don't see this as a 'bug', it's rather a missing
feature. In theory, we can add something like
Fixes: 810a52126502 ("x86/hyperv: Add new hvcall guest address host visibility
support")
but I'm on the fence whether this is accurate or not.
> Should it be marked as a stable backport?
I think it may make sense even without an explicit 'Fixes:': kdump is the
user's last resort when it comes to kernel crashes and doubly so on
CVMs. Pure kexec may also come handy.
--
Vitaly
