Re: [PATCH v4] x86/hyperv: Fix kdump on Azure CVMs

[Vitaly Kuznetsov <vkuznets@redhat.com>]

Wei Liu <wei.liu@kernel.org> 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 <vkuznets@redhat.com>
>
> 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