linux.git/drivers/hv/ring_buffer.c, branch v6.12.80

Drivers: hv: vmbus: Remove second way of mapping ring buffers

2023-04-17T19:19:04+00:00

With changes to how Hyper-V guest VMs flip memory between private
(encrypted) and shared (decrypted), it's no longer necessary to
have separate code paths for mapping VMBus ring buffers for
for normal VMs and for Confidential VMs.

As such, remove the code path that uses vmap_pfn(), and set
the protection flags argument to vmap() to account for the
difference between normal and Confidential VMs.

Signed-off-by: Michael Kelley 
Reviewed-by: Tianyu Lan 
Link: https://lore.kernel.org/r/1679838727-87310-10-git-send-email-mikelley@microsoft.com
Signed-off-by: Wei Liu

Drivers: hv: Explicitly request decrypted in vmap_pfn() calls

2023-03-27T06:46:43+00:00

Update vmap_pfn() calls to explicitly request that the mapping
be for decrypted access to the memory.  There's no change in
functionality since the PFNs passed to vmap_pfn() are above the
shared_gpa_boundary, implicitly producing a decrypted mapping.
But explicitly requesting "decrypted" allows the code to work
before and after changes that cause vmap_pfn() to mask the
PFNs to being below the shared_gpa_boundary.

Signed-off-by: Michael Kelley 
Signed-off-by: Borislav Petkov (AMD) 
Reviewed-by: Tianyu Lan 
Link: https://lore.kernel.org/r/1679838727-87310-4-git-send-email-mikelley@microsoft.com

video: hyperv_fb: Avoid taking busy spinlock on panic path

2022-11-28T16:48:20+00:00

The Hyper-V framebuffer code registers a panic notifier in order
to try updating its fbdev if the kernel crashed. The notifier
callback is straightforward, but it calls the vmbus_sendpacket()
routine eventually, and such function takes a spinlock for the
ring buffer operations.

Panic path runs in atomic context, with local interrupts and
preemption disabled, and all secondary CPUs shutdown. That said,
taking a spinlock might cause a lockup if a secondary CPU was
disabled with such lock taken. Fix it here by checking if the
ring buffer spinlock is busy on Hyper-V framebuffer panic notifier;
if so, bail-out avoiding the potential lockup scenario.

Cc: Andrea Parri (Microsoft) 
Cc: Dexuan Cui 
Cc: Haiyang Zhang 
Cc: "K. Y. Srinivasan" 
Cc: Michael Kelley 
Cc: Stephen Hemminger 
Cc: Tianyu Lan 
Cc: Wei Liu 
Tested-by: Fabio A M Martins 
Signed-off-by: Guilherme G. Piccoli 
Reviewed-by: Michael Kelley 
Link: https://lore.kernel.org/r/20220819221731.480795-10-gpiccoli@igalia.com
Signed-off-by: Wei Liu

Drivers: hv: vmbus: Refactor the ring-buffer iterator functions

2022-04-28T15:01:15+00:00

With no users of hv_pkt_iter_next_raw() and no "external" users of
hv_pkt_iter_first_raw(), the iterator functions can be refactored
and simplified to remove some indirection/code.

Signed-off-by: Andrea Parri (Microsoft) 
Reviewed-by: Michael Kelley 
Link: https://lore.kernel.org/r/20220428145107.7878-6-parri.andrea@gmail.com
Signed-off-by: Wei Liu

Drivers: hv: vmbus: Introduce vmbus_sendpacket_getid()

2022-04-25T15:51:12+00:00

The function can be used to send a VMbus packet and retrieve the
corresponding transaction ID.  It will be used by hv_pci.

No functional change.

Suggested-by: Michael Kelley 
Signed-off-by: Andrea Parri (Microsoft) 
Reviewed-by: Michael Kelley 
Link: https://lore.kernel.org/r/20220419122325.10078-4-parri.andrea@gmail.com
Signed-off-by: Wei Liu

Drivers: hv: vmbus: Prevent load re-ordering when reading ring buffer

2022-03-29T13:19:33+00:00

When reading a packet from a host-to-guest ring buffer, there is no
memory barrier between reading the write index (to see if there is
a packet to read) and reading the contents of the packet. The Hyper-V
host uses store-release when updating the write index to ensure that
writes of the packet data are completed first. On the guest side,
the processor can reorder and read the packet data before the write
index, and sometimes get stale packet data. Getting such stale packet
data has been observed in a reproducible case in a VM on ARM64.

Fix this by using virt_load_acquire() to read the write index,
ensuring that reads of the packet data cannot be reordered
before it. Preventing such reordering is logically correct, and
with this change, getting stale data can no longer be reproduced.

Signed-off-by: Michael Kelley 
Reviewed-by: Andrea Parri (Microsoft) 
Link: https://lore.kernel.org/r/1648394710-33480-1-git-send-email-mikelley@microsoft.com
Signed-off-by: Wei Liu

Drivers: hv : vmbus: Adding NULL pointer check

2021-10-28T11:40:32+00:00

This patch fixes the following Coccinelle warning:
drivers/hv/ring_buffer.c:223: alloc with no test

Reported-by: Zeal Robot 
Signed-off-by: Lv Ruyi 
Link: https://lore.kernel.org/r/20211028104138.14576-1-lv.ruyi@zte.com.cn
Signed-off-by: Wei Liu

Drivers: hv: vmbus: Initialize VMbus ring buffer for Isolation VM

2021-10-28T11:26:36+00:00

VMbus ring buffer are shared with host and it's need to
be accessed via extra address space of Isolation VM with
AMD SNP support. This patch is to map the ring buffer
address in extra address space via vmap_pfn(). Hyperv set
memory host visibility hvcall smears data in the ring buffer
and so reset the ring buffer memory to zero after mapping.

Reviewed-by: Michael Kelley 
Signed-off-by: Tianyu Lan 
Link: https://lore.kernel.org/r/20211025122116.264793-10-ltykernel@gmail.com
Signed-off-by: Wei Liu

Drivers: hv: vmbus: Fix kernel crash upon unbinding a device from uio_hv_generic driver

2021-09-03T11:00:06+00:00

The following crash happens when a never-used device is unbound from
uio_hv_generic driver:

 kernel BUG at mm/slub.c:321!
 invalid opcode: 0000 [#1] SMP PTI
 CPU: 0 PID: 4001 Comm: bash Kdump: loaded Tainted: G               X --------- ---  5.14.0-0.rc2.23.el9.x86_64 #1
 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090008  12/07/2018
 RIP: 0010:__slab_free+0x1d5/0x3d0
...
 Call Trace:
  ? pick_next_task_fair+0x18e/0x3b0
  ? __cond_resched+0x16/0x40
  ? vunmap_pmd_range.isra.0+0x154/0x1c0
  ? __vunmap+0x22d/0x290
  ? hv_ringbuffer_cleanup+0x36/0x40 [hv_vmbus]
  kfree+0x331/0x380
  ? hv_uio_remove+0x43/0x60 [uio_hv_generic]
  hv_ringbuffer_cleanup+0x36/0x40 [hv_vmbus]
  vmbus_free_ring+0x21/0x60 [hv_vmbus]
  hv_uio_remove+0x4f/0x60 [uio_hv_generic]
  vmbus_remove+0x23/0x30 [hv_vmbus]
  __device_release_driver+0x17a/0x230
  device_driver_detach+0x3c/0xa0
  unbind_store+0x113/0x130
...

The problem appears to be that we free 'ring_info->pkt_buffer' twice:
first, when the device is unbound from in-kernel driver (netvsc in this
case) and second from hv_uio_remove(). Normally, ring buffer is supposed
to be re-initialized from hv_uio_open() but this happens when UIO device
is being opened and this is not guaranteed to happen.

Generally, it is OK to call hv_ringbuffer_cleanup() twice for the same
channel (which is being handed over between in-kernel drivers and UIO) even
if we didn't call hv_ringbuffer_init() in between. We, however, need to
avoid kfree() call for an already freed pointer.

Fixes: adae1e931acd ("Drivers: hv: vmbus: Copy packets sent by Hyper-V out of the ring buffer")
Signed-off-by: Vitaly Kuznetsov 
Reviewed-by: Andrea Parri 
Reviewed-by: Michael Kelley 
Link: https://lore.kernel.org/r/20210831143916.144983-1-vkuznets@redhat.com
Signed-off-by: Wei Liu

scsi: storvsc: Use blk_mq_unique_tag() to generate requestIDs

2021-05-14T17:39:32+00:00

Use blk_mq_unique_tag() to generate requestIDs for StorVSC, avoiding
all issues with allocating enough entries in the VMbus requestor.

Suggested-by: Michael Kelley 
Signed-off-by: Andrea Parri (Microsoft) 
Reviewed-by: Michael Kelley 
Acked-by: Martin K. Petersen 
Link: https://lore.kernel.org/r/20210510210841.370472-1-parri.andrea@gmail.com
Signed-off-by: Wei Liu