From nobody Sat Feb 7 13:41:45 2026 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 65E751DE2CE; Mon, 10 Mar 2025 22:12:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=13.77.154.182 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741644726; cv=none; b=tfYRjTwjB4m7/DLf5CA4MQwYiVP6fLFmYs969A4XK8cZ0Fy6/Eq0yqmduM4TdKUUVScJFNrE+FjozRHrtq9QAyiHZiJQSQdF8TNogUPcsHJTg9NEzhCmZK7Gf/DVWbJpEYFcCNvucQi1/RfqAqljiHBKvEAQJA8s+mJkJ2U9EnE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741644726; c=relaxed/simple; bh=SKvO+7zXnoNHvTpiQVfIZVEjAhuH9e4b+IWhxYM/mIk=; h=From:To:Cc:Subject:Date:Message-Id; b=PFqdxIpHsG4DTOIG2ZPNmvomCvUlT66zpUbW/nuCFRW67mgSJCHZ+khRXp0CUrDjZSKACCC/9haXof3YPFKLdL+/gi1IMq6Z7Of+5dql3yDVUiA/mw7BwXmrwGR1m4R49mN3IpsCv/NzT+uiil5ZqgVVciFvjRl56wE5Po6FSNc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linuxonhyperv.com; spf=pass smtp.mailfrom=linux.microsoft.com; dkim=pass (1024-bit key) header.d=linuxonhyperv.com header.i=@linuxonhyperv.com header.b=JQSHsWDP; arc=none smtp.client-ip=13.77.154.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linuxonhyperv.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxonhyperv.com header.i=@linuxonhyperv.com header.b="JQSHsWDP" Received: by linux.microsoft.com (Postfix, from userid 1202) id DC698205492D; Mon, 10 Mar 2025 15:12:03 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com DC698205492D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxonhyperv.com; s=default; t=1741644723; bh=asMeEivWZCVDFdinhQ6RmSqwY26km8pyKKRGxicSGAs=; h=From:To:Cc:Subject:Date:From; b=JQSHsWDPQZ3LknXNpKFxiTiesnGE5sEDYuWFUe30YokttyuaFCfr9XpsTGvO9YImN zHXWlrReDZg64w03bcr/HWMLJwwbg+laoTCmzL5q9sidIhvqFaGgetk+L/ymx00tCn 1AZ1tOli1vwNjHjdp5iescLaOSXp5au9x/SiW4VY= From: longli@linuxonhyperv.com To: "K. Y. Srinivasan" , Haiyang Zhang , Wei Liu , Dexuan Cui , Greg Kroah-Hartman , linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Long Li Subject: [Patch v3] uio_hv_generic: Set event for all channels on the device Date: Mon, 10 Mar 2025 15:12:01 -0700 Message-Id: <1741644721-20389-1-git-send-email-longli@linuxonhyperv.com> X-Mailer: git-send-email 1.8.3.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" From: Long Li Hyper-V may offer a non latency sensitive device with subchannels without monitor bit enabled. The decision is entirely on the Hyper-V host not configurable within guest. When a device has subchannels, also signal events for the subchannel if its monitor bit is disabled. This patch also removes the memory barrier when monitor bit is enabled as it is not necessary. The memory barrier is only needed between setting up interrupt mask and calling vmbus_set_event() when monitor bit is disabled. Signed-off-by: Long Li Reviewed-by: Saurabh Sengar --- Change log v2: Use vmbus_set_event() to avoid additional check on monitored bit Lock vmbus_connection.channel_mutex when going through subchannels v3: Add details in commit messsage on the memory barrier. drivers/uio/uio_hv_generic.c | 32 ++++++++++++++++++++++++++------ 1 file changed, 26 insertions(+), 6 deletions(-) diff --git a/drivers/uio/uio_hv_generic.c b/drivers/uio/uio_hv_generic.c index 3976360d0096..45be2f8baade 100644 --- a/drivers/uio/uio_hv_generic.c +++ b/drivers/uio/uio_hv_generic.c @@ -65,6 +65,16 @@ struct hv_uio_private_data { char send_name[32]; }; =20 +static void set_event(struct vmbus_channel *channel, s32 irq_state) +{ + channel->inbound.ring_buffer->interrupt_mask =3D !irq_state; + if (!channel->offermsg.monitor_allocated && irq_state) { + /* MB is needed for host to see the interrupt mask first */ + virt_mb(); + vmbus_set_event(channel); + } +} + /* * This is the irqcontrol callback to be registered to uio_info. * It can be used to disable/enable interrupt from user space processes. @@ -79,12 +89,15 @@ hv_uio_irqcontrol(struct uio_info *info, s32 irq_state) { struct hv_uio_private_data *pdata =3D info->priv; struct hv_device *dev =3D pdata->device; + struct vmbus_channel *primary, *sc; =20 - dev->channel->inbound.ring_buffer->interrupt_mask =3D !irq_state; - virt_mb(); + primary =3D dev->channel; + set_event(primary, irq_state); =20 - if (!dev->channel->offermsg.monitor_allocated && irq_state) - vmbus_setevent(dev->channel); + mutex_lock(&vmbus_connection.channel_mutex); + list_for_each_entry(sc, &primary->sc_list, sc_list) + set_event(sc, irq_state); + mutex_unlock(&vmbus_connection.channel_mutex); =20 return 0; } @@ -95,12 +108,19 @@ hv_uio_irqcontrol(struct uio_info *info, s32 irq_state) static void hv_uio_channel_cb(void *context) { struct vmbus_channel *chan =3D context; - struct hv_device *hv_dev =3D chan->device_obj; - struct hv_uio_private_data *pdata =3D hv_get_drvdata(hv_dev); + struct hv_device *hv_dev; + struct hv_uio_private_data *pdata; =20 chan->inbound.ring_buffer->interrupt_mask =3D 1; virt_mb(); =20 + /* + * The callback may come from a subchannel, in which case look + * for the hv device in the primary channel + */ + hv_dev =3D chan->primary_channel ? + chan->primary_channel->device_obj : chan->device_obj; + pdata =3D hv_get_drvdata(hv_dev); uio_event_notify(&pdata->info); } =20 --=20 2.34.1