* [PATCH v3 1/2] mshv: refactor synic init and cleanup
From: Anirudh Rayabharam @ 2026-02-04 17:42 UTC (permalink / raw)
To: kys, haiyangz, wei.liu, decui, longli, linux-hyperv, linux-kernel; +Cc: anirudh
In-Reply-To: <20260204174237.1201153-1-anirudh@anirudhrb.com>
From: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>
Rename mshv_synic_init() to mshv_synic_cpu_init() and
mshv_synic_cleanup() to mshv_synic_cpu_exit() to better reflect that
these functions handle per-cpu synic setup and teardown.
Use mshv_synic_init/cleanup() to perform init/cleanup that is not per-cpu.
Move all the synic related setup from mshv_parent_partition_init.
Move the reboot notifier to mshv_synic.c because it currently only
operates on the synic cpuhp state.
Move out synic_pages from the global mshv_root since it's use is now
completely local to mshv_synic.c.
This is in preparation for the next patch which will add more stuff to
mshv_synic_init().
No functional change.
Signed-off-by: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>
---
drivers/hv/mshv_root.h | 5 ++-
drivers/hv/mshv_root_main.c | 59 +++++-------------------------
drivers/hv/mshv_synic.c | 71 +++++++++++++++++++++++++++++++++----
3 files changed, 75 insertions(+), 60 deletions(-)
diff --git a/drivers/hv/mshv_root.h b/drivers/hv/mshv_root.h
index 3c1d88b36741..26e0320c8097 100644
--- a/drivers/hv/mshv_root.h
+++ b/drivers/hv/mshv_root.h
@@ -183,7 +183,6 @@ struct hv_synic_pages {
};
struct mshv_root {
- struct hv_synic_pages __percpu *synic_pages;
spinlock_t pt_ht_lock;
DECLARE_HASHTABLE(pt_htable, MSHV_PARTITIONS_HASH_BITS);
struct hv_partition_property_vmm_capabilities vmm_caps;
@@ -242,8 +241,8 @@ int mshv_register_doorbell(u64 partition_id, doorbell_cb_t doorbell_cb,
void mshv_unregister_doorbell(u64 partition_id, int doorbell_portid);
void mshv_isr(void);
-int mshv_synic_init(unsigned int cpu);
-int mshv_synic_cleanup(unsigned int cpu);
+int mshv_synic_init(struct device *dev);
+void mshv_synic_cleanup(void);
static inline bool mshv_partition_encrypted(struct mshv_partition *partition)
{
diff --git a/drivers/hv/mshv_root_main.c b/drivers/hv/mshv_root_main.c
index 681b58154d5e..7c1666456e78 100644
--- a/drivers/hv/mshv_root_main.c
+++ b/drivers/hv/mshv_root_main.c
@@ -2035,7 +2035,6 @@ mshv_dev_release(struct inode *inode, struct file *filp)
return 0;
}
-static int mshv_cpuhp_online;
static int mshv_root_sched_online;
static const char *scheduler_type_to_string(enum hv_scheduler_type type)
@@ -2198,40 +2197,14 @@ root_scheduler_deinit(void)
free_percpu(root_scheduler_output);
}
-static int mshv_reboot_notify(struct notifier_block *nb,
- unsigned long code, void *unused)
-{
- cpuhp_remove_state(mshv_cpuhp_online);
- return 0;
-}
-
-struct notifier_block mshv_reboot_nb = {
- .notifier_call = mshv_reboot_notify,
-};
-
static void mshv_root_partition_exit(void)
{
- unregister_reboot_notifier(&mshv_reboot_nb);
root_scheduler_deinit();
}
static int __init mshv_root_partition_init(struct device *dev)
{
- int err;
-
- err = root_scheduler_init(dev);
- if (err)
- return err;
-
- err = register_reboot_notifier(&mshv_reboot_nb);
- if (err)
- goto root_sched_deinit;
-
- return 0;
-
-root_sched_deinit:
- root_scheduler_deinit();
- return err;
+ return root_scheduler_init(dev);
}
static void mshv_init_vmm_caps(struct device *dev)
@@ -2276,31 +2249,18 @@ static int __init mshv_parent_partition_init(void)
MSHV_HV_MAX_VERSION);
}
- mshv_root.synic_pages = alloc_percpu(struct hv_synic_pages);
- if (!mshv_root.synic_pages) {
- dev_err(dev, "Failed to allocate percpu synic page\n");
- ret = -ENOMEM;
+ ret = mshv_synic_init(dev);
+ if (ret)
goto device_deregister;
- }
-
- ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "mshv_synic",
- mshv_synic_init,
- mshv_synic_cleanup);
- if (ret < 0) {
- dev_err(dev, "Failed to setup cpu hotplug state: %i\n", ret);
- goto free_synic_pages;
- }
-
- mshv_cpuhp_online = ret;
ret = mshv_retrieve_scheduler_type(dev);
if (ret)
- goto remove_cpu_state;
+ goto synic_cleanup;
if (hv_root_partition())
ret = mshv_root_partition_init(dev);
if (ret)
- goto remove_cpu_state;
+ goto synic_cleanup;
mshv_init_vmm_caps(dev);
@@ -2318,10 +2278,8 @@ static int __init mshv_parent_partition_init(void)
exit_partition:
if (hv_root_partition())
mshv_root_partition_exit();
-remove_cpu_state:
- cpuhp_remove_state(mshv_cpuhp_online);
-free_synic_pages:
- free_percpu(mshv_root.synic_pages);
+synic_cleanup:
+ mshv_synic_cleanup();
device_deregister:
misc_deregister(&mshv_dev);
return ret;
@@ -2335,8 +2293,7 @@ static void __exit mshv_parent_partition_exit(void)
mshv_irqfd_wq_cleanup();
if (hv_root_partition())
mshv_root_partition_exit();
- cpuhp_remove_state(mshv_cpuhp_online);
- free_percpu(mshv_root.synic_pages);
+ mshv_synic_cleanup();
}
module_init(mshv_parent_partition_init);
diff --git a/drivers/hv/mshv_synic.c b/drivers/hv/mshv_synic.c
index f8b0337cdc82..074e37c48876 100644
--- a/drivers/hv/mshv_synic.c
+++ b/drivers/hv/mshv_synic.c
@@ -12,11 +12,16 @@
#include <linux/mm.h>
#include <linux/io.h>
#include <linux/random.h>
+#include <linux/cpuhotplug.h>
+#include <linux/reboot.h>
#include <asm/mshyperv.h>
#include "mshv_eventfd.h"
#include "mshv.h"
+static int synic_cpuhp_online;
+static struct hv_synic_pages __percpu *synic_pages;
+
static u32 synic_event_ring_get_queued_port(u32 sint_index)
{
struct hv_synic_event_ring_page **event_ring_page;
@@ -26,7 +31,7 @@ static u32 synic_event_ring_get_queued_port(u32 sint_index)
u32 message;
u8 tail;
- spages = this_cpu_ptr(mshv_root.synic_pages);
+ spages = this_cpu_ptr(synic_pages);
event_ring_page = &spages->synic_event_ring_page;
synic_eventring_tail = (u8 **)this_cpu_ptr(hv_synic_eventring_tail);
@@ -393,7 +398,7 @@ mshv_intercept_isr(struct hv_message *msg)
void mshv_isr(void)
{
- struct hv_synic_pages *spages = this_cpu_ptr(mshv_root.synic_pages);
+ struct hv_synic_pages *spages = this_cpu_ptr(synic_pages);
struct hv_message_page **msg_page = &spages->hyp_synic_message_page;
struct hv_message *msg;
bool handled;
@@ -446,7 +451,7 @@ void mshv_isr(void)
}
}
-int mshv_synic_init(unsigned int cpu)
+static int mshv_synic_cpu_init(unsigned int cpu)
{
union hv_synic_simp simp;
union hv_synic_siefp siefp;
@@ -455,7 +460,7 @@ int mshv_synic_init(unsigned int cpu)
union hv_synic_sint sint;
#endif
union hv_synic_scontrol sctrl;
- struct hv_synic_pages *spages = this_cpu_ptr(mshv_root.synic_pages);
+ struct hv_synic_pages *spages = this_cpu_ptr(synic_pages);
struct hv_message_page **msg_page = &spages->hyp_synic_message_page;
struct hv_synic_event_flags_page **event_flags_page =
&spages->synic_event_flags_page;
@@ -542,14 +547,14 @@ int mshv_synic_init(unsigned int cpu)
return -EFAULT;
}
-int mshv_synic_cleanup(unsigned int cpu)
+static int mshv_synic_cpu_exit(unsigned int cpu)
{
union hv_synic_sint sint;
union hv_synic_simp simp;
union hv_synic_siefp siefp;
union hv_synic_sirbp sirbp;
union hv_synic_scontrol sctrl;
- struct hv_synic_pages *spages = this_cpu_ptr(mshv_root.synic_pages);
+ struct hv_synic_pages *spages = this_cpu_ptr(synic_pages);
struct hv_message_page **msg_page = &spages->hyp_synic_message_page;
struct hv_synic_event_flags_page **event_flags_page =
&spages->synic_event_flags_page;
@@ -663,3 +668,57 @@ mshv_unregister_doorbell(u64 partition_id, int doorbell_portid)
mshv_portid_free(doorbell_portid);
}
+
+static int mshv_synic_reboot_notify(struct notifier_block *nb,
+ unsigned long code, void *unused)
+{
+ if (!hv_root_partition())
+ return 0;
+
+ cpuhp_remove_state(synic_cpuhp_online);
+ return 0;
+}
+
+static struct notifier_block mshv_synic_reboot_nb = {
+ .notifier_call = mshv_synic_reboot_notify,
+};
+
+int __init mshv_synic_init(struct device *dev)
+{
+ int ret = 0;
+
+ synic_pages = alloc_percpu(struct hv_synic_pages);
+ if (!synic_pages) {
+ dev_err(dev, "Failed to allocate percpu synic page\n");
+ return -ENOMEM;
+ }
+
+ ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "mshv_synic",
+ mshv_synic_cpu_init,
+ mshv_synic_cpu_exit);
+ if (ret < 0) {
+ dev_err(dev, "Failed to setup cpu hotplug state: %i\n", ret);
+ goto free_synic_pages;
+ }
+
+ synic_cpuhp_online = ret;
+
+ ret = register_reboot_notifier(&mshv_synic_reboot_nb);
+ if (ret)
+ goto remove_cpuhp_state;
+
+ return 0;
+
+remove_cpuhp_state:
+ cpuhp_remove_state(synic_cpuhp_online);
+free_synic_pages:
+ free_percpu(synic_pages);
+ return ret;
+}
+
+void mshv_synic_cleanup(void)
+{
+ unregister_reboot_notifier(&mshv_synic_reboot_nb);
+ cpuhp_remove_state(synic_cpuhp_online);
+ free_percpu(synic_pages);
+}
--
2.34.1
^ permalink raw reply related
* [PATCH v3 0/2] ARM64 support for doorbell and intercept SINTs
From: Anirudh Rayabharam @ 2026-02-04 17:42 UTC (permalink / raw)
To: kys, haiyangz, wei.liu, decui, longli, linux-hyperv, linux-kernel; +Cc: anirudh
From: "Anirudh Rayabharam (Microsoft)" <anirudh@anirudhrb.com>
On x86, the HYPERVISOR_CALLBACK_VECTOR is used to receive synthetic
interrupts (SINTs) from the hypervisor for doorbells and intercepts.
There is no such vector reserved for arm64.
On arm64, the INTID for SINTs should be in the SGI or PPI range. The
hypervisor exposes a virtual device in the ACPI that reserves a
PPI for this use. Introduce a platform_driver that binds to this ACPI
device and obtains the interrupt vector that can be used for SINTs.
Changes in v3:
- Moved the hv_root_partition() check into the reboot notifier
to avoid doing it multiple times.
v2: https://lore.kernel.org/linux-hyperv/20260202182706.648192-1-anirudh@anirudhrb.com/
Changes in v2:
Addressed review comments:
- Moved more stuff into mshv_synic.c
- Code simplifications
- Removed unnecessary debug prints
v1: https://lore.kernel.org/linux-hyperv/20260128160437.3342167-1-anirudh@anirudhrb.com/
Anirudh Rayabharam (Microsoft) (2):
mshv: refactor synic init and cleanup
mshv: add arm64 support for doorbell & intercept SINTs
drivers/hv/mshv_root.h | 5 +-
drivers/hv/mshv_root_main.c | 59 ++-------
drivers/hv/mshv_synic.c | 232 ++++++++++++++++++++++++++++++++++--
3 files changed, 230 insertions(+), 66 deletions(-)
--
2.34.1
^ permalink raw reply
* Re: [PATCH] x86: mshyperv: Use kthread for vmbus interrupts on PREEMPT_RT
From: Jan Kiszka @ 2026-02-04 13:04 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, skinsburskii, mrathor, anirudh, schakrabarti,
ssengar
In-Reply-To: <20260204073629.GP79272@liuwe-devbox-debian-v2.local>
On 04.02.26 08:36, Wei Liu wrote:
> On Wed, Feb 04, 2026 at 08:32:04AM +0100, Jan Kiszka wrote:
>> 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?
>
> No, you wouldn't. You cannot do that until later this year. If you
> cannot test that, so be it. I'm fine with applying your patch and then
> move the mshv_handler logic later ourselves.
Based on my review, I bet you have to lift the mshv_handler to a thread
as well, e.g. sysvec_hyperv_callback ... -> kick_vp -> wake_up.
OTOH, the probability that someone tries to use PREEMPT_RT as root Linux
is likely even lower than someone trying it as a normal guest. IMHO, you
could also consider to rule out that combination at Kconfig level.
Jan
--
Siemens AG, Foundational Technologies
Linux Expert Center
^ permalink raw reply
* Re: [PATCH] pci: pci-hyperv-intf: remove unnecessary module_init/exit functions
From: Manivannan Sadhasivam @ 2026-02-04 12:38 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,
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>
Acked-by: Manivannan Sadhasivam <mani@kernel.org>
- Mani
> ---
> drivers/pci/controller/pci-hyperv-intf.c | 12 ------------
> 1 file changed, 12 deletions(-)
>
> diff --git a/drivers/pci/controller/pci-hyperv-intf.c b/drivers/pci/controller/pci-hyperv-intf.c
> index 28b3e93d31c0..18acbda867f0 100644
> --- a/drivers/pci/controller/pci-hyperv-intf.c
> +++ b/drivers/pci/controller/pci-hyperv-intf.c
> @@ -52,17 +52,5 @@ int hyperv_reg_block_invalidate(struct pci_dev *dev, void *context,
> }
> EXPORT_SYMBOL_GPL(hyperv_reg_block_invalidate);
>
> -static void __exit exit_hv_pci_intf(void)
> -{
> -}
> -
> -static int __init init_hv_pci_intf(void)
> -{
> - return 0;
> -}
> -
> -module_init(init_hv_pci_intf);
> -module_exit(exit_hv_pci_intf);
> -
> MODULE_DESCRIPTION("Hyper-V PCI Interface");
> MODULE_LICENSE("GPL v2");
> --
> 2.43.0
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH 1/1] PCI: hv: Remove unused field pci_bus in struct hv_pcibus_device
From: mani @ 2026-02-04 12:37 UTC (permalink / raw)
To: Michael Kelley
Cc: lpieralisi@kernel.org, kwilczynski@kernel.org, robh@kernel.org,
bhelgaas@google.com, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org,
kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org,
decui@microsoft.com, longli@microsoft.com
In-Reply-To: <SN6PR02MB41575DE702FAF2BCE5FD38CFD49EA@SN6PR02MB4157.namprd02.prod.outlook.com>
On Thu, Jan 29, 2026 at 04:35:29AM +0000, Michael Kelley wrote:
> From: mhkelley58@gmail.com <mhkelley58@gmail.com> Sent: Sunday, January 11, 2026 9:01 AM
> >
> > 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>
>
> Could a PCI maintainer give an Ack for this trivial patch?
>
I see this got queued by Wei Liu, but FWIW:
Acked-by: Manivannan Sadhasivam <mani@kernel.org>
- Mani
> Thx, Michael
>
> > ---
> > 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 1/3] x86/x2apic: disable x2apic on resume if the kernel expects so
From: Shashank Balaji @ 2026-02-04 9:17 UTC (permalink / raw)
To: Sohil Mehta
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Suresh Siddha, K. Y. Srinivasan, Haiyang Zhang,
Wei Liu, Dexuan Cui, Long Li, Ajay Kaher, Alexey Makhalov,
Broadcom internal kernel review list, Jan Kiszka, Paolo Bonzini,
Vitaly Kuznetsov, Juergen Gross, Boris Ostrovsky, Ingo Molnar,
linux-kernel, linux-hyperv, virtualization, jailhouse-dev, kvm,
xen-devel, Rahul Bukte, Daniel Palmer, Tim Bird, stable
In-Reply-To: <0149c37d-7065-4c72-ab56-4cea1a6c15d0@intel.com>
Hi Sohil,
On Tue, Feb 03, 2026 at 01:08:39PM -0800, Sohil Mehta wrote:
> > diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
> > index d93f87f29d03..cc64d61f82cf 100644
> > --- a/arch/x86/kernel/apic/apic.c
> > +++ b/arch/x86/kernel/apic/apic.c
> > @@ -2456,6 +2456,12 @@ static void lapic_resume(void *data)
> > if (x2apic_mode) {
> > __x2apic_enable();
> > } else {
> > + /*
> > + * x2apic may have been re-enabled by the
> > + * firmware on resuming from s2ram
> > + */
> > + __x2apic_disable();
> > +
>
> We should likely only disable x2apic on platforms that support it and
> need the disabling. How about?
>
> ...
> } else {
> /*
> *
> */
> if (x2apic_enabled())
> __x2apic_disable();
__x2apic_disable disables x2apic only if boot_cpu_has(X86_FEATURE_APIC)
and x2apic is already enabled. x2apic_enabled also does the same checks,
the only difference being, it uses rdmsrq_safe instead of just rdmsrq,
which is what __x2apic_disable uses. The safe version is because of
Boris' suggestion [1]. If that's applicable here as well, then rdmsrq in
__x2apic_disable should be changed to rdmsrq_safe.
> I considered if an error message should be printed along with this. But,
> I am not sure if it can really be called a firmware issue. It's probably
> just that newer CPUs might have started defaulting to x2apic on.
>
> Can you specify what platform you are encountering this?
I'm not sure it's the CPU defaulting to x2apic on. As per Section
12.12.5.1 of the Intel SDM:
On coming out of reset, the local APIC unit is enabled and is in
the xAPIC mode: IA32_APIC_BASE[EN]=1 and IA32_APIC_BASE[EXTD]=0.
So, the CPU should be turning on in xapic mode. In fact, when x2apic is
disabled in the firmware, this problem doesn't happen.
Either way, a pr_warn maybe helpful. How about "x2apic re-enabled by the
firmware during resume. Disabling\n"?
[1] https://lore.kernel.org/all/20150116095927.GA18880@pd.tnic/
^ permalink raw reply
* Re: [PATCH] x86: mshyperv: Use kthread for vmbus interrupts on PREEMPT_RT
From: Wei Liu @ 2026-02-04 7:36 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, skinsburskii, mrathor,
anirudh, schakrabarti, ssengar
In-Reply-To: <d1dded05-a47f-4be2-94c4-913104c758e2@siemens.com>
On Wed, Feb 04, 2026 at 08:32:04AM +0100, Jan Kiszka wrote:
> 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?
No, you wouldn't. You cannot do that until later this year. If you
cannot test that, so be it. I'm fine with applying your patch and then
move the mshv_handler logic later ourselves.
I've CC'ed a few folks from Microsoft.
Saurabh, Long, and Dexuan, can you review and test this patch for VMBus?
Thanks,
Wei
>
> Jan
>
> --
> 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: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
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