lkml.org 
[lkml]   [2020]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH 03/11] Drivers: hv: vmbus: Replace the per-CPU channel lists with a global array of channels
Date
From: Andrea Parri (Microsoft) <parri.andrea@gmail.com> Sent: Sunday, April 5, 2020 5:15 PM
>
> When Hyper-V sends an interrupt to the guest, the guest has to figure
> out which channel the interrupt is associated with. Hyper-V sets a bit
> in a memory page that is shared with the guest, indicating a particular
> "relid" that the interrupt is associated with. The current Linux code
> then uses a set of per-CPU linked lists to map a given "relid" to a
> pointer to a channel structure.
>
> This design introduces a synchronization problem if the CPU that Hyper-V
> will interrupt for a certain channel is changed. If the interrupt comes
> on the "old CPU" and the channel was already moved to the per-CPU list
> of the "new CPU", then the relid -> channel mapping will fail and the
> interrupt is dropped. Similarly, if the interrupt comes on the new CPU
> but the channel was not moved to the per-CPU list of the new CPU, then
> the mapping will fail and the interrupt is dropped.
>
> Relids are integers ranging from 0 to 2047. The mapping from relids to
> channel structures can be done by setting up an array with 2048 entries,
> each entry being a pointer to a channel structure (hence total size ~16K
> bytes, which is not a problem). The array is global, so there are no
> per-CPU linked lists to update. The array can be searched and updated
> by loading from/storing to the array at the specified index. With no
> per-CPU data structures, the above mentioned synchronization problem is
> avoided and the relid2channel() function gets simpler.
>
> Suggested-by: Michael Kelley <mikelley@microsoft.com>
> Signed-off-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com>
> ---
> NOTE. The inline comment in vmbus_channel_map_relid() follows the argument
> discussed in the RFC [1]. An attempt has been made to make this argument
> more 'explicit' (and, hopefully, more 'robust' against future changes) by
> adding a full memory barrier in vmbus_channel_map_relid(): the barrier takes
> the role of the 'implicit' full memory barriers from queue_work() and from
> check_ready_for_resume_event() referred to in the RFC.
>
> [1] https://lore.kernel.org/linux-hyperv/20200403133826.GA25401@andrea/
>
> drivers/hv/channel_mgmt.c | 179 ++++++++++++++++++++++++--------------
> drivers/hv/connection.c | 38 +++-----
> drivers/hv/hv.c | 2 -
> drivers/hv/hyperv_vmbus.h | 14 +--
> drivers/hv/vmbus_drv.c | 48 ++++++----
> include/linux/hyperv.h | 5 --
> 6 files changed, 160 insertions(+), 126 deletions(-)
>

Reviewed-by: Michael Kelley <mikelley@microsoft.com>

\
 
 \ /
  Last update: 2020-04-10 19:31    [W:0.192 / U:1.352 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site