Linux virtualization list
 help / color / mirror / Atom feed
* Re: Hyper-V TODO file
From: Greg KH @ 2011-09-01 20:30 UTC (permalink / raw)
  To: K. Y. Srinivasan; +Cc: gregkh, linux-kernel, devel, virtualization
In-Reply-To: <20110901202733.GA15185@kroah.com>

On Thu, Sep 01, 2011 at 01:27:33PM -0700, Greg KH wrote:
> On Wed, Aug 31, 2011 at 03:16:51PM -0700, K. Y. Srinivasan wrote:
> > 2) With your help, we have fixed all of the issues related to these drivers
> > conforming to the Linux Device Driver model. One of the TODO work items is 
> > "audit the vmbus to verify it is working properly with the driver model".
> 
> I have a few comments about this, I'll respond in another email.

Ok, it looks a _lot_ better, but I have a few minor nits, and one larger
one:

- rename the vmbus_child_* functions to vmbus_* as there's no need to
  think of "children" here.

- vmbus_onoffer comment is incorrect.  You handle offers from lots of
  other types.  Or if not, am I reading the code incorrectly?

- the static hv_cb_utils array needs to go away.  In the hv_utils.c
  util_probe() call, properly register the channel callback, and the
  same goes for the util_remove() call, unregister things there.
  Note, you can use the driver_data field to determine exactly which
  callback needs to be registered to make things easy.  Something like
  the following (pseudo code only):

static const struct hv_vmbus_device_id id_table[] = {
	/* Shutdown guid */
	{ VMBUS_DEVICE(0x31, 0x60, 0x0B, 0X0E, 0x13, 0x52, 0x34, 0x49,
		       0x81, 0x8B, 0x38, 0XD9, 0x0C, 0xED, 0x39, 0xDB),
	  .driver_data = &shutdown_onchannelcallback },
	....
};

util_probe(struct hv_device *dev, const struct hv_vmbus_device_id *id)
 [ Yes, you will have to change the probe callback signature, but that's fine. ]
{
	void *fn(void *context);
	u8 *buffer;

	fn = id->driver_data;
	buffer = kmalloc(PAGE_SIZE, GFP_KERNEL);

	/* Hook up callback and buffer with a call to the proper vmbus
	 * function
	 */
	 ...
}

util_remove()
{
	/* undo what you did in util_probe(), unhooking the callback and
	 * freeing the data */
}


Does that make any sense?

thanks,

greg k-h

^ permalink raw reply
* Re: Hyper-V TODO file
From: Greg KH @ 2011-09-01 20:31 UTC (permalink / raw)
  To: Peter Foley
  Cc: K. Y. Srinivasan, gregkh, Linux Kernel Mailing List, devel,
	virtualization
In-Reply-To: <alpine.LNX.2.00.1108311907130.20924@linux>

On Wed, Aug 31, 2011 at 07:11:39PM -0400, Peter Foley wrote:
> On Wed, 31 Aug 2011, K. Y. Srinivasan wrote:
> > Greg, as I have been pestering you for some time now, we are very interested in
> > exiting staging and we are willing to dedicate the necessary development 
> > resources to address whatever issues that may still be pending. So, your help
> > in identifying what needs to be done will be greatly appreciated. To that end,
> > I think it will be useful to update the TODO file to reflect the current state of
> > the drivers. Let us know how we should proceed here. 
>  
> An issue I've come across in the hyper-v drivers is the forced modular 
> build. You might want to see if the "depends on m" is still needed.

Ah, good point, KY, can you try this out and see if that can be changed?
If not, something is wrong and that needs to get fixed.

thanks,

greg k-h

^ permalink raw reply
* RE: Hyper-V TODO file
From: KY Srinivasan @ 2011-09-01 20:57 UTC (permalink / raw)
  To: Greg KH
  Cc: gregkh@suse.de, linux-kernel@vger.kernel.org,
	devel@linuxdriverproject.org, virtualization@lists.osdl.org
In-Reply-To: <20110901202733.GA15185@kroah.com>



> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Thursday, September 01, 2011 4:28 PM
> To: KY Srinivasan
> Cc: gregkh@suse.de; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; virtualization@lists.osdl.org
> Subject: Re: Hyper-V TODO file
> 
> On Wed, Aug 31, 2011 at 03:16:51PM -0700, K. Y. Srinivasan wrote:
> >
> > Greg,
> >
> > The TODO file for Hyper-V drivers has not been updated in a while and does
> > not reflect the current state of these drivers:
> >
> > 1) There are no more checkpatch warnings/errors in this code. One of the
> TODO
> > work items is "fix remaining checkpatch warnings and errors".
> 
> Great, you can delete it.

Will do.
> 
> > 2) With your help, we have fixed all of the issues related to these drivers
> > conforming to the Linux Device Driver model. One of the TODO work items is
> > "audit the vmbus to verify it is working properly with the driver model".
> 
> I have a few comments about this, I'll respond in another email.
> 
> > 3) Like all other virtualization platforms, the protocol to communicate with
> > the host is very host specific. The ringbuffer control structures are shared
> > between the host and the guest and so, the guest is compelled to follow the
> > mandates of the host. Thus, it is not possible for us to merge the vmbus with
> > other virtual buses in the system. One of the TODO work items is  "see if the
> > vmbus can be merged with the other virtual busses in the kernel".
> 
> Sure, you can delete it.
> 
Will do.
> > 4) A couple of months ago, we had posted the network driver for community
> review.
> > We have submitted patches (and these have been applied) to address the
> review
> > comments. One of the TODO work items is "audit the network driver"
> 
> Leave that until the network subsystem authors agree that this is all
> taken care of by merging the driver into their subsystem.
> 
Ok; will do.

> > 5) Recently, we have merged the IDE and scsi drivers into a single driver that
> > can handle both IDE and SCSI devices. These patches have been already
> checked in.
> > As part of this effort, we have addressed all of the community comments on
> the
> > combined storage driver. The TODO file currently has two work items on this
> > issue: "audit the block driver" and "audit the scsi driver".
> 
> Same as above for the network driver, but you can leave just one entry
> now.

Ok; will do.
> 
> I can't apply patches right now due to the kernel.org infrastructure
> reworking, so you will have to wait a few days for me to apply your
> previous ones, but feel free to send a patch cleaning up the TODO file
> now.

Thanks Greg. I will get the patches out soon.

Regards,

K. Y

^ permalink raw reply
* Re: [PATCH 1/1] staging: hv: Add support for >2 TB LUN in storage driver.
From: Greg KH @ 2011-09-01 20:59 UTC (permalink / raw)
  To: Mike Sterling
  Cc: devel, virtualization, linux-kernel, Mike Sterling,
	K.Y. Srinivasan, Haiyang Zhang
In-Reply-To: <1314911512-1079-1-git-send-email-mike.sterling@microsoft.com>

On Thu, Sep 01, 2011 at 02:11:52PM -0700, Mike Sterling wrote:
> If a LUN larger than 2 TB is attached to a Linux VM on Hyper-V, we currently 
> report a maximum size of 2 TB. This patch resolves the issue in hv_storvsc. 
> Thanks to Robert Scheck <robert.scheck@etes.de> for reporting the issue.
> 
> Signed-off-by: Mike Sterling <mike.sterling@microsoft.com>

As I'm guessing you want this to show up as being done by
mike.sterling@microsoft.com and not steelforce@gmail.com, can you please
resend this from your mike.sterling@microsoft.com account, or put the
proper "From:" line in the patch body as described in the file,
Documentation/SubmittingPatches so I can apply it correctly?

Also, please use the proper "Reported-by:" tag for the bug reporter.

Please resend.

greg k-h

^ permalink raw reply
* RE: Hyper-V TODO file
From: KY Srinivasan @ 2011-09-01 21:08 UTC (permalink / raw)
  To: Greg KH
  Cc: gregkh@suse.de, linux-kernel@vger.kernel.org,
	devel@linuxdriverproject.org, virtualization@lists.osdl.org
In-Reply-To: <20110901203031.GB15185@kroah.com>



> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Thursday, September 01, 2011 4:31 PM
> To: KY Srinivasan
> Cc: gregkh@suse.de; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; virtualization@lists.osdl.org
> Subject: Re: Hyper-V TODO file
> 
> On Thu, Sep 01, 2011 at 01:27:33PM -0700, Greg KH wrote:
> > On Wed, Aug 31, 2011 at 03:16:51PM -0700, K. Y. Srinivasan wrote:
> > > 2) With your help, we have fixed all of the issues related to these drivers
> > > conforming to the Linux Device Driver model. One of the TODO work items is
> > > "audit the vmbus to verify it is working properly with the driver model".
> >
> > I have a few comments about this, I'll respond in another email.
> 
> Ok, it looks a _lot_ better, but I have a few minor nits, and one larger
> one:
> 
> - rename the vmbus_child_* functions to vmbus_* as there's no need to
>   think of "children" here.

Ok; will do.
> 
> - vmbus_onoffer comment is incorrect.  You handle offers from lots of
>   other types.  Or if not, am I reading the code incorrectly?

You are right; I will clean this up.

> 
> - the static hv_cb_utils array needs to go away.  In the hv_utils.c
>   util_probe() call, properly register the channel callback, and the
>   same goes for the util_remove() call, unregister things there.
>   Note, you can use the driver_data field to determine exactly which
>   callback needs to be registered to make things easy.  Something like
>   the following (pseudo code only):
> 
> static const struct hv_vmbus_device_id id_table[] = {
> 	/* Shutdown guid */
> 	{ VMBUS_DEVICE(0x31, 0x60, 0x0B, 0X0E, 0x13, 0x52, 0x34, 0x49,
> 		       0x81, 0x8B, 0x38, 0XD9, 0x0C, 0xED, 0x39, 0xDB),
> 	  .driver_data = &shutdown_onchannelcallback },
> 	....
> };
> 
> util_probe(struct hv_device *dev, const struct hv_vmbus_device_id *id)
>  [ Yes, you will have to change the probe callback signature, but that's fine. ]
> {
> 	void *fn(void *context);
> 	u8 *buffer;
> 
> 	fn = id->driver_data;
> 	buffer = kmalloc(PAGE_SIZE, GFP_KERNEL);
> 
> 	/* Hook up callback and buffer with a call to the proper vmbus
> 	 * function
> 	 */
> 	 ...
> }
> 
> util_remove()
> {
> 	/* undo what you did in util_probe(), unhooking the callback and
> 	 * freeing the data */
> }
> 
> 
> Does that make any sense?

Yes; I will get these patches to you soon. I see how the data ptr can be used;
I will buy you the beer the next time we meet.

Regards,

K. Y
> 
> thanks,
> 
> greg k-h

^ permalink raw reply
* [PATCH 1/1] staging: hv: Add support for >2 TB LUN in storage driver.
From: Mike Sterling @ 2011-09-01 21:11 UTC (permalink / raw)
  To: devel, virtualization, gregkh, linux-kernel
  Cc: Mike Sterling, K.Y. Srinivasan, Haiyang Zhang

If a LUN larger than 2 TB is attached to a Linux VM on Hyper-V, we currently 
report a maximum size of 2 TB. This patch resolves the issue in hv_storvsc. 
Thanks to Robert Scheck <robert.scheck@etes.de> for reporting the issue.

Signed-off-by: Mike Sterling <mike.sterling@microsoft.com>
Signed-off-by: K.Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
---
 drivers/staging/hv/hyperv_storage.h |    1 +
 drivers/staging/hv/storvsc_drv.c    |    2 ++
 2 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/staging/hv/hyperv_storage.h b/drivers/staging/hv/hyperv_storage.h
index a01f9a0..5af82f4 100644
--- a/drivers/staging/hv/hyperv_storage.h
+++ b/drivers/staging/hv/hyperv_storage.h
@@ -218,6 +218,7 @@ struct vstor_packet {
 #define STORVSC_MAX_LUNS_PER_TARGET			64
 #define STORVSC_MAX_TARGETS				1
 #define STORVSC_MAX_CHANNELS				1
+#define STORVSC_MAX_CMD_LEN				16
 
 struct hv_storvsc_request;
 
diff --git a/drivers/staging/hv/storvsc_drv.c b/drivers/staging/hv/storvsc_drv.c
index 7effaf3..26983ac 100644
--- a/drivers/staging/hv/storvsc_drv.c
+++ b/drivers/staging/hv/storvsc_drv.c
@@ -701,6 +701,8 @@ static int storvsc_probe(struct hv_device *device)
 	host->max_id = STORVSC_MAX_TARGETS;
 	/* max # of channels */
 	host->max_channel = STORVSC_MAX_CHANNELS - 1;
+	/* max cmd length */
+	host->max_cmd_len = STORVSC_MAX_CMD_LEN;
 
 	/* Register the HBA and start the scsi bus scan */
 	ret = scsi_add_host(host, &device->device);
-- 
1.7.1

^ permalink raw reply related
* [PATCH 1/1] staging: hv: Add support for >2 TB LUN in storage driver.
From: Mike Sterling @ 2011-09-01 22:11 UTC (permalink / raw)
  To: haiyangz, hjanssen, kys, gregkh, linux-kernel, devel,
	virtualization
  Cc: Mike Sterling

If a LUN larger than 2 TB is attached to a Linux VM on Hyper-V, we currently 
report a maximum size of 2 TB. This patch resolves the issue in hv_storvsc. 
Thanks to Robert Scheck <robert.scheck@etes.de> for reporting the issue.

Reported-by: Robert Scheck <robert.scheck@etes.de>
Signed-off-by: Mike Sterling <mike.sterling@microsoft.com>
Signed-off-by: K.Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
---
 drivers/staging/hv/hyperv_storage.h |    1 +
 drivers/staging/hv/storvsc_drv.c    |    2 ++
 2 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/staging/hv/hyperv_storage.h b/drivers/staging/hv/hyperv_storage.h
index a01f9a0..5af82f4 100644
--- a/drivers/staging/hv/hyperv_storage.h
+++ b/drivers/staging/hv/hyperv_storage.h
@@ -218,6 +218,7 @@ struct vstor_packet {
 #define STORVSC_MAX_LUNS_PER_TARGET			64
 #define STORVSC_MAX_TARGETS				1
 #define STORVSC_MAX_CHANNELS				1
+#define STORVSC_MAX_CMD_LEN				16
 
 struct hv_storvsc_request;
 
diff --git a/drivers/staging/hv/storvsc_drv.c b/drivers/staging/hv/storvsc_drv.c
index 7effaf3..26983ac 100644
--- a/drivers/staging/hv/storvsc_drv.c
+++ b/drivers/staging/hv/storvsc_drv.c
@@ -701,6 +701,8 @@ static int storvsc_probe(struct hv_device *device)
 	host->max_id = STORVSC_MAX_TARGETS;
 	/* max # of channels */
 	host->max_channel = STORVSC_MAX_CHANNELS - 1;
+	/* max cmd length */
+	host->max_cmd_len = STORVSC_MAX_CMD_LEN;
 
 	/* Register the HBA and start the scsi bus scan */
 	ret = scsi_add_host(host, &device->device);
-- 
1.7.1

^ permalink raw reply related
* Re: [PATCH 1/1] staging: hv: Add support for >2 TB LUN in storage driver.
From: Greg KH @ 2011-09-01 22:22 UTC (permalink / raw)
  To: Mike Sterling
  Cc: haiyangz, hjanssen, kys, linux-kernel, devel, virtualization
In-Reply-To: <1314915069-1796-1-git-send-email-mike.sterling@microsoft.com>

On Thu, Sep 01, 2011 at 03:11:09PM -0700, Mike Sterling wrote:
> If a LUN larger than 2 TB is attached to a Linux VM on Hyper-V, we currently 
> report a maximum size of 2 TB. This patch resolves the issue in hv_storvsc. 
> Thanks to Robert Scheck <robert.scheck@etes.de> for reporting the issue.
> 
> Reported-by: Robert Scheck <robert.scheck@etes.de>
> Signed-off-by: Mike Sterling <mike.sterling@microsoft.com>
> Signed-off-by: K.Y. Srinivasan <kys@microsoft.com>
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>

Much better, thanks.

Is this something that needs to go to older kernels (3.0, 2.6.32, etc.)
as well?

greg k-h

^ permalink raw reply
* Re: [PATCH 1/1] Staging: hv: Integrate the time source driver with Hyper-V detection code
From: Thomas Gleixner @ 2011-09-02  8:13 UTC (permalink / raw)
  To: K. Y. Srinivasan
  Cc: gregkh, linux-kernel, devel, virtualization, andi, akpm, x86,
	Haiyang Zhang
In-Reply-To: <1312300982-11609-1-git-send-email-kys@microsoft.com>

On Tue, 2 Aug 2011, K. Y. Srinivasan wrote:

> The Hyper-V timesource driver is best integrated with Hyper-V detection code
> since: (a) Linux guests running on Hyper-V need this timesource and (b)
> by integrating with Hyper-V detection, we could significantly  minimize the
> code in the timesource driver.
> 
> Andrew, could you take this patch for the -mm tree. I have sent this patch
> out multiple times and I have not recived any response or comments.
> 
> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>

Acked-by: Thomas Gleixner <tglx@linutronix.de>

> ---
>  arch/x86/kernel/cpu/mshyperv.c     |   24 ++++++++
>  drivers/staging/hv/Makefile        |    2 +-
>  drivers/staging/hv/hv_timesource.c |  102 ------------------------------------
>  3 files changed, 25 insertions(+), 103 deletions(-)
>  delete mode 100644 drivers/staging/hv/hv_timesource.c
> 
> diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
> index d944bf6..c97f88d 100644
> --- a/arch/x86/kernel/cpu/mshyperv.c
> +++ b/arch/x86/kernel/cpu/mshyperv.c
> @@ -11,6 +11,8 @@
>   */
>  
>  #include <linux/types.h>
> +#include <linux/time.h>
> +#include <linux/clocksource.h>
>  #include <linux/module.h>
>  #include <asm/processor.h>
>  #include <asm/hypervisor.h>
> @@ -36,6 +38,25 @@ static bool __init ms_hyperv_platform(void)
>  		!memcmp("Microsoft Hv", hyp_signature, 12);
>  }
>  
> +static cycle_t read_hv_clock(struct clocksource *arg)
> +{
> +	cycle_t current_tick;
> +	/*
> +	 * Read the partition counter to get the current tick count. This count
> +	 * is set to 0 when the partition is created and is incremented in
> +	 * 100 nanosecond units.
> +	 */
> +	rdmsrl(HV_X64_MSR_TIME_REF_COUNT, current_tick);
> +	return current_tick;
> +}
> +
> +static struct clocksource hyperv_cs = {
> +	.name           = "hyperv_clocksource",
> +	.rating         = 400, /* use this when running on Hyperv*/
> +	.read           = read_hv_clock,
> +	.mask           = CLOCKSOURCE_MASK(64),
> +};
> +
>  static void __init ms_hyperv_init_platform(void)
>  {
>  	/*
> @@ -46,6 +67,9 @@ static void __init ms_hyperv_init_platform(void)
>  
>  	printk(KERN_INFO "HyperV: features 0x%x, hints 0x%x\n",
>  	       ms_hyperv.features, ms_hyperv.hints);
> +
> +
> +	clocksource_register_hz(&hyperv_cs, NSEC_PER_SEC/100);
>  }
>  
>  const __refconst struct hypervisor_x86 x86_hyper_ms_hyperv = {
> diff --git a/drivers/staging/hv/Makefile b/drivers/staging/hv/Makefile
> index bd176b1..3e0d7e6 100644
> --- a/drivers/staging/hv/Makefile
> +++ b/drivers/staging/hv/Makefile
> @@ -1,4 +1,4 @@
> -obj-$(CONFIG_HYPERV)		+= hv_vmbus.o hv_timesource.o
> +obj-$(CONFIG_HYPERV)		+= hv_vmbus.o
>  obj-$(CONFIG_HYPERV_STORAGE)	+= hv_storvsc.o
>  obj-$(CONFIG_HYPERV_NET)	+= hv_netvsc.o
>  obj-$(CONFIG_HYPERV_UTILS)	+= hv_utils.o
> diff --git a/drivers/staging/hv/hv_timesource.c b/drivers/staging/hv/hv_timesource.c
> deleted file mode 100644
> index 0efb049..0000000
> --- a/drivers/staging/hv/hv_timesource.c
> +++ /dev/null
> @@ -1,102 +0,0 @@
> -/*
> - * A clocksource for Linux running on HyperV.
> - *
> - *
> - * Copyright (C) 2010, Novell, Inc.
> - * Author : K. Y. Srinivasan <ksrinivasan@novell.com>
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
> - *
> - * This program is distributed in the hope that it will be useful, but
> - * WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or
> - * NON INFRINGEMENT.  See the GNU General Public License for more
> - * details.
> - *
> - * You should have received a copy of the GNU General Public License
> - * along with this program; if not, write to the Free Software
> - * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
> - *
> - */
> -#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> -
> -#include <linux/version.h>
> -#include <linux/clocksource.h>
> -#include <linux/init.h>
> -#include <linux/module.h>
> -#include <linux/pci.h>
> -#include <linux/dmi.h>
> -#include <asm/hyperv.h>
> -#include <asm/mshyperv.h>
> -#include <asm/hypervisor.h>
> -
> -#define HV_CLOCK_SHIFT	22
> -
> -static cycle_t read_hv_clock(struct clocksource *arg)
> -{
> -	cycle_t current_tick;
> -	/*
> -	 * Read the partition counter to get the current tick count. This count
> -	 * is set to 0 when the partition is created and is incremented in
> -	 * 100 nanosecond units.
> -	 */
> -	rdmsrl(HV_X64_MSR_TIME_REF_COUNT, current_tick);
> -	return current_tick;
> -}
> -
> -static struct clocksource hyperv_cs = {
> -	.name           = "hyperv_clocksource",
> -	.rating         = 400, /* use this when running on Hyperv*/
> -	.read           = read_hv_clock,
> -	.mask           = CLOCKSOURCE_MASK(64),
> -	/*
> -	 * The time ref counter in HyperV is in 100ns units.
> -	 * The definition of mult is:
> -	 * mult/2^shift = ns/cyc = 100
> -	 * mult = (100 << shift)
> -	 */
> -	.mult           = (100 << HV_CLOCK_SHIFT),
> -	.shift          = HV_CLOCK_SHIFT,
> -};
> -
> -static const struct dmi_system_id __initconst
> -hv_timesource_dmi_table[] __maybe_unused  = {
> -	{
> -		.ident = "Hyper-V",
> -		.matches = {
> -			DMI_MATCH(DMI_SYS_VENDOR, "Microsoft Corporation"),
> -			DMI_MATCH(DMI_PRODUCT_NAME, "Virtual Machine"),
> -			DMI_MATCH(DMI_BOARD_NAME, "Virtual Machine"),
> -		},
> -	},
> -	{ },
> -};
> -MODULE_DEVICE_TABLE(dmi, hv_timesource_dmi_table);
> -
> -static const struct pci_device_id __initconst
> -hv_timesource_pci_table[] __maybe_unused = {
> -	{ PCI_DEVICE(0x1414, 0x5353) }, /* VGA compatible controller */
> -	{ 0 }
> -};
> -MODULE_DEVICE_TABLE(pci, hv_timesource_pci_table);
> -
> -
> -static int __init init_hv_clocksource(void)
> -{
> -	if ((x86_hyper != &x86_hyper_ms_hyperv) ||
> -		!(ms_hyperv.features & HV_X64_MSR_TIME_REF_COUNT_AVAILABLE))
> -		return -ENODEV;
> -
> -	if (!dmi_check_system(hv_timesource_dmi_table))
> -		return -ENODEV;
> -
> -	pr_info("Registering HyperV clock source\n");
> -	return clocksource_register(&hyperv_cs);
> -}
> -
> -module_init(init_hv_clocksource);
> -MODULE_DESCRIPTION("HyperV based clocksource");
> -MODULE_AUTHOR("K. Y. Srinivasan <ksrinivasan@novell.com>");
> -MODULE_LICENSE("GPL");
> -- 
> 1.7.4.1
> 
> 

^ permalink raw reply
* RE: [PATCH 1/1] Staging: hv: Integrate the time source driver with Hyper-V detection code
From: KY Srinivasan @ 2011-09-02 13:30 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: x86@kernel.org, Haiyang Zhang, gregkh@suse.de,
	linux-kernel@vger.kernel.org, virtualization@lists.osdl.org,
	andi@firstfloor.org, devel@linuxdriverproject.org,
	akpm@linux-foundation.org
In-Reply-To: <alpine.LFD.2.02.1109021013390.2723@ionos>



> -----Original Message-----
> From: Thomas Gleixner [mailto:tglx@linutronix.de]
> Sent: Friday, September 02, 2011 4:14 AM
> To: KY Srinivasan
> Cc: gregkh@suse.de; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; virtualization@lists.osdl.org; andi@firstfloor.org;
> akpm@linux-foundation.org; x86@kernel.org; Haiyang Zhang
> Subject: Re: [PATCH 1/1] Staging: hv: Integrate the time source driver with Hyper-
> V detection code
> 
> On Tue, 2 Aug 2011, K. Y. Srinivasan wrote:
> 
> > The Hyper-V timesource driver is best integrated with Hyper-V detection code
> > since: (a) Linux guests running on Hyper-V need this timesource and (b)
> > by integrating with Hyper-V detection, we could significantly  minimize the
> > code in the timesource driver.
> >
> > Andrew, could you take this patch for the -mm tree. I have sent this patch
> > out multiple times and I have not recived any response or comments.
> >
> > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> 
> Acked-by: Thomas Gleixner <tglx@linutronix.de>

Thanks Thomas. As you are one of the maintainers, would you be
taking this patch?

Regards,

K. Y 

^ permalink raw reply
* RE: Hyper-V TODO file
From: KY Srinivasan @ 2011-09-02 14:09 UTC (permalink / raw)
  To: Greg KH, Peter Foley
  Cc: gregkh@suse.de, Linux Kernel Mailing List,
	devel@linuxdriverproject.org, virtualization@lists.osdl.org
In-Reply-To: <20110901203113.GA15259@kroah.com>



> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Thursday, September 01, 2011 4:31 PM
> To: Peter Foley
> Cc: KY Srinivasan; gregkh@suse.de; Linux Kernel Mailing List;
> devel@linuxdriverproject.org; virtualization@lists.osdl.org
> Subject: Re: Hyper-V TODO file
> 
> On Wed, Aug 31, 2011 at 07:11:39PM -0400, Peter Foley wrote:
> > On Wed, 31 Aug 2011, K. Y. Srinivasan wrote:
> > > Greg, as I have been pestering you for some time now, we are very
> interested in
> > > exiting staging and we are willing to dedicate the necessary development
> > > resources to address whatever issues that may still be pending. So, your help
> > > in identifying what needs to be done will be greatly appreciated. To that end,
> > > I think it will be useful to update the TODO file to reflect the current state of
> > > the drivers. Let us know how we should proceed here.
> >
> > An issue I've come across in the hyper-v drivers is the forced modular
> > build. You might want to see if the "depends on m" is still needed.
> 
> Ah, good point, KY, can you try this out and see if that can be changed?
> If not, something is wrong and that needs to get fixed.

I will check it and let you know. If there are issues, I fill fix them

Regards,

K. Y

^ permalink raw reply
* RE: Hyper-V TODO file
From: KY Srinivasan @ 2011-09-02 15:17 UTC (permalink / raw)
  To: Greg KH, Peter Foley
  Cc: gregkh@suse.de, Linux Kernel Mailing List,
	devel@linuxdriverproject.org, virtualization@lists.osdl.org
In-Reply-To: <20110901203113.GA15259@kroah.com>



> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Thursday, September 01, 2011 4:31 PM
> To: Peter Foley
> Cc: KY Srinivasan; gregkh@suse.de; Linux Kernel Mailing List;
> devel@linuxdriverproject.org; virtualization@lists.osdl.org
> Subject: Re: Hyper-V TODO file
> 
> On Wed, Aug 31, 2011 at 07:11:39PM -0400, Peter Foley wrote:
> > On Wed, 31 Aug 2011, K. Y. Srinivasan wrote:
> > > Greg, as I have been pestering you for some time now, we are very
> interested in
> > > exiting staging and we are willing to dedicate the necessary development
> > > resources to address whatever issues that may still be pending. So, your help
> > > in identifying what needs to be done will be greatly appreciated. To that end,
> > > I think it will be useful to update the TODO file to reflect the current state of
> > > the drivers. Let us know how we should proceed here.
> >
> > An issue I've come across in the hyper-v drivers is the forced modular
> > build. You might want to see if the "depends on m" is still needed.
> 
> Ah, good point, KY, can you try this out and see if that can be changed?
> If not, something is wrong and that needs to get fixed.

Just verified that we can build into the kernel (not as modules) all hyper-V
drivers except hv_storvsc. hv_storvsc depends upon functionality that in my build 
is being built as modules (SCSI etc.) and this is the reason why I could not build
hv_storvsc as part of the kernel.

Greg, do you want me to submit a patch to Kconfig, getting rid of the module
dependency (for hyperv-v drivers).

Regards,

K. Y

^ permalink raw reply
* [PATCH 1/1] Staging: hv: Update TODO file
From: K. Y. Srinivasan @ 2011-09-02 15:55 UTC (permalink / raw)
  To: gregkh, linux-kernel, devel, virtualization
  Cc: K. Y. Srinivasan, Haiyang Zhang

Based on input from Greg, update the TODO file.

Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
---
 drivers/staging/hv/TODO |    7 ++-----
 1 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/hv/TODO b/drivers/staging/hv/TODO
index 582fd4a..7c9a93f 100644
--- a/drivers/staging/hv/TODO
+++ b/drivers/staging/hv/TODO
@@ -1,14 +1,11 @@
 TODO:
-	- fix remaining checkpatch warnings and errors
 	- audit the vmbus to verify it is working properly with the
 	  driver model
-	- see if the vmbus can be merged with the other virtual busses
-	  in the kernel
 	- audit the network driver
 	  - checking for carrier inside open is wrong, network device API
             confusion??
-	- audit the block driver
 	- audit the scsi driver
 
 Please send patches for this code to Greg Kroah-Hartman <gregkh@suse.de>,
-Hank Janssen <hjanssen@microsoft.com>, and Haiyang Zhang <haiyangz@microsoft.com>.
+Hank Janssen <hjanssen@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>,
+K. Y. Srinivasan <kys@microsoft.com>
-- 
1.7.4.1

^ permalink raw reply related
* Re: Hyper-V TODO file
From: Greg KH @ 2011-09-02 16:03 UTC (permalink / raw)
  To: KY Srinivasan
  Cc: Peter Foley, gregkh@suse.de, Linux Kernel Mailing List,
	devel@linuxdriverproject.org, virtualization@lists.osdl.org
In-Reply-To: <6E21E5352C11B742B20C142EB499E048081B5FA3@TK5EX14MBXC126.redmond.corp.microsoft.com>

On Fri, Sep 02, 2011 at 03:17:19PM +0000, KY Srinivasan wrote:
> 
> 
> > -----Original Message-----
> > From: Greg KH [mailto:greg@kroah.com]
> > Sent: Thursday, September 01, 2011 4:31 PM
> > To: Peter Foley
> > Cc: KY Srinivasan; gregkh@suse.de; Linux Kernel Mailing List;
> > devel@linuxdriverproject.org; virtualization@lists.osdl.org
> > Subject: Re: Hyper-V TODO file
> > 
> > On Wed, Aug 31, 2011 at 07:11:39PM -0400, Peter Foley wrote:
> > > On Wed, 31 Aug 2011, K. Y. Srinivasan wrote:
> > > > Greg, as I have been pestering you for some time now, we are very
> > interested in
> > > > exiting staging and we are willing to dedicate the necessary development
> > > > resources to address whatever issues that may still be pending. So, your help
> > > > in identifying what needs to be done will be greatly appreciated. To that end,
> > > > I think it will be useful to update the TODO file to reflect the current state of
> > > > the drivers. Let us know how we should proceed here.
> > >
> > > An issue I've come across in the hyper-v drivers is the forced modular
> > > build. You might want to see if the "depends on m" is still needed.
> > 
> > Ah, good point, KY, can you try this out and see if that can be changed?
> > If not, something is wrong and that needs to get fixed.
> 
> Just verified that we can build into the kernel (not as modules) all hyper-V
> drivers except hv_storvsc. hv_storvsc depends upon functionality that in my build 
> is being built as modules (SCSI etc.) and this is the reason why I could not build
> hv_storvsc as part of the kernel.

So 'make allyesconfig' with the module dependancy turned off doesn't
break the build?  If so, great.

> Greg, do you want me to submit a patch to Kconfig, getting rid of the module
> dependency (for hyperv-v drivers).

Yes please.

thanks,

greg k-h

^ permalink raw reply
* Re: Hyper-V TODO file
From: Greg KH @ 2011-09-02 16:09 UTC (permalink / raw)
  To: K. Y. Srinivasan; +Cc: gregkh, linux-kernel, devel, virtualization
In-Reply-To: <20110901203031.GB15185@kroah.com>

On Thu, Sep 01, 2011 at 01:30:31PM -0700, Greg KH wrote:
> On Thu, Sep 01, 2011 at 01:27:33PM -0700, Greg KH wrote:
> > On Wed, Aug 31, 2011 at 03:16:51PM -0700, K. Y. Srinivasan wrote:
> > > 2) With your help, we have fixed all of the issues related to these drivers
> > > conforming to the Linux Device Driver model. One of the TODO work items is 
> > > "audit the vmbus to verify it is working properly with the driver model".
> > 
> > I have a few comments about this, I'll respond in another email.
> 
> Ok, it looks a _lot_ better, but I have a few minor nits, and one larger
> one:

Oh, here's another issue I forgot about.  You can get rid of the 'ext'
field of the hv_device structure and use the proper function in the
driver core for this type of thing, just wrap it up in your own function
to make it "sane" looking, like USB and PCI does with their
usb_get_intfdata(), usb_set_intfdata(), pci_get_drvdata(), and
pci_set_drvdata() functions.

thanks,

greg k-h

^ permalink raw reply
* [PATCH] Staging: hv: vmbus: Show the modalias in /sys/bus/vmbus/devices/*/
From: Olaf Hering @ 2011-09-02 16:25 UTC (permalink / raw)
  To: K. Y. Srinivasan; +Cc: gregkh, linux-kernel, devel, virtualization

Show a modalias file in /sys/bus/vmbus/devices/*/
Add a helper function to print the same content in modalias and uevent.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

---
 drivers/staging/hv/vmbus_drv.c |   21 ++++++++++++++++-----
 1 file changed, 16 insertions(+), 5 deletions(-)

--- a/drivers/staging/hv/vmbus_drv.c
+++ b/drivers/staging/hv/vmbus_drv.c
@@ -93,6 +93,14 @@ static void get_channel_info(struct hv_d
 		debug_info.outbound.bytes_avail_towrite;
 }
 
+#define VMBUS_ALIAS_LEN ((sizeof((struct hv_vmbus_device_id *)0)->guid) * 2)
+static void print_alias_name(struct hv_device *hv_dev, char *alias_name)
+{
+	int i;
+	for (i = 0; i < VMBUS_ALIAS_LEN; i += 2)
+		sprintf(&alias_name[i], "%02x", hv_dev->dev_type.b[i/2]);
+}
+
 /*
  * vmbus_show_device_attr - Show the device attribute in sysfs.
  *
@@ -105,6 +113,7 @@ static ssize_t vmbus_show_device_attr(st
 {
 	struct hv_device *hv_dev = device_to_hv_device(dev);
 	struct hv_device_info device_info;
+	char alias_name[VMBUS_ALIAS_LEN + 1];
 
 	memset(&device_info, 0, sizeof(struct hv_device_info));
 
@@ -148,6 +157,9 @@ static ssize_t vmbus_show_device_attr(st
 			       device_info.chn_instance.b[13],
 			       device_info.chn_instance.b[14],
 			       device_info.chn_instance.b[15]);
+	} else if (!strcmp(dev_attr->attr.name, "modalias")) {
+		print_alias_name(hv_dev, alias_name);
+		return sprintf(buf, "vmbus:%s\n", alias_name);
 	} else if (!strcmp(dev_attr->attr.name, "state")) {
 		return sprintf(buf, "%d\n", device_info.chn_state);
 	} else if (!strcmp(dev_attr->attr.name, "id")) {
@@ -204,6 +216,7 @@ static struct device_attribute vmbus_dev
 	__ATTR(class_id, S_IRUGO, vmbus_show_device_attr, NULL),
 	__ATTR(device_id, S_IRUGO, vmbus_show_device_attr, NULL),
 	__ATTR(monitor_id, S_IRUGO, vmbus_show_device_attr, NULL),
+	__ATTR(modalias, S_IRUGO, vmbus_show_device_attr, NULL),
 
 	__ATTR(server_monitor_pending, S_IRUGO, vmbus_show_device_attr, NULL),
 	__ATTR(server_monitor_latency, S_IRUGO, vmbus_show_device_attr, NULL),
@@ -242,12 +255,10 @@ static struct device_attribute vmbus_dev
 static int vmbus_uevent(struct device *device, struct kobj_uevent_env *env)
 {
 	struct hv_device *dev = device_to_hv_device(device);
-	int i, ret;
-	char alias_name[((sizeof((struct hv_vmbus_device_id *)0)->guid) + 1) * 2];
-
-	for (i = 0; i < ((sizeof((struct hv_vmbus_device_id *)0)->guid) * 2); i += 2)
-		sprintf(&alias_name[i], "%02x", dev->dev_type.b[i/2]);
+	int ret;
+	char alias_name[VMBUS_ALIAS_LEN + 1];
 
+	print_alias_name(dev, alias_name);
 	ret = add_uevent_var(env, "MODALIAS=vmbus:%s", alias_name);
 	return ret;
 }

^ permalink raw reply
* Re: [PATCH] Staging: hv: vmbus: Show the modalias in /sys/bus/vmbus/devices/*/
From: Greg KH @ 2011-09-02 16:35 UTC (permalink / raw)
  To: Olaf Hering; +Cc: K. Y. Srinivasan, linux-kernel, devel, virtualization
In-Reply-To: <20110902162556.GA25073@aepfle.de>

On Fri, Sep 02, 2011 at 06:25:56PM +0200, Olaf Hering wrote:
> Show a modalias file in /sys/bus/vmbus/devices/*/
> Add a helper function to print the same content in modalias and uevent.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>

Nice idea, thanks for this, one minor nit below:

> ---
>  drivers/staging/hv/vmbus_drv.c |   21 ++++++++++++++++-----
>  1 file changed, 16 insertions(+), 5 deletions(-)
> 
> --- a/drivers/staging/hv/vmbus_drv.c
> +++ b/drivers/staging/hv/vmbus_drv.c
> @@ -93,6 +93,14 @@ static void get_channel_info(struct hv_d
>  		debug_info.outbound.bytes_avail_towrite;
>  }
>  
> +#define VMBUS_ALIAS_LEN ((sizeof((struct hv_vmbus_device_id *)0)->guid) * 2)
> +static void print_alias_name(struct hv_device *hv_dev, char *alias_name)
> +{
> +	int i;
> +	for (i = 0; i < VMBUS_ALIAS_LEN; i += 2)
> +		sprintf(&alias_name[i], "%02x", hv_dev->dev_type.b[i/2]);
> +}
> +
>  /*
>   * vmbus_show_device_attr - Show the device attribute in sysfs.
>   *
> @@ -105,6 +113,7 @@ static ssize_t vmbus_show_device_attr(st
>  {
>  	struct hv_device *hv_dev = device_to_hv_device(dev);
>  	struct hv_device_info device_info;
> +	char alias_name[VMBUS_ALIAS_LEN + 1];

Is that too big to put on the stack?  64 bytes, right?  Hm, maybe not.

Wait, hv_device_info is huge, that should be dynamic in the first place.
Olaf, not your issue, but KY, want to fix that up?

thanks,

greg k-h

^ permalink raw reply
* Re: [PATCH] Staging: hv: vmbus: Show the modalias in /sys/bus/vmbus/devices/*/
From: Olaf Hering @ 2011-09-02 16:38 UTC (permalink / raw)
  To: Greg KH; +Cc: K. Y. Srinivasan, linux-kernel, devel, virtualization
In-Reply-To: <20110902163550.GA5508@suse.de>

On Fri, Sep 02, Greg KH wrote:

> On Fri, Sep 02, 2011 at 06:25:56PM +0200, Olaf Hering wrote:

> > +#define VMBUS_ALIAS_LEN ((sizeof((struct hv_vmbus_device_id *)0)->guid) * 2)

> > +	char alias_name[VMBUS_ALIAS_LEN + 1];
> 
> Is that too big to put on the stack?  64 bytes, right?  Hm, maybe not.

16 * 2 + 1 = 33 bytes.

Olaf

^ permalink raw reply
* RE: [PATCH] Staging: hv: vmbus: Show the modalias in /sys/bus/vmbus/devices/*/
From: KY Srinivasan @ 2011-09-02 17:50 UTC (permalink / raw)
  To: Olaf Hering
  Cc: gregkh@suse.de, linux-kernel@vger.kernel.org,
	devel@linuxdriverproject.org, virtualization@lists.osdl.org
In-Reply-To: <20110902162556.GA25073@aepfle.de>



> -----Original Message-----
> From: Olaf Hering [mailto:olaf@aepfle.de]
> Sent: Friday, September 02, 2011 12:26 PM
> To: KY Srinivasan
> Cc: gregkh@suse.de; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; virtualization@lists.osdl.org
> Subject: [PATCH] Staging: hv: vmbus: Show the modalias in
> /sys/bus/vmbus/devices/*/
> 
> Show a modalias file in /sys/bus/vmbus/devices/*/
> Add a helper function to print the same content in modalias and uevent.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> ---
>  drivers/staging/hv/vmbus_drv.c |   21 ++++++++++++++++-----
>  1 file changed, 16 insertions(+), 5 deletions(-)
> 
> --- a/drivers/staging/hv/vmbus_drv.c
> +++ b/drivers/staging/hv/vmbus_drv.c
> @@ -93,6 +93,14 @@ static void get_channel_info(struct hv_d
>  		debug_info.outbound.bytes_avail_towrite;
>  }
> 
> +#define VMBUS_ALIAS_LEN ((sizeof((struct hv_vmbus_device_id *)0)->guid) *
> 2)
> +static void print_alias_name(struct hv_device *hv_dev, char *alias_name)
> +{
> +	int i;
> +	for (i = 0; i < VMBUS_ALIAS_LEN; i += 2)
> +		sprintf(&alias_name[i], "%02x", hv_dev->dev_type.b[i/2]);
> +}
> +
>  /*
>   * vmbus_show_device_attr - Show the device attribute in sysfs.
>   *
> @@ -105,6 +113,7 @@ static ssize_t vmbus_show_device_attr(st
>  {
>  	struct hv_device *hv_dev = device_to_hv_device(dev);
>  	struct hv_device_info device_info;
> +	char alias_name[VMBUS_ALIAS_LEN + 1];
> 
>  	memset(&device_info, 0, sizeof(struct hv_device_info));
> 
> @@ -148,6 +157,9 @@ static ssize_t vmbus_show_device_attr(st
>  			       device_info.chn_instance.b[13],
>  			       device_info.chn_instance.b[14],
>  			       device_info.chn_instance.b[15]);
> +	} else if (!strcmp(dev_attr->attr.name, "modalias")) {
> +		print_alias_name(hv_dev, alias_name);
> +		return sprintf(buf, "vmbus:%s\n", alias_name);
>  	} else if (!strcmp(dev_attr->attr.name, "state")) {
>  		return sprintf(buf, "%d\n", device_info.chn_state);
>  	} else if (!strcmp(dev_attr->attr.name, "id")) {
> @@ -204,6 +216,7 @@ static struct device_attribute vmbus_dev
>  	__ATTR(class_id, S_IRUGO, vmbus_show_device_attr, NULL),
>  	__ATTR(device_id, S_IRUGO, vmbus_show_device_attr, NULL),
>  	__ATTR(monitor_id, S_IRUGO, vmbus_show_device_attr, NULL),
> +	__ATTR(modalias, S_IRUGO, vmbus_show_device_attr, NULL),
> 
>  	__ATTR(server_monitor_pending, S_IRUGO, vmbus_show_device_attr,
> NULL),
>  	__ATTR(server_monitor_latency, S_IRUGO, vmbus_show_device_attr,
> NULL),
> @@ -242,12 +255,10 @@ static struct device_attribute vmbus_dev
>  static int vmbus_uevent(struct device *device, struct kobj_uevent_env *env)
>  {
>  	struct hv_device *dev = device_to_hv_device(device);
> -	int i, ret;
> -	char alias_name[((sizeof((struct hv_vmbus_device_id *)0)->guid) + 1) *
> 2];
> -
> -	for (i = 0; i < ((sizeof((struct hv_vmbus_device_id *)0)->guid) * 2); i += 2)
> -		sprintf(&alias_name[i], "%02x", dev->dev_type.b[i/2]);
> +	int ret;
> +	char alias_name[VMBUS_ALIAS_LEN + 1];
> 
> +	print_alias_name(dev, alias_name);
>  	ret = add_uevent_var(env, "MODALIAS=vmbus:%s", alias_name);
>  	return ret;
>  }

Acked-by:  K. Y. Srinivasan <kys@microsoft.com>



^ permalink raw reply
* RE: [PATCH] Staging: hv: vmbus: Show the modalias in /sys/bus/vmbus/devices/*/
From: KY Srinivasan @ 2011-09-02 17:53 UTC (permalink / raw)
  To: Greg KH, Olaf Hering
  Cc: linux-kernel@vger.kernel.org, devel@linuxdriverproject.org,
	virtualization@lists.osdl.org
In-Reply-To: <20110902163550.GA5508@suse.de>



> -----Original Message-----
> From: Greg KH [mailto:gregkh@suse.de]
> Sent: Friday, September 02, 2011 12:36 PM
> To: Olaf Hering
> Cc: KY Srinivasan; linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> virtualization@lists.osdl.org
> Subject: Re: [PATCH] Staging: hv: vmbus: Show the modalias in
> /sys/bus/vmbus/devices/*/
> 
> On Fri, Sep 02, 2011 at 06:25:56PM +0200, Olaf Hering wrote:
> > Show a modalias file in /sys/bus/vmbus/devices/*/
> > Add a helper function to print the same content in modalias and uevent.
> >
> > Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> Nice idea, thanks for this, one minor nit below:
> 
> > ---
> >  drivers/staging/hv/vmbus_drv.c |   21 ++++++++++++++++-----
> >  1 file changed, 16 insertions(+), 5 deletions(-)
> >
> > --- a/drivers/staging/hv/vmbus_drv.c
> > +++ b/drivers/staging/hv/vmbus_drv.c
> > @@ -93,6 +93,14 @@ static void get_channel_info(struct hv_d
> >  		debug_info.outbound.bytes_avail_towrite;
> >  }
> >
> > +#define VMBUS_ALIAS_LEN ((sizeof((struct hv_vmbus_device_id *)0)->guid)
> * 2)
> > +static void print_alias_name(struct hv_device *hv_dev, char *alias_name)
> > +{
> > +	int i;
> > +	for (i = 0; i < VMBUS_ALIAS_LEN; i += 2)
> > +		sprintf(&alias_name[i], "%02x", hv_dev->dev_type.b[i/2]);
> > +}
> > +
> >  /*
> >   * vmbus_show_device_attr - Show the device attribute in sysfs.
> >   *
> > @@ -105,6 +113,7 @@ static ssize_t vmbus_show_device_attr(st
> >  {
> >  	struct hv_device *hv_dev = device_to_hv_device(dev);
> >  	struct hv_device_info device_info;
> > +	char alias_name[VMBUS_ALIAS_LEN + 1];
> 
> Is that too big to put on the stack?  64 bytes, right?  Hm, maybe not.
> 
> Wait, hv_device_info is huge, that should be dynamic in the first place.
> Olaf, not your issue, but KY, want to fix that up?

hv_device_info is about 101 bytes. I will fix this. Greg, if you are applying Olaf's patch,
I will generate my patch on top of Olaf's. Let me know.

Regards,

K. Y

^ permalink raw reply
* Re: [PATCH] Staging: hv: vmbus: Show the modalias in /sys/bus/vmbus/devices/*/
From: Greg KH @ 2011-09-02 18:12 UTC (permalink / raw)
  To: KY Srinivasan
  Cc: devel@linuxdriverproject.org, Olaf Hering,
	linux-kernel@vger.kernel.org, virtualization@lists.osdl.org
In-Reply-To: <6E21E5352C11B742B20C142EB499E048081B605D@TK5EX14MBXC126.redmond.corp.microsoft.com>

On Fri, Sep 02, 2011 at 05:53:37PM +0000, KY Srinivasan wrote:
> 
> 
> > -----Original Message-----
> > From: Greg KH [mailto:gregkh@suse.de]
> > Sent: Friday, September 02, 2011 12:36 PM
> > To: Olaf Hering
> > Cc: KY Srinivasan; linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> > virtualization@lists.osdl.org
> > Subject: Re: [PATCH] Staging: hv: vmbus: Show the modalias in
> > /sys/bus/vmbus/devices/*/
> > 
> > On Fri, Sep 02, 2011 at 06:25:56PM +0200, Olaf Hering wrote:
> > > Show a modalias file in /sys/bus/vmbus/devices/*/
> > > Add a helper function to print the same content in modalias and uevent.
> > >
> > > Signed-off-by: Olaf Hering <olaf@aepfle.de>
> > 
> > Nice idea, thanks for this, one minor nit below:
> > 
> > > ---
> > >  drivers/staging/hv/vmbus_drv.c |   21 ++++++++++++++++-----
> > >  1 file changed, 16 insertions(+), 5 deletions(-)
> > >
> > > --- a/drivers/staging/hv/vmbus_drv.c
> > > +++ b/drivers/staging/hv/vmbus_drv.c
> > > @@ -93,6 +93,14 @@ static void get_channel_info(struct hv_d
> > >  		debug_info.outbound.bytes_avail_towrite;
> > >  }
> > >
> > > +#define VMBUS_ALIAS_LEN ((sizeof((struct hv_vmbus_device_id *)0)->guid)
> > * 2)
> > > +static void print_alias_name(struct hv_device *hv_dev, char *alias_name)
> > > +{
> > > +	int i;
> > > +	for (i = 0; i < VMBUS_ALIAS_LEN; i += 2)
> > > +		sprintf(&alias_name[i], "%02x", hv_dev->dev_type.b[i/2]);
> > > +}
> > > +
> > >  /*
> > >   * vmbus_show_device_attr - Show the device attribute in sysfs.
> > >   *
> > > @@ -105,6 +113,7 @@ static ssize_t vmbus_show_device_attr(st
> > >  {
> > >  	struct hv_device *hv_dev = device_to_hv_device(dev);
> > >  	struct hv_device_info device_info;
> > > +	char alias_name[VMBUS_ALIAS_LEN + 1];
> > 
> > Is that too big to put on the stack?  64 bytes, right?  Hm, maybe not.
> > 
> > Wait, hv_device_info is huge, that should be dynamic in the first place.
> > Olaf, not your issue, but KY, want to fix that up?
> 
> hv_device_info is about 101 bytes. I will fix this. Greg, if you are applying Olaf's patch,
> I will generate my patch on top of Olaf's. Let me know.

I'll take his, and then feel free to send me one on top of that fixing
this.

But again, as kernel.org is still down, I can't apply anything until
next week at the earliest, sorry.

greg k-h

^ permalink raw reply
* RE: Hyper-V TODO file
From: KY Srinivasan @ 2011-09-02 19:47 UTC (permalink / raw)
  To: Greg KH
  Cc: gregkh@suse.de, linux-kernel@vger.kernel.org,
	devel@linuxdriverproject.org, virtualization@lists.osdl.org
In-Reply-To: <20110901203031.GB15185@kroah.com>



> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Thursday, September 01, 2011 4:31 PM
> To: KY Srinivasan
> Cc: gregkh@suse.de; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; virtualization@lists.osdl.org
> Subject: Re: Hyper-V TODO file
> 
> On Thu, Sep 01, 2011 at 01:27:33PM -0700, Greg KH wrote:
> > On Wed, Aug 31, 2011 at 03:16:51PM -0700, K. Y. Srinivasan wrote:
> > > 2) With your help, we have fixed all of the issues related to these drivers
> > > conforming to the Linux Device Driver model. One of the TODO work items is
> > > "audit the vmbus to verify it is working properly with the driver model".
> >
> > I have a few comments about this, I'll respond in another email.
> 
> Ok, it looks a _lot_ better, but I have a few minor nits, and one larger
> one:
> 
> - rename the vmbus_child_* functions to vmbus_* as there's no need to
>   think of "children" here.
> 
> - vmbus_onoffer comment is incorrect.  You handle offers from lots of
>   other types.  Or if not, am I reading the code incorrectly?
> 
> - the static hv_cb_utils array needs to go away.  In the hv_utils.c
>   util_probe() call, properly register the channel callback, and the
>   same goes for the util_remove() call, unregister things there.
>   Note, you can use the driver_data field to determine exactly which
>   callback needs to be registered to make things easy.  Something like
>   the following (pseudo code only):
> 
> static const struct hv_vmbus_device_id id_table[] = {
> 	/* Shutdown guid */
> 	{ VMBUS_DEVICE(0x31, 0x60, 0x0B, 0X0E, 0x13, 0x52, 0x34, 0x49,
> 		       0x81, 0x8B, 0x38, 0XD9, 0x0C, 0xED, 0x39, 0xDB),
> 	  .driver_data = &shutdown_onchannelcallback },
> 	....
> };
> 
> util_probe(struct hv_device *dev, const struct hv_vmbus_device_id *id)
>  [ Yes, you will have to change the probe callback signature, but that's fine. ]

Greg, I think if I understand you correctly, the id parameter to the probe function
would be pointing to relevant entry in the hv_vmbus_device_id array. Since the driver
can handle multiple ids (guids), we need to either in the driver specific probe function or
in the bus specific probe function,  figure out which of the many devices the driver
supports is being probed. I have couple of implementation options and would appreciate 
your preference:

1) Do the guid parsing at the vmbus level parsing function. If I go this route, the driver specific probe
function would get an extra parameter as you have described in pseudo code.

2) Do the guid parsing in the util probe function. In this case, we don't need to change the signature for
the probe function as all the id information is available in the (util) driver. 

I personally would prefer the second approach since it does not affect other drivers (no need to change
the signature for the probe function). Let me know how you want me to proceed here.

Regards,

K. Y

^ permalink raw reply
* Re: Hyper-V TODO file
From: Greg KH @ 2011-09-02 19:58 UTC (permalink / raw)
  To: KY Srinivasan
  Cc: gregkh@suse.de, linux-kernel@vger.kernel.org,
	devel@linuxdriverproject.org, virtualization@lists.osdl.org
In-Reply-To: <6E21E5352C11B742B20C142EB499E048081C595A@TK5EX14MBXC126.redmond.corp.microsoft.com>

On Fri, Sep 02, 2011 at 07:47:12PM +0000, KY Srinivasan wrote:
> 
> 
> > -----Original Message-----
> > From: Greg KH [mailto:greg@kroah.com]
> > Sent: Thursday, September 01, 2011 4:31 PM
> > To: KY Srinivasan
> > Cc: gregkh@suse.de; linux-kernel@vger.kernel.org;
> > devel@linuxdriverproject.org; virtualization@lists.osdl.org
> > Subject: Re: Hyper-V TODO file
> > 
> > On Thu, Sep 01, 2011 at 01:27:33PM -0700, Greg KH wrote:
> > > On Wed, Aug 31, 2011 at 03:16:51PM -0700, K. Y. Srinivasan wrote:
> > > > 2) With your help, we have fixed all of the issues related to these drivers
> > > > conforming to the Linux Device Driver model. One of the TODO work items is
> > > > "audit the vmbus to verify it is working properly with the driver model".
> > >
> > > I have a few comments about this, I'll respond in another email.
> > 
> > Ok, it looks a _lot_ better, but I have a few minor nits, and one larger
> > one:
> > 
> > - rename the vmbus_child_* functions to vmbus_* as there's no need to
> >   think of "children" here.
> > 
> > - vmbus_onoffer comment is incorrect.  You handle offers from lots of
> >   other types.  Or if not, am I reading the code incorrectly?
> > 
> > - the static hv_cb_utils array needs to go away.  In the hv_utils.c
> >   util_probe() call, properly register the channel callback, and the
> >   same goes for the util_remove() call, unregister things there.
> >   Note, you can use the driver_data field to determine exactly which
> >   callback needs to be registered to make things easy.  Something like
> >   the following (pseudo code only):
> > 
> > static const struct hv_vmbus_device_id id_table[] = {
> > 	/* Shutdown guid */
> > 	{ VMBUS_DEVICE(0x31, 0x60, 0x0B, 0X0E, 0x13, 0x52, 0x34, 0x49,
> > 		       0x81, 0x8B, 0x38, 0XD9, 0x0C, 0xED, 0x39, 0xDB),
> > 	  .driver_data = &shutdown_onchannelcallback },
> > 	....
> > };
> > 
> > util_probe(struct hv_device *dev, const struct hv_vmbus_device_id *id)
> >  [ Yes, you will have to change the probe callback signature, but that's fine. ]
> 
> Greg, I think if I understand you correctly, the id parameter to the probe function
> would be pointing to relevant entry in the hv_vmbus_device_id array.

Yes, just like it does for USB, PCI, etc.

> Since the driver can handle multiple ids (guids), we need to either in
> the driver specific probe function or in the bus specific probe
> function,  figure out which of the many devices the driver supports is
> being probed. I have couple of implementation options and would
> appreciate your preference:
> 
> 1) Do the guid parsing at the vmbus level parsing function. If I go
> this route, the driver specific probe function would get an extra
> parameter as you have described in pseudo code.

Yes, that's the proper way to do this, as your match function already
found the proper id structure, so you have the pointer, just pass it to
the probe function callback.

> 2) Do the guid parsing in the util probe function. In this case, we
> don't need to change the signature for the probe function as all the
> id information is available in the (util) driver. 

Yes, but you end up doing the matching all over again in the util
driver, which isn't nice and ripe for duplication and bugs.

> I personally would prefer the second approach since it does not affect
> other drivers (no need to change the signature for the probe
> function). Let me know how you want me to proceed here.

As you only have 3 probe functions, it's not a big deal to change them
all :)

thanks,

greg k-h

^ permalink raw reply
* RE: Hyper-V TODO file
From: KY Srinivasan @ 2011-09-02 20:54 UTC (permalink / raw)
  To: Greg KH
  Cc: gregkh@suse.de, linux-kernel@vger.kernel.org,
	devel@linuxdriverproject.org, virtualization@lists.osdl.org
In-Reply-To: <20110902195807.GA2339@kroah.com>



> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Friday, September 02, 2011 3:58 PM
> To: KY Srinivasan
> Cc: gregkh@suse.de; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; virtualization@lists.osdl.org
> Subject: Re: Hyper-V TODO file
> 
> On Fri, Sep 02, 2011 at 07:47:12PM +0000, KY Srinivasan wrote:
> >
> >
> > > -----Original Message-----
> > > From: Greg KH [mailto:greg@kroah.com]
> > > Sent: Thursday, September 01, 2011 4:31 PM
> > > To: KY Srinivasan
> > > Cc: gregkh@suse.de; linux-kernel@vger.kernel.org;
> > > devel@linuxdriverproject.org; virtualization@lists.osdl.org
> > > Subject: Re: Hyper-V TODO file
> > >
> > > On Thu, Sep 01, 2011 at 01:27:33PM -0700, Greg KH wrote:
> > > > On Wed, Aug 31, 2011 at 03:16:51PM -0700, K. Y. Srinivasan wrote:
> > > > > 2) With your help, we have fixed all of the issues related to these drivers
> > > > > conforming to the Linux Device Driver model. One of the TODO work
> items is
> > > > > "audit the vmbus to verify it is working properly with the driver model".
> > > >
> > > > I have a few comments about this, I'll respond in another email.
> > >
> > > Ok, it looks a _lot_ better, but I have a few minor nits, and one larger
> > > one:
> > >
> > > - rename the vmbus_child_* functions to vmbus_* as there's no need to
> > >   think of "children" here.
> > >
> > > - vmbus_onoffer comment is incorrect.  You handle offers from lots of
> > >   other types.  Or if not, am I reading the code incorrectly?
> > >
> > > - the static hv_cb_utils array needs to go away.  In the hv_utils.c
> > >   util_probe() call, properly register the channel callback, and the
> > >   same goes for the util_remove() call, unregister things there.
> > >   Note, you can use the driver_data field to determine exactly which
> > >   callback needs to be registered to make things easy.  Something like
> > >   the following (pseudo code only):
> > >
> > > static const struct hv_vmbus_device_id id_table[] = {
> > > 	/* Shutdown guid */
> > > 	{ VMBUS_DEVICE(0x31, 0x60, 0x0B, 0X0E, 0x13, 0x52, 0x34, 0x49,
> > > 		       0x81, 0x8B, 0x38, 0XD9, 0x0C, 0xED, 0x39, 0xDB),
> > > 	  .driver_data = &shutdown_onchannelcallback },
> > > 	....
> > > };
> > >
> > > util_probe(struct hv_device *dev, const struct hv_vmbus_device_id *id)
> > >  [ Yes, you will have to change the probe callback signature, but that's fine. ]
> >
> > Greg, I think if I understand you correctly, the id parameter to the probe
> function
> > would be pointing to relevant entry in the hv_vmbus_device_id array.
> 
> Yes, just like it does for USB, PCI, etc.
> 
> > Since the driver can handle multiple ids (guids), we need to either in
> > the driver specific probe function or in the bus specific probe
> > function,  figure out which of the many devices the driver supports is
> > being probed. I have couple of implementation options and would
> > appreciate your preference:
> >
> > 1) Do the guid parsing at the vmbus level parsing function. If I go
> > this route, the driver specific probe function would get an extra
> > parameter as you have described in pseudo code.
> 
> Yes, that's the proper way to do this, as your match function already
> found the proper id structure, so you have the pointer, just pass it to
> the probe function callback.
> 
> > 2) Do the guid parsing in the util probe function. In this case, we
> > don't need to change the signature for the probe function as all the
> > id information is available in the (util) driver.
> 
> Yes, but you end up doing the matching all over again in the util
> driver, which isn't nice and ripe for duplication and bugs.
> 
> > I personally would prefer the second approach since it does not affect
> > other drivers (no need to change the signature for the probe
> > function). Let me know how you want me to proceed here.
> 
> As you only have 3 probe functions, it's not a big deal to change them
> all :)

Ok; will do. I am glad I checked with you!

Regards,

K. Y

^ permalink raw reply
* ACM MTAGS 2011: deadline extension to September 26th
From: Ioan Raicu @ 2011-09-05 17:41 UTC (permalink / raw)
  To: virtualization


[-- Attachment #1.1: Type: text/plain, Size: 2226 bytes --]

CALL FOR PAPERS
4th Workshop on Many-Task Computing on Grids and Supercomputers (MTAGS) 2011

http://datasys.cs.iit.edu/events/MTAGS11/index.html
http://sc11.supercomputing.org/schedule/event_detail.php?evid=wksp122

***DEADLINE EXTENSION -- September 26th, 2011*

The 4th workshop on Many-Task Computing on Grids and Supercomputers 
(MTAGS11) will provide the scientific community a dedicated forum for 
presenting new research, development, and deployment efforts of 
large-scale many-task computing (MTC) applications on large scale 
clusters, Grids, Supercomputers, and Cloud Computing infrastructure. 
MTC, the theme of the workshop encompasses loosely coupled applications, 
which are generally composed of many tasks (both independent and 
dependent tasks) to achieve some larger application goal. This workshop 
will cover challenges that can hamper efficiency and utilization in 
running applications on large-scale systems, such as local resource 
manager scalability and granularity, efficient utilization of raw 
hardware, parallel file system contention and scalability, data 
management, I/O management, reliability at scale, and application 
scalability.

*General Chairs (mtags11-chairs@datasys.cs.iit.edu 
<mailto:mtags11-chairs@datasys.cs.iit.edu>)*

  * Ioan Raicu, Illinois Institute of Technology & Argonne National
    Laboratory, USA
  * Ian Foster, University of Chicago & Argonne National Laboratory, USA
  * Yong Zhao, University of Electronic Science and Technology of China,
    China

-- 
=================================================================
Ioan Raicu, Ph.D.
Assistant Professor, Illinois Institute of Technology (IIT)
Guest Research Faculty, Argonne National Laboratory (ANL)
=================================================================
Data-Intensive Distributed Systems Laboratory, CS/IIT
Distributed Systems Laboratory, MCS/ANL
=================================================================
Cel:    1-847-722-0876
Office: 1-312-567-5704
Email:  iraicu@cs.iit.edu
Web:    http://www.cs.iit.edu/~iraicu/
Web:    http://datasys.cs.iit.edu/
=================================================================
=================================================================



[-- Attachment #1.2: Type: text/html, Size: 3319 bytes --]

[-- Attachment #2: Type: text/plain, Size: 184 bytes --]

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

^ permalink raw reply
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox