[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID:
<SN6PR02MB4157B42CCDC571AA07A34E82D403A@SN6PR02MB4157.namprd02.prod.outlook.com>
Date: Fri, 5 Sep 2025 15:57:03 +0000
From: Michael Kelley <mhklinux@...look.com>
To: Vitaly Kuznetsov <vkuznets@...hat.com>, Wei Liu <wei.liu@...nel.org>
CC: "linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>, "K. Y.
Srinivasan" <kys@...rosoft.com>, Haiyang Zhang <haiyangz@...rosoft.com>, Wei
Liu <wei.liu@...nel.org>, Dexuan Cui <decui@...rosoft.com>, "x86@...nel.org"
<x86@...nel.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, Nuno Das Neves
<nunodasneves@...ux.microsoft.com>, Tianyu Lan <tiala@...rosoft.com>, Li Tian
<litian@...hat.com>, Philipp Rudo <prudo@...hat.com>
Subject: RE: [PATCH v4] x86/hyperv: Fix kdump on Azure CVMs
From: Vitaly Kuznetsov <vkuznets@...hat.com> Sent: Friday, September 5, 2025 12:48 AM
>
> Wei Liu <wei.liu@...nel.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@...hat.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.
>
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".
Michael
Powered by blists - more mailing lists