<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/hv, branch v6.18.36</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.18.36</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.18.36'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-06-19T11:43:56+00:00</updated>
<entry>
<title>Drivers: hv: vmbus: Provide option to skip VMBus unload on panic</title>
<updated>2026-06-19T11:43:56+00:00</updated>
<author>
<name>Michael Kelley</name>
<email>mhklinux@outlook.com</email>
</author>
<published>2026-02-17T18:23:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b0f77f76231be8674faa6348c636a4cc4a17c953'/>
<id>urn:sha1:b0f77f76231be8674faa6348c636a4cc4a17c953</id>
<content type='text'>
[ Upstream commit c5c3ef8d49e15d2fc1cec4ad7c91d81b99977440 ]

Currently, VMBus code initiates a VMBus unload in the panic path so
that if a kdump kernel is loaded, it can start fresh in setting up its
own VMBus connection. However, a driver for the VMBus virtual frame
buffer may need to flush dirty portions of the frame buffer back to
the Hyper-V host so that panic information is visible in the graphics
console. To support such flushing, provide exported functions for the
frame buffer driver to specify that the VMBus unload should not be
done by the VMBus driver, and to initiate the VMBus unload itself.
Together these allow a frame buffer driver to delay the VMBus unload
until after it has completed the flush.

Ideally, the VMBus driver could use its own panic-path callback to do
the unload after all frame buffer drivers have finished. But DRM frame
buffer drivers use the kmsg dump callback, and there are no callbacks
after that in the panic path. Hence this somewhat messy approach to
properly sequencing the frame buffer flush and the VMBus unload.

Fixes: 3671f3777758 ("drm/hyperv: Add support for drm_panic")
Signed-off-by: Michael Kelley &lt;mhklinux@outlook.com&gt;
Reviewed-by: Long Li &lt;longli@microsoft.com&gt;
Signed-off-by: Wei Liu &lt;wei.liu@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>Drivers: hv: VMBus protocol version 6.0</title>
<updated>2026-06-19T11:43:55+00:00</updated>
<author>
<name>Roman Kisel</name>
<email>romank@linux.microsoft.com</email>
</author>
<published>2025-10-08T23:34:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1639df1a9844e9fefbbe099e61942ea8c8792811'/>
<id>urn:sha1:1639df1a9844e9fefbbe099e61942ea8c8792811</id>
<content type='text'>
[ Upstream commit 6802d8af47d1dccd9a74a1f708fb9129244ef843 ]

The confidential VMBus is supported starting from the protocol
version 6.0 onwards.

Provide the required definitions. No functional changes.

Signed-off-by: Roman Kisel &lt;romank@linux.microsoft.com&gt;
Reviewed-by: Alok Tiwari &lt;alok.a.tiwari@oracle.com&gt;
Reviewed-by: Michael Kelley &lt;mhklinux@outlook.com&gt;
Signed-off-by: Wei Liu &lt;wei.liu@kernel.org&gt;
Stable-dep-of: c5c3ef8d49e1 ("Drivers: hv: vmbus: Provide option to skip VMBus unload on panic")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>hv: Select CONFIG_SYSFB only for CONFIG_HYPERV_VMBUS</title>
<updated>2026-05-14T13:30:17+00:00</updated>
<author>
<name>Thomas Zimmermann</name>
<email>tzimmermann@suse.de</email>
</author>
<published>2026-04-02T09:09:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cb028f72fb3b2d4af81c74883e904df58ad01db6'/>
<id>urn:sha1:cb028f72fb3b2d4af81c74883e904df58ad01db6</id>
<content type='text'>
commit d33db956c9618e7cb08c2520ce708437914214ec upstream.

Hyperv's sysfb access only exists in the VMBUS support. Therefore
only select CONFIG_SYSFB for CONFIG_HYPERV_VMBUS. Avoids sysfb code
on systems that don't need it.

Signed-off-by: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
Fixes: 96959283a58d ("Drivers: hv: Always select CONFIG_SYSFB for Hyper-V guests")
Cc: Michael Kelley &lt;mhklinux@outlook.com&gt;
Cc: Saurabh Sengar &lt;ssengar@linux.microsoft.com&gt;
Cc: Wei Liu &lt;wei.liu@kernel.org&gt;
Cc: "K. Y. Srinivasan" &lt;kys@microsoft.com&gt;
Cc: Haiyang Zhang &lt;haiyangz@microsoft.com&gt;
Cc: Dexuan Cui &lt;decui@microsoft.com&gt;
Cc: Long Li &lt;longli@microsoft.com&gt;
Cc: linux-hyperv@vger.kernel.org
Cc: &lt;stable@vger.kernel.org&gt; # v6.16+
Reviewed-by: Saurabh Sengar &lt;ssengar@linux.microsoft.com&gt;
Link: https://patch.msgid.link/20260402092305.208728-2-tzimmermann@suse.de
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>mshv: clear eventfd counter on irqfd shutdown</title>
<updated>2026-03-04T12:20:39+00:00</updated>
<author>
<name>Carlos López</name>
<email>clopez@suse.de</email>
</author>
<published>2026-01-22T11:41:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c57b6b4bc339a3cf7e3d0d8c542f048e3ff36190'/>
<id>urn:sha1:c57b6b4bc339a3cf7e3d0d8c542f048e3ff36190</id>
<content type='text'>
[ Upstream commit 2b4246153e2184e3a3b4edc8cc35337d7a2455a6 ]

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 &lt;clopez@suse.de&gt;
Signed-off-by: Wei Liu &lt;wei.liu@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>Drivers: hv: vmbus: Use kthread for vmbus interrupts on PREEMPT_RT</title>
<updated>2026-02-26T22:59:47+00:00</updated>
<author>
<name>Jan Kiszka</name>
<email>jan.kiszka@siemens.com</email>
</author>
<published>2026-02-16T16:24:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b20266f1880b100a0479a0e4b4f987542b8175f8'/>
<id>urn:sha1:b20266f1880b100a0479a0e4b4f987542b8175f8</id>
<content type='text'>
commit f8e6343b7a89c7c649db5a9e309ba7aa20401813 upstream.

Resolves the following lockdep report when booting PREEMPT_RT on Hyper-V
with related guest support enabled:

[    1.127941] hv_vmbus: registering driver hyperv_drm

[    1.132518] =============================
[    1.132519] [ BUG: Invalid wait context ]
[    1.132521] 6.19.0-rc8+ #9 Not tainted
[    1.132524] -----------------------------
[    1.132525] swapper/0/0 is trying to lock:
[    1.132526] ffff8b9381bb3c90 (&amp;channel-&gt;sched_lock){....}-{3:3}, at: vmbus_chan_sched+0xc4/0x2b0
[    1.132543] other info that might help us debug this:
[    1.132544] context-{2:2}
[    1.132545] 1 lock held by swapper/0/0:
[    1.132547]  #0: ffffffffa010c4c0 (rcu_read_lock){....}-{1:3}, at: vmbus_chan_sched+0x31/0x2b0
[    1.132557] stack backtrace:
[    1.132560] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.19.0-rc8+ #9 PREEMPT_{RT,(lazy)}
[    1.132565] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/25/2025
[    1.132567] Call Trace:
[    1.132570]  &lt;IRQ&gt;
[    1.132573]  dump_stack_lvl+0x6e/0xa0
[    1.132581]  __lock_acquire+0xee0/0x21b0
[    1.132592]  lock_acquire+0xd5/0x2d0
[    1.132598]  ? vmbus_chan_sched+0xc4/0x2b0
[    1.132606]  ? lock_acquire+0xd5/0x2d0
[    1.132613]  ? vmbus_chan_sched+0x31/0x2b0
[    1.132619]  rt_spin_lock+0x3f/0x1f0
[    1.132623]  ? vmbus_chan_sched+0xc4/0x2b0
[    1.132629]  ? vmbus_chan_sched+0x31/0x2b0
[    1.132634]  vmbus_chan_sched+0xc4/0x2b0
[    1.132641]  vmbus_isr+0x2c/0x150
[    1.132648]  __sysvec_hyperv_callback+0x5f/0xa0
[    1.132654]  sysvec_hyperv_callback+0x88/0xb0
[    1.132658]  &lt;/IRQ&gt;
[    1.132659]  &lt;TASK&gt;
[    1.132660]  asm_sysvec_hyperv_callback+0x1a/0x20

As code paths that handle vmbus IRQs use sleepy locks under PREEMPT_RT,
the vmbus_isr execution needs to be moved into thread context. Open-
coding this allows to skip the IPI that irq_work would additionally
bring and which we do not need, being an IRQ, never an NMI.

This affects both x86 and arm64, therefore hook into the common driver
logic.

Signed-off-by: Jan Kiszka &lt;jan.kiszka@siemens.com&gt;
Reviewed-by: Florian Bezdeka &lt;florian.bezdeka@siemens.com&gt;
Tested-by: Florian Bezdeka &lt;florian.bezdeka@siemens.com&gt;
Reviewed-by: Michael Kelley &lt;mhklinux@outlook.com&gt;
Tested-by: Michael Kelley &lt;mhklinux@outlook.com&gt;
Signed-off-by: Wei Liu &lt;wei.liu@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>mshv: fix SRCU protection in irqfd resampler ack handler</title>
<updated>2026-02-26T22:59:42+00:00</updated>
<author>
<name>Li RongQing</name>
<email>lirongqing@baidu.com</email>
</author>
<published>2026-02-05T09:40:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a62afa5a595ec4a5bbb63a1d9efd6470b8ca39f2'/>
<id>urn:sha1:a62afa5a595ec4a5bbb63a1d9efd6470b8ca39f2</id>
<content type='text'>
[ Upstream commit 2e7577cd5ddc1f86d1b6c48caf3cfa87dbb14e34 ]

Replace hlist_for_each_entry_rcu() with hlist_for_each_entry_srcu()
in mshv_irqfd_resampler_ack() to correctly handle SRCU-protected
linked list traversal.

The function uses SRCU (sleepable RCU) synchronization via
partition-&gt;pt_irq_srcu, but was incorrectly using the RCU variant
for list iteration. This could lead to race conditions when the
list is modified concurrently.

Also add srcu_read_lock_held() assertion as required by
hlist_for_each_entry_srcu() to ensure we're in the proper
read-side critical section.

Fixes: 621191d709b14 ("Drivers: hv: Introduce mshv_root module to expose /dev/mshv to VMMs")
Signed-off-by: Li RongQing &lt;lirongqing@baidu.com&gt;
Reviewed-by: Anirudh Rayabharam (Microsoft) &lt;anirudh@anirudhrb.com&gt;
Acked-by: Stanislav Kinsburskii &lt;skinsburskii@linux.microsoft.com&gt;
Signed-off-by: Wei Liu &lt;wei.liu@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>Drivers: hv: Always do Hyper-V panic notification in hv_kmsg_dump()</title>
<updated>2026-01-30T09:32:09+00:00</updated>
<author>
<name>Michael Kelley</name>
<email>mhklinux@outlook.com</email>
</author>
<published>2025-12-31T20:14:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6abad2eb9a1bdbb8965ef1d2b5aae3573d3b7d27'/>
<id>urn:sha1:6abad2eb9a1bdbb8965ef1d2b5aae3573d3b7d27</id>
<content type='text'>
[ Upstream commit 49f49d47af67f8a7b221db1d758fc634242dc91a ]

hv_kmsg_dump() currently skips the panic notification entirely if it
doesn't get any message bytes to pass to Hyper-V due to an error from
kmsg_dump_get_buffer(). Skipping the notification is undesirable because
it leaves the Hyper-V host uncertain about the state of a panic'ed guest.

Fix this by always doing the panic notification, even if bytes_written
is zero. Also ensure that bytes_written is initialized, which fixes a
kernel test robot warning. The warning is actually bogus because
kmsg_dump_get_buffer() happens to set bytes_written even if it fails, and
in the kernel test robot's CONFIG_PRINTK not set case, hv_kmsg_dump() is
never called. But do the initialization for robustness and to quiet the
static checker.

Fixes: 9c318a1d9b50 ("Drivers: hv: move panic report code from vmbus to hv early init code")
Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Reported-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Closes: https://lore.kernel.org/all/202512172103.OcUspn1Z-lkp@intel.com/
Signed-off-by: Michael Kelley &lt;mhklinux@outlook.com&gt;
Reviewed-by: Roman Kisel &lt;vdso@mailbox.org&gt;
Signed-off-by: Wei Liu &lt;wei.liu@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>mshv: Fix create memory region overlap check</title>
<updated>2025-12-18T13:03:02+00:00</updated>
<author>
<name>Nuno Das Neves</name>
<email>nunodasneves@linux.microsoft.com</email>
</author>
<published>2025-11-06T22:13:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ab3e7a78d83a61d335458cfe2e4d17eba69ae73d'/>
<id>urn:sha1:ab3e7a78d83a61d335458cfe2e4d17eba69ae73d</id>
<content type='text'>
[ Upstream commit ba9eb9b86d232854e983203dc2fb1ba18e316681 ]

The current check is incorrect; it only checks if the beginning or end
of a region is within an existing region. This doesn't account for
userspace specifying a region that begins before and ends after an
existing region.

Change the logic to a range intersection check against gfns and uaddrs
for each region.

Remove mshv_partition_region_by_uaddr() as it is no longer used.

Fixes: 621191d709b1 ("Drivers: hv: Introduce mshv_root module to expose /dev/mshv to VMMs")
Reported-by: Michael Kelley &lt;mhklinux@outlook.com&gt;
Closes: https://lore.kernel.org/linux-hyperv/SN6PR02MB41575BE0406D3AB22E1D7DB5D4C2A@SN6PR02MB4157.namprd02.prod.outlook.com/
Signed-off-by: Nuno Das Neves &lt;nunodasneves@linux.microsoft.com&gt;
Reviewed-by: Michael Kelley &lt;mhklinux@outlook.com&gt;
Signed-off-by: Wei Liu &lt;wei.liu@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>mshv: Fix deposit memory in MSHV_ROOT_HVCALL</title>
<updated>2025-12-18T13:03:01+00:00</updated>
<author>
<name>Nuno Das Neves</name>
<email>nunodasneves@linux.microsoft.com</email>
</author>
<published>2025-10-17T18:58:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=38080597380815897a8db07d682f739cf9738ad1'/>
<id>urn:sha1:38080597380815897a8db07d682f739cf9738ad1</id>
<content type='text'>
[ Upstream commit 4cc1aa469cd6b714adc958547a4866247bfd60a9 ]

When the MSHV_ROOT_HVCALL ioctl is executing a hypercall, and gets
HV_STATUS_INSUFFICIENT_MEMORY, it deposits memory and then returns
-EAGAIN to userspace. The expectation is that the VMM will retry.

However, some VMM code in the wild doesn't do this and simply fails.
Rather than force the VMM to retry, change the ioctl to deposit
memory on demand and immediately retry the hypercall as is done with
all the other hypercall helper functions.

In addition to making the ioctl easier to use, removing the need for
multiple syscalls improves performance.

There is a complication: unlike the other hypercall helper functions,
in MSHV_ROOT_HVCALL the input is opaque to the kernel. This is
problematic for rep hypercalls, because the next part of the input
list can't be copied on each loop after depositing pages (this was
the original reason for returning -EAGAIN in this case).

Introduce hv_do_rep_hypercall_ex(), which adds a 'rep_start'
parameter. This solves the issue, allowing the deposit loop in
MSHV_ROOT_HVCALL to restart a rep hypercall after depositing pages
partway through.

Fixes: 621191d709b1 ("Drivers: hv: Introduce mshv_root module to expose /dev/mshv to VMMs")
Signed-off-by: Nuno Das Neves &lt;nunodasneves@linux.microsoft.com&gt;
Reviewed-by: Michael Kelley &lt;mhklinux@outlook.com&gt;
Signed-off-by: Wei Liu &lt;wei.liu@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>Drivers: hv: Make CONFIG_HYPERV bool</title>
<updated>2025-10-01T00:00:45+00:00</updated>
<author>
<name>Mukesh Rathor</name>
<email>mrathor@linux.microsoft.com</email>
</author>
<published>2025-09-15T23:46:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e3ec97c3abaf2fb68cc755cae3229288696b9f3d'/>
<id>urn:sha1:e3ec97c3abaf2fb68cc755cae3229288696b9f3d</id>
<content type='text'>
With CONFIG_HYPERV and CONFIG_HYPERV_VMBUS separated, change CONFIG_HYPERV
to bool from tristate. CONFIG_HYPERV now becomes the core Hyper-V
hypervisor support, such as hypercalls, clocks/timers, Confidential
Computing setup, PCI passthru, etc. that doesn't involve VMBus or VMBus
devices.

Signed-off-by: Mukesh Rathor &lt;mrathor@linux.microsoft.com&gt;
Signed-off-by: Wei Liu &lt;wei.liu@kernel.org&gt;
</content>
</entry>
</feed>
