* Re: [PATCH] x86: mshyperv: Use kthread for vmbus interrupts on PREEMPT_RT
From: Jan Kiszka @ 2026-02-04 7:32 UTC (permalink / raw)
To: Wei Liu
Cc: Magnus Kulke, K. Y. Srinivasan, Haiyang Zhang, Dexuan Cui,
Long Li, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, linux-hyperv, linux-kernel, Florian Bezdeka, RT,
Mitchell Levy
In-Reply-To: <20260204072930.GO79272@liuwe-devbox-debian-v2.local>
On 04.02.26 08:29, Wei Liu wrote:
> On Wed, Feb 04, 2026 at 08:26:48AM +0100, Jan Kiszka wrote:
>> On 04.02.26 08:19, Jan Kiszka wrote:
>>> On 04.02.26 08:00, Wei Liu wrote:
>>>> On Tue, Feb 03, 2026 at 05:01:30PM +0100, Jan Kiszka wrote:
>>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>>>
>>>>> Resolves the following lockdep report when booting PREEMPT_RT on Hyper-V
>>>>> with related guest support enabled:
>>>>
>>>> So all it takes to reproduce this is to enabled PREEMPT_RT?
>>>>
>>>
>>> ...and enable CONFIG_PROVE_LOCKING so that you do not have to wait for
>>> your system to actually run into the bug. Lockdep already triggers
>>> during bootup.
>>>
>>>> Asking because ...
>>>>
>>>>> struct pt_regs *old_regs = set_irq_regs(regs);
>>>>> @@ -158,8 +196,12 @@ DEFINE_IDTENTRY_SYSVEC(sysvec_hyperv_callback)
>>>>> if (mshv_handler)
>>>>> mshv_handler();
>>>>
>>>> ... to err on the safe side we should probably do the same for
>>>> mshv_handler as well.
>>>>
>>>
>>> Valid question. We so far worked based on lockdep reports, and the
>>> mshv_handler didn't trigger yet. Either it is not run in our setup, or
>>> it is actually already fine. But I have a code review on my agenda
>>> regarding potential remaining issues in mshv.
>>>
>>> Is there something needed to trigger the mshv_handler so that we can
>>> test it?
>>>
>>
>> Ah, that depends on CONFIG_MSHV_ROOT. Is that related to the accelerator
>> mode that Magnus presented in [1]? We briefly chatted about it and also
>> my problems with the drivers after his talk on Saturday.
>
> Yes. That is the driver. If PROVE_LOCKING triggers the warning without
> running the code, perhaps turning on MSHV_ROOT is enough.
>
But if my VM is not a root partition, I wouldn't use that driver, would I?
Jan
--
Siemens AG, Foundational Technologies
Linux Expert Center
^ permalink raw reply
* Re: [PATCH] x86: mshyperv: Use kthread for vmbus interrupts on PREEMPT_RT
From: Wei Liu @ 2026-02-04 7:29 UTC (permalink / raw)
To: Jan Kiszka
Cc: Wei Liu, Magnus Kulke, K. Y. Srinivasan, Haiyang Zhang,
Dexuan Cui, Long Li, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, linux-hyperv, linux-kernel,
Florian Bezdeka, RT, Mitchell Levy
In-Reply-To: <10ec70f2-27a5-477f-b6e9-164f7b7545d9@siemens.com>
On Wed, Feb 04, 2026 at 08:26:48AM +0100, Jan Kiszka wrote:
> On 04.02.26 08:19, Jan Kiszka wrote:
> > On 04.02.26 08:00, Wei Liu wrote:
> >> On Tue, Feb 03, 2026 at 05:01:30PM +0100, Jan Kiszka wrote:
> >>> From: Jan Kiszka <jan.kiszka@siemens.com>
> >>>
> >>> Resolves the following lockdep report when booting PREEMPT_RT on Hyper-V
> >>> with related guest support enabled:
> >>
> >> So all it takes to reproduce this is to enabled PREEMPT_RT?
> >>
> >
> > ...and enable CONFIG_PROVE_LOCKING so that you do not have to wait for
> > your system to actually run into the bug. Lockdep already triggers
> > during bootup.
> >
> >> Asking because ...
> >>
> >>> struct pt_regs *old_regs = set_irq_regs(regs);
> >>> @@ -158,8 +196,12 @@ DEFINE_IDTENTRY_SYSVEC(sysvec_hyperv_callback)
> >>> if (mshv_handler)
> >>> mshv_handler();
> >>
> >> ... to err on the safe side we should probably do the same for
> >> mshv_handler as well.
> >>
> >
> > Valid question. We so far worked based on lockdep reports, and the
> > mshv_handler didn't trigger yet. Either it is not run in our setup, or
> > it is actually already fine. But I have a code review on my agenda
> > regarding potential remaining issues in mshv.
> >
> > Is there something needed to trigger the mshv_handler so that we can
> > test it?
> >
>
> Ah, that depends on CONFIG_MSHV_ROOT. Is that related to the accelerator
> mode that Magnus presented in [1]? We briefly chatted about it and also
> my problems with the drivers after his talk on Saturday.
Yes. That is the driver. If PROVE_LOCKING triggers the warning without
running the code, perhaps turning on MSHV_ROOT is enough.
Wei
>
> Jan
>
> [1]
> https://fosdem.org/2026/schedule/event/BFQ8XA-introducing-mshv-accelerator-in-qemu/
>
> --
> Siemens AG, Foundational Technologies
> Linux Expert Center
>
^ permalink raw reply
* Re: [PATCH] x86: mshyperv: Use kthread for vmbus interrupts on PREEMPT_RT
From: Jan Kiszka @ 2026-02-04 7:26 UTC (permalink / raw)
To: Wei Liu, Magnus Kulke
Cc: K. Y. Srinivasan, Haiyang Zhang, Dexuan Cui, Long Li,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
linux-hyperv, linux-kernel, Florian Bezdeka, RT, Mitchell Levy
In-Reply-To: <c377fab9-54f1-4eb9-8810-013a8bfb340e@siemens.com>
On 04.02.26 08:19, Jan Kiszka wrote:
> On 04.02.26 08:00, Wei Liu wrote:
>> On Tue, Feb 03, 2026 at 05:01:30PM +0100, Jan Kiszka wrote:
>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>
>>> Resolves the following lockdep report when booting PREEMPT_RT on Hyper-V
>>> with related guest support enabled:
>>
>> So all it takes to reproduce this is to enabled PREEMPT_RT?
>>
>
> ...and enable CONFIG_PROVE_LOCKING so that you do not have to wait for
> your system to actually run into the bug. Lockdep already triggers
> during bootup.
>
>> Asking because ...
>>
>>> struct pt_regs *old_regs = set_irq_regs(regs);
>>> @@ -158,8 +196,12 @@ DEFINE_IDTENTRY_SYSVEC(sysvec_hyperv_callback)
>>> if (mshv_handler)
>>> mshv_handler();
>>
>> ... to err on the safe side we should probably do the same for
>> mshv_handler as well.
>>
>
> Valid question. We so far worked based on lockdep reports, and the
> mshv_handler didn't trigger yet. Either it is not run in our setup, or
> it is actually already fine. But I have a code review on my agenda
> regarding potential remaining issues in mshv.
>
> Is there something needed to trigger the mshv_handler so that we can
> test it?
>
Ah, that depends on CONFIG_MSHV_ROOT. Is that related to the accelerator
mode that Magnus presented in [1]? We briefly chatted about it and also
my problems with the drivers after his talk on Saturday.
Jan
[1]
https://fosdem.org/2026/schedule/event/BFQ8XA-introducing-mshv-accelerator-in-qemu/
--
Siemens AG, Foundational Technologies
Linux Expert Center
^ permalink raw reply
* Re: [PATCH] x86: mshyperv: Use kthread for vmbus interrupts on PREEMPT_RT
From: Jan Kiszka @ 2026-02-04 7:19 UTC (permalink / raw)
To: Wei Liu
Cc: K. Y. Srinivasan, Haiyang Zhang, Dexuan Cui, Long Li,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
linux-hyperv, linux-kernel, Florian Bezdeka, RT, Mitchell Levy
In-Reply-To: <20260204070004.GM79272@liuwe-devbox-debian-v2.local>
On 04.02.26 08:00, Wei Liu wrote:
> On Tue, Feb 03, 2026 at 05:01:30PM +0100, Jan Kiszka wrote:
>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>
>> Resolves the following lockdep report when booting PREEMPT_RT on Hyper-V
>> with related guest support enabled:
>
> So all it takes to reproduce this is to enabled PREEMPT_RT?
>
...and enable CONFIG_PROVE_LOCKING so that you do not have to wait for
your system to actually run into the bug. Lockdep already triggers
during bootup.
> Asking because ...
>
>> struct pt_regs *old_regs = set_irq_regs(regs);
>> @@ -158,8 +196,12 @@ DEFINE_IDTENTRY_SYSVEC(sysvec_hyperv_callback)
>> if (mshv_handler)
>> mshv_handler();
>
> ... to err on the safe side we should probably do the same for
> mshv_handler as well.
>
Valid question. We so far worked based on lockdep reports, and the
mshv_handler didn't trigger yet. Either it is not run in our setup, or
it is actually already fine. But I have a code review on my agenda
regarding potential remaining issues in mshv.
Is there something needed to trigger the mshv_handler so that we can
test it?
> Note we don't support RT yet, but if issues are found we might as well
> just fix them up.
This is actually not about RT itself but about supporting all
configurable locking semantics of the. And the mshv drivers fail here.
>
> How urgent do you want this patch to get applied?
If I asked my folks: yesterday (we shipped it...).
We would also need in upstream stable and stable-rt, though it may not
reach the current production kernel anymore (6.1-rt from bookworm)
because it reaching EOL in a few months.
Jan
--
Siemens AG, Foundational Technologies
Linux Expert Center
^ permalink raw reply
* Re: [PATCH v4] mshv: Add support for integrated scheduler
From: Wei Liu @ 2026-02-04 7:18 UTC (permalink / raw)
To: Stanislav Kinsburskii
Cc: kys, haiyangz, wei.liu, decui, longli, linux-hyperv, linux-kernel
In-Reply-To: <177006034399.132128.8748943595417271449.stgit@skinsburskii-cloud-desktop.internal.cloudapp.net>
On Mon, Feb 02, 2026 at 07:26:06PM +0000, Stanislav Kinsburskii wrote:
> Query the hypervisor for integrated scheduler support and use it if
> configured.
>
> Microsoft Hypervisor originally provided two schedulers: root and core. The
Microsoft Hypervisor provides three schedulers: root, classic
(with or without SMT) and core. The latter two are hypervisor based.
> root scheduler allows the root partition to schedule guest vCPUs across
> physical cores, supporting both time slicing and CPU affinity (e.g., via
> cgroups). In contrast, the core scheduler delegates vCPU-to-physical-core
> scheduling entirely to the hypervisor.
>
> Direct virtualization introduces a new privileged guest partition type - L1
Level-1 Virtualization Host.
> Virtual Host (L1VH) — which can create child partitions from its own
> resources. These child partitions are effectively siblings, scheduled by
> the hypervisor's core scheduler. This prevents the L1VH parent from setting
> affinity or time slicing for its own processes or guest VPs. While cgroups,
> CFS, and cpuset controllers can still be used, their effectiveness is
> unpredictable, as the core scheduler swaps vCPUs according to its own logic
> (typically round-robin across all allocated physical CPUs). As a result,
> the system may appear to "steal" time from the L1VH and its children.
>
> To address this, Microsoft Hypervisor introduces the integrated scheduler.
> This allows an L1VH partition to schedule its own vCPUs and those of its
> guests across its "physical" cores, effectively emulating root scheduler
> behavior within the L1VH, while retaining core scheduler behavior for the
> rest of the system.
>
> The integrated scheduler is controlled by the root partition and gated by
> the vmm_enable_integrated_scheduler capability bit. If set, the hypervisor
> supports the integrated scheduler. The L1VH partition must then check if it
> is enabled by querying the corresponding extended partition property. If
> this property is true, the L1VH partition must use the root scheduler
> logic; otherwise, it must use the core scheduler. This requirement makes
> reading VMM capabilities in L1VH partition a requirement too.
>
> Signed-off-by: Andreea Pintilie <anpintil@microsoft.com>
> Signed-off-by: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>
> ---
[...]
> +++ b/include/hyperv/hvhdk_mini.h
> @@ -87,6 +87,9 @@ enum hv_partition_property_code {
> HV_PARTITION_PROPERTY_PRIVILEGE_FLAGS = 0x00010000,
> HV_PARTITION_PROPERTY_SYNTHETIC_PROC_FEATURES = 0x00010001,
>
> + /* Integrated scheduling properties */
> + HV_PARTITION_PROPERTY_INTEGRATED_SCHEDULER_ENABLED = 0x00020005,
The internal name is "HvPartitionPropertyHierarchicalIntegratedSchedulerEnabled".
You missed the "Hierarchical" part in the property code name.
Wei
> +
> /* Resource properties */
> HV_PARTITION_PROPERTY_GPA_PAGE_ACCESS_TRACKING = 0x00050005,
> HV_PARTITION_PROPERTY_UNIMPLEMENTED_MSR_ACTION = 0x00050017,
> @@ -102,7 +105,7 @@ enum hv_partition_property_code {
> };
>
> #define HV_PARTITION_VMM_CAPABILITIES_BANK_COUNT 1
> -#define HV_PARTITION_VMM_CAPABILITIES_RESERVED_BITFIELD_COUNT 59
> +#define HV_PARTITION_VMM_CAPABILITIES_RESERVED_BITFIELD_COUNT 57
>
> struct hv_partition_property_vmm_capabilities {
> u16 bank_count;
> @@ -119,6 +122,8 @@ struct hv_partition_property_vmm_capabilities {
> u64 reservedbit3: 1;
> #endif
> u64 assignable_synthetic_proc_features: 1;
> + u64 reservedbit5: 1;
> + u64 vmm_enable_integrated_scheduler : 1;
> u64 reserved0: HV_PARTITION_VMM_CAPABILITIES_RESERVED_BITFIELD_COUNT;
> } __packed;
> };
>
>
>
^ permalink raw reply
* Re: [PATCH] x86: mshyperv: Use kthread for vmbus interrupts on PREEMPT_RT
From: Wei Liu @ 2026-02-04 7:00 UTC (permalink / raw)
To: Jan Kiszka
Cc: K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
linux-hyperv, linux-kernel, Florian Bezdeka, RT, Mitchell Levy
In-Reply-To: <133a95d9-8148-40ea-9acc-edfd8e3ceef4@siemens.com>
On Tue, Feb 03, 2026 at 05:01:30PM +0100, Jan Kiszka wrote:
> From: Jan Kiszka <jan.kiszka@siemens.com>
>
> Resolves the following lockdep report when booting PREEMPT_RT on Hyper-V
> with related guest support enabled:
So all it takes to reproduce this is to enabled PREEMPT_RT?
Asking because ...
> struct pt_regs *old_regs = set_irq_regs(regs);
> @@ -158,8 +196,12 @@ DEFINE_IDTENTRY_SYSVEC(sysvec_hyperv_callback)
> if (mshv_handler)
> mshv_handler();
... to err on the safe side we should probably do the same for
mshv_handler as well.
Note we don't support RT yet, but if issues are found we might as well
just fix them up.
How urgent do you want this patch to get applied?
Thanks,
Wei
>
> - if (vmbus_handler)
> - vmbus_handler();
> + if (vmbus_handler) {
> + if (IS_ENABLED(CONFIG_PREEMPT_RT))
> + vmbus_irqd_wake();
> + else
> + vmbus_handler();
> + }
>
> if (ms_hyperv.hints & HV_DEPRECATING_AEOI_RECOMMENDED)
> apic_eoi();
> @@ -174,6 +216,10 @@ void hv_setup_mshv_handler(void (*handler)(void))
>
> void hv_setup_vmbus_handler(void (*handler)(void))
> {
> + if (IS_ENABLED(CONFIG_PREEMPT_RT) && !vmbus_irq_initialized) {
> + BUG_ON(smpboot_register_percpu_thread(&vmbus_irq_threads));
> + vmbus_irq_initialized = true;
> + }
> vmbus_handler = handler;
> }
>
> @@ -181,6 +227,8 @@ void hv_remove_vmbus_handler(void)
> {
> /* We have no way to deallocate the interrupt gate */
> vmbus_handler = NULL;
> + smpboot_unregister_percpu_thread(&vmbus_irq_threads);
> + vmbus_irq_initialized = false;
> }
>
> /*
> --
> 2.51.0
^ permalink raw reply
* Re: [PATCH 1/1] x86/hyperv: Update comment in hyperv_cleanup()
From: Wei Liu @ 2026-02-04 6:50 UTC (permalink / raw)
To: mhklinux
Cc: kys, haiyangz, wei.liu, decui, longli, tglx, mingo, bp,
dave.hansen, x86, hpa, linux-hyperv, linux-kernel
In-Reply-To: <20260202164839.1691-1-mhklinux@outlook.com>
On Mon, Feb 02, 2026 at 08:48:39AM -0800, mhkelley58@gmail.com wrote:
> From: Michael Kelley <mhklinux@outlook.com>
>
> The comment in hyperv_cleanup() became out-of-date as a result of
> commit c8ed0812646e ("x86/hyperv: Use direct call to hypercall-page").
>
> Update the comment. No code or functional change.
>
> Signed-off-by: Michael Kelley <mhklinux@outlook.com>
Applied to hyperv-next.
^ permalink raw reply
* Re: [PATCH] mshv: clear eventfd counter on irqfd shutdown
From: Wei Liu @ 2026-02-04 6:43 UTC (permalink / raw)
To: Carlos López
Cc: linux-hyperv, K. Y. Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, open list, skinsburskii, mrathor, anirudh,
schakrabarti
In-Reply-To: <20260122114130.92860-2-clopez@suse.de>
On Thu, Jan 22, 2026 at 12:41:31PM +0100, Carlos López wrote:
> While unhooking from the irqfd waitqueue, clear the internal eventfd
> counter by using eventfd_ctx_remove_wait_queue() instead of
> remove_wait_queue(), preventing potential spurious interrupts. This
> removes the need to store a pointer into the workqueue, as the eventfd
> already keeps track of it.
>
> This mimicks what other similar subsystems do on their equivalent paths
> with their irqfds (KVM, Xen, ACRN support, etc).
>
> Signed-off-by: Carlos López <clopez@suse.de>
This looks like a good change to me. I've queued it to hyperv-next.
Thanks!
Also CC our kernel folks just in case I missed something.
Wei
> ---
> drivers/hv/mshv_eventfd.c | 5 ++---
> drivers/hv/mshv_eventfd.h | 1 -
> 2 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/hv/mshv_eventfd.c b/drivers/hv/mshv_eventfd.c
> index d93a18f09c76..4432063e963d 100644
> --- a/drivers/hv/mshv_eventfd.c
> +++ b/drivers/hv/mshv_eventfd.c
> @@ -247,12 +247,13 @@ static void mshv_irqfd_shutdown(struct work_struct *work)
> {
> struct mshv_irqfd *irqfd =
> container_of(work, struct mshv_irqfd, irqfd_shutdown);
> + u64 cnt;
>
> /*
> * Synchronize with the wait-queue and unhook ourselves to prevent
> * further events.
> */
> - remove_wait_queue(irqfd->irqfd_wqh, &irqfd->irqfd_wait);
> + eventfd_ctx_remove_wait_queue(irqfd->irqfd_eventfd_ctx, &irqfd->irqfd_wait, &cnt);
>
> if (irqfd->irqfd_resampler) {
> mshv_irqfd_resampler_shutdown(irqfd);
> @@ -371,8 +372,6 @@ static void mshv_irqfd_queue_proc(struct file *file, wait_queue_head_t *wqh,
> struct mshv_irqfd *irqfd =
> container_of(polltbl, struct mshv_irqfd, irqfd_polltbl);
>
> - irqfd->irqfd_wqh = wqh;
> -
> /*
> * TODO: Ensure there isn't already an exclusive, priority waiter, e.g.
> * that the irqfd isn't already bound to another partition. Only the
> diff --git a/drivers/hv/mshv_eventfd.h b/drivers/hv/mshv_eventfd.h
> index 332e7670a344..464c6b81ab33 100644
> --- a/drivers/hv/mshv_eventfd.h
> +++ b/drivers/hv/mshv_eventfd.h
> @@ -32,7 +32,6 @@ struct mshv_irqfd {
> struct mshv_lapic_irq irqfd_lapic_irq;
> struct hlist_node irqfd_hnode;
> poll_table irqfd_polltbl;
> - wait_queue_head_t *irqfd_wqh;
> wait_queue_entry_t irqfd_wait;
> struct work_struct irqfd_shutdown;
> struct mshv_irqfd_resampler *irqfd_resampler;
>
> base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
> --
> 2.51.0
>
^ permalink raw reply
* Re: [PATCH 1/1] x86/hyperv: Use memremap()/memunmap() instead of ioremap_cache()/iounmap()
From: Wei Liu @ 2026-02-04 6:30 UTC (permalink / raw)
To: mhklinux
Cc: kys, haiyangz, wei.liu, decui, longli, tglx, mingo, bp,
dave.hansen, x86, hpa, linux-hyperv, linux-kernel
In-Reply-To: <20260119155937.46203-1-mhklinux@outlook.com>
On Mon, Jan 19, 2026 at 07:59:37AM -0800, mhkelley58@gmail.com wrote:
> From: Michael Kelley <mhklinux@outlook.com>
>
> When running with a paravisor and SEV-SNP, the GHCB page is provided
> by the paravisor instead of being allocated by Linux. The provided page
> is normal memory, but is outside of the physical address space seen by
> Linux. As such it cannot be accessed via the kernel's direct map, and
> must be explicitly mapped to a kernel virtual address.
>
> Current code uses ioremap_cache() and iounmap() to map and unmap the page.
> These functions are for use on I/O address space that may not behave as
> normal memory, so they generate or expect addresses with the __iomem
> attribute. For normal memory, the preferred functions are memremap() and
> memunmap(), which operate similarly but without __iomem.
>
> At the time of the original work on CoCo VMs on Hyper-V, memremap() did not
> support creating a decrypted mapping, so ioremap_cache() was used instead,
> since I/O address space is always mapped decrypted. memremap() has since
> been enhanced to allow decrypted mappings, so replace ioremap_cache() with
> memremap() when mapping the GHCB page. Similarly, replace iounmap() with
> memunmap(). As a side benefit, the replacement cleans up 'sparse' warnings
> about __iomem mismatches.
>
> The replacement is done to use the correct functions as long-term goodness
> and to clean up the sparse warnings. No runtime bugs are fixed.
>
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202311111925.iPGGJik4-lkp@intel.com/
> Signed-off-by: Michael Kelley <mhklinux@outlook.com>
Applied to hyperv-next. Thanks.
^ permalink raw reply
* Re: [PATCH 1/1] Drivers: hv: Use memremap()/memunmap() instead of ioremap_cache()/iounmap()
From: Wei Liu @ 2026-02-04 6:29 UTC (permalink / raw)
To: mhklinux
Cc: kys, haiyangz, wei.liu, decui, longli, linux-hyperv, linux-kernel
In-Reply-To: <20260119033435.3358-1-mhklinux@outlook.com>
On Sun, Jan 18, 2026 at 07:34:35PM -0800, mhkelley58@gmail.com wrote:
> From: Michael Kelley <mhklinux@outlook.com>
>
> When running with a paravisor or in the root partition, the SynIC event and
> message pages are provided by the paravisor or hypervisor respectively,
> instead of being allocated by Linux. The provided pages are normal memory,
> but are outside of the physical address space seen by Linux. As such they
> cannot be accessed via the kernel's direct map, and must be explicitly
> mapped to a kernel virtual address.
>
> Current code uses ioremap_cache() and iounmap() to map and unmap the pages.
> These functions are for use on I/O address space that may not behave as
> normal memory, so they generate or expect addresses with the __iomem
> attribute. For normal memory, the preferred functions are memremap() and
> memunmap(), which operate similarly but without __iomem.
>
> At the time of the original work on CoCo VMs on Hyper-V, memremap() did not
> support creating a decrypted mapping, so ioremap_cache() was used instead,
> since I/O address space is always mapped decrypted. memremap() has since
> been enhanced to allow decrypted mappings, so replace ioremap_cache() with
> memremap() when mapping the event and message pages. Similarly, replace
> iounmap() with memunmap(). As a side benefit, the replacement cleans up
> 'sparse' warnings about __iomem mismatches.
>
> The replacement is done to use the correct functions as long-term goodness
> and to clean up the sparse warnings. No runtime bugs are fixed.
>
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202601170445.JtZQwndW-lkp@intel.com/
> Closes: https://lore.kernel.org/oe-kbuild-all/202512150359.fMdmbddk-lkp@intel.com/
> Signed-off-by: Michael Kelley <mhklinux@outlook.com>
Applied to hyperv-next. Thanks.
^ permalink raw reply
* Re: [PATCH v1] x86/hyperv: Move hv crash init after hypercall pg setup
From: Wei Liu @ 2026-02-04 6:27 UTC (permalink / raw)
To: Mukesh R; +Cc: linux-hyperv, linux-kernel, wei.liu
In-Reply-To: <20260204015800.40843-1-mrathor@linux.microsoft.com>
On Tue, Feb 03, 2026 at 05:58:00PM -0800, Mukesh R wrote:
> hv_root_crash_init() is not setting up the hypervisor crash collection
> for baremetal cases because when it's called, hypervisor page is not
> setup.
> This got missed due to internal mirror falling behind.
This doesn't provide useful information for our future selves.
>
> Fix is simple, just move the crash init call after the hypercall
> page setup.
>
> Signed-off-by: Mukesh Rathor <mrathor@linux.microsoft.com>
Applied.
Wei
> ---
> arch/x86/hyperv/hv_init.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
> index 14de43f4bc6c..7f3301bd081e 100644
> --- a/arch/x86/hyperv/hv_init.c
> +++ b/arch/x86/hyperv/hv_init.c
> @@ -558,7 +558,6 @@ void __init hyperv_init(void)
> memunmap(src);
>
> hv_remap_tsc_clocksource();
> - hv_root_crash_init();
> hv_sleep_notifiers_register();
> } else {
> hypercall_msr.guest_physical_address = vmalloc_to_pfn(hv_hypercall_pg);
> @@ -567,6 +566,9 @@ void __init hyperv_init(void)
>
> hv_set_hypercall_pg(hv_hypercall_pg);
>
> + if (hv_root_partition()) /* after set hypercall pg */
> + hv_root_crash_init();
> +
> skip_hypercall_pg_init:
> /*
> * hyperv_init() is called before LAPIC is initialized: see
> --
> 2.51.2.vfs.0.1
>
^ permalink raw reply
* Re: [PATCH] pci: pci-hyperv-intf: remove unnecessary module_init/exit functions
From: Wei Liu @ 2026-02-04 6:21 UTC (permalink / raw)
To: Ethan Nelson-Moore
Cc: linux-hyperv, linux-pci, K. Y. Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas
In-Reply-To: <20260131020017.45712-1-enelsonmoore@gmail.com>
On Fri, Jan 30, 2026 at 06:00:17PM -0800, Ethan Nelson-Moore wrote:
> The pci-hyperv-intf driver has unnecessary empty module_init and
> module_exit functions. Remove them. Note that if a module_init function
> exists, a module_exit function must also exist; otherwise, the module
> cannot be unloaded.
>
> Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Applied to hyperv-next. I modified the subject line to match our
conventions. Thanks.
Wei
^ permalink raw reply
* Re: [PATCH v6 0/7] mshv: Debugfs interface for mshv_root
From: Wei Liu @ 2026-02-04 6:17 UTC (permalink / raw)
To: Nuno Das Neves
Cc: linux-hyperv, linux-kernel, mhklinux, skinsburskii, kys, haiyangz,
wei.liu, decui, longli, prapal, mrathor, paekkaladevi
In-Reply-To: <20260128181146.517708-1-nunodasneves@linux.microsoft.com>
On Wed, Jan 28, 2026 at 10:11:39AM -0800, Nuno Das Neves wrote:
> Expose hypervisor, logical processor, partition, and virtual processor
> statistics via debugfs. These are provided by mapping 'stats' pages via
> hypercall.
>
> Patch #1: Update hv_call_map_stats_page() to return success when
> HV_STATS_AREA_PARENT is unavailable, which is the case on some
> hypervisor versions, where it can fall back to HV_STATS_AREA_SELF
> Patch #2: Use struct hv_stats_page pointers instead of void *
> Patch #3: Make mshv_vp_stats_map/unmap() more flexible to use with debugfs
> code
> Patch #4: Always map vp stats page regardless of scheduler, to reuse in
> debugfs
> Patch #5: Change to hv_stats_page definition and
> VpRootDispatchThreadBlocked
> Patch #6: Introduce the definitions needed for the various stats pages
> Patch #7: Add mshv_debugfs.c, and integrate it with the mshv_root driver to
> expose the partition and VP stats.
>
[...]
>
> drivers/hv/Makefile | 1 +
> drivers/hv/mshv_debugfs.c | 726 +++++++++++++++++++++++++++++
> drivers/hv/mshv_debugfs_counters.c | 490 +++++++++++++++++++
> drivers/hv/mshv_root.h | 49 +-
> drivers/hv/mshv_root_hv_call.c | 64 ++-
> drivers/hv/mshv_root_main.c | 140 +++---
> include/hyperv/hvhdk.h | 7 +
> 7 files changed, 1412 insertions(+), 65 deletions(-)
> create mode 100644 drivers/hv/mshv_debugfs.c
> create mode 100644 drivers/hv/mshv_debugfs_counters.c
>
Applied to hyperv-next. Thank you!
^ permalink raw reply
* Re: [PATCH 1/1] mshv: Use EPOLLIN and EPOLLHUP instead of POLLIN and POLLHUP
From: Wei Liu @ 2026-02-04 6:16 UTC (permalink / raw)
To: Stanislav Kinsburskii
Cc: mhklinux, kys, haiyangz, wei.liu, decui, longli, linux-hyperv,
linux-kernel
In-Reply-To: <aYIX9tvVut-i9QXt@skinsburskii.localdomain>
On Tue, Feb 03, 2026 at 07:44:54AM -0800, Stanislav Kinsburskii wrote:
> On Thu, Jan 29, 2026 at 07:51:54AM -0800, mhkelley58@gmail.com wrote:
> > From: Michael Kelley <mhklinux@outlook.com>
> >
> > mshv code currently uses the POLLIN and POLLHUP flags. Starting with
> > commit a9a08845e9acb ("vfs: do bulk POLL* -> EPOLL* replacement") the
> > intent is to use the EPOLL* versions throughout the kernel.
> >
> > The comment at the top of mshv_eventfd.c describes it as being inspired
> > by the KVM implementation, which was changed by the above mentioned
> > commit in 2018 to use EPOLL*. mshv_eventfd.c is much newer than 2018
> > and there's no statement as to why it must use the POLL* versions.
> > So change it to use the EPOLL* versions. This change also resolves
> > a 'sparse' warning.
> >
> > No functional change, and the generated code is the same.
> >
> > Reported-by: kernel test robot <lkp@intel.com>
> > Closes: https://lore.kernel.org/oe-kbuild-all/202601220948.MUTO60W4-lkp@intel.com/
> > Signed-off-by: Michael Kelley <mhklinux@outlook.com>
>
> Reviewed-by: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>
Applied.
^ permalink raw reply
* Re: [PATCH V0] x86/hyperv: Fix compiler warnings in hv_crash.c
From: Wei Liu @ 2026-02-04 6:12 UTC (permalink / raw)
To: Michael Kelley
Cc: Mukesh R, linux-hyperv@vger.kernel.org,
linux-kernel@vger.kernel.org, wei.liu@kernel.org
In-Reply-To: <SN6PR02MB4157F7458CA9AE3F84B9B95BD49EA@SN6PR02MB4157.namprd02.prod.outlook.com>
On Thu, Jan 29, 2026 at 04:21:56AM +0000, Michael Kelley wrote:
> From: Mukesh R <mrathor@linux.microsoft.com> Sent: Tuesday, January 20, 2026 6:41 PM
> >
> > Fix two compiler warnings:
> > o smp_ops is only defined if CONFIG_SMP
> > o status is set but not explicitly used.
> >
> > Reported-by: kernel test robot <lkp@intel.com>
> > Closes: https://lore.kernel.org/oe-kbuild-all/202512301641.FC6OAbGM-lkp@intel.com/
> > Signed-off-by: Mukesh R <mrathor@linux.microsoft.com>
> > ---
> > arch/x86/hyperv/hv_crash.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/x86/hyperv/hv_crash.c b/arch/x86/hyperv/hv_crash.c
> > index c0e22921ace1..82915b22ceae 100644
> > --- a/arch/x86/hyperv/hv_crash.c
> > +++ b/arch/x86/hyperv/hv_crash.c
> > @@ -279,7 +279,6 @@ static void hv_notify_prepare_hyp(void)
> > static noinline __noclone void crash_nmi_callback(struct pt_regs *regs)
> > {
> > struct hv_input_disable_hyp_ex *input;
> > - u64 status;
> > int msecs = 1000, ccpu = smp_processor_id();
> >
> > if (ccpu == 0) {
> > @@ -313,7 +312,7 @@ static noinline __noclone void crash_nmi_callback(struct
> > pt_regs *regs)
> > input->rip = trampoline_pa;
> > input->arg = devirt_arg;
> >
> > - status = hv_do_hypercall(HVCALL_DISABLE_HYP_EX, input, NULL);
> > + hv_do_hypercall(HVCALL_DISABLE_HYP_EX, input, NULL);
> >
> > hv_panic_timeout_reboot();
> > }
> > @@ -628,8 +627,9 @@ void hv_root_crash_init(void)
> > if (rc)
> > goto err_out;
> >
> > +#ifdef CONFIG_SMP
> > smp_ops.crash_stop_other_cpus = hv_crash_stop_other_cpus;
> > -
> > +#endif
> > crash_kexec_post_notifiers = true;
> > hv_crash_enabled = true;
> > pr_info("Hyper-V: both linux and hypervisor kdump support enabled\n");
> > --
> > 2.51.2.vfs.0.1
> >
>
> Ingo Molnar has separately fixed the smp_ops problem in [1]. Removing
> the unused "status" value looks good to me, though it's probably slightly
> better to add (void) to hv_do_hypercall() as an explicit acknowledgement
> that there's a return value that's not relevant and is being ignored; i.e.,
>
> (void)hv_do_hypercall(HVCALL_DISABLE_HYP_EX, input, NULL);
>
> Regardless, for the unused "status" part of this patch,
>
> Reviewed-by: Michael Kelley <mhklinux@outlook.com>
>
> [1] https://lore.kernel.org/all/176959812223.510.4055929851272785854.tip-bot2@tip-bot2/
It's my fault. I didn't get to this earlier.
I have applied the other fix to my tree.
Thanks,
Wei
^ permalink raw reply
* Re: [PATCH 1/1] mshv: Fix compiler warning about cast converting incompatible function type
From: Wei Liu @ 2026-02-04 6:08 UTC (permalink / raw)
To: Naman Jain
Cc: mhklinux, kys, haiyangz, wei.liu, decui, longli, linux-hyperv,
linux-kernel
In-Reply-To: <e99513ac-a790-424b-9b80-4a91fd87cba2@linux.microsoft.com>
On Mon, Jan 19, 2026 at 11:02:01AM +0530, Naman Jain wrote:
>
>
> On 1/18/2026 10:32 PM, mhkelley58@gmail.com wrote:
> > From: Michael Kelley <mhklinux@outlook.com>
> >
> > In mshv_vtl_sint_ioctl_pause_msg_stream(), the reference to function
> > mshv_vtl_synic_mask_vmbus_sint() is cast to type smp_call_func_t. The
> > cast generates a compiler warning because the function signature of
> > mshv_vtl_synic_mask_vmbus_sint() doesn't match smp_call_func_t.
> >
> > There's no actual bug here because the mis-matched function signatures
> > are compatible at runtime. Nonetheless, eliminate the compiler warning
> > by changing the function signature of mshv_vtl_synic_mask_vmbus_sint()
> > to match what on_each_cpu() expects. Remove the cast because it is then
> > no longer necessary.
> >
> > No functional change.
> >
> > Reported-by: kernel test robot <lkp@intel.com>
> > Closes: https://lore.kernel.org/oe-kbuild-all/202601170352.qbh3EKH5-lkp@intel.com/
> > Signed-off-by: Michael Kelley <mhklinux@outlook.com>
[...]
>
> Reviewed-by: Naman Jain <namjain@linux.microsoft.com>
>
Queued.
^ permalink raw reply
* Re: [PATCH v2] mshv: make certain field names descriptive in a header struct
From: Wei Liu @ 2026-02-04 6:06 UTC (permalink / raw)
To: Mukesh Rathor; +Cc: linux-hyperv, wei.liu, nunodasneves
In-Reply-To: <20260116224904.2532807-1-mrathor@linux.microsoft.com>
On Fri, Jan 16, 2026 at 02:49:04PM -0800, Mukesh Rathor wrote:
> When struct fields use very common names like "pages" or "type", it makes
> it difficult to find uses of these fields with tools like grep, cscope,
> etc when the struct is in a header file included in many places. Add the
> prefix mreg_ to some fields in struct mshv_mem_region to make it easier
> to find them.
>
> There is no functional change.
>
> Signed-off-by: Mukesh Rathor <mrathor@linux.microsoft.com>
I generally don't mind such changes, but this patch doesn't apply
anymore. Please rebase to the latest hyperv-next.
Wei
^ permalink raw reply
* Re: [PATCH 1/1] PCI: hv: Remove unused field pci_bus in struct hv_pcibus_device
From: Wei Liu @ 2026-02-04 6:02 UTC (permalink / raw)
To: mhklinux
Cc: kys, haiyangz, wei.liu, decui, longli, lpieralisi, kwilczynski,
mani, robh, bhelgaas, linux-pci, linux-kernel, linux-hyperv
In-Reply-To: <20260111170034.67558-1-mhklinux@outlook.com>
On Sun, Jan 11, 2026 at 09:00:34AM -0800, mhkelley58@gmail.com wrote:
> From: Michael Kelley <mhklinux@outlook.com>
>
> Field pci_bus in struct hv_pcibus_device is unused since
> commit 418cb6c8e051 ("PCI: hv: Generify PCI probing"). Remove it.
>
> No functional change.
>
> Signed-off-by: Michael Kelley <mhklinux@outlook.com>
It looks like this trivial patch is not yet picked up. I've queued it
up.
Thanks,
Wei
> ---
> drivers/pci/controller/pci-hyperv.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c
> index 1e237d3538f9..7fcba05cec30 100644
> --- a/drivers/pci/controller/pci-hyperv.c
> +++ b/drivers/pci/controller/pci-hyperv.c
> @@ -501,7 +501,6 @@ struct hv_pcibus_device {
> struct resource *low_mmio_res;
> struct resource *high_mmio_res;
> struct completion *survey_event;
> - struct pci_bus *pci_bus;
> spinlock_t config_lock; /* Avoid two threads writing index page */
> spinlock_t device_list_lock; /* Protect lists below */
> void __iomem *cfg_addr;
> --
> 2.25.1
>
^ permalink raw reply
* Re: [PATCH] mshv: Make MSHV mutually exclusive with KEXEC
From: Anirudh Rayabharam @ 2026-02-04 5:33 UTC (permalink / raw)
To: Stanislav Kinsburskii
Cc: kys, haiyangz, wei.liu, decui, longli, linux-hyperv, linux-kernel
In-Reply-To: <aYJPwp2i47P33xuz@skinsburskii.localdomain>
On Tue, Feb 03, 2026 at 11:42:58AM -0800, Stanislav Kinsburskii wrote:
> On Tue, Feb 03, 2026 at 04:46:03PM +0000, Anirudh Rayabharam wrote:
> > On Tue, Feb 03, 2026 at 07:40:36AM -0800, Stanislav Kinsburskii wrote:
> > > On Tue, Feb 03, 2026 at 10:34:28AM +0530, Anirudh Rayabharam wrote:
> > > > On Mon, Feb 02, 2026 at 11:18:27AM -0800, Stanislav Kinsburskii wrote:
> > > > > On Mon, Feb 02, 2026 at 07:01:01PM +0000, Anirudh Rayabharam wrote:
> > > > > > On Mon, Feb 02, 2026 at 09:10:00AM -0800, Stanislav Kinsburskii wrote:
> > > > > > > On Fri, Jan 30, 2026 at 08:32:45PM +0000, Anirudh Rayabharam wrote:
> > > > > > > > On Fri, Jan 30, 2026 at 10:46:45AM -0800, Stanislav Kinsburskii wrote:
> > > > > > > > > On Fri, Jan 30, 2026 at 05:11:12PM +0000, Anirudh Rayabharam wrote:
> > > > > > > > > > On Wed, Jan 28, 2026 at 03:11:14PM -0800, Stanislav Kinsburskii wrote:
> > > > > > > > > > > On Wed, Jan 28, 2026 at 04:16:31PM +0000, Anirudh Rayabharam wrote:
> > > > > > > > > > > > On Mon, Jan 26, 2026 at 12:46:44PM -0800, Stanislav Kinsburskii wrote:
> > > > > > > > > > > > > On Tue, Jan 27, 2026 at 12:19:24AM +0530, Anirudh Rayabharam wrote:
> > > > > > > > > > > > > > On Fri, Jan 23, 2026 at 10:20:53PM +0000, 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.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Someone might want to stop all guest VMs and do a kexec. Which is valid
> > > > > > > > > > > > > > and would work without any issue for L1VH.
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > No, it won't work and hypervsisor depostied pages won't be withdrawn.
> > > > > > > > > > > >
> > > > > > > > > > > > All pages that were deposited in the context of a guest partition (i.e.
> > > > > > > > > > > > with the guest partition ID), would be withdrawn when you kill the VMs,
> > > > > > > > > > > > right? What other deposited pages would be left?
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > The driver deposits two types of pages: one for the guests (withdrawn
> > > > > > > > > > > upon gust shutdown) and the other - for the host itself (never
> > > > > > > > > > > withdrawn).
> > > > > > > > > > > See hv_call_create_partition, for example: it deposits pages for the
> > > > > > > > > > > host partition.
> > > > > > > > > >
> > > > > > > > > > Hmm.. I see. Is it not possible to reclaim this memory in module_exit?
> > > > > > > > > > Also, can't we forcefully kill all running partitions in module_exit and
> > > > > > > > > > then reclaim memory? Would this help with kernel consistency
> > > > > > > > > > irrespective of userspace behavior?
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > It would, but this is sloppy and cannot be a long-term solution.
> > > > > > > > >
> > > > > > > > > It is also not reliable. We have no hook to prevent kexec. So if we fail
> > > > > > > > > to kill the guest or reclaim the memory for any reason, the new kernel
> > > > > > > > > may still crash.
> > > > > > > >
> > > > > > > > Actually guests won't be running by the time we reach our module_exit
> > > > > > > > function during a kexec. Userspace processes would've been killed by
> > > > > > > > then.
> > > > > > > >
> > > > > > >
> > > > > > > No, they will not: "kexec -e" doesn't kill user processes.
> > > > > > > We must not rely on OS to do graceful shutdown before doing
> > > > > > > kexec.
> > > > > >
> > > > > > I see kexec -e is too brutal. Something like systemctl kexec is
> > > > > > more graceful and is probably used more commonly. In this case at least
> > > > > > we could register a reboot notifier and attempt to clean things up.
> > > > > >
> > > > > > I think it is better to support kexec to this extent rather than
> > > > > > disabling it entirely.
> > > > > >
> > > > >
> > > > > You do understand that once our kernel is released to third parties, we
> > > > > can’t control how they will use kexec, right?
> > > >
> > > > Yes, we can't. But that's okay. It is fine for us to say that only some
> > > > kexec scenarios are supported and some aren't (iff you're creating VMs
> > > > using MSHV; if you're not creating VMs all of kexec is supported).
> > > >
> > >
> > > Well, I disagree here. If we say the kernel supports MSHV, we must
> > > provide a robust solution. A partially working solution is not
> > > acceptable. It makes us look careless and can damage our reputation as a
> > > team (and as a company).
> >
> > It won't if we call out upfront what is supported and what is not.
> >
> > >
> > > > >
> > > > > This is a valid and existing option. We have to account for it. Yet
> > > > > again, L1VH will be used by arbitrary third parties out there, not just
> > > > > by us.
> > > > >
> > > > > We can’t say the kernel supports MSHV until we close these gaps. We must
> > > >
> > > > We can. It is okay say some scenarios are supported and some aren't.
> > > >
> > > > All kexecs are supported if they never create VMs using MSHV. If they do
> > > > create VMs using MSHV and we implement cleanup in a reboot notifier at
> > > > least systemctl kexec and crashdump kexec would which are probably the
> > > > most common uses of kexec. It's okay to say that this is all we support
> > > > as of now.
> > > >
> > >
> > > I'm repeating myself, but I'll try to put it differently.
> > > There won't be any kernel core collected if a page was deposited. You're
> > > arguing for a lost cause here. Once a page is allocated and deposited,
> > > the crash kernel will try to write it into the core.
> >
> > That's why we have to implement something where we attempt to destroy
> > partitions and reclaim memory (and BUG() out if that fails; which
> > hopefully should happen very rarely if at all). This should be *the*
> > solution we work towards. We don't need a temporary disable kexec
> > solution.
> >
>
> No, the solution is to preserve the shared state and pass it over via KHO.
Okay, then work towards it without doing temporary KEXEC disable. We can
call out that kexec is not supported until then. Disabling KEXEC is too
intrusive.
Is there any precedent for this? Do you know if any driver ever disabled
KEXEC this way?
>
> > >
> > > > Also, what makes you think customers would even be interested in enabling
> > > > our module in their kernel configs if it takes away kexec?
> > > >
> > >
> > > It's simple: L1VH isn't a host, so I can spin up new VMs instead of
> > > servicing the existing ones.
> >
> > And what about the L2 VM state then? They might not be throwaway in all
> > cases.
> >
>
> L2 guest can (and likely will) be migrated fromt he old L1VH to the new
> one.
> And this is most likely the current scenario customers are using.
>
> > >
> > > Why do you think there won’t be customers interested in using MSHV in
> > > L1VH without kexec support?
> >
> > Because they could already be using kexec for their servicing needs or
> > whatever. And no we can't just say "don't service these VMs just spin up
> > new ones".
> >
>
> Are you speculating or know for sure?
It's a reasonable assumption that people are using kexec for servicing.
>
> > Also, keep in mind that once L1VH is available in Azure, the distros
> > that run on it would be the same distros that run on all other Azure
> > VMs. There won't be special distros with a kernel specifically built for
> > L1VH. And KEXEC is generally enabled in distros. Distro vendors won't be
> > happy that they would need to publish a separate version of their image with
> > MSHV_ROOT enabled and KEXEC disabled because they wouldn't want KEXEC to
> > be disabled for all Azure VMs. Also, the customers will be confused why
> > the same distro doesn't work on L1VH.
> >
>
> I don't think distro happiness is our concern. They already build custom
If distros are not happy they won't package this and consequently
nobody will use it.
> versions for Azure. They can build another custom version for L1VH if
> needed.
We should at least check if they are ready to do this.
Thanks,
Anirudh.
>
> Anyway, I don't see the point in continuing this discussion. All points
> have been made, and solutions have been proposed.
>
> If you can come up with something better in the next few days, so we at
> least have a chance to get it merged in the next merge window, great. If
> not, we should explicitly forbid the unsupported feature and move on.
>
> Thanks,
> Thanks,
> Stanislav
>
> > Thanks,
> > Anirudh.
^ permalink raw reply
* Re: [PATCH] mshv: Make MSHV mutually exclusive with KEXEC
From: Mukesh R @ 2026-02-04 2:46 UTC (permalink / raw)
To: Stanislav Kinsburskii
Cc: Anirudh Rayabharam, kys, haiyangz, wei.liu, decui, longli,
linux-hyperv, linux-kernel
In-Reply-To: <e03cea10-0970-88b6-ae44-7cb9759f2683@linux.microsoft.com>
On 2/2/26 12:15, Mukesh R wrote:
> On 2/2/26 08:43, Stanislav Kinsburskii wrote:
>> On Fri, Jan 30, 2026 at 11:47:48AM -0800, Mukesh R wrote:
>>> On 1/30/26 10:41, Stanislav Kinsburskii wrote:
>>>> On Fri, Jan 30, 2026 at 05:17:52PM +0000, Anirudh Rayabharam wrote:
>>>>> On Thu, Jan 29, 2026 at 06:59:31PM -0800, Mukesh R wrote:
>>>>>> On 1/28/26 15:08, Stanislav Kinsburskii wrote:
>>>>>>> On Tue, Jan 27, 2026 at 11:56:02AM -0800, Mukesh R wrote:
>>>>>>>> On 1/27/26 09:47, Stanislav Kinsburskii wrote:
>>>>>>>>> On Mon, Jan 26, 2026 at 05:39:49PM -0800, Mukesh R wrote:
>>>>>>>>>> On 1/26/26 16:21, Stanislav Kinsburskii wrote:
>>>>>>>>>>> On Mon, Jan 26, 2026 at 03:07:18PM -0800, Mukesh R wrote:
>>>>>>>>>>>> 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?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This quick hack you mention isn't quick in the upstream kernel as there
>>>>>>>>>>> is no hook to interrupt kexec process except the live update one.
>>>>>>>>>>
>>>>>>>>>> That's the one we want to interrupt and block right? crash kexec
>>>>>>>>>> is ok and should be allowed. We can document we don't support kexec
>>>>>>>>>> for update for now.
>>>>>>>>>>
>>>>>>>>>>> I sent an RFC for that one but given todays conversation details is
>>>>>>>>>>> won't be accepted as is.
>>>>>>>>>>
>>>>>>>>>> Are you taking about this?
>>>>>>>>>>
>>>>>>>>>> "mshv: Add kexec safety for deposited pages"
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yes.
>>>>>>>>>
>>>>>>>>>>> Making mshv mutually exclusive with kexec is the only viable option for
>>>>>>>>>>> now given time constraints.
>>>>>>>>>>> It is intended to be replaced with proper page lifecycle management in
>>>>>>>>>>> the future.
>>>>>>>>>>
>>>>>>>>>> Yeah, that could take a long time and imo we cannot just disable KEXEC
>>>>>>>>>> completely. What we want is just block kexec for updates from some
>>>>>>>>>> mshv file for now, we an print during boot that kexec for updates is
>>>>>>>>>> not supported on mshv. Hope that makes sense.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The trade-off here is between disabling kexec support and having the
>>>>>>>>> kernel crash after kexec in a non-obvious way. This affects both regular
>>>>>>>>> kexec and crash kexec.
>>>>>>>>
>>>>>>>> crash kexec on baremetal is not affected, hence disabling that
>>>>>>>> doesn't make sense as we can't debug crashes then on bm.
>>>>>>>>
>>>>>>>
>>>>>>> Bare metal support is not currently relevant, as it is not available.
>>>>>>> This is the upstream kernel, and this driver will be accessible to
>>>>>>> third-party customers beginning with kernel 6.19 for running their
>>>>>>> kernels in Azure L1VH, so consistency is required.
>>>>>>
>>>>>> Well, without crashdump support, customers will not be running anything
>>>>>> anywhere.
>>>>>
>>>>> This is my concern too. I don't think customers will be particularly
>>>>> happy that kexec doesn't work with our driver.
>>>>>
>>>>
>>>> I wasn?t clear earlier, so let me restate it. Today, kexec is not
>>>> supported in L1VH. This is a bug we have not fixed yet. Disabling kexec
>>>> is not a long-term solution. But it is better to disable it explicitly
>>>> than to have kernel crashes after kexec.
>>>
>>> I don't think there is disagreement on this. The undesired part is turning
>>> off KEXEC config completely.
>>>
>>
>> There is no disagreement on this either. If you have a better solution
>> that can be implemented and merged before next kernel merge window,
>> please propose it. Otherwise, this patch will remain as is for now.
>
> Like I said previously, I'll explore a bit. I think I found something,
> but need to test it a bit and get second opinion on it. For me, I am
Nah, it works, but is too intrusive and no chance of being accepted. So
giving up on it. Hopefully a cleaner way can be achieved working with
kexec folks.
Thanks,
-Mukesh
> not convinced this absolutely has to be in this merge window as it only
> involves MSHV for l1vh and has been like this all this time. Moreover,
> other things like makedumpfile are broken on l1vh. But Wei can make
> final decision.
>
> Thanks,
> -Mukesh
>
>> Thanks,
>> Stanislav
>>
>>> Thanks,
>>> -Mukesh
>>>
>>>
>>>> This does not mean the bug should not be fixed. But the upstream kernel
>>>> has its own policies and merge windows. For kernel 6.19, it is better to
>>>> have a clear kexec error than random crashes after kexec.
>>>>
>>>> Thanks,
>>>> Stanislav
>>>>
>>>>> Thanks,
>>>>> Anirudh
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> -Mukesh
>>>>>>
>>>>>>> Thanks,
>>>>>>> Stanislav
>>>>>>>
>>>>>>>> Let me think and explore a bit, and if I come up with something, I'll
>>>>>>>> send a patch here. If nothing, then we can do this as last resort.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> -Mukesh
>>>>>>>>
>>>>>>>>
>>>>>>>>> It?s a pity we can?t apply a quick hack to disable only regular kexec.
>>>>>>>>> However, since crash kexec would hit the same issues, until we have a
>>>>>>>>> proper state transition for deposted pages, the best workaround for now
>>>>>>>>> is to reset the hypervisor state on every kexec, which needs design,
>>>>>>>>> work, and testing.
>>>>>>>>>
>>>>>>>>> Disabling kexec is the only consistent way to handle this in the
>>>>>>>>> upstream kernel at the moment.
>>>>>>>>>
>>>>>>>>> Thanks, Stanislav
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> -Mukesh
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Stanislav
>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> -Mukesh
>>>>>>>>>>>>
>>>>>>>>>>>>> Therefor it should be explicitly forbidden as it's essentially not
>>>>>>>>>>>>> supported yet.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Stanislav
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Stanislav
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>> -Mukesh
>>>>>>
>>>
>
^ permalink raw reply
* [PATCH v1] x86/hyperv: Move hv crash init after hypercall pg setup
From: Mukesh R @ 2026-02-04 1:58 UTC (permalink / raw)
To: linux-hyperv, linux-kernel; +Cc: wei.liu
hv_root_crash_init() is not setting up the hypervisor crash collection
for baremetal cases because when it's called, hypervisor page is not
setup. This got missed due to internal mirror falling behind.
Fix is simple, just move the crash init call after the hypercall
page setup.
Signed-off-by: Mukesh Rathor <mrathor@linux.microsoft.com>
---
arch/x86/hyperv/hv_init.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index 14de43f4bc6c..7f3301bd081e 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -558,7 +558,6 @@ void __init hyperv_init(void)
memunmap(src);
hv_remap_tsc_clocksource();
- hv_root_crash_init();
hv_sleep_notifiers_register();
} else {
hypercall_msr.guest_physical_address = vmalloc_to_pfn(hv_hypercall_pg);
@@ -567,6 +566,9 @@ void __init hyperv_init(void)
hv_set_hypercall_pg(hv_hypercall_pg);
+ if (hv_root_partition()) /* after set hypercall pg */
+ hv_root_crash_init();
+
skip_hypercall_pg_init:
/*
* hyperv_init() is called before LAPIC is initialized: see
--
2.51.2.vfs.0.1
^ permalink raw reply related
* Re: [PATCH v0] x86/hyperv: Move hv crash init after hypercall pg setup
From: Mukesh R @ 2026-02-04 1:35 UTC (permalink / raw)
To: Easwar Hariharan; +Cc: linux-hyperv, linux-kernel, wei.liu
In-Reply-To: <ae52e158-d138-4344-ab0c-74b2fae56ddb@linux.microsoft.com>
On 2/3/26 16:25, Easwar Hariharan wrote:
> On 2/3/2026 2:41 PM, Mukesh R wrote:
>> Fix a regression where hv_root_crash_init() fails a hypercall because
>> the hypercall page is not fully setup. The regression is caused by
>> following commit:
>>
>> commit c8ed0812646e ("x86/hyperv: Use direct call to hypercall-page")
>>
>
> Is that the right commit? The named commit was merged in v6.18-rc1 and
> hv_root_crash_init() was only merged in v6.19-rc1...
>
> Thanks,
> Easwar (he/him)
Ah, you are right. I guess that commit was not in our internal
hyper-next mirror, so testing did not reveal the issue and I did not
notice it. Because of few missing things, we've to use internal mirror
to test. Anyways, will fix the commit and resend.
Thanks,
-Mukesh
^ permalink raw reply
* Re: [PATCH 1/1] mshv: Add comment about huge page mappings in guest physical address space
From: Stanislav Kinsburskii @ 2026-02-04 0:54 UTC (permalink / raw)
To: Michael Kelley
Cc: mhkelley58@gmail.com, 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
In-Reply-To: <SN6PR02MB41575CA65B0A07C935F85665D49BA@SN6PR02MB4157.namprd02.prod.outlook.com>
On Tue, Feb 03, 2026 at 06:35:40PM +0000, Michael Kelley wrote:
> From: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com> Sent: Monday, February 2, 2026 10:56 AM
> >
> > On Mon, Feb 02, 2026 at 06:26:42PM +0000, Michael Kelley wrote:
> > > From: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com> Sent: Monday, February 2, 2026 9:18 AM
> > > >
> > > > On Mon, Feb 02, 2026 at 08:51:01AM -0800, mhkelley58@gmail.com wrote:
> > > > > From: Michael Kelley <mhklinux@outlook.com>
> > > > >
> > > > > Huge page mappings in the guest physical address space depend on having
> > > > > matching alignment of the userspace address in the parent partition and
> > > > > of the guest physical address. Add a comment that captures this
> > > > > information. See the link to the mailing list thread.
> > > > >
> > > > > No code or functional change.
> > > > >
> > > > > Link: https://lore.kernel.org/linux-hyperv/aUrC94YvscoqBzh3@skinsburskii.localdomain/T/#m0871d2cae9b297fd397ddb8459e534981307c7dc
> > > > > Signed-off-by: Michael Kelley <mhklinux@outlook.com>
> > > > > ---
> > > > > drivers/hv/mshv_root_main.c | 14 ++++++++++++++
> > > > > 1 file changed, 14 insertions(+)
> > > > >
> > > > > diff --git a/drivers/hv/mshv_root_main.c b/drivers/hv/mshv_root_main.c
> > > > > index 681b58154d5e..bc738ff4508e 100644
> > > > > --- a/drivers/hv/mshv_root_main.c
> > > > > +++ b/drivers/hv/mshv_root_main.c
> > > > > @@ -1389,6 +1389,20 @@ mshv_partition_ioctl_set_memory(struct mshv_partition *partition,
> > > > > if (mem.flags & BIT(MSHV_SET_MEM_BIT_UNMAP))
> > > > > return mshv_unmap_user_memory(partition, mem);
> > > > >
> > > > > + /*
> > > > > + * If the userspace_addr and the guest physical address (as derived
> > > > > + * from the guest_pfn) have the same alignment modulo PMD huge page
> > > > > + * size, the MSHV driver can map any PMD huge pages to the guest
> > > > > + * physical address space as PMD huge pages. If the alignments do
> > > > > + * not match, PMD huge pages must be mapped as single pages in the
> > > > > + * guest physical address space. The MSHV driver does not enforce
> > > > > + * that the alignments match, and it invokes the hypervisor to set
> > > > > + * up correct functional mappings either way. See mshv_chunk_stride().
> > > > > + * The caller of the ioctl is responsible for providing userspace_addr
> > > > > + * and guest_pfn values with matching alignments if it wants the guest
> > > > > + * to get the performance benefits of PMD huge page mappings of its
> > > > > + * physical address space to real system memory.
> > > > > + */
> > > >
> > > > Thanks. However, I'd suggest to reduce this commet a lot and put the
> > > > details into the commit message instead. Also, why this place? Why not a
> > > > part of the function description instead, for example?
> > >
> > > In general, I'm very much an advocate of putting a bit more detail into code
> > > comments, so that someone new reading the code has a chance of figuring
> > > out what's going on without having to search through the commit history
> > > and read commit messages. The commit history is certainly useful for the
> > > historical record, and especially how things have changed over time. But for
> > > "how non-obvious things work now", I like to see that in the code comments.
> > >
> >
> > This approach is not well aligned with the existing kernel coding style.
> > It is common to answer the "why" question in the commit message.
> > Code comments should focus on "what" the code does.
> >
> > https://www.kernel.org/doc/html/latest/process/coding-style.html
> >
>
> Which says "Instead, put the comments at the head of the function,
> telling people what it does, and possibly WHY it does it." I'm good with
> that approach.
>
> > For more details, it is common to use `git blame` to learn the context
> > of a change when needed.
>
> Yep, I use that all the time for the historical record.
>
> >
> > > As for where to put the comment, I'm flexible. I thought about placing it
> > > outside the function as a "header" (which is what I think you mean by the
> > > "function description"), but the function handles both "map" and "unmap"
> > > operations, and this comment applies only to "map". Hence I put it after
> > > the test for whether we're doing "map" vs. "unmap". But I wouldn't object
> > > to it being placed as a function description, though the text would need to be
> > > enhanced to more broadly be a function description instead of just a comment
> > > about a specific aspect of "map" behavior.
> > >
> >
> > As for the location, since this documents the userspace API, I would
> > rather place it above the function as part of the function description.
> > Even though the function handles both map and unmap, unmap also deals
> > with huge pages.
>
> I'll do a version written as the function description. But the full function
> description will be more extensive to cover all the "what" that this function
> implements:
> * input parameters, and their valid values
> * map and unmap
> * when pinned vs. movable vs. mmio regions are created
> * what is done with huge pages in the above cases (i.e., a massaged version
> of what I've already written)
> * populating and pinning of pages for pinned regions
>
> Does that match with your expectations?
I’d rather suggest something simpler for the function header:
* What regions are created
* What pages sizes are supported
I.e. describe what the function does, not the rationale or the
architecture behind it.
For example, something like this (suggested by AI, feel free to rewrite
completly):
* Depending on the request, the region is created as pinned RAM, movable RAM,
* or MMIO. PMD-sized huge page mappings are supported when the userspace
* address and guest physical address (guest_pfn << PAGE_SHIFT) have matching
* alignment modulo PMD_SIZE; otherwise the mapping is established using base
* pages.
The rationale and architecture can be put into the commit message.
Thanks,
Stanislav
> Michael
^ permalink raw reply
* Re: [PATCH v0] x86/hyperv: Move hv crash init after hypercall pg setup
From: Easwar Hariharan @ 2026-02-04 0:25 UTC (permalink / raw)
To: Mukesh R; +Cc: linux-hyperv, linux-kernel, easwar.hariharan, wei.liu
In-Reply-To: <20260203224121.26711-1-mrathor@linux.microsoft.com>
On 2/3/2026 2:41 PM, Mukesh R wrote:
> Fix a regression where hv_root_crash_init() fails a hypercall because
> the hypercall page is not fully setup. The regression is caused by
> following commit:
>
> commit c8ed0812646e ("x86/hyperv: Use direct call to hypercall-page")
>
Is that the right commit? The named commit was merged in v6.18-rc1 and
hv_root_crash_init() was only merged in v6.19-rc1...
Thanks,
Easwar (he/him)
^ permalink raw reply
* Re: [PATCH v2 0/4] Improve Hyper-V memory deposit error handling
From: Mukesh R @ 2026-02-03 23:03 UTC (permalink / raw)
To: Stanislav Kinsburskii, kys, haiyangz, wei.liu, decui, longli
Cc: linux-hyperv, linux-kernel
In-Reply-To: <177005499596.120041.5908089206606113719.stgit@skinsburskii-cloud-desktop.internal.cloudapp.net>
On 2/2/26 09:58, Stanislav Kinsburskii wrote:
> This series extends the MSHV driver to properly handle additional
> memory-related error codes from the Microsoft Hypervisor by depositing
> memory pages when needed.
>
> Currently, when the hypervisor returns HV_STATUS_INSUFFICIENT_MEMORY
> during partition creation, the driver calls hv_call_deposit_pages() to
> provide the necessary memory. However, there are other memory-related
> error codes that indicate the hypervisor needs additional memory
> resources, but the driver does not attempt to deposit pages for these
> cases.
>
> This series introduces a dedicated helper function macro to identify all
> memory-related error codes (HV_STATUS_INSUFFICIENT_MEMORY,
> HV_STATUS_INSUFFICIENT_BUFFERS, HV_STATUS_INSUFFICIENT_DEVICE_DOMAINS, and
> HV_STATUS_INSUFFICIENT_ROOT_MEMORY) and ensures the driver attempts to
> deposit pages for all of them via new hv_deposit_memory() helper.
>
> With these changes, partition creation becomes more robust by handling
> all scenarios where the hypervisor requires additional memory deposits.
>
> v2:
> - Rename hv_result_oom() into hv_result_needs_memory()
>
> ---
>
> Stanislav Kinsburskii (4):
> mshv: Introduce hv_result_needs_memory() helper function
> mshv: Introduce hv_deposit_memory helper functions
> mshv: Handle insufficient contiguous memory hypervisor status
> mshv: Handle insufficient root memory hypervisor statuses
>
>
> drivers/hv/hv_common.c | 3 ++
> drivers/hv/hv_proc.c | 54 +++++++++++++++++++++++++++++++++++---
> drivers/hv/mshv_root_hv_call.c | 45 +++++++++++++-------------------
> drivers/hv/mshv_root_main.c | 5 +---
> include/asm-generic/mshyperv.h | 13 +++++++++
> include/hyperv/hvgdk_mini.h | 57 +++++++++++++++++++++-------------------
> include/hyperv/hvhdk_mini.h | 2 +
> 7 files changed, 119 insertions(+), 60 deletions(-)
>
for the whole series:
Reviewed-by: Mukesh R <mrathor@linux.microsoft.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox