On Fri, Sep 05, 2025 at 03:57:03PM +0000, Michael Kelley wrote: > From: Vitaly Kuznetsov <[email protected]> Sent: Friday, September 5, 2025 > 12:48 AM > > > > 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. > > > > I agree -- think of this as adding a feature instead of fixing a bug. Prior > to now, there hasn't been any attempt to make kexec/kdump work > for Azure CVMs. > > Instead of using the word "Fix", maybe the patch "Subject:" should be > changed to "x86/hyperv: Add kexec/kdump support on Azure CVMs".
I have fixed that in the hyperv-next tree. Thanks for the discussion. Wei > > Michael
