Hyper-V TODO file

Hyper-V TODO file

[K. Y. Srinivasan]

Greg,

With your last checkin of the patches for Hyper-V, I have addressed all of 
the issues you had raised as part of the vmbus audit. Should I send you a 
patch to update the TODO file to reflect this. Let me know.


Regards,

K. Y

Re: Hyper-V TODO file

[Joe Perches]

On Thu, 2011-09-22 at 09:17 -0700, K. Y. Srinivasan wrote:
> With your last checkin of the patches for Hyper-V, I have addressed all of 
> the issues you had raised as part of the vmbus audit. Should I send you a 
> patch to update the TODO file to reflect this. Let me know.

Is there really anything left to do but send
the patch that moves hv out of staging?

Re: Hyper-V TODO file

[Greg KH]

On Thu, Sep 22, 2011 at 09:17:20AM -0700, K. Y. Srinivasan wrote:
> 
> Greg,
> 
> With your last checkin of the patches for Hyper-V, I have addressed all of 
> the issues you had raised as part of the vmbus audit. Should I send you a 
> patch to update the TODO file to reflect this. Let me know.

Yes, please send patches.

RE: Hyper-V TODO file

[KY Srinivasan]

> -----Original Message-----
> From: Greg KH [mailto:gregkh@suse.de]
> Sent: Thursday, September 22, 2011 1:05 PM
> To: KY Srinivasan
> Cc: linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> virtualization@lists.osdl.org
> Subject: Re: Hyper-V TODO file
> 
> On Thu, Sep 22, 2011 at 09:17:20AM -0700, K. Y. Srinivasan wrote:
> >
> > Greg,
> >
> > With your last checkin of the patches for Hyper-V, I have addressed all of
> > the issues you had raised as part of the vmbus audit. Should I send you a
> > patch to update the TODO file to reflect this. Let me know.
> 
> Yes, please send patches.

Thanks Greg. In addition to the patch to update the TODO file, do you want me to
send you patches for moving the vmbus and util driver out of staging as well.

Regards,

K. Y

Re: Hyper-V TODO file

[Greg KH]

On Thu, Sep 22, 2011 at 05:20:59PM +0000, KY Srinivasan wrote:
> 
> 
> > -----Original Message-----
> > From: Greg KH [mailto:gregkh@suse.de]
> > Sent: Thursday, September 22, 2011 1:05 PM
> > To: KY Srinivasan
> > Cc: linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> > virtualization@lists.osdl.org
> > Subject: Re: Hyper-V TODO file
> > 
> > On Thu, Sep 22, 2011 at 09:17:20AM -0700, K. Y. Srinivasan wrote:
> > >
> > > Greg,
> > >
> > > With your last checkin of the patches for Hyper-V, I have addressed all of
> > > the issues you had raised as part of the vmbus audit. Should I send you a
> > > patch to update the TODO file to reflect this. Let me know.
> > 
> > Yes, please send patches.
> 
> Thanks Greg. In addition to the patch to update the TODO file, do you want me to
> send you patches for moving the vmbus and util driver out of staging as well.

No, I'll do that if we agree that it is ready to do so.

thanks,

greg k-h

RE: Hyper-V TODO file

[KY Srinivasan]

> -----Original Message-----
> From: Greg KH [mailto:gregkh@suse.de]
> Sent: Thursday, September 22, 2011 1:36 PM
> To: KY Srinivasan
> Cc: linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> virtualization@lists.osdl.org
> Subject: Re: Hyper-V TODO file
> 
> On Thu, Sep 22, 2011 at 05:20:59PM +0000, KY Srinivasan wrote:
> >
> >
> > > -----Original Message-----
> > > From: Greg KH [mailto:gregkh@suse.de]
> > > Sent: Thursday, September 22, 2011 1:05 PM
> > > To: KY Srinivasan
> > > Cc: linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> > > virtualization@lists.osdl.org
> > > Subject: Re: Hyper-V TODO file
> > >
> > > On Thu, Sep 22, 2011 at 09:17:20AM -0700, K. Y. Srinivasan wrote:
> > > >
> > > > Greg,
> > > >
> > > > With your last checkin of the patches for Hyper-V, I have addressed all of
> > > > the issues you had raised as part of the vmbus audit. Should I send you a
> > > > patch to update the TODO file to reflect this. Let me know.
> > >
> > > Yes, please send patches.
> >
> > Thanks Greg. In addition to the patch to update the TODO file, do you want me
> to
> > send you patches for moving the vmbus and util driver out of staging as well.
> 
> No, I'll do that if we agree that it is ready to do so.

Fair enough! When you said earlier  " Yes, please send patches", I naturally assumed that you
meant more than a single patch required to update the TODO file. I must admit that  there was also
a good measure of wishful thinking on my part as well! 

Regards,

K. Y

RE: Hyper-V TODO file

[KY Srinivasan]

> -----Original Message-----
> From: Greg KH [mailto:gregkh@suse.de]
> Sent: Thursday, September 22, 2011 1:36 PM
> To: KY Srinivasan
> Cc: linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> virtualization@lists.osdl.org
> Subject: Re: Hyper-V TODO file
> 
> On Thu, Sep 22, 2011 at 05:20:59PM +0000, KY Srinivasan wrote:
> >
> >
> > > -----Original Message-----
> > > From: Greg KH [mailto:gregkh@suse.de]
> > > Sent: Thursday, September 22, 2011 1:05 PM
> > > To: KY Srinivasan
> > > Cc: linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> > > virtualization@lists.osdl.org
> > > Subject: Re: Hyper-V TODO file
> > >
> > > On Thu, Sep 22, 2011 at 09:17:20AM -0700, K. Y. Srinivasan wrote:
> > > >
> > > > Greg,
> > > >
> > > > With your last checkin of the patches for Hyper-V, I have addressed all of
> > > > the issues you had raised as part of the vmbus audit. Should I send you a
> > > > patch to update the TODO file to reflect this. Let me know.
> > >
> > > Yes, please send patches.
> >
> > Thanks Greg. In addition to the patch to update the TODO file, do you want me
> to
> > send you patches for moving the vmbus and util driver out of staging as well.
> 
> No, I'll do that if we agree that it is ready to do so.

Greg, sometime back you checked in the changes to the TODO file reflecting
that there are no outstanding vmbus related issues. What is the process now
for getting the vmbus (and util) drivers out of staging. Let me know if there is 
something I can do to help this along.  As you know, we had posted the network 
driver for public review a while ago (several months ago) and we have addressed 
all the review comments we got. Any guidance on what we should do next would be
greatly appreciated.

Regards,

K. Y

Re: Hyper-V TODO file

[Greg KH]

On Tue, Oct 04, 2011 at 01:59:56PM +0000, KY Srinivasan wrote:
> Greg, sometime back you checked in the changes to the TODO file reflecting
> that there are no outstanding vmbus related issues. What is the process now
> for getting the vmbus (and util) drivers out of staging. Let me know if there is 
> something I can do to help this along.  As you know, we had posted the network 
> driver for public review a while ago (several months ago) and we have addressed 
> all the review comments we got. Any guidance on what we should do next would be
> greatly appreciated.

At this point in time, just ask me, and I will move the files.

So, to confirm, you want to have the following files moved to
drivers/hv/:
	drivers/staging/hv/Kconfig (part of this file)
	drivers/staging/hv/Makefile (part of this file)
	drivers/staging/hv/vmbus_drv.c
	drivers/staging/hv/hv.c
	drivers/staging/hv/connection.c
	drivers/staging/hv/channel.c
	drivers/staging/hv/channel_mgmt.c
	drivers/staging/hv/ring_buffer.c
	drivers/staging/hv/hv_util.c
	drivers/staging/hv/hv_kmp.c
	drivers/staging/hv/hv_kvp.h
	drivers/staging/hv/hyperv_vmbus.h

The following file moved to include/linux/:
	drivers/staging/hv/hyperv.h
(I think there is stuff in there that can go into hyperv_vmbus.h as it's
not needed in the "global" directory, but I can do that movement.)

The following file moved to tools/hv/:
	drivers/staging/hv/tools/*

And the following files modified to tie drivers/hv/ into the build service:
	drivers/Makefile
	drivers/Kconfig

Is all of that correct?

thanks,

greg k-h

RE: Hyper-V TODO file

[KY Srinivasan]

> -----Original Message-----
> From: Greg KH [mailto:gregkh@suse.de]
> Sent: Tuesday, October 04, 2011 1:04 PM
> To: KY Srinivasan
> Cc: linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> virtualization@lists.osdl.org
> Subject: Re: Hyper-V TODO file
> 
> On Tue, Oct 04, 2011 at 01:59:56PM +0000, KY Srinivasan wrote:
> > Greg, sometime back you checked in the changes to the TODO file reflecting
> > that there are no outstanding vmbus related issues. What is the process now
> > for getting the vmbus (and util) drivers out of staging. Let me know if there is
> > something I can do to help this along.  As you know, we had posted the
> network
> > driver for public review a while ago (several months ago) and we have
> addressed
> > all the review comments we got. Any guidance on what we should do next
> would be
> > greatly appreciated.
> 
> At this point in time, just ask me, and I will move the files.
> 
> So, to confirm, you want to have the following files moved to
> drivers/hv/:
> 	drivers/staging/hv/Kconfig (part of this file)
> 	drivers/staging/hv/Makefile (part of this file)
> 	drivers/staging/hv/vmbus_drv.c
> 	drivers/staging/hv/hv.c
> 	drivers/staging/hv/connection.c
> 	drivers/staging/hv/channel.c
> 	drivers/staging/hv/channel_mgmt.c
> 	drivers/staging/hv/ring_buffer.c
> 	drivers/staging/hv/hv_util.c
> 	drivers/staging/hv/hv_kmp.c
This is hv_kvp.c
> 	drivers/staging/hv/hv_kvp.h
> 	drivers/staging/hv/hyperv_vmbus.h
> 

Yes; this would be the list of files to be moved to drivers/hv/

> The following file moved to include/linux/:
> 	drivers/staging/hv/hyperv.h
> (I think there is stuff in there that can go into hyperv_vmbus.h as it's
> not needed in the "global" directory, but I can do that movement.)
> 

Correct.
> The following file moved to tools/hv/:
> 	drivers/staging/hv/tools/*
> 
> And the following files modified to tie drivers/hv/ into the build service:
> 	drivers/Makefile
> 	drivers/Kconfig
> 
> Is all of that correct?
> 

Yes; the list you have is correct. Thanks a lot for doing this.

Regards,

K. Y

Move hyperv out of the drivers/staging/ directory

[Greg KH]

[-- Attachment #1: Type: text/plain, Size: 314 bytes --]

KY, how about the following patch?

Any objection from the virt developers about this?

KY, I'd like to get your signed-off-by before committing this, care to
test this out and pass it around the other hyperv developers and then
sign off on it?  Then I will be glad to commit this to my tree.

thanks,

greg k-h



[-- Attachment #2: 0001-Staging-hv-move-hyperv-code-out-of-staging-directory.patch --]
[-- Type: text/x-patch, Size: 11798 bytes --]

>From 82a986ecb50f336751dc18370a0ec61f2d3002db Mon Sep 17 00:00:00 2001
From: Greg Kroah-Hartman <gregkh@suse.de>
Date: Tue, 4 Oct 2011 12:29:52 -0700
Subject: Staging: hv: move hyperv code out of staging directory

After many years wandering the desert, it is finally time for the
Microsoft HyperV code to move out of the staging directory.  Or at least
the core hyperv bus code, and the utility driver, the rest still have
some review to get through by the various subsystem maintainers.

Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/Kconfig                                    |    2 +
 drivers/Makefile                                   |    2 +
 drivers/hv/Kconfig                                 |   14 ++++++++++
 drivers/hv/Makefile                                |    7 +++++
 drivers/{staging => }/hv/channel.c                 |    2 +-
 drivers/{staging => }/hv/channel_mgmt.c            |    2 +-
 drivers/{staging => }/hv/connection.c              |    2 +-
 drivers/{staging => }/hv/hv.c                      |    2 +-
 drivers/{staging => }/hv/hv_kvp.c                  |    2 +-
 drivers/{staging => }/hv/hv_kvp.h                  |    0
 drivers/{staging => }/hv/hv_util.c                 |    2 +-
 drivers/{staging => }/hv/hyperv_vmbus.h            |    3 +-
 drivers/{staging => }/hv/ring_buffer.c             |    2 +-
 drivers/{staging => }/hv/vmbus_drv.c               |    2 +-
 drivers/staging/hv/Kconfig                         |   28 ++-----------------
 drivers/staging/hv/Makefile                        |    7 +----
 drivers/staging/hv/hv_mouse.c                      |    3 +-
 drivers/staging/hv/hyperv_net.h                    |    2 +-
 drivers/staging/hv/storvsc_drv.c                   |    2 +-
 {drivers/staging/hv => include/linux}/hyperv.h     |    0
 .../staging/hv/tools => tools/hv}/hv_kvp_daemon.c  |    0
 21 files changed, 41 insertions(+), 45 deletions(-)
 create mode 100644 drivers/hv/Kconfig
 create mode 100644 drivers/hv/Makefile
 rename drivers/{staging => }/hv/channel.c (99%)
 rename drivers/{staging => }/hv/channel_mgmt.c (99%)
 rename drivers/{staging => }/hv/connection.c (99%)
 rename drivers/{staging => }/hv/hv.c (99%)
 rename drivers/{staging => }/hv/hv_kvp.c (99%)
 rename drivers/{staging => }/hv/hv_kvp.h (100%)
 rename drivers/{staging => }/hv/hv_util.c (99%)
 rename drivers/{staging => }/hv/hyperv_vmbus.h (99%)
 rename drivers/{staging => }/hv/ring_buffer.c (99%)
 rename drivers/{staging => }/hv/vmbus_drv.c (99%)
 rename {drivers/staging/hv => include/linux}/hyperv.h (100%)
 rename {drivers/staging/hv/tools => tools/hv}/hv_kvp_daemon.c (100%)

diff --git a/drivers/Kconfig b/drivers/Kconfig
index 95b9e7e..ce3c35f 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -130,4 +130,6 @@ source "drivers/iommu/Kconfig"
 
 source "drivers/virt/Kconfig"
 
+source "drivers/hv/Kconfig"
+
 endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 7fa433a..ef693cf 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -127,3 +127,5 @@ obj-$(CONFIG_IOMMU_SUPPORT)	+= iommu/
 
 # Virtualization drivers
 obj-$(CONFIG_VIRT_DRIVERS)	+= virt/
+obj-$(CONFIG_HYPERV)		+= hv/
+
diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
new file mode 100644
index 0000000..9fa09ac
--- /dev/null
+++ b/drivers/hv/Kconfig
@@ -0,0 +1,14 @@
+config HYPERV
+	tristate "Microsoft Hyper-V client drivers"
+	depends on X86 && ACPI && PCI
+	help
+	  Select this option to run Linux as a Hyper-V client operating
+	  system.
+
+config HYPERV_UTILS
+	tristate "Microsoft Hyper-V Utilities driver"
+	depends on HYPERV && CONNECTOR && NLS
+	help
+	  Select this option to enable the Hyper-V Utilities.
+
+
diff --git a/drivers/hv/Makefile b/drivers/hv/Makefile
new file mode 100644
index 0000000..a23938b
--- /dev/null
+++ b/drivers/hv/Makefile
@@ -0,0 +1,7 @@
+obj-$(CONFIG_HYPERV)		+= hv_vmbus.o
+obj-$(CONFIG_HYPERV_UTILS)	+= hv_utils.o
+
+hv_vmbus-y := vmbus_drv.o \
+		 hv.o connection.o channel.o \
+		 channel_mgmt.o ring_buffer.o
+hv_utils-y := hv_util.o hv_kvp.o
diff --git a/drivers/staging/hv/channel.c b/drivers/hv/channel.c
similarity index 99%
rename from drivers/staging/hv/channel.c
rename to drivers/hv/channel.c
index b6f3d38..4065374 100644
--- a/drivers/staging/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -26,8 +26,8 @@
 #include <linux/mm.h>
 #include <linux/slab.h>
 #include <linux/module.h>
+#include <linux/hyperv.h>
 
-#include "hyperv.h"
 #include "hyperv_vmbus.h"
 
 #define NUM_PAGES_SPANNED(addr, len) \
diff --git a/drivers/staging/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
similarity index 99%
rename from drivers/staging/hv/channel_mgmt.c
rename to drivers/hv/channel_mgmt.c
index 9f00752..41bf287 100644
--- a/drivers/staging/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -28,8 +28,8 @@
 #include <linux/list.h>
 #include <linux/module.h>
 #include <linux/completion.h>
+#include <linux/hyperv.h>
 
-#include "hyperv.h"
 #include "hyperv_vmbus.h"
 
 struct vmbus_channel_message_table_entry {
diff --git a/drivers/staging/hv/connection.c b/drivers/hv/connection.c
similarity index 99%
rename from drivers/staging/hv/connection.c
rename to drivers/hv/connection.c
index 649b91b..5f438b6 100644
--- a/drivers/staging/hv/connection.c
+++ b/drivers/hv/connection.c
@@ -29,8 +29,8 @@
 #include <linux/mm.h>
 #include <linux/slab.h>
 #include <linux/vmalloc.h>
+#include <linux/hyperv.h>
 
-#include "hyperv.h"
 #include "hyperv_vmbus.h"
 
 
diff --git a/drivers/staging/hv/hv.c b/drivers/hv/hv.c
similarity index 99%
rename from drivers/staging/hv/hv.c
rename to drivers/hv/hv.c
index 06f1e15..931b7b0 100644
--- a/drivers/staging/hv/hv.c
+++ b/drivers/hv/hv.c
@@ -25,8 +25,8 @@
 #include <linux/mm.h>
 #include <linux/slab.h>
 #include <linux/vmalloc.h>
+#include <linux/hyperv.h>
 
-#include "hyperv.h"
 #include "hyperv_vmbus.h"
 
 /* The one and only */
diff --git a/drivers/staging/hv/hv_kvp.c b/drivers/hv/hv_kvp.c
similarity index 99%
rename from drivers/staging/hv/hv_kvp.c
rename to drivers/hv/hv_kvp.c
index 9aa9ede..219124b 100644
--- a/drivers/staging/hv/hv_kvp.c
+++ b/drivers/hv/hv_kvp.c
@@ -26,8 +26,8 @@
 #include <linux/nls.h>
 #include <linux/connector.h>
 #include <linux/workqueue.h>
+#include <linux/hyperv.h>
 
-#include "hyperv.h"
 #include "hv_kvp.h"
 
 
diff --git a/drivers/staging/hv/hv_kvp.h b/drivers/hv/hv_kvp.h
similarity index 100%
rename from drivers/staging/hv/hv_kvp.h
rename to drivers/hv/hv_kvp.h
diff --git a/drivers/staging/hv/hv_util.c b/drivers/hv/hv_util.c
similarity index 99%
rename from drivers/staging/hv/hv_util.c
rename to drivers/hv/hv_util.c
index faa6607..e0e3a6d 100644
--- a/drivers/staging/hv/hv_util.c
+++ b/drivers/hv/hv_util.c
@@ -26,8 +26,8 @@
 #include <linux/slab.h>
 #include <linux/sysctl.h>
 #include <linux/reboot.h>
+#include <linux/hyperv.h>
 
-#include "hyperv.h"
 #include "hv_kvp.h"
 
 
diff --git a/drivers/staging/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
similarity index 99%
rename from drivers/staging/hv/hyperv_vmbus.h
rename to drivers/hv/hyperv_vmbus.h
index 3d2d836..8261cb6 100644
--- a/drivers/staging/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -28,8 +28,7 @@
 #include <linux/list.h>
 #include <asm/sync_bitops.h>
 #include <linux/atomic.h>
-
-#include "hyperv.h"
+#include <linux/hyperv.h>
 
 /*
  * The below CPUID leaves are present if VersionAndFeatures.HypervisorPresent
diff --git a/drivers/staging/hv/ring_buffer.c b/drivers/hv/ring_buffer.c
similarity index 99%
rename from drivers/staging/hv/ring_buffer.c
rename to drivers/hv/ring_buffer.c
index 70e2e66..f594ed0 100644
--- a/drivers/staging/hv/ring_buffer.c
+++ b/drivers/hv/ring_buffer.c
@@ -25,8 +25,8 @@
 
 #include <linux/kernel.h>
 #include <linux/mm.h>
+#include <linux/hyperv.h>
 
-#include "hyperv.h"
 #include "hyperv_vmbus.h"
 
 
diff --git a/drivers/staging/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
similarity index 99%
rename from drivers/staging/hv/vmbus_drv.c
rename to drivers/hv/vmbus_drv.c
index d2562af..b0d08f9 100644
--- a/drivers/staging/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -32,8 +32,8 @@
 #include <linux/acpi.h>
 #include <acpi/acpi_bus.h>
 #include <linux/completion.h>
+#include <linux/hyperv.h>
 
-#include "hyperv.h"
 #include "hyperv_vmbus.h"
 
 
diff --git a/drivers/staging/hv/Kconfig b/drivers/staging/hv/Kconfig
index 815f8c2..072185e 100644
--- a/drivers/staging/hv/Kconfig
+++ b/drivers/staging/hv/Kconfig
@@ -1,39 +1,17 @@
-config HYPERV
-	tristate "Microsoft Hyper-V client drivers"
-	depends on X86 && ACPI && PCI
-	default n
-	help
-	  Select this option to run Linux as a Hyper-V client operating
-	  system.
-
-if HYPERV
-
 config HYPERV_STORAGE
 	tristate "Microsoft Hyper-V virtual storage driver"
-	depends on SCSI
-	default HYPERV
+	depends on HYPERV && SCSI
 	help
 	 Select this option to enable the Hyper-V virtual storage driver.
 
 config HYPERV_NET
 	tristate "Microsoft Hyper-V virtual network driver"
-	depends on NET
-	default HYPERV
+	depends on HYPERV && NET
 	help
 	  Select this option to enable the Hyper-V virtual network driver.
 
-config HYPERV_UTILS
-	tristate "Microsoft Hyper-V Utilities driver"
-	depends on CONNECTOR && NLS
-	default HYPERV
-	help
-	  Select this option to enable the Hyper-V Utilities.
-
 config HYPERV_MOUSE
 	tristate "Microsoft Hyper-V mouse driver"
-	depends on HID
-	default HYPERV
+	depends on HYPERV && HID
 	help
 	  Select this option to enable the Hyper-V mouse driver.
-
-endif
diff --git a/drivers/staging/hv/Makefile b/drivers/staging/hv/Makefile
index bd176b1..e071c12 100644
--- a/drivers/staging/hv/Makefile
+++ b/drivers/staging/hv/Makefile
@@ -1,12 +1,7 @@
-obj-$(CONFIG_HYPERV)		+= hv_vmbus.o hv_timesource.o
+obj-$(CONFIG_HYPERV)		+= hv_timesource.o
 obj-$(CONFIG_HYPERV_STORAGE)	+= hv_storvsc.o
 obj-$(CONFIG_HYPERV_NET)	+= hv_netvsc.o
-obj-$(CONFIG_HYPERV_UTILS)	+= hv_utils.o
 obj-$(CONFIG_HYPERV_MOUSE)	+= hv_mouse.o
 
-hv_vmbus-y := vmbus_drv.o \
-		 hv.o connection.o channel.o \
-		 channel_mgmt.o ring_buffer.o
 hv_storvsc-y := storvsc_drv.o
 hv_netvsc-y := netvsc_drv.o netvsc.o rndis_filter.o
-hv_utils-y := hv_util.o hv_kvp.o
diff --git a/drivers/staging/hv/hv_mouse.c b/drivers/staging/hv/hv_mouse.c
index edbb479..c354ade 100644
--- a/drivers/staging/hv/hv_mouse.c
+++ b/drivers/staging/hv/hv_mouse.c
@@ -22,8 +22,7 @@
 #include <linux/input.h>
 #include <linux/hid.h>
 #include <linux/hiddev.h>
-
-#include "hyperv.h"
+#include <linux/hyperv.h>
 
 
 struct hv_input_dev_info {
diff --git a/drivers/staging/hv/hyperv_net.h b/drivers/staging/hv/hyperv_net.h
index 366dd2b..ac1ec84 100644
--- a/drivers/staging/hv/hyperv_net.h
+++ b/drivers/staging/hv/hyperv_net.h
@@ -26,7 +26,7 @@
 #define _HYPERV_NET_H
 
 #include <linux/list.h>
-#include "hyperv.h"
+#include <linux/hyperv.h>
 
 /* Fwd declaration */
 struct hv_netvsc_packet;
diff --git a/drivers/staging/hv/storvsc_drv.c b/drivers/staging/hv/storvsc_drv.c
index 807c94d..c4dfed4 100644
--- a/drivers/staging/hv/storvsc_drv.c
+++ b/drivers/staging/hv/storvsc_drv.c
@@ -31,6 +31,7 @@
 #include <linux/slab.h>
 #include <linux/module.h>
 #include <linux/device.h>
+#include <linux/hyperv.h>
 #include <scsi/scsi.h>
 #include <scsi/scsi_cmnd.h>
 #include <scsi/scsi_host.h>
@@ -40,7 +41,6 @@
 #include <scsi/scsi_devinfo.h>
 #include <scsi/scsi_dbg.h>
 
-#include "hyperv.h"
 
 #define STORVSC_RING_BUFFER_SIZE			(20*PAGE_SIZE)
 static int storvsc_ringbuffer_size = STORVSC_RING_BUFFER_SIZE;
diff --git a/drivers/staging/hv/hyperv.h b/include/linux/hyperv.h
similarity index 100%
rename from drivers/staging/hv/hyperv.h
rename to include/linux/hyperv.h
diff --git a/drivers/staging/hv/tools/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
similarity index 100%
rename from drivers/staging/hv/tools/hv_kvp_daemon.c
rename to tools/hv/hv_kvp_daemon.c
-- 
1.7.6.4

RE: Move hyperv out of the drivers/staging/ directory

[KY Srinivasan]

> -----Original Message-----
> From: Greg KH [mailto:gregkh@suse.de]
> Sent: Tuesday, October 04, 2011 3:34 PM
> To: KY Srinivasan
> Cc: linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> virtualization@lists.osdl.org
> Subject: Move hyperv out of the drivers/staging/ directory
> 
> KY, how about the following patch?

Looks good Greg. This morning Thomas informed me that he has checked in
my patch to integrate the time source driver with the Hyper-V detection code.
Thomas indicated that this patch has been applied to the tip already. How will this
be reflected in the staging tree?
 
> 
> Any objection from the virt developers about this?
> 
> KY, I'd like to get your signed-off-by before committing this, care to
> test this out and pass it around the other hyperv developers and then
> sign off on it?  Then I will be glad to commit this to my tree.

I have started the test cycle; I will let you know shortly what we discover.

Regards,

K. Y

RE: Move hyperv out of the drivers/staging/ directory

[KY Srinivasan]

> -----Original Message-----
> From: Greg KH [mailto:gregkh@suse.de]
> Sent: Tuesday, October 04, 2011 3:34 PM
> To: KY Srinivasan
> Cc: linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> virtualization@lists.osdl.org
> Subject: Move hyperv out of the drivers/staging/ directory
> 
> KY, how about the following patch?
> 
> Any objection from the virt developers about this?
> 
> KY, I'd like to get your signed-off-by before committing this, care to
> test this out and pass it around the other hyperv developers and then
> sign off on it?  Then I will be glad to commit this to my tree.

We completed the testing and everything is functional. Here is my sign-off:

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

Regards,

K. Y


> 
> thanks,
> 
> greg k-h
> 

0xB16B00B5? Really? (was Re: Move hyperv out of the drivers/staging/ directory)

[Paolo Bonzini]

Il 04/10/2011 21:34, Greg KH ha scritto:
> diff --git a/drivers/staging/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
> similarity index 99%
> rename from drivers/staging/hv/hyperv_vmbus.h
> rename to drivers/hv/hyperv_vmbus.h
> index 3d2d836..8261cb6 100644
> --- a/drivers/staging/hv/hyperv_vmbus.h
> +++ b/drivers/hv/hyperv_vmbus.h
> @@ -28,8 +28,7 @@
>  #include <linux/list.h>
>  #include <asm/sync_bitops.h>
>  #include <linux/atomic.h>
> -
> -#include "hyperv.h"
> +#include <linux/hyperv.h>
>  
>  /*
>   * The below CPUID leaves are present if VersionAndFeatures.HypervisorPresent

git's rename detection snips away this gem:

+#define HV_LINUX_GUEST_ID_LO		0x00000000
+#define HV_LINUX_GUEST_ID_HI		0xB16B00B5
+#define HV_LINUX_GUEST_ID		(((u64)HV_LINUX_GUEST_ID_HI << 32) | \
+					   HV_LINUX_GUEST_ID_LO)

Somone was trying to be funny, I guess.

KY, I suppose you have access to Hyper-V code or can ask someone who does.
Is this signature actually used in the Hyper-V host code?

Paolo

RE: 0xB16B00B5? Really? (was Re: Move hyperv out of the drivers/staging/ directory)

[KY Srinivasan]

> -----Original Message-----
> From: Paolo Bonzini [mailto:paolo.bonzini@gmail.com] On Behalf Of Paolo
> Bonzini
> Sent: Friday, July 13, 2012 6:23 AM
> To: KY Srinivasan
> Cc: Greg KH; devel@linuxdriverproject.org; linux-kernel@vger.kernel.org;
> virtualization@lists.osdl.org
> Subject: 0xB16B00B5? Really? (was Re: Move hyperv out of the drivers/staging/
> directory)
> 
> Il 04/10/2011 21:34, Greg KH ha scritto:
> > diff --git a/drivers/staging/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
> > similarity index 99%
> > rename from drivers/staging/hv/hyperv_vmbus.h
> > rename to drivers/hv/hyperv_vmbus.h
> > index 3d2d836..8261cb6 100644
> > --- a/drivers/staging/hv/hyperv_vmbus.h
> > +++ b/drivers/hv/hyperv_vmbus.h
> > @@ -28,8 +28,7 @@
> >  #include <linux/list.h>
> >  #include <asm/sync_bitops.h>
> >  #include <linux/atomic.h>
> > -
> > -#include "hyperv.h"
> > +#include <linux/hyperv.h>
> >
> >  /*
> >   * The below CPUID leaves are present if
> VersionAndFeatures.HypervisorPresent
> 
> git's rename detection snips away this gem:
> 
> +#define HV_LINUX_GUEST_ID_LO		0x00000000
> +#define HV_LINUX_GUEST_ID_HI		0xB16B00B5
> +#define HV_LINUX_GUEST_ID		(((u64)HV_LINUX_GUEST_ID_HI
> << 32) | \
> +					   HV_LINUX_GUEST_ID_LO)
> 
> Somone was trying to be funny, I guess.
> 
> KY, I suppose you have access to Hyper-V code or can ask someone who does.
> Is this signature actually used in the Hyper-V host code?

It is still early in the morning here and pardon me if I am not seeing the issue.
Could you elaborate on what you want changed and why. This is a guest
signature that is stashed away in the hypervisor and perhaps can be retrieved
by the host. Other than that, this is not used anywhere else. MSFT has defined a
a namespace for guest IDs and while some ranges are reserved for MSFT operating
systems, there really is nothing special about the guest ID.

Regards,

K. Y

Re: 0xB16B00B5? Really? (was Re: Move hyperv out of the drivers/staging/ directory)

[Paolo Bonzini]

Il 13/07/2012 15:13, KY Srinivasan ha scritto:
>> > 
>> > Somone was trying to be funny, I guess.
>> > 
>> > KY, I suppose you have access to Hyper-V code or can ask someone who does.
>> > Is this signature actually used in the Hyper-V host code?
> It is still early in the morning here and pardon me if I am not seeing the issue.

[offlist]

0xB16B00B5 = big boobs

Paolo

RE: 0xB16B00B5? Really? (was Re: Move hyperv out of the drivers/staging/ directory)

[KY Srinivasan]

> -----Original Message-----
> From: Paolo Bonzini [mailto:pbonzini@redhat.com]
> Sent: Friday, July 13, 2012 9:15 AM
> To: KY Srinivasan
> Cc: Greg KH; devel@linuxdriverproject.org; linux-kernel@vger.kernel.org;
> virtualization@lists.osdl.org
> Subject: Re: 0xB16B00B5? Really? (was Re: Move hyperv out of the
> drivers/staging/ directory)
> 
> Il 13/07/2012 15:13, KY Srinivasan ha scritto:
> >> >
> >> > Somone was trying to be funny, I guess.
> >> >
> >> > KY, I suppose you have access to Hyper-V code or can ask someone who
> does.
> >> > Is this signature actually used in the Hyper-V host code?
> > It is still early in the morning here and pardon me if I am not seeing the issue.
> 
> [offlist]
> 
> 0xB16B00B5 = big boobs

Ok! I don't know how easy it is to change this. If I remember correctly, I think on our Cloud
(Azure), the guest ID may be currently used in our management stack.

Regards,

K. Y

RE: 2976579765? Really? (was Re: Move hyperv out of the drivers/staging/ directory)

[Paul Bolle]

On Fri, 2012-07-13 at 13:21 +0000, KY Srinivasan wrote:
> Ok! I don't know how easy it is to change this.

I'd say nothing could possibly break if you just changed that line to
    #define HV_LINUX_GUEST_ID_HI           2976579765

(Not that I, somehow, tested this.)


Paul Bolle

Re: 0xB16B00B5? Really? (was Re: Move hyperv out of the drivers/staging/ directory)

[Borislav Petkov]

On Fri, Jul 13, 2012 at 03:15:29PM +0200, Paolo Bonzini wrote:
> Il 13/07/2012 15:13, KY Srinivasan ha scritto:
> >> > 
> >> > Somone was trying to be funny, I guess.
> >> > 
> >> > KY, I suppose you have access to Hyper-V code or can ask someone who does.
> >> > Is this signature actually used in the Hyper-V host code?
> > It is still early in the morning here and pardon me if I am not seeing the issue.
> 
> [offlist]
> 
> 0xB16B00B5 = big boobs

LOL! You can't make this stuff up!

:-)

-- 
Regards/Gruss,
Boris.

Re: 0xB16B00B5? Really? (was Re: Move hyperv out of the drivers/staging/ directory)

[Steven Rostedt]

On Fri, Jul 13, 2012 at 03:24:43PM +0200, Borislav Petkov wrote:
> On Fri, Jul 13, 2012 at 03:15:29PM +0200, Paolo Bonzini wrote:
> > Il 13/07/2012 15:13, KY Srinivasan ha scritto:
> > >> > 
> > >> > Somone was trying to be funny, I guess.
> > >> > 
> > >> > KY, I suppose you have access to Hyper-V code or can ask someone who does.
> > >> > Is this signature actually used in the Hyper-V host code?
> > > It is still early in the morning here and pardon me if I am not seeing the issue.
> > 
> > [offlist]

I guess not :-)

> > 
> > 0xB16B00B5 = big boobs
> 
> LOL! You can't make this stuff up!
> 

I guess that's why it's in a file called hyPERV_vmbus. ;-)

-- Steve

Re: 0xB16B00B5? Really? (was Re: Move hyperv out of the drivers/staging/ directory)

[Borislav Petkov]

On Fri, Jul 13, 2012 at 03:00:57PM -0400, Steven Rostedt wrote:
> I guess that's why it's in a file called hyPERV_vmbus. ;-)

Ladies and gentlemen, Steve can see nastyness in an arbitrary ASCII
string.

8-).

-- 
Regards/Gruss,
    Boris.

[PATCH] hv: Change the guest ID value

[Matthew Garrett]

If I have to explain this I'm going to be very sad.

Signed-off-by: Matthew Garrett <mjg@redhat.com>
---
 drivers/hv/hyperv_vmbus.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index b9426a6..77e48b0 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -411,7 +411,7 @@ enum {
 #define HV_PRESENT_BIT			0x80000000
 
 #define HV_LINUX_GUEST_ID_LO		0x00000000
-#define HV_LINUX_GUEST_ID_HI		0xB16B00B5
+#define HV_LINUX_GUEST_ID_HI		0x0DEFACED
 #define HV_LINUX_GUEST_ID		(((u64)HV_LINUX_GUEST_ID_HI << 32) | \
 					   HV_LINUX_GUEST_ID_LO)
 
-- 
1.7.10.4

RE: 0xB16B00B5? Really? (was Re: Move hyperv out of the drivers/staging/ directory)

[KY Srinivasan]

> -----Original Message-----
> From: Paolo Bonzini [mailto:paolo.bonzini@gmail.com] On Behalf Of Paolo
> Bonzini
> Sent: Friday, July 13, 2012 6:23 AM
> To: KY Srinivasan
> Cc: Greg KH; devel@linuxdriverproject.org; linux-kernel@vger.kernel.org;
> virtualization@lists.osdl.org
> Subject: 0xB16B00B5? Really? (was Re: Move hyperv out of the drivers/staging/
> directory)
> 
> Il 04/10/2011 21:34, Greg KH ha scritto:
> > diff --git a/drivers/staging/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
> > similarity index 99%
> > rename from drivers/staging/hv/hyperv_vmbus.h
> > rename to drivers/hv/hyperv_vmbus.h
> > index 3d2d836..8261cb6 100644
> > --- a/drivers/staging/hv/hyperv_vmbus.h
> > +++ b/drivers/hv/hyperv_vmbus.h
> > @@ -28,8 +28,7 @@
> >  #include <linux/list.h>
> >  #include <asm/sync_bitops.h>
> >  #include <linux/atomic.h>
> > -
> > -#include "hyperv.h"
> > +#include <linux/hyperv.h>
> >
> >  /*
> >   * The below CPUID leaves are present if
> VersionAndFeatures.HypervisorPresent
> 
> git's rename detection snips away this gem:
> 
> +#define HV_LINUX_GUEST_ID_LO		0x00000000
> +#define HV_LINUX_GUEST_ID_HI		0xB16B00B5
> +#define HV_LINUX_GUEST_ID		(((u64)HV_LINUX_GUEST_ID_HI
> << 32) | \
> +					   HV_LINUX_GUEST_ID_LO)
> 
> Somone was trying to be funny, I guess.
> 
> KY, I suppose you have access to Hyper-V code or can ask someone who does.
> Is this signature actually used in the Hyper-V host code?

Paolo,

As I noted earlier, this is just a guest ID that needs to be registered with the
hypervisor.  Thanks  for reporting this issue and on behalf of Microsoft, I would
like to  apologize for this offensive string. I have submitted a patch to fix this issue. 

Regards,

K. Y  
 

Re: 0xB16B00B5? Really? (was Re: Move hyperv out of the drivers/staging/ directory)

[Borislav Petkov]

On Thu, Jul 19, 2012 at 02:11:47AM +0000, KY Srinivasan wrote:
> As I noted earlier, this is just a guest ID that needs to be
> registered with the hypervisor. Thanks for reporting this issue and
> on behalf of Microsoft, I would like to apologize for this offensive
> string. I have submitted a patch to fix this issue.

Ok, quick question:

http://msdn.microsoft.com/en-us/library/windows/hardware/ff542653%28v=vs.85%29.aspx

says that that guest ID encodes a bunch of version numbers and IDs
pertaining to the guest OS. And in that case, I would've thought
you'd encode kernel versions or whatever like it is done with
LINUX_VERSION_CODE, for example.

How does this define fit with that scheme or was it chosen completely
arbitrarily?

Thanks.

-- 
Regards/Gruss,
Boris.

RE: 0xB16B00B5? Really? (was Re: Move hyperv out of the drivers/staging/ directory)

[KY Srinivasan]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1519 bytes --]



> -----Original Message-----
> From: Borislav Petkov [mailto:bp@alien8.de]
> Sent: Thursday, July 19, 2012 11:30 AM
> To: KY Srinivasan
> Cc: Paolo Bonzini; Greg KH (gregkh@linuxfoundation.org);
> devel@linuxdriverproject.org; linux-kernel@vger.kernel.org;
> virtualization@lists.osdl.org
> Subject: Re: 0xB16B00B5? Really? (was Re: Move hyperv out of the
> drivers/staging/ directory)
> 
> On Thu, Jul 19, 2012 at 02:11:47AM +0000, KY Srinivasan wrote:
> > As I noted earlier, this is just a guest ID that needs to be
> > registered with the hypervisor. Thanks for reporting this issue and
> > on behalf of Microsoft, I would like to apologize for this offensive
> > string. I have submitted a patch to fix this issue.
> 
> Ok, quick question:
> 
> http://msdn.microsoft.com/en-
> us/library/windows/hardware/ff542653%28v=vs.85%29.aspx
> 
> says that that guest ID encodes a bunch of version numbers and IDs
> pertaining to the guest OS. And in that case, I would've thought
> you'd encode kernel versions or whatever like it is done with
> LINUX_VERSION_CODE, for example.
> 
> How does this define fit with that scheme or was it chosen completely
> arbitrarily?

>From what I know, this constant was chosen I think, completely arbitrarily.
Currently, the hypervisor does not interpret this, however the host partition
can retrieve it. 

Regards,

K. Y 

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: 0xB16B00B5? Really? (was Re: Move hyperv out of the drivers/staging/ directory)

[Greg KH (gregkh@linuxfoundation.org)]

On Thu, Jul 19, 2012 at 02:11:47AM +0000, KY Srinivasan wrote:
> 
> 
> > -----Original Message-----
> > From: Paolo Bonzini [mailto:paolo.bonzini@gmail.com] On Behalf Of Paolo
> > Bonzini
> > Sent: Friday, July 13, 2012 6:23 AM
> > To: KY Srinivasan
> > Cc: Greg KH; devel@linuxdriverproject.org; linux-kernel@vger.kernel.org;
> > virtualization@lists.osdl.org
> > Subject: 0xB16B00B5? Really? (was Re: Move hyperv out of the drivers/staging/
> > directory)
> > 
> > Il 04/10/2011 21:34, Greg KH ha scritto:
> > > diff --git a/drivers/staging/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
> > > similarity index 99%
> > > rename from drivers/staging/hv/hyperv_vmbus.h
> > > rename to drivers/hv/hyperv_vmbus.h
> > > index 3d2d836..8261cb6 100644
> > > --- a/drivers/staging/hv/hyperv_vmbus.h
> > > +++ b/drivers/hv/hyperv_vmbus.h
> > > @@ -28,8 +28,7 @@
> > >  #include <linux/list.h>
> > >  #include <asm/sync_bitops.h>
> > >  #include <linux/atomic.h>
> > > -
> > > -#include "hyperv.h"
> > > +#include <linux/hyperv.h>
> > >
> > >  /*
> > >   * The below CPUID leaves are present if
> > VersionAndFeatures.HypervisorPresent
> > 
> > git's rename detection snips away this gem:
> > 
> > +#define HV_LINUX_GUEST_ID_LO		0x00000000
> > +#define HV_LINUX_GUEST_ID_HI		0xB16B00B5
> > +#define HV_LINUX_GUEST_ID		(((u64)HV_LINUX_GUEST_ID_HI
> > << 32) | \
> > +					   HV_LINUX_GUEST_ID_LO)
> > 
> > Somone was trying to be funny, I guess.
> > 
> > KY, I suppose you have access to Hyper-V code or can ask someone who does.
> > Is this signature actually used in the Hyper-V host code?
> 
> Paolo,
> 
> As I noted earlier, this is just a guest ID that needs to be registered with the
> hypervisor.  Thanks  for reporting this issue and on behalf of Microsoft, I would
> like to  apologize for this offensive string. I have submitted a patch to fix this issue. 

You only changed it to be in decimal, you did not change the id at all.
Is there some reason why you can not change it?  You said there was a
reserved range of ids that could be used, perhaps just pick another one?
What is the valid range that can be used here?

thanks,

greg k-h

RE: 0xB16B00B5? Really? (was Re: Move hyperv out of the drivers/staging/ directory)

[KY Srinivasan]

> -----Original Message-----
> From: Greg KH (gregkh@linuxfoundation.org)
> [mailto:gregkh@linuxfoundation.org]
> Sent: Thursday, July 19, 2012 5:07 PM
> To: KY Srinivasan
> Cc: Paolo Bonzini; devel@linuxdriverproject.org; linux-kernel@vger.kernel.org;
> virtualization@lists.osdl.org
> Subject: Re: 0xB16B00B5? Really? (was Re: Move hyperv out of the
> drivers/staging/ directory)
> 
> On Thu, Jul 19, 2012 at 02:11:47AM +0000, KY Srinivasan wrote:
> >
> >
> > > -----Original Message-----
> > > From: Paolo Bonzini [mailto:paolo.bonzini@gmail.com] On Behalf Of Paolo
> > > Bonzini
> > > Sent: Friday, July 13, 2012 6:23 AM
> > > To: KY Srinivasan
> > > Cc: Greg KH; devel@linuxdriverproject.org; linux-kernel@vger.kernel.org;
> > > virtualization@lists.osdl.org
> > > Subject: 0xB16B00B5? Really? (was Re: Move hyperv out of the
> drivers/staging/
> > > directory)
> > >
> > > Il 04/10/2011 21:34, Greg KH ha scritto:
> > > > diff --git a/drivers/staging/hv/hyperv_vmbus.h
> b/drivers/hv/hyperv_vmbus.h
> > > > similarity index 99%
> > > > rename from drivers/staging/hv/hyperv_vmbus.h
> > > > rename to drivers/hv/hyperv_vmbus.h
> > > > index 3d2d836..8261cb6 100644
> > > > --- a/drivers/staging/hv/hyperv_vmbus.h
> > > > +++ b/drivers/hv/hyperv_vmbus.h
> > > > @@ -28,8 +28,7 @@
> > > >  #include <linux/list.h>
> > > >  #include <asm/sync_bitops.h>
> > > >  #include <linux/atomic.h>
> > > > -
> > > > -#include "hyperv.h"
> > > > +#include <linux/hyperv.h>
> > > >
> > > >  /*
> > > >   * The below CPUID leaves are present if
> > > VersionAndFeatures.HypervisorPresent
> > >
> > > git's rename detection snips away this gem:
> > >
> > > +#define HV_LINUX_GUEST_ID_LO		0x00000000
> > > +#define HV_LINUX_GUEST_ID_HI		0xB16B00B5
> > > +#define HV_LINUX_GUEST_ID		(((u64)HV_LINUX_GUEST_ID_HI
> > > << 32) | \
> > > +					   HV_LINUX_GUEST_ID_LO)
> > >
> > > Somone was trying to be funny, I guess.
> > >
> > > KY, I suppose you have access to Hyper-V code or can ask someone who
> does.
> > > Is this signature actually used in the Hyper-V host code?
> >
> > Paolo,
> >
> > As I noted earlier, this is just a guest ID that needs to be registered with the
> > hypervisor.  Thanks  for reporting this issue and on behalf of Microsoft, I would
> > like to  apologize for this offensive string. I have submitted a patch to fix this
> issue.
> 
> You only changed it to be in decimal, you did not change the id at all.
> Is there some reason why you can not change it?  You said there was a
> reserved range of ids that could be used, perhaps just pick another one?
> What is the valid range that can be used here?

Greg,

As you know, this ID has been in use for a long time now. While the hypervisor
does not interpret the guest ID that is registered, I am not sure what dependencies
there might be on this value. That is the reason I am reluctant to change the value.
Since the hex representation of this constant was what was offensive, changing it to
a decimal number would not break anything while simultaneously addressing the issue
Paolo brought up. 


Regards,

K. Y 

Re: 0xB16B00B5? Really? (was Re: Move hyperv out of the drivers/staging/ directory)

[Greg KH (gregkh@linuxfoundation.org)]

On Thu, Jul 19, 2012 at 09:22:53PM +0000, KY Srinivasan wrote:
> 
> 
> > -----Original Message-----
> > From: Greg KH (gregkh@linuxfoundation.org)
> > [mailto:gregkh@linuxfoundation.org]
> > Sent: Thursday, July 19, 2012 5:07 PM
> > To: KY Srinivasan
> > Cc: Paolo Bonzini; devel@linuxdriverproject.org; linux-kernel@vger.kernel.org;
> > virtualization@lists.osdl.org
> > Subject: Re: 0xB16B00B5? Really? (was Re: Move hyperv out of the
> > drivers/staging/ directory)
> > 
> > On Thu, Jul 19, 2012 at 02:11:47AM +0000, KY Srinivasan wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Paolo Bonzini [mailto:paolo.bonzini@gmail.com] On Behalf Of Paolo
> > > > Bonzini
> > > > Sent: Friday, July 13, 2012 6:23 AM
> > > > To: KY Srinivasan
> > > > Cc: Greg KH; devel@linuxdriverproject.org; linux-kernel@vger.kernel.org;
> > > > virtualization@lists.osdl.org
> > > > Subject: 0xB16B00B5? Really? (was Re: Move hyperv out of the
> > drivers/staging/
> > > > directory)
> > > >
> > > > Il 04/10/2011 21:34, Greg KH ha scritto:
> > > > > diff --git a/drivers/staging/hv/hyperv_vmbus.h
> > b/drivers/hv/hyperv_vmbus.h
> > > > > similarity index 99%
> > > > > rename from drivers/staging/hv/hyperv_vmbus.h
> > > > > rename to drivers/hv/hyperv_vmbus.h
> > > > > index 3d2d836..8261cb6 100644
> > > > > --- a/drivers/staging/hv/hyperv_vmbus.h
> > > > > +++ b/drivers/hv/hyperv_vmbus.h
> > > > > @@ -28,8 +28,7 @@
> > > > >  #include <linux/list.h>
> > > > >  #include <asm/sync_bitops.h>
> > > > >  #include <linux/atomic.h>
> > > > > -
> > > > > -#include "hyperv.h"
> > > > > +#include <linux/hyperv.h>
> > > > >
> > > > >  /*
> > > > >   * The below CPUID leaves are present if
> > > > VersionAndFeatures.HypervisorPresent
> > > >
> > > > git's rename detection snips away this gem:
> > > >
> > > > +#define HV_LINUX_GUEST_ID_LO		0x00000000
> > > > +#define HV_LINUX_GUEST_ID_HI		0xB16B00B5
> > > > +#define HV_LINUX_GUEST_ID		(((u64)HV_LINUX_GUEST_ID_HI
> > > > << 32) | \
> > > > +					   HV_LINUX_GUEST_ID_LO)
> > > >
> > > > Somone was trying to be funny, I guess.
> > > >
> > > > KY, I suppose you have access to Hyper-V code or can ask someone who
> > does.
> > > > Is this signature actually used in the Hyper-V host code?
> > >
> > > Paolo,
> > >
> > > As I noted earlier, this is just a guest ID that needs to be registered with the
> > > hypervisor.  Thanks  for reporting this issue and on behalf of Microsoft, I would
> > > like to  apologize for this offensive string. I have submitted a patch to fix this
> > issue.
> > 
> > You only changed it to be in decimal, you did not change the id at all.
> > Is there some reason why you can not change it?  You said there was a
> > reserved range of ids that could be used, perhaps just pick another one?
> > What is the valid range that can be used here?
> 
> Greg,
> 
> As you know, this ID has been in use for a long time now. While the hypervisor
> does not interpret the guest ID that is registered, I am not sure what dependencies
> there might be on this value.

Could you please go find out the answer to this?

If, as you originally stated, there is a range of values we can use,
then we should probably use another one, right?

thanks,

greg k-h

RE: 0xB16B00B5? Really? (was Re: Move hyperv out of the drivers/staging/ directory)

[KY Srinivasan]

> -----Original Message-----
> From: Greg KH (gregkh@linuxfoundation.org)
> [mailto:gregkh@linuxfoundation.org]
> Sent: Thursday, July 19, 2012 6:02 PM
> To: KY Srinivasan
> Cc: Paolo Bonzini; devel@linuxdriverproject.org; linux-kernel@vger.kernel.org;
> virtualization@lists.osdl.org
> Subject: Re: 0xB16B00B5? Really? (was Re: Move hyperv out of the
> drivers/staging/ directory)
> 
> On Thu, Jul 19, 2012 at 09:22:53PM +0000, KY Srinivasan wrote:
> >
> >
> > > -----Original Message-----
> > > From: Greg KH (gregkh@linuxfoundation.org)
> > > [mailto:gregkh@linuxfoundation.org]
> > > Sent: Thursday, July 19, 2012 5:07 PM
> > > To: KY Srinivasan
> > > Cc: Paolo Bonzini; devel@linuxdriverproject.org; linux-
> kernel@vger.kernel.org;
> > > virtualization@lists.osdl.org
> > > Subject: Re: 0xB16B00B5? Really? (was Re: Move hyperv out of the
> > > drivers/staging/ directory)
> > >
> > > On Thu, Jul 19, 2012 at 02:11:47AM +0000, KY Srinivasan wrote:
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Paolo Bonzini [mailto:paolo.bonzini@gmail.com] On Behalf Of Paolo
> > > > > Bonzini
> > > > > Sent: Friday, July 13, 2012 6:23 AM
> > > > > To: KY Srinivasan
> > > > > Cc: Greg KH; devel@linuxdriverproject.org; linux-kernel@vger.kernel.org;
> > > > > virtualization@lists.osdl.org
> > > > > Subject: 0xB16B00B5? Really? (was Re: Move hyperv out of the
> > > drivers/staging/
> > > > > directory)
> > > > >
> > > > > Il 04/10/2011 21:34, Greg KH ha scritto:
> > > > > > diff --git a/drivers/staging/hv/hyperv_vmbus.h
> > > b/drivers/hv/hyperv_vmbus.h
> > > > > > similarity index 99%
> > > > > > rename from drivers/staging/hv/hyperv_vmbus.h
> > > > > > rename to drivers/hv/hyperv_vmbus.h
> > > > > > index 3d2d836..8261cb6 100644
> > > > > > --- a/drivers/staging/hv/hyperv_vmbus.h
> > > > > > +++ b/drivers/hv/hyperv_vmbus.h
> > > > > > @@ -28,8 +28,7 @@
> > > > > >  #include <linux/list.h>
> > > > > >  #include <asm/sync_bitops.h>
> > > > > >  #include <linux/atomic.h>
> > > > > > -
> > > > > > -#include "hyperv.h"
> > > > > > +#include <linux/hyperv.h>
> > > > > >
> > > > > >  /*
> > > > > >   * The below CPUID leaves are present if
> > > > > VersionAndFeatures.HypervisorPresent
> > > > >
> > > > > git's rename detection snips away this gem:
> > > > >
> > > > > +#define HV_LINUX_GUEST_ID_LO		0x00000000
> > > > > +#define HV_LINUX_GUEST_ID_HI		0xB16B00B5
> > > > > +#define HV_LINUX_GUEST_ID		(((u64)HV_LINUX_GUEST_ID_HI
> > > > > << 32) | \
> > > > > +					   HV_LINUX_GUEST_ID_LO)
> > > > >
> > > > > Somone was trying to be funny, I guess.
> > > > >
> > > > > KY, I suppose you have access to Hyper-V code or can ask someone who
> > > does.
> > > > > Is this signature actually used in the Hyper-V host code?
> > > >
> > > > Paolo,
> > > >
> > > > As I noted earlier, this is just a guest ID that needs to be registered with the
> > > > hypervisor.  Thanks  for reporting this issue and on behalf of Microsoft, I
> would
> > > > like to  apologize for this offensive string. I have submitted a patch to fix this
> > > issue.
> > >
> > > You only changed it to be in decimal, you did not change the id at all.
> > > Is there some reason why you can not change it?  You said there was a
> > > reserved range of ids that could be used, perhaps just pick another one?
> > > What is the valid range that can be used here?
> >
> > Greg,
> >
> > As you know, this ID has been in use for a long time now. While the hypervisor
> > does not interpret the guest ID that is registered, I am not sure what
> dependencies
> > there might be on this value.
> 
> Could you please go find out the answer to this?

That is easier said than done. I have sent emails out asking this very question and I have
not received a definitive answer yet. Not knowing if and when I can get a definitive
answer here, I chose the least risky approach in my patch. 
> 
> If, as you originally stated, there is a range of values we can use,
> then we should probably use another one, right?

On the Windows side this ID namespace is managed well. However on the Linux
side, we have really had this current ID in use for almost five years now. I am not
aware of any pool of IDs available for Linux usage except that Linux IDs be distinct from
the guest IDs in use by MSFT operating systems. If I were to change the guest ID, I would
probably want to comply with the MSFT guidance on constructing these IDs (although not
all fields may be relevant for Linux).

Regards,

K. Y 
 

Re: 0xB16B00B5? Really? (was Re: Move hyperv out of the drivers/staging/ directory)

[Anthony Liguori]

On 07/19/2012 05:30 PM, KY Srinivasan wrote:
>
>
>> -----Original Message-----
>> From: Greg KH (gregkh@linuxfoundation.org)
>> [mailto:gregkh@linuxfoundation.org]
>> Sent: Thursday, July 19, 2012 6:02 PM
>> To: KY Srinivasan
>> Cc: Paolo Bonzini; devel@linuxdriverproject.org; linux-kernel@vger.kernel.org;
>> virtualization@lists.osdl.org
>> Subject: Re: 0xB16B00B5? Really? (was Re: Move hyperv out of the
>> drivers/staging/ directory)
>>
>> On Thu, Jul 19, 2012 at 09:22:53PM +0000, KY Srinivasan wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Greg KH (gregkh@linuxfoundation.org)
>>>> [mailto:gregkh@linuxfoundation.org]
>>>> Sent: Thursday, July 19, 2012 5:07 PM
>>>> To: KY Srinivasan
>>>> Cc: Paolo Bonzini; devel@linuxdriverproject.org; linux-
>> kernel@vger.kernel.org;
>>>> virtualization@lists.osdl.org
>>>> Subject: Re: 0xB16B00B5? Really? (was Re: Move hyperv out of the
>>>> drivers/staging/ directory)
>>>>
>>>> On Thu, Jul 19, 2012 at 02:11:47AM +0000, KY Srinivasan wrote:
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Paolo Bonzini [mailto:paolo.bonzini@gmail.com] On Behalf Of Paolo
>>>>>> Bonzini
>>>>>> Sent: Friday, July 13, 2012 6:23 AM
>>>>>> To: KY Srinivasan
>>>>>> Cc: Greg KH; devel@linuxdriverproject.org; linux-kernel@vger.kernel.org;
>>>>>> virtualization@lists.osdl.org
>>>>>> Subject: 0xB16B00B5? Really? (was Re: Move hyperv out of the
>>>> drivers/staging/
>>>>>> directory)
>>>>>>
>>>>>> Il 04/10/2011 21:34, Greg KH ha scritto:
>>>>>>> diff --git a/drivers/staging/hv/hyperv_vmbus.h
>>>> b/drivers/hv/hyperv_vmbus.h
>>>>>>> similarity index 99%
>>>>>>> rename from drivers/staging/hv/hyperv_vmbus.h
>>>>>>> rename to drivers/hv/hyperv_vmbus.h
>>>>>>> index 3d2d836..8261cb6 100644
>>>>>>> --- a/drivers/staging/hv/hyperv_vmbus.h
>>>>>>> +++ b/drivers/hv/hyperv_vmbus.h
>>>>>>> @@ -28,8 +28,7 @@
>>>>>>>   #include<linux/list.h>
>>>>>>>   #include<asm/sync_bitops.h>
>>>>>>>   #include<linux/atomic.h>
>>>>>>> -
>>>>>>> -#include "hyperv.h"
>>>>>>> +#include<linux/hyperv.h>
>>>>>>>
>>>>>>>   /*
>>>>>>>    * The below CPUID leaves are present if
>>>>>> VersionAndFeatures.HypervisorPresent
>>>>>>
>>>>>> git's rename detection snips away this gem:
>>>>>>
>>>>>> +#define HV_LINUX_GUEST_ID_LO		0x00000000
>>>>>> +#define HV_LINUX_GUEST_ID_HI		0xB16B00B5
>>>>>> +#define HV_LINUX_GUEST_ID		(((u64)HV_LINUX_GUEST_ID_HI
>>>>>> <<  32) | \
>>>>>> +					   HV_LINUX_GUEST_ID_LO)
>>>>>>
>>>>>> Somone was trying to be funny, I guess.
>>>>>>
>>>>>> KY, I suppose you have access to Hyper-V code or can ask someone who
>>>> does.
>>>>>> Is this signature actually used in the Hyper-V host code?
>>>>>
>>>>> Paolo,
>>>>>
>>>>> As I noted earlier, this is just a guest ID that needs to be registered with the
>>>>> hypervisor.  Thanks  for reporting this issue and on behalf of Microsoft, I
>> would
>>>>> like to  apologize for this offensive string. I have submitted a patch to fix this
>>>> issue.
>>>>
>>>> You only changed it to be in decimal, you did not change the id at all.
>>>> Is there some reason why you can not change it?  You said there was a
>>>> reserved range of ids that could be used, perhaps just pick another one?
>>>> What is the valid range that can be used here?
>>>
>>> Greg,
>>>
>>> As you know, this ID has been in use for a long time now. While the hypervisor
>>> does not interpret the guest ID that is registered, I am not sure what
>> dependencies
>>> there might be on this value.
>>
>> Could you please go find out the answer to this?
>
> That is easier said than done. I have sent emails out asking this very question and I have
> not received a definitive answer yet. Not knowing if and when I can get a definitive
> answer here, I chose the least risky approach in my patch.
>>
>> If, as you originally stated, there is a range of values we can use,
>> then we should probably use another one, right?
>
> On the Windows side this ID namespace is managed well. However on the Linux
> side, we have really had this current ID in use for almost five years now. I am not
> aware of any pool of IDs available for Linux usage except that Linux IDs be distinct from
> the guest IDs in use by MSFT operating systems. If I were to change the guest ID, I would
> probably want to comply with the MSFT guidance on constructing these IDs (although not
> all fields may be relevant for Linux).

Presumably, Hyper-V can deal with unexpected values here, no?  Otherwise, it 
wouldn't be future proof against new types of guests.

So worst case scenario, Hyper-V disables optimizations on Linux guests that 
report then new ID until they patch Hyper-V to know about the new ID.

That seems like a reasonable trade off to me.  I'm sure there's sufficient 
incentive to patch Hyper-V for this at Microsoft...

Regards,

Anthony Liguori

>
> Regards,
>
> K. Y
>
>
>

RE: 0xB16B00B5? Really? (was Re: Move hyperv out of the drivers/staging/ directory)

[KY Srinivasan]

> -----Original Message-----
> From: Anthony Liguori [mailto:anthony@codemonkey.ws]
> Sent: Thursday, July 19, 2012 7:18 PM
> To: KY Srinivasan
> Cc: Greg KH (gregkh@linuxfoundation.org); Paolo Bonzini;
> devel@linuxdriverproject.org; linux-kernel@vger.kernel.org;
> virtualization@lists.osdl.org
> Subject: Re: 0xB16B00B5? Really? (was Re: Move hyperv out of the
> drivers/staging/ directory)
> 
> On 07/19/2012 05:30 PM, KY Srinivasan wrote:
> >
> >
> >> -----Original Message-----
> >> From: Greg KH (gregkh@linuxfoundation.org)
> >> [mailto:gregkh@linuxfoundation.org]
> >> Sent: Thursday, July 19, 2012 6:02 PM
> >> To: KY Srinivasan
> >> Cc: Paolo Bonzini; devel@linuxdriverproject.org; linux-
> kernel@vger.kernel.org;
> >> virtualization@lists.osdl.org
> >> Subject: Re: 0xB16B00B5? Really? (was Re: Move hyperv out of the
> >> drivers/staging/ directory)
> >>
> >> On Thu, Jul 19, 2012 at 09:22:53PM +0000, KY Srinivasan wrote:
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Greg KH (gregkh@linuxfoundation.org)
> >>>> [mailto:gregkh@linuxfoundation.org]
> >>>> Sent: Thursday, July 19, 2012 5:07 PM
> >>>> To: KY Srinivasan
> >>>> Cc: Paolo Bonzini; devel@linuxdriverproject.org; linux-
> >> kernel@vger.kernel.org;
> >>>> virtualization@lists.osdl.org
> >>>> Subject: Re: 0xB16B00B5? Really? (was Re: Move hyperv out of the
> >>>> drivers/staging/ directory)
> >>>>
> >>>> On Thu, Jul 19, 2012 at 02:11:47AM +0000, KY Srinivasan wrote:
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Paolo Bonzini [mailto:paolo.bonzini@gmail.com] On Behalf Of
> Paolo
> >>>>>> Bonzini
> >>>>>> Sent: Friday, July 13, 2012 6:23 AM
> >>>>>> To: KY Srinivasan
> >>>>>> Cc: Greg KH; devel@linuxdriverproject.org; linux-
> kernel@vger.kernel.org;
> >>>>>> virtualization@lists.osdl.org
> >>>>>> Subject: 0xB16B00B5? Really? (was Re: Move hyperv out of the
> >>>> drivers/staging/
> >>>>>> directory)
> >>>>>>
> >>>>>> Il 04/10/2011 21:34, Greg KH ha scritto:
> >>>>>>> diff --git a/drivers/staging/hv/hyperv_vmbus.h
> >>>> b/drivers/hv/hyperv_vmbus.h
> >>>>>>> similarity index 99%
> >>>>>>> rename from drivers/staging/hv/hyperv_vmbus.h
> >>>>>>> rename to drivers/hv/hyperv_vmbus.h
> >>>>>>> index 3d2d836..8261cb6 100644
> >>>>>>> --- a/drivers/staging/hv/hyperv_vmbus.h
> >>>>>>> +++ b/drivers/hv/hyperv_vmbus.h
> >>>>>>> @@ -28,8 +28,7 @@
> >>>>>>>   #include<linux/list.h>
> >>>>>>>   #include<asm/sync_bitops.h>
> >>>>>>>   #include<linux/atomic.h>
> >>>>>>> -
> >>>>>>> -#include "hyperv.h"
> >>>>>>> +#include<linux/hyperv.h>
> >>>>>>>
> >>>>>>>   /*
> >>>>>>>    * The below CPUID leaves are present if
> >>>>>> VersionAndFeatures.HypervisorPresent
> >>>>>>
> >>>>>> git's rename detection snips away this gem:
> >>>>>>
> >>>>>> +#define HV_LINUX_GUEST_ID_LO		0x00000000
> >>>>>> +#define HV_LINUX_GUEST_ID_HI		0xB16B00B5
> >>>>>> +#define HV_LINUX_GUEST_ID
> 	(((u64)HV_LINUX_GUEST_ID_HI
> >>>>>> <<  32) | \
> >>>>>> +					   HV_LINUX_GUEST_ID_LO)
> >>>>>>
> >>>>>> Somone was trying to be funny, I guess.
> >>>>>>
> >>>>>> KY, I suppose you have access to Hyper-V code or can ask someone who
> >>>> does.
> >>>>>> Is this signature actually used in the Hyper-V host code?
> >>>>>
> >>>>> Paolo,
> >>>>>
> >>>>> As I noted earlier, this is just a guest ID that needs to be registered with
> the
> >>>>> hypervisor.  Thanks  for reporting this issue and on behalf of Microsoft, I
> >> would
> >>>>> like to  apologize for this offensive string. I have submitted a patch to fix
> this
> >>>> issue.
> >>>>
> >>>> You only changed it to be in decimal, you did not change the id at all.
> >>>> Is there some reason why you can not change it?  You said there was a
> >>>> reserved range of ids that could be used, perhaps just pick another one?
> >>>> What is the valid range that can be used here?
> >>>
> >>> Greg,
> >>>
> >>> As you know, this ID has been in use for a long time now. While the
> hypervisor
> >>> does not interpret the guest ID that is registered, I am not sure what
> >> dependencies
> >>> there might be on this value.
> >>
> >> Could you please go find out the answer to this?
> >
> > That is easier said than done. I have sent emails out asking this very question
> and I have
> > not received a definitive answer yet. Not knowing if and when I can get a
> definitive
> > answer here, I chose the least risky approach in my patch.
> >>
> >> If, as you originally stated, there is a range of values we can use,
> >> then we should probably use another one, right?
> >
> > On the Windows side this ID namespace is managed well. However on the Linux
> > side, we have really had this current ID in use for almost five years now. I am
> not
> > aware of any pool of IDs available for Linux usage except that Linux IDs be
> distinct from
> > the guest IDs in use by MSFT operating systems. If I were to change the guest
> ID, I would
> > probably want to comply with the MSFT guidance on constructing these IDs
> (although not
> > all fields may be relevant for Linux).
> 
> Presumably, Hyper-V can deal with unexpected values here, no?  Otherwise, it
> wouldn't be future proof against new types of guests.

Anthony,

As I noted earlier, the current versions of MSFT hypervisors don't interpret the guest ID
value although future versions might. However, this ID may be retrieved from the
parent partition and can be used by the management stack (today).
> 
> So worst case scenario, Hyper-V disables optimizations on Linux guests that
> report then new ID until they patch Hyper-V to know about the new ID.
> 
> That seems like a reasonable trade off to me.  I'm sure there's sufficient
> incentive to patch Hyper-V for this at Microsoft...

This is something I want to do once I am sure that nothing will break.

Regards,

K. Y

Re: 0xB16B00B5? Really? (was Re: Move hyperv out of the drivers/staging/ directory)

[Greg KH (gregkh@linuxfoundation.org)]

On Thu, Jul 19, 2012 at 10:30:38PM +0000, KY Srinivasan wrote:
> > > As you know, this ID has been in use for a long time now. While the hypervisor
> > > does not interpret the guest ID that is registered, I am not sure what
> > dependencies
> > > there might be on this value.
> > 
> > Could you please go find out the answer to this?
> 
> That is easier said than done. I have sent emails out asking this very question and I have
> not received a definitive answer yet. Not knowing if and when I can get a definitive
> answer here, I chose the least risky approach in my patch. 

What happens if you test with different values?

> > If, as you originally stated, there is a range of values we can use,
> > then we should probably use another one, right?
> 
> On the Windows side this ID namespace is managed well.

It is?  How is this managed?  What does this tell the hypervisor?  What
changes with the different values?

> However on the Linux side, we have really had this current ID in use
> for almost five years now. I am not aware of any pool of IDs available
> for Linux usage except that Linux IDs be distinct from the guest IDs
> in use by MSFT operating systems. If I were to change the guest ID, I
> would probably want to comply with the MSFT guidance on constructing
> these IDs (although not all fields may be relevant for Linux).

What are those rules?

thanks,

greg k-h

RE: 0xB16B00B5? Really? (was Re: Move hyperv out of the drivers/staging/ directory)

[KY Srinivasan]

> -----Original Message-----
> From: Greg KH (gregkh@linuxfoundation.org)
> [mailto:gregkh@linuxfoundation.org]
> Sent: Thursday, July 19, 2012 7:29 PM
> To: KY Srinivasan
> Cc: Paolo Bonzini; devel@linuxdriverproject.org; linux-kernel@vger.kernel.org;
> virtualization@lists.osdl.org
> Subject: Re: 0xB16B00B5? Really? (was Re: Move hyperv out of the
> drivers/staging/ directory)
> 
> On Thu, Jul 19, 2012 at 10:30:38PM +0000, KY Srinivasan wrote:
> > > > As you know, this ID has been in use for a long time now. While the
> hypervisor
> > > > does not interpret the guest ID that is registered, I am not sure what
> > > dependencies
> > > > there might be on this value.
> > >
> > > Could you please go find out the answer to this?
> >
> > That is easier said than done. I have sent emails out asking this very question
> and I have
> > not received a definitive answer yet. Not knowing if and when I can get a
> definitive
> > answer here, I chose the least risky approach in my patch.
> 
> What happens if you test with different values?

Nothing and that is not the issue. Current MSFT hypervisors don't interpret this
ID value while future versions might. However, this ID can be retrieved by the parent
partition and can be used by the management stack today (that is what I am told). 
> 
> > > If, as you originally stated, there is a range of values we can use,
> > > then we should probably use another one, right?
> >
> > On the Windows side this ID namespace is managed well.
> 
> It is?  How is this managed?  What does this tell the hypervisor?  What
> changes with the different values?
> 
> > However on the Linux side, we have really had this current ID in use
> > for almost five years now. I am not aware of any pool of IDs available
> > for Linux usage except that Linux IDs be distinct from the guest IDs
> > in use by MSFT operating systems. If I were to change the guest ID, I
> > would probably want to comply with the MSFT guidance on constructing
> > these IDs (although not all fields may be relevant for Linux).
> 
> What are those rules?

Here is the link that describes how the guest ID should be composed:

http://msdn.microsoft.com/en-us/library/windows/hardware/ff542653%28v=vs.85%29.aspx


Regards,

K. Y

Re: 0xB16B00B5? Really? (was Re: Move hyperv out of the drivers/staging/ directory)

[Bjørn Mork]

KY Srinivasan <kys@microsoft.com> writes:

> Here is the link that describes how the guest ID should be composed:
>
> http://msdn.microsoft.com/en-us/library/windows/hardware/ff542653%28v=vs.85%29.aspx

The unwanted value does not conform to those rules:  Linux is not yet at
major version 0xB5.

I propose that you change this into a macro actually taking the OS
major/minor version into account, keeping the 0xB16B vendor ID (which
seems safest as the vendor ID registration process seems a bit unclear)  


Bjørn

[PATCH] drivers: hv: use Linux version in guest ID

[Bjørn Mork]

Use OS version number in the guest ID as recommended by Microsoft

Signed-off-by: Bjørn Mork <bjorn@mork.no>
---
So how about something like this?  Yes, I know including
linux/version.h often is unwanted, but the spec does
recommend using the actual OS version in the guest ID

Yes, this will be offensive again when Linux is at 
version 181.0, but we might have found a better solution by
then :-)


 drivers/hv/hyperv_vmbus.h |   20 ++++++++++++++++----
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index b9426a6..cc0c3f0 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -29,6 +29,7 @@
 #include <asm/sync_bitops.h>
 #include <linux/atomic.h>
 #include <linux/hyperv.h>
+#include <linux/version.h>
 
 /*
  * The below CPUID leaves are present if VersionAndFeatures.HypervisorPresent
@@ -410,10 +411,21 @@ enum {
 
 #define HV_PRESENT_BIT			0x80000000
 
-#define HV_LINUX_GUEST_ID_LO		0x00000000
-#define HV_LINUX_GUEST_ID_HI		0xB16B00B5
-#define HV_LINUX_GUEST_ID		(((u64)HV_LINUX_GUEST_ID_HI << 32) | \
-					   HV_LINUX_GUEST_ID_LO)
+/* Linux vendor ID allocated by Microsoft */
+#define HV_LINUX_GUEST_ID_VENDOR	0xB16B
+
+/* Creating a guest ID conforming to the encoding recommended by
+ * Microsoft, with variant and build fixed to 0
+ *
+ *   63:48 - Vendor ID
+ *   47:40 - OS Variant
+ *   39:32 - Major Version
+ *   31:24 - Minor Version
+ *   23:16 - Service Version
+ *   15:0  - Build Number
+ */
+#define HV_LINUX_GUEST_ID		((u64)HV_LINUX_GUEST_ID_VENDOR << 48 | \
+					 (u64)LINUX_VERSION_CODE << 16)
 
 #define HV_CPU_POWER_MANAGEMENT		(1 << 0)
 #define HV_RECOMMENDATIONS_MAX		4
-- 
1.7.10.4

Re: [PATCH] drivers: hv: use Linux version in guest ID

[Greg KH]

On Fri, Jul 20, 2012 at 10:03:08AM +0200, Bjørn Mork wrote:
> Use OS version number in the guest ID as recommended by Microsoft
> 
> Signed-off-by: Bjørn Mork <bjorn@mork.no>
> ---
> So how about something like this?  Yes, I know including
> linux/version.h often is unwanted, but the spec does
> recommend using the actual OS version in the guest ID
> 
> Yes, this will be offensive again when Linux is at 
> version 181.0, but we might have found a better solution by
> then :-)
> 
> 
>  drivers/hv/hyperv_vmbus.h |   20 ++++++++++++++++----
>  1 file changed, 16 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
> index b9426a6..cc0c3f0 100644
> --- a/drivers/hv/hyperv_vmbus.h
> +++ b/drivers/hv/hyperv_vmbus.h
> @@ -29,6 +29,7 @@
>  #include <asm/sync_bitops.h>
>  #include <linux/atomic.h>
>  #include <linux/hyperv.h>
> +#include <linux/version.h>
>  
>  /*
>   * The below CPUID leaves are present if VersionAndFeatures.HypervisorPresent
> @@ -410,10 +411,21 @@ enum {
>  
>  #define HV_PRESENT_BIT			0x80000000
>  
> -#define HV_LINUX_GUEST_ID_LO		0x00000000
> -#define HV_LINUX_GUEST_ID_HI		0xB16B00B5
> -#define HV_LINUX_GUEST_ID		(((u64)HV_LINUX_GUEST_ID_HI << 32) | \
> -					   HV_LINUX_GUEST_ID_LO)
> +/* Linux vendor ID allocated by Microsoft */
> +#define HV_LINUX_GUEST_ID_VENDOR	0xB16B
> +
> +/* Creating a guest ID conforming to the encoding recommended by
> + * Microsoft, with variant and build fixed to 0

We could use the kernel build number here as well, if we really wanted
it, right?

Otherwise, I like this patch, KY, any objection to me taking it?

thanks,

greg k-h

RE: [PATCH] drivers: hv: use Linux version in guest ID

[KY Srinivasan]

> -----Original Message-----
> From: Greg KH [mailto:gregkh@linuxfoundation.org]
> Sent: Friday, July 20, 2012 11:27 AM
> To: Bjørn Mork
> Cc: KY Srinivasan; Paolo Bonzini; devel@linuxdriverproject.org; linux-
> kernel@vger.kernel.org; virtualization@lists.osdl.org
> Subject: Re: [PATCH] drivers: hv: use Linux version in guest ID
> 
> On Fri, Jul 20, 2012 at 10:03:08AM +0200, Bjørn Mork wrote:
> > Use OS version number in the guest ID as recommended by Microsoft
> >
> > Signed-off-by: Bjørn Mork <bjorn@mork.no>
> > ---
> > So how about something like this?  Yes, I know including
> > linux/version.h often is unwanted, but the spec does
> > recommend using the actual OS version in the guest ID
> >
> > Yes, this will be offensive again when Linux is at
> > version 181.0, but we might have found a better solution by
> > then :-)
> >
> >
> >  drivers/hv/hyperv_vmbus.h |   20 ++++++++++++++++----
> >  1 file changed, 16 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
> > index b9426a6..cc0c3f0 100644
> > --- a/drivers/hv/hyperv_vmbus.h
> > +++ b/drivers/hv/hyperv_vmbus.h
> > @@ -29,6 +29,7 @@
> >  #include <asm/sync_bitops.h>
> >  #include <linux/atomic.h>
> >  #include <linux/hyperv.h>
> > +#include <linux/version.h>
> >
> >  /*
> >   * The below CPUID leaves are present if
> VersionAndFeatures.HypervisorPresent
> > @@ -410,10 +411,21 @@ enum {
> >
> >  #define HV_PRESENT_BIT			0x80000000
> >
> > -#define HV_LINUX_GUEST_ID_LO		0x00000000
> > -#define HV_LINUX_GUEST_ID_HI		0xB16B00B5
> > -#define HV_LINUX_GUEST_ID		(((u64)HV_LINUX_GUEST_ID_HI
> << 32) | \
> > -					   HV_LINUX_GUEST_ID_LO)
> > +/* Linux vendor ID allocated by Microsoft */
> > +#define HV_LINUX_GUEST_ID_VENDOR	0xB16B
> > +
> > +/* Creating a guest ID conforming to the encoding recommended by
> > + * Microsoft, with variant and build fixed to 0
> 
> We could use the kernel build number here as well, if we really wanted
> it, right?
> 
> Otherwise, I like this patch, KY, any objection to me taking it?

Greg,

If it is ok with you can we wait a couple of days. I am pushing to get information
back from folks within MSFT. I am hoping  we can fix this issue soon.

Regards,

K. Y
 

Re: [PATCH] drivers: hv: use Linux version in guest ID

[Greg KH]

On Fri, Jul 20, 2012 at 04:02:44PM +0000, KY Srinivasan wrote:
> > On Fri, Jul 20, 2012 at 10:03:08AM +0200, Bjørn Mork wrote:
> > > Use OS version number in the guest ID as recommended by Microsoft
> > >
> > > Signed-off-by: Bjørn Mork <bjorn@mork.no>
> > > ---
> > > So how about something like this?  Yes, I know including
> > > linux/version.h often is unwanted, but the spec does
> > > recommend using the actual OS version in the guest ID
> > >
> > > Yes, this will be offensive again when Linux is at
> > > version 181.0, but we might have found a better solution by
> > > then :-)
> > >
> > >
> > >  drivers/hv/hyperv_vmbus.h |   20 ++++++++++++++++----
> > >  1 file changed, 16 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
> > > index b9426a6..cc0c3f0 100644
> > > --- a/drivers/hv/hyperv_vmbus.h
> > > +++ b/drivers/hv/hyperv_vmbus.h
> > > @@ -29,6 +29,7 @@
> > >  #include <asm/sync_bitops.h>
> > >  #include <linux/atomic.h>
> > >  #include <linux/hyperv.h>
> > > +#include <linux/version.h>
> > >
> > >  /*
> > >   * The below CPUID leaves are present if
> > VersionAndFeatures.HypervisorPresent
> > > @@ -410,10 +411,21 @@ enum {
> > >
> > >  #define HV_PRESENT_BIT			0x80000000
> > >
> > > -#define HV_LINUX_GUEST_ID_LO		0x00000000
> > > -#define HV_LINUX_GUEST_ID_HI		0xB16B00B5
> > > -#define HV_LINUX_GUEST_ID		(((u64)HV_LINUX_GUEST_ID_HI
> > << 32) | \
> > > -					   HV_LINUX_GUEST_ID_LO)
> > > +/* Linux vendor ID allocated by Microsoft */
> > > +#define HV_LINUX_GUEST_ID_VENDOR	0xB16B
> > > +
> > > +/* Creating a guest ID conforming to the encoding recommended by
> > > + * Microsoft, with variant and build fixed to 0
> > 
> > We could use the kernel build number here as well, if we really wanted
> > it, right?
> > 
> > Otherwise, I like this patch, KY, any objection to me taking it?
> 
> Greg,
> 
> If it is ok with you can we wait a couple of days. I am pushing to get information
> back from folks within MSFT. I am hoping  we can fix this issue soon.

Ok, I'll hold on to it for a week or so.

thanks,

greg k-h

RE: [PATCH] drivers: hv: use Linux version in guest ID

[KY Srinivasan]

> -----Original Message-----
> From: Greg KH [mailto:gregkh@linuxfoundation.org]
> Sent: Friday, July 20, 2012 12:10 PM
> To: KY Srinivasan
> Cc: Bjørn Mork; Paolo Bonzini; devel@linuxdriverproject.org; linux-
> kernel@vger.kernel.org
> Subject: Re: [PATCH] drivers: hv: use Linux version in guest ID
> 
> On Fri, Jul 20, 2012 at 04:02:44PM +0000, KY Srinivasan wrote:
> > > On Fri, Jul 20, 2012 at 10:03:08AM +0200, Bjørn Mork wrote:
> > > > Use OS version number in the guest ID as recommended by Microsoft
> > > >
> > > > Signed-off-by: Bjørn Mork <bjorn@mork.no>
> > > > ---
> > > > So how about something like this?  Yes, I know including
> > > > linux/version.h often is unwanted, but the spec does
> > > > recommend using the actual OS version in the guest ID
> > > >
> > > > Yes, this will be offensive again when Linux is at
> > > > version 181.0, but we might have found a better solution by
> > > > then :-)
> > > >
> > > >
> > > >  drivers/hv/hyperv_vmbus.h |   20 ++++++++++++++++----
> > > >  1 file changed, 16 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
> > > > index b9426a6..cc0c3f0 100644
> > > > --- a/drivers/hv/hyperv_vmbus.h
> > > > +++ b/drivers/hv/hyperv_vmbus.h
> > > > @@ -29,6 +29,7 @@
> > > >  #include <asm/sync_bitops.h>
> > > >  #include <linux/atomic.h>
> > > >  #include <linux/hyperv.h>
> > > > +#include <linux/version.h>
> > > >
> > > >  /*
> > > >   * The below CPUID leaves are present if
> > > VersionAndFeatures.HypervisorPresent
> > > > @@ -410,10 +411,21 @@ enum {
> > > >
> > > >  #define HV_PRESENT_BIT			0x80000000
> > > >
> > > > -#define HV_LINUX_GUEST_ID_LO		0x00000000
> > > > -#define HV_LINUX_GUEST_ID_HI		0xB16B00B5
> > > > -#define HV_LINUX_GUEST_ID		(((u64)HV_LINUX_GUEST_ID_HI
> > > << 32) | \
> > > > -					   HV_LINUX_GUEST_ID_LO)
> > > > +/* Linux vendor ID allocated by Microsoft */
> > > > +#define HV_LINUX_GUEST_ID_VENDOR	0xB16B
> > > > +
> > > > +/* Creating a guest ID conforming to the encoding recommended by
> > > > + * Microsoft, with variant and build fixed to 0
> > >
> > > We could use the kernel build number here as well, if we really wanted
> > > it, right?
> > >
> > > Otherwise, I like this patch, KY, any objection to me taking it?
> >
> > Greg,
> >
> > If it is ok with you can we wait a couple of days. I am pushing to get information
> > back from folks within MSFT. I am hoping  we can fix this issue soon.
> 
> Ok, I'll hold on to it for a week or so.

Greg,

While there is some dependency on the current Linux guest ID, we will go ahead and
change the guest ID for Linux to conform to MSFT documented guidelines. Over the next
couple of days, we are planning on finalizing the ID namespace for non-windows guests
on Hyper-V. I will post our proposal on this mailing list soon. 

Regards,

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

Re: [PATCH] drivers: hv: use Linux version in guest ID

[Bjørn Mork]

Greg KH <gregkh@linuxfoundation.org> writes:
> On Fri, Jul 20, 2012 at 04:02:44PM +0000, KY Srinivasan wrote:
>> > On Fri, Jul 20, 2012 at 10:03:08AM +0200, Bjørn Mork wrote:
>> >
>> > > +/* Linux vendor ID allocated by Microsoft */
>> > > +#define HV_LINUX_GUEST_ID_VENDOR	0xB16B
>> > > +
>> > > +/* Creating a guest ID conforming to the encoding recommended by
>> > > + * Microsoft, with variant and build fixed to 0
>> > 
>> > We could use the kernel build number here as well, if we really wanted
>> > it, right?

Yes, we could.  I just didn't see any value it that. Why would you want
your hypervisor to care about some arbitrary build number?

But it can of course be added if anyone needs it.

>> > Otherwise, I like this patch, KY, any objection to me taking it?
>> 
>> Greg,
>> 
>> If it is ok with you can we wait a couple of days. I am pushing to get information
>> back from folks within MSFT. I am hoping  we can fix this issue soon.
>
> Ok, I'll hold on to it for a week or so.

Not to nag or anything like that, but ... It's been a week or so now,
hasn't it? :-)


Bjørn

RE: [PATCH] drivers: hv: use Linux version in guest ID

[KY Srinivasan]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1754 bytes --]



> -----Original Message-----
> From: Bjørn Mork [mailto:bjorn@mork.no]
> Sent: Monday, August 13, 2012 9:00 AM
> To: Greg KH
> Cc: KY Srinivasan; Paolo Bonzini; devel@linuxdriverproject.org; linux-
> kernel@vger.kernel.org
> Subject: Re: [PATCH] drivers: hv: use Linux version in guest ID
> 
> Greg KH <gregkh@linuxfoundation.org> writes:
> > On Fri, Jul 20, 2012 at 04:02:44PM +0000, KY Srinivasan wrote:
> >> > On Fri, Jul 20, 2012 at 10:03:08AM +0200, Bjørn Mork wrote:
> >> >
> >> > > +/* Linux vendor ID allocated by Microsoft */
> >> > > +#define HV_LINUX_GUEST_ID_VENDOR	0xB16B
> >> > > +
> >> > > +/* Creating a guest ID conforming to the encoding recommended by
> >> > > + * Microsoft, with variant and build fixed to 0
> >> >
> >> > We could use the kernel build number here as well, if we really wanted
> >> > it, right?
> 
> Yes, we could.  I just didn't see any value it that. Why would you want
> your hypervisor to care about some arbitrary build number?
> 
> But it can of course be added if anyone needs it.
> 
> >> > Otherwise, I like this patch, KY, any objection to me taking it?
> >>
> >> Greg,
> >>
> >> If it is ok with you can we wait a couple of days. I am pushing to get
> information
> >> back from folks within MSFT. I am hoping  we can fix this issue soon.
> >
> > Ok, I'll hold on to it for a week or so.
> 
> Not to nag or anything like that, but ... It's been a week or so now,
> hasn't it? :-)

In the interim, I have submitted a patch that conforms to the MSFT guidelines
for generating guest IDs for non-MSFT operating systems on Hyper-V.

Regards,

K. Y
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: [PATCH] drivers: hv: use Linux version in guest ID

[Bjørn Mork]

KY Srinivasan <kys@microsoft.com> writes:

> In the interim, I have submitted a patch that conforms to the MSFT guidelines
> for generating guest IDs for non-MSFT operating systems on Hyper-V.

Oh, sorry.  I missed that.  Found it now.  Thanks

Including distro info in a driver interface looks a bit weird to me, but
I don't really care as long as the previous static value goes away.


Bjørn

RE: [PATCH] drivers: hv: use Linux version in guest ID

[KY Srinivasan]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 919 bytes --]



> -----Original Message-----
> From: Bjørn Mork [mailto:bjorn@mork.no]
> Sent: Monday, August 13, 2012 9:33 AM
> To: KY Srinivasan
> Cc: Greg KH; Paolo Bonzini; devel@linuxdriverproject.org; linux-
> kernel@vger.kernel.org
> Subject: Re: [PATCH] drivers: hv: use Linux version in guest ID
> 
> KY Srinivasan <kys@microsoft.com> writes:
> 
> > In the interim, I have submitted a patch that conforms to the MSFT guidelines
> > for generating guest IDs for non-MSFT operating systems on Hyper-V.
> 
> Oh, sorry.  I missed that.  Found it now.  Thanks
> 
> Including distro info in a driver interface looks a bit weird to me, but
> I don't really care as long as the previous static value goes away.
This is optional and does not need to be populated.

K. Y


ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

RE: 0xB16B00B5? Really? (was Re: Move hyperv out of the drivers/staging/ directory)

[KY Srinivasan]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1252 bytes --]



> -----Original Message-----
> From: Bjørn Mork [mailto:bjorn@mork.no]
> Sent: Friday, July 20, 2012 3:59 AM
> To: KY Srinivasan
> Cc: Greg KH (gregkh@linuxfoundation.org); Paolo Bonzini;
> devel@linuxdriverproject.org; linux-kernel@vger.kernel.org;
> virtualization@lists.osdl.org
> Subject: Re: 0xB16B00B5? Really? (was Re: Move hyperv out of the
> drivers/staging/ directory)
> 
> KY Srinivasan <kys@microsoft.com> writes:
> 
> > Here is the link that describes how the guest ID should be composed:
> >
> > http://msdn.microsoft.com/en-
> us/library/windows/hardware/ff542653%28v=vs.85%29.aspx
> 
> The unwanted value does not conform to those rules:  Linux is not yet at
> major version 0xB5.
> 
> I propose that you change this into a macro actually taking the OS
> major/minor version into account, keeping the 0xB16B vendor ID (which
> seems safest as the vendor ID registration process seems a bit unclear)

Thank you for your interest in fixing this problem. When we decide to change this
ID, we will conform to the MSFT guidelines on constructing this guest ID.

Regards,

K. Y

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: 0xB16B00B5? Really? (was Re: Move hyperv out of the drivers/staging/ directory)

[richard -rw- weinberger]

On Fri, Jul 20, 2012 at 4:00 PM, KY Srinivasan <kys@microsoft.com> wrote:
> Thank you for your interest in fixing this problem. When we decide to change this
> ID, we will conform to the MSFT guidelines on constructing this guest ID.
>

I'm wondering why it hasn't been conform to the MSFT guidelines from
the very beginning on?

-- 
Thanks,
//richard

RE: 0xB16B00B5? Really? (was Re: Move hyperv out of the drivers/staging/ directory)

[KY Srinivasan]

> -----Original Message-----
> From: richard -rw- weinberger [mailto:richard.weinberger@gmail.com]
> Sent: Friday, July 20, 2012 11:04 AM
> To: KY Srinivasan
> Cc: Bjørn Mork; Greg KH (gregkh@linuxfoundation.org); Paolo Bonzini;
> devel@linuxdriverproject.org; linux-kernel@vger.kernel.org;
> virtualization@lists.osdl.org
> Subject: Re: 0xB16B00B5? Really? (was Re: Move hyperv out of the
> drivers/staging/ directory)
> 
> On Fri, Jul 20, 2012 at 4:00 PM, KY Srinivasan <kys@microsoft.com> wrote:
> > Thank you for your interest in fixing this problem. When we decide to change
> this
> > ID, we will conform to the MSFT guidelines on constructing this guest ID.
> >
> 
> I'm wondering why it hasn't been conform to the MSFT guidelines from
> the very beginning on?

Great question; this was before my time in MSFT and so I cannot answer that.

Regards,

 

Re: 0xB16B00B5? Really? (was Re: Move hyperv out of the drivers/staging/ directory)

[valdis.kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1160 bytes --]

On Fri, 20 Jul 2012 17:03:59 +0200, richard -rw- weinberger said:
> On Fri, Jul 20, 2012 at 4:00 PM, KY Srinivasan <kys@microsoft.com> wrote:
> > Thank you for your interest in fixing this problem. When we decide to change this
> > ID, we will conform to the MSFT guidelines on constructing this guest ID.
> >
>
> I'm wondering why it hasn't been conform to the MSFT guidelines from
> the very beginning on?

It's a lot easier to sneak something cute into code when it isn't maintained in
git repositories and mailing lists readable by everybody and their pet llama.

I'll admit to not doing a *lot* of extensive review, but I try to at least read
Kconfig patches (mostly out of self-defense so when I do a 'make oldconfig' I
get presented with something useful ;)  - and it's amazing how often I spot
issues in stuff that's presumably already had several pair of eyeballs look at
it already.

Probably what happened - some programmer had a 60 hour week, wrote the code on
a Friday and had a sudden attack of the sillies, and it went through a code
review meeting, but they had to cover 800 lines of code in a one-hour meeting
so nobody looked *too* close...


[-- Attachment #2: Type: application/pgp-signature, Size: 865 bytes --]

Hyper-V TODO file

[K. Y. Srinivasan]

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".

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".

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".

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"

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".

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. 

Regards,

K. Y

Re: Hyper-V TODO file

[Peter Foley]

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.

Thanks,

Peter Foley

Re: Hyper-V TODO file

[Greg KH]

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

RE: Hyper-V TODO file

[KY Srinivasan]

> -----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

RE: Hyper-V TODO file

[KY Srinivasan]

> -----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

Re: Hyper-V TODO file

[Greg KH]

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

Re: Hyper-V TODO file

[Greg KH]

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.

> 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.

> 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.

> 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.

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 k-h

Re: Hyper-V TODO file

[Greg KH]

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

RE: Hyper-V TODO file

[KY Srinivasan]

> -----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

Re: Hyper-V TODO file

[Greg KH]

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

RE: Hyper-V TODO file

[KY Srinivasan]

> -----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

Re: Hyper-V TODO file

[Greg KH]

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

RE: Hyper-V TODO file

[KY Srinivasan]

> -----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

RE: Hyper-V TODO file

[KY Srinivasan]

> -----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