Received: by 2002:ac0:8845:0:0:0:0:0 with SMTP id g63csp326425img; Tue, 26 Feb 2019 00:20:50 -0800 (PST) X-Google-Smtp-Source: AHgI3IZ9ctEY0U2BoPgkrl3M5FQp0gum8MBpY9lKS/bB18Bm5xjlLwLn0EfYarM9qwvMnAEFYIgZ X-Received: by 2002:a63:35ce:: with SMTP id c197mr10584419pga.281.1551169250333; Tue, 26 Feb 2019 00:20:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551169250; cv=none; d=google.com; s=arc-20160816; b=zPFxtRGSBLGCm8Gz5a23LX+rq3Ba7TEjl3HDzMwevKrlTP2BeIy/JGfX2iNYd97/+c sYJ5m1atTQHc6J7FxZnTmkhRM1W5CTbPF0EXkGQ2oCRbpkvdUDkjEApEfXrSa0GRVQWz 1hjhBkx9PXk4EQX76BzmrFoetMD5CxsbJbeQsM8NayR1zNrloVXd31AvENUznyLz2fuI 2w8oiK4/1yIMRzLzXF+DQLPwNlQF8Xc7DJM4SeAY2AMXJstJe8jf1pYMME03h8GVcwap lCDByyuJpbYnQDJZykimytKExXZSpVyADrkf6ulTm+uAw43qh3AmDvJj39hPpE1BgCvo Icpw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=WyU1u619sae25KvA8srD32Eu8DWSxOkaSkw1+Hwd1ZQ=; b=v0i2gkPPVX5w1DU/Ld4WscePWS48LjL6ow0pb9nYKCCErrcdZc9NX0WFcp4R/FfD/O HBEefa+7H+1geUIMlzuCzSaKPcvppUvsvkRJSjd8+iiRX0jTPlNWhZkj/xC7/fuZfOAy ySzWnUJhsYUozOKpbbON1P1wL2CZq+DMTaCvzEIW+6fgeBZHr5K0fXi/hHpxMW5iofl1 /8qOTn1ZLl39ZLhBrS2qir/euVHKg+ignw4mLblo7kQCKQt2nKoIYNGskib7dlsD7OyP 5zuOKXnhr1hwFoAEggRHCdX3pNtuueT1sGhqYo3Sf0+au/DIzfi1/02NYgti1v5NprIt 6l/A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=lXNGPjrx; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b9si3381112pfj.255.2019.02.26.00.20.34; Tue, 26 Feb 2019 00:20:50 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=lXNGPjrx; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727260AbfBZISw (ORCPT + 99 others); Tue, 26 Feb 2019 03:18:52 -0500 Received: from mail.kernel.org ([198.145.29.99]:41208 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725977AbfBZISw (ORCPT ); Tue, 26 Feb 2019 03:18:52 -0500 Received: from localhost (5356596B.cm-6-7b.dynamic.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 0758A213A2; Tue, 26 Feb 2019 08:18:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1551169130; bh=0JV6VA8+mfx3k8ro0Aco18Zd4Jzci2z5u93qMkxYPbU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=lXNGPjrxLiJ5wYI6mdfb6qHIw2Pvdfigb2BoOh3vJabvrpd4hxkHGgDlSD9L8kdxn 47G4aLBrYK3bZwDv/ueCBmxQIQNTvJtz8DyPHra8c57MAZOwrIFU1oGl0jKksofxgi m2fQjCHcBaTPoJwhs3ZlYgo/8Zwzp/QYpE0GJaz8= Date: Tue, 26 Feb 2019 09:18:48 +0100 From: Greg KH To: Kimberly Brown Cc: Michael Kelley , Long Li , Sasha Levin , Stephen Hemminger , Dexuan Cui , "K. Y. Srinivasan" , Haiyang Zhang , linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3] Drivers: hv: vmbus: Expose monitor data when channel uses monitor pages Message-ID: <20190226081848.GA15659@kroah.com> References: <7481d15f52427917a5f620e29308c1aa5c63f3eb.1550554279.git.kimbrownkd@gmail.com> <20190226053530.GA2897@ubu-Virtual-Machine> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190226053530.GA2897@ubu-Virtual-Machine> User-Agent: Mutt/1.11.3 (2019-02-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 26, 2019 at 12:35:30AM -0500, Kimberly Brown wrote: > There are two methods for signaling the host: the monitor page mechanism > and hypercalls. The monitor page mechanism is used by performance > critical channels (storage, networking, etc.) because it provides > improved throughput. However, latency is increased. Monitor pages are > allocated to these channels. > > Monitor pages are not allocated to channels that do not use the monitor > page mechanism. Therefore, these channels do not have a valid monitor id > or valid monitor page data. In these cases, some of the "_show" > functions return incorrect data. They return an invalid monitor id and > data that is beyond the bounds of the hv_monitor_page array fields. > > The "channel->offermsg.monitor_allocated" value can be used to determine > whether monitor pages have been allocated to a channel. > > Move the device-level monitor page attributes to a separate > attribute_group struct. If the channel uses the monitor page mechanism, > set up the sysfs files for these attributes in vmbus_device_register(). > > Move the channel-level monitor page attributes to a separate > attribute_group struct. If the channel uses the monitor page mechanism, > set up the sysfs files for these attributes in vmbus_add_channel_kobj(). > > Signed-off-by: Kimberly Brown > --- > Changes in v3: > The monitor "_show" functions no longer return an error when a channel > does not use the monitor page mechanism. Instead, the monitor page sysfs > files are created only when a channel uses the monitor page mechanism. > This change was suggested by G. Kroah-Hartman. > > Note: this patch was originally patch 2/2 in a patchset. Patch 1/2 has > already been added to char-misc-testing, so I'm not resending it. > > Changes in v2: > - Changed the return value for cases where monitor_allocated is not set > to "-EINVAL". > - Updated the commit message to provide more details about the monitor > page mechanism. > - Updated the sysfs documentation to describe the new return value. > > Documentation/ABI/stable/sysfs-bus-vmbus | 12 ++++-- > drivers/hv/vmbus_drv.c | 52 +++++++++++++++++++----- > 2 files changed, 51 insertions(+), 13 deletions(-) > > diff --git a/Documentation/ABI/stable/sysfs-bus-vmbus b/Documentation/ABI/stable/sysfs-bus-vmbus > index 826689dcc2e6..6d5cb195b119 100644 > --- a/Documentation/ABI/stable/sysfs-bus-vmbus > +++ b/Documentation/ABI/stable/sysfs-bus-vmbus > @@ -81,7 +81,9 @@ What: /sys/bus/vmbus/devices//channels//latency > Date: September. 2017 > KernelVersion: 4.14 > Contact: Stephen Hemminger > -Description: Channel signaling latency > +Description: Channel signaling latency. This file is available only for > + performance critical channels (storage, network, etc.) that use > + the monitor page mechanism. > Users: Debugging tools > > What: /sys/bus/vmbus/devices//channels//out_mask > @@ -95,7 +97,9 @@ What: /sys/bus/vmbus/devices//channels//pending > Date: September. 2017 > KernelVersion: 4.14 > Contact: Stephen Hemminger > -Description: Channel interrupt pending state > +Description: Channel interrupt pending state. This file is available only for > + performance critical channels (storage, network, etc.) that use > + the monitor page mechanism. > Users: Debugging tools > > What: /sys/bus/vmbus/devices//channels//read_avail > @@ -137,7 +141,9 @@ What: /sys/bus/vmbus/devices//channels//monitor_id > Date: January. 2018 > KernelVersion: 4.16 > Contact: Stephen Hemminger > -Description: Monitor bit associated with channel > +Description: Monitor bit associated with channel. This file is available only > + for performance critical channels (storage, network, etc.) that > + use the monitor page mechanism. > Users: Debugging tools and userspace drivers > > What: /sys/bus/vmbus/devices//channels//ring > diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c > index 000b53e5a17a..ede858b0ee46 100644 > --- a/drivers/hv/vmbus_drv.c > +++ b/drivers/hv/vmbus_drv.c > @@ -601,19 +601,12 @@ static DEVICE_ATTR_RW(driver_override); > static struct attribute *vmbus_dev_attrs[] = { > &dev_attr_id.attr, > &dev_attr_state.attr, > - &dev_attr_monitor_id.attr, > &dev_attr_class_id.attr, > &dev_attr_device_id.attr, > &dev_attr_modalias.attr, > #ifdef CONFIG_NUMA > &dev_attr_numa_node.attr, > #endif > - &dev_attr_server_monitor_pending.attr, > - &dev_attr_client_monitor_pending.attr, > - &dev_attr_server_monitor_latency.attr, > - &dev_attr_client_monitor_latency.attr, > - &dev_attr_server_monitor_conn_id.attr, > - &dev_attr_client_monitor_conn_id.attr, > &dev_attr_out_intr_mask.attr, > &dev_attr_out_read_index.attr, > &dev_attr_out_write_index.attr, > @@ -632,6 +625,22 @@ static struct attribute *vmbus_dev_attrs[] = { > }; > ATTRIBUTE_GROUPS(vmbus_dev); > > +/* > + * Set up per device monitor page attributes. These attributes are used only by > + * channels that use the monitor page mechanism. > + */ > +static struct attribute *vmbus_dev_monitor_attrs[] = { > + &dev_attr_monitor_id.attr, > + &dev_attr_server_monitor_pending.attr, > + &dev_attr_client_monitor_pending.attr, > + &dev_attr_server_monitor_latency.attr, > + &dev_attr_client_monitor_latency.attr, > + &dev_attr_server_monitor_conn_id.attr, > + &dev_attr_client_monitor_conn_id.attr, > + NULL > +}; > +ATTRIBUTE_GROUPS(vmbus_dev_monitor); No need to create a special group for this and then manually add it if you need it. Just the is_visible() callback in the attribute instead, as that is what it is there for. Thanks, greg k-h