From: Mukesh R <mrathor@linux.microsoft.com>
To: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>
Cc: kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org,
decui@microsoft.com, longli@microsoft.com,
linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mshv: Make MSHV mutually exclusive with KEXEC
Date: Mon, 26 Jan 2026 15:07:18 -0800 [thread overview]
Message-ID: <2b42997d-7cc0-56ba-e1ca-a8640ce71ea9@linux.microsoft.com> (raw)
In-Reply-To: <aXfSDm-4BjPPZMNu@skinsburskii.localdomain>
On 1/26/26 12:43, Stanislav Kinsburskii wrote:
> On Mon, Jan 26, 2026 at 12:20:09PM -0800, Mukesh R wrote:
>> On 1/25/26 14:39, Stanislav Kinsburskii wrote:
>>> On Fri, Jan 23, 2026 at 04:16:33PM -0800, Mukesh R wrote:
>>>> On 1/23/26 14:20, Stanislav Kinsburskii wrote:
>>>>> The MSHV driver deposits kernel-allocated pages to the hypervisor during
>>>>> runtime and never withdraws them. This creates a fundamental incompatibility
>>>>> with KEXEC, as these deposited pages remain unavailable to the new kernel
>>>>> loaded via KEXEC, leading to potential system crashes upon kernel accessing
>>>>> hypervisor deposited pages.
>>>>>
>>>>> Make MSHV mutually exclusive with KEXEC until proper page lifecycle
>>>>> management is implemented.
>>>>>
>>>>> Signed-off-by: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>
>>>>> ---
>>>>> drivers/hv/Kconfig | 1 +
>>>>> 1 file changed, 1 insertion(+)
>>>>>
>>>>> diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
>>>>> index 7937ac0cbd0f..cfd4501db0fa 100644
>>>>> --- a/drivers/hv/Kconfig
>>>>> +++ b/drivers/hv/Kconfig
>>>>> @@ -74,6 +74,7 @@ config MSHV_ROOT
>>>>> # e.g. When withdrawing memory, the hypervisor gives back 4k pages in
>>>>> # no particular order, making it impossible to reassemble larger pages
>>>>> depends on PAGE_SIZE_4KB
>>>>> + depends on !KEXEC
>>>>> select EVENTFD
>>>>> select VIRT_XFER_TO_GUEST_WORK
>>>>> select HMM_MIRROR
>>>>>
>>>>>
>>>>
>>>> Will this affect CRASH kexec? I see few CONFIG_CRASH_DUMP in kexec.c
>>>> implying that crash dump might be involved. Or did you test kdump
>>>> and it was fine?
>>>>
>>>
>>> Yes, it will. Crash kexec depends on normal kexec functionality, so it
>>> will be affected as well.
>>
>> So not sure I understand the reason for this patch. We can just block
>> kexec if there are any VMs running, right? Doing this would mean any
>> further developement would be without a ver important and major feature,
>> right?
>
> This is an option. But until it's implemented and merged, a user mshv
> driver gets into a situation where kexec is broken in a non-obvious way.
> The system may crash at any time after kexec, depending on whether the
> new kernel touches the pages deposited to hypervisor or not. This is a
> bad user experience.
I understand that. But with this we cannot collect core and debug any
crashes. I was thinking there would be a quick way to prohibit kexec
for update via notifier or some other quick hack. Did you already
explore that and didn't find anything, hence this?
Thanks,
-Mukesh
> Therefor it should be explicitly forbidden as it's essentially not
> supported yet.
>
> Thanks,
> Stanislav
>
>>
>>> Thanks,
>>> Stanislav
>>>
>>>> Thanks,
>>>> -Mukesh
next prev parent reply other threads:[~2026-01-26 23:07 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-23 22:20 [PATCH] mshv: Make MSHV mutually exclusive with KEXEC Stanislav Kinsburskii
2026-01-24 0:09 ` Nuno Das Neves
2026-01-24 0:16 ` Mukesh R
2026-01-25 22:39 ` Stanislav Kinsburskii
2026-01-26 20:20 ` Mukesh R
2026-01-26 20:43 ` Stanislav Kinsburskii
2026-01-26 23:07 ` Mukesh R [this message]
2026-01-27 0:21 ` Stanislav Kinsburskii
2026-01-27 1:39 ` Mukesh R
2026-01-27 17:47 ` Stanislav Kinsburskii
2026-01-27 19:56 ` Mukesh R
2026-01-28 15:53 ` Michael Kelley
2026-01-30 2:52 ` Mukesh R
2026-01-28 23:08 ` Stanislav Kinsburskii
2026-01-30 2:59 ` Mukesh R
2026-01-30 17:17 ` Anirudh Rayabharam
2026-01-30 18:41 ` Stanislav Kinsburskii
2026-01-30 19:47 ` Mukesh R
2026-02-02 16:43 ` Stanislav Kinsburskii
2026-02-02 20:15 ` Mukesh R
2026-02-04 2:46 ` Mukesh R
2026-01-26 18:49 ` Anirudh Rayabharam
2026-01-26 20:46 ` Stanislav Kinsburskii
2026-01-28 16:16 ` Anirudh Rayabharam
2026-01-28 23:11 ` Stanislav Kinsburskii
2026-01-30 17:11 ` Anirudh Rayabharam
2026-01-30 18:46 ` Stanislav Kinsburskii
2026-01-30 20:32 ` Anirudh Rayabharam
2026-02-02 17:10 ` Stanislav Kinsburskii
2026-02-02 19:01 ` Anirudh Rayabharam
2026-02-02 19:18 ` Stanislav Kinsburskii
2026-02-03 5:04 ` Anirudh Rayabharam
2026-02-03 15:40 ` Stanislav Kinsburskii
2026-02-03 16:46 ` Anirudh Rayabharam
2026-02-03 19:42 ` Stanislav Kinsburskii
2026-02-04 5:33 ` Anirudh Rayabharam
2026-02-04 18:33 ` Stanislav Kinsburskii
2026-02-05 4:59 ` Anirudh Rayabharam
2026-02-05 17:12 ` Stanislav Kinsburskii
2026-02-02 18:09 ` Stanislav Kinsburskii
2026-02-02 16:56 ` Naman Jain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2b42997d-7cc0-56ba-e1ca-a8640ce71ea9@linux.microsoft.com \
--to=mrathor@linux.microsoft.com \
--cc=decui@microsoft.com \
--cc=haiyangz@microsoft.com \
--cc=kys@microsoft.com \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=longli@microsoft.com \
--cc=skinsburskii@linux.microsoft.com \
--cc=wei.liu@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.