[PATCH 0/4] Remove support for Hyper-V 2008 and 2008R2/Win7

[PATCH 0/4] Remove support for Hyper-V 2008 and 2008R2/Win7

[Michael Kelley]

Linux code for running as a Hyper-V guest includes special cases for the
first released versions of Hyper-V: 2008 and 2008R2/Windows 7. These
versions were very thinly used for running Linux guests when first
released more than 12 years ago, and they are now out of support
(except for extended security updates). As initial versions, they
lack the performance features needed for effective production usage
of Linux guests. In total, there's no need to continue to support
the latest Linux kernels on these versions of Hyper-V.

Simplify the code for running on Hyper-V by removing the special
cases. This includes removing the negotiation of the VMbus protocol
versions for 2008 and 2008R2, and the special case code based on
those VMbus protocol versions. Changes are in the core VMbus code and
several drivers for synthetic VMbus devices.

Some drivers have driver-specific protocols with the Hyper-V host and
may have versions of those protocols that are limited to 2008 and
2008R2. This patch set does the clean-up only for the top-level
VMbus protocol versions, and not the driver-specific protocols.
Cleaning up the driver-specific protocols can be done with
follow-on patches.

There's no specific urgency to removing the special case code for
2008 and 2008R2, so if the broader Linux kernel community surfaces
a reason why this clean-up should not be done now, we can wait.
But I think we want to eventually stop carrying around this extra
baggage, and based on discussions with the Hyper-V team within
Microsoft, we're already past the point that it has any value.

Michael Kelley (4):
  Drivers: hv: vmbus: Remove support for Hyper-V 2008 and Hyper-V
    2008R2/Win7
  scsi: storvsc: Remove support for Hyper-V 2008 and 2008R2/Win7
  video: hyperv_fb: Remove support for Hyper-V 2008 and 2008R2/Win7
  drm/hyperv: Remove support for Hyper-V 2008 and 2008R2/Win7

 drivers/gpu/drm/hyperv/hyperv_drm_proto.c | 23 ++++--------
 drivers/hv/channel_mgmt.c                 | 29 ++++++---------
 drivers/hv/connection.c                   |  6 ++--
 drivers/hv/vmbus_drv.c                    | 60 +++++++------------------------
 drivers/scsi/storvsc_drv.c                | 36 +++++--------------
 drivers/video/fbdev/hyperv_fb.c           | 23 ++----------
 include/linux/hyperv.h                    | 10 ++++--
 7 files changed, 52 insertions(+), 135 deletions(-)

-- 
1.8.3.1

[PATCH 1/4] Drivers: hv: vmbus: Remove support for Hyper-V 2008 and Hyper-V 2008R2/Win7

[Michael Kelley]

The VMbus driver has special case code for running on the first released
versions of Hyper-V: 2008 and 2008 R2/Windows 7. These versions are now
out of support (except for extended security updates) and lack the
performance features needed for effective production usage of Linux
guests.

Simplify the code by removing the negotiation of the VMbus protocol
versions required for these releases of Hyper-V, and by removing the
special case code for handling these VMbus protocol versions.

Signed-off-by: Michael Kelley <mikelley@microsoft.com>
---
 drivers/hv/channel_mgmt.c | 29 +++++++++--------------
 drivers/hv/connection.c   |  6 ++---
 drivers/hv/vmbus_drv.c    | 60 ++++++++++-------------------------------------
 include/linux/hyperv.h    | 10 +++++---
 4 files changed, 33 insertions(+), 72 deletions(-)

diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 85a2142..575459a 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -713,15 +713,13 @@ static bool hv_cpuself_used(u32 cpu, struct vmbus_channel *chn)
 static int next_numa_node_id;
 
 /*
- * Starting with Win8, we can statically distribute the incoming
- * channel interrupt load by binding a channel to VCPU.
+ * We can statically distribute the incoming channel interrupt load
+ * by binding a channel to VCPU.
  *
- * For pre-win8 hosts or non-performance critical channels we assign the
- * VMBUS_CONNECT_CPU.
- *
- * Starting with win8, performance critical channels will be distributed
- * evenly among all the available NUMA nodes.  Once the node is assigned,
- * we will assign the CPU based on a simple round robin scheme.
+ * For non-performance critical channels we assign the VMBUS_CONNECT_CPU.
+ * Performance critical channels will be distributed evenly among all
+ * the available NUMA nodes.  Once the node is assigned, we will assign
+ * the CPU based on a simple round robin scheme.
  */
 static void init_vp_index(struct vmbus_channel *channel)
 {
@@ -732,13 +730,10 @@ static void init_vp_index(struct vmbus_channel *channel)
 	u32 target_cpu;
 	int numa_node;
 
-	if ((vmbus_proto_version == VERSION_WS2008) ||
-	    (vmbus_proto_version == VERSION_WIN7) || (!perf_chn) ||
+	if (!perf_chn ||
 	    !alloc_cpumask_var(&available_mask, GFP_KERNEL)) {
 		/*
-		 * Prior to win8, all channel interrupts are
-		 * delivered on VMBUS_CONNECT_CPU.
-		 * Also if the channel is not a performance critical
+		 * If the channel is not a performance critical
 		 * channel, bind it to VMBUS_CONNECT_CPU.
 		 * In case alloc_cpumask_var() fails, bind it to
 		 * VMBUS_CONNECT_CPU.
@@ -931,11 +926,9 @@ static void vmbus_setup_channel_state(struct vmbus_channel *channel,
 	 */
 	channel->sig_event = VMBUS_EVENT_CONNECTION_ID;
 
-	if (vmbus_proto_version != VERSION_WS2008) {
-		channel->is_dedicated_interrupt =
-				(offer->is_dedicated_interrupt != 0);
-		channel->sig_event = offer->connection_id;
-	}
+	channel->is_dedicated_interrupt =
+			(offer->is_dedicated_interrupt != 0);
+	channel->sig_event = offer->connection_id;
 
 	memcpy(&channel->offermsg, offer,
 	       sizeof(struct vmbus_channel_offer_channel));
diff --git a/drivers/hv/connection.c b/drivers/hv/connection.c
index a3d8be8..6218bbf 100644
--- a/drivers/hv/connection.c
+++ b/drivers/hv/connection.c
@@ -47,6 +47,8 @@ struct vmbus_connection vmbus_connection = {
 
 /*
  * Table of VMBus versions listed from newest to oldest.
+ * VERSION_WIN7 and VERSION_WS2008 are no longer supported in
+ * Linux guests and are not listed.
  */
 static __u32 vmbus_versions[] = {
 	VERSION_WIN10_V5_3,
@@ -56,9 +58,7 @@ struct vmbus_connection vmbus_connection = {
 	VERSION_WIN10_V4_1,
 	VERSION_WIN10,
 	VERSION_WIN8_1,
-	VERSION_WIN8,
-	VERSION_WIN7,
-	VERSION_WS2008
+	VERSION_WIN8
 };
 
 /*
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 14de170..9c1b3620 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -1263,23 +1263,17 @@ static void vmbus_chan_sched(struct hv_per_cpu_context *hv_cpu)
 	unsigned long *recv_int_page;
 	u32 maxbits, relid;
 
-	if (vmbus_proto_version < VERSION_WIN8) {
-		maxbits = MAX_NUM_CHANNELS_SUPPORTED;
-		recv_int_page = vmbus_connection.recv_int_page;
-	} else {
-		/*
-		 * When the host is win8 and beyond, the event page
-		 * can be directly checked to get the id of the channel
-		 * that has the interrupt pending.
-		 */
-		void *page_addr = hv_cpu->synic_event_page;
-		union hv_synic_event_flags *event
-			= (union hv_synic_event_flags *)page_addr +
-						 VMBUS_MESSAGE_SINT;
+	/*
+	 * The event page can be directly checked to get the id of
+	 * the channel that has the interrupt pending.
+	 */
+	void *page_addr = hv_cpu->synic_event_page;
+	union hv_synic_event_flags *event
+		= (union hv_synic_event_flags *)page_addr +
+					 VMBUS_MESSAGE_SINT;
 
-		maxbits = HV_EVENT_FLAGS_COUNT;
-		recv_int_page = event->flags;
-	}
+	maxbits = HV_EVENT_FLAGS_COUNT;
+	recv_int_page = event->flags;
 
 	if (unlikely(!recv_int_page))
 		return;
@@ -1351,40 +1345,10 @@ static void vmbus_isr(void)
 {
 	struct hv_per_cpu_context *hv_cpu
 		= this_cpu_ptr(hv_context.cpu_context);
-	void *page_addr = hv_cpu->synic_event_page;
+	void *page_addr;
 	struct hv_message *msg;
-	union hv_synic_event_flags *event;
-	bool handled = false;
-
-	if (unlikely(page_addr == NULL))
-		return;
-
-	event = (union hv_synic_event_flags *)page_addr +
-					 VMBUS_MESSAGE_SINT;
-	/*
-	 * Check for events before checking for messages. This is the order
-	 * in which events and messages are checked in Windows guests on
-	 * Hyper-V, and the Windows team suggested we do the same.
-	 */
-
-	if ((vmbus_proto_version == VERSION_WS2008) ||
-		(vmbus_proto_version == VERSION_WIN7)) {
-
-		/* Since we are a child, we only need to check bit 0 */
-		if (sync_test_and_clear_bit(0, event->flags))
-			handled = true;
-	} else {
-		/*
-		 * Our host is win8 or above. The signaling mechanism
-		 * has changed and we can directly look at the event page.
-		 * If bit n is set then we have an interrup on the channel
-		 * whose id is n.
-		 */
-		handled = true;
-	}
 
-	if (handled)
-		vmbus_chan_sched(hv_cpu);
+	vmbus_chan_sched(hv_cpu);
 
 	page_addr = hv_cpu->synic_message_page;
 	msg = (struct hv_message *)page_addr + VMBUS_MESSAGE_SINT;
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index fe2e017..9a4ac13 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -230,15 +230,19 @@ static inline u32 hv_get_avail_to_write_percent(
  * two 16 bit quantities: major_number. minor_number.
  *
  * 0 . 13 (Windows Server 2008)
- * 1 . 1  (Windows 7)
- * 2 . 4  (Windows 8)
- * 3 . 0  (Windows 8 R2)
+ * 1 . 1  (Windows 7, WS2008 R2)
+ * 2 . 4  (Windows 8, WS2012)
+ * 3 . 0  (Windows 8.1, WS2012 R2)
  * 4 . 0  (Windows 10)
  * 4 . 1  (Windows 10 RS3)
  * 5 . 0  (Newer Windows 10)
  * 5 . 1  (Windows 10 RS4)
  * 5 . 2  (Windows Server 2019, RS5)
  * 5 . 3  (Windows Server 2022)
+ *
+ * The WS2008 and WIN7 versions are listed here for
+ * completeness but are no longer supported in the
+ * Linux kernel.
  */
 
 #define VERSION_WS2008  ((0 << 16) | (13))
-- 
1.8.3.1

[PATCH 2/4] scsi: storvsc: Remove support for Hyper-V 2008 and 2008R2/Win7

[Michael Kelley]

The storvsc driver has special case code for running on the first released
versions of Hyper-V: 2008 and 2008 R2/Windows 7.  These versions are now
out of support (except for extended security updates) and lack support
for performance features like multiple VMbus channels that are needed for
effective production usage of Linux guests.

The negotiation of the VMbus protocol versions required by these old
Hyper-V versions has been removed from the VMbus driver.  So now remove
the handling of these VMbus protocol versions from the storvsc driver.

Signed-off-by: Michael Kelley <mikelley@microsoft.com>
---
 drivers/scsi/storvsc_drv.c | 36 +++++++++---------------------------
 1 file changed, 9 insertions(+), 27 deletions(-)

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 9a0bba5..5585e9d 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1966,34 +1966,16 @@ static int storvsc_probe(struct hv_device *device,
 	bool is_fc = ((dev_id->driver_data == SFC_GUID) ? true : false);
 	int target = 0;
 	struct storvsc_device *stor_device;
-	int max_luns_per_target;
-	int max_targets;
-	int max_channels;
 	int max_sub_channels = 0;
 
 	/*
-	 * Based on the windows host we are running on,
-	 * set state to properly communicate with the host.
+	 * We support sub-channels for storage on SCSI and FC controllers.
+	 * The number of sub-channels offerred is based on the number of
+	 * VCPUs in the guest.
 	 */
-
-	if (vmbus_proto_version < VERSION_WIN8) {
-		max_luns_per_target = STORVSC_IDE_MAX_LUNS_PER_TARGET;
-		max_targets = STORVSC_IDE_MAX_TARGETS;
-		max_channels = STORVSC_IDE_MAX_CHANNELS;
-	} else {
-		max_luns_per_target = STORVSC_MAX_LUNS_PER_TARGET;
-		max_targets = STORVSC_MAX_TARGETS;
-		max_channels = STORVSC_MAX_CHANNELS;
-		/*
-		 * On Windows8 and above, we support sub-channels for storage
-		 * on SCSI and FC controllers.
-		 * The number of sub-channels offerred is based on the number of
-		 * VCPUs in the guest.
-		 */
-		if (!dev_is_ide)
-			max_sub_channels =
-				(num_cpus - 1) / storvsc_vcpus_per_sub_channel;
-	}
+	if (!dev_is_ide)
+		max_sub_channels =
+			(num_cpus - 1) / storvsc_vcpus_per_sub_channel;
 
 	scsi_driver.can_queue = max_outstanding_req_per_channel *
 				(max_sub_channels + 1) *
@@ -2046,9 +2028,9 @@ static int storvsc_probe(struct hv_device *device,
 		break;
 
 	case SCSI_GUID:
-		host->max_lun = max_luns_per_target;
-		host->max_id = max_targets;
-		host->max_channel = max_channels - 1;
+		host->max_lun = STORVSC_MAX_LUNS_PER_TARGET;
+		host->max_id = STORVSC_MAX_TARGETS;
+		host->max_channel = STORVSC_MAX_CHANNELS - 1;
 		break;
 
 	default:
-- 
1.8.3.1

[PATCH 3/4] video: hyperv_fb: Remove support for Hyper-V 2008 and 2008R2/Win7

[Michael Kelley]

The hyperv_fb driver has special case code for running on the first
released versions of Hyper-V: 2008 and 2008 R2/Windows 7.  These versions
are now out of support (except for extended security updates) and lack
support for performance features that are needed for effective production
usage of Linux guests.

The negotiation of the VMbus protocol versions required by these old
Hyper-V versions has been removed from the VMbus driver.  So now remove
the handling of these VMbus protocol versions from the hyperv_fb driver.

Signed-off-by: Michael Kelley <mikelley@microsoft.com>
---
 drivers/video/fbdev/hyperv_fb.c | 23 +++--------------------
 1 file changed, 3 insertions(+), 20 deletions(-)

diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
index c8e0ea2..7563d54 100644
--- a/drivers/video/fbdev/hyperv_fb.c
+++ b/drivers/video/fbdev/hyperv_fb.c
@@ -63,6 +63,7 @@
 #define MAX_VMBUS_PKT_SIZE 0x4000
 
 #define SYNTHVID_VERSION(major, minor) ((minor) << 16 | (major))
+/* Support for VERSION_WIN7 is removed. #define is retained for reference. */
 #define SYNTHVID_VERSION_WIN7 SYNTHVID_VERSION(3, 0)
 #define SYNTHVID_VERSION_WIN8 SYNTHVID_VERSION(3, 2)
 #define SYNTHVID_VERSION_WIN10 SYNTHVID_VERSION(3, 5)
@@ -70,13 +71,7 @@
 #define SYNTHVID_VER_GET_MAJOR(ver) (ver & 0x0000ffff)
 #define SYNTHVID_VER_GET_MINOR(ver) ((ver & 0xffff0000) >> 16)
 
-#define SYNTHVID_DEPTH_WIN7 16
 #define SYNTHVID_DEPTH_WIN8 32
-
-#define SYNTHVID_FB_SIZE_WIN7 (4 * 1024 * 1024)
-#define SYNTHVID_WIDTH_MAX_WIN7 1600
-#define SYNTHVID_HEIGHT_MAX_WIN7 1200
-
 #define SYNTHVID_FB_SIZE_WIN8 (8 * 1024 * 1024)
 
 #define PCI_VENDOR_ID_MICROSOFT 0x1414
@@ -644,12 +639,6 @@ static int synthvid_connect_vsp(struct hv_device *hdev)
 	case VERSION_WIN8:
 	case VERSION_WIN8_1:
 		ret = synthvid_negotiate_ver(hdev, SYNTHVID_VERSION_WIN8);
-		if (!ret)
-			break;
-		fallthrough;
-	case VERSION_WS2008:
-	case VERSION_WIN7:
-		ret = synthvid_negotiate_ver(hdev, SYNTHVID_VERSION_WIN7);
 		break;
 	default:
 		ret = synthvid_negotiate_ver(hdev, SYNTHVID_VERSION_WIN10);
@@ -661,11 +650,7 @@ static int synthvid_connect_vsp(struct hv_device *hdev)
 		goto error;
 	}
 
-	if (par->synthvid_version == SYNTHVID_VERSION_WIN7)
-		screen_depth = SYNTHVID_DEPTH_WIN7;
-	else
-		screen_depth = SYNTHVID_DEPTH_WIN8;
-
+	screen_depth = SYNTHVID_DEPTH_WIN8;
 	if (synthvid_ver_ge(par->synthvid_version, SYNTHVID_VERSION_WIN10)) {
 		ret = synthvid_get_supported_resolution(hdev);
 		if (ret)
@@ -933,9 +918,7 @@ static void hvfb_get_option(struct fb_info *info)
 	    (synthvid_ver_ge(par->synthvid_version, SYNTHVID_VERSION_WIN10) &&
 	    (x * y * screen_depth / 8 > screen_fb_size)) ||
 	    (par->synthvid_version == SYNTHVID_VERSION_WIN8 &&
-	     x * y * screen_depth / 8 > SYNTHVID_FB_SIZE_WIN8) ||
-	    (par->synthvid_version == SYNTHVID_VERSION_WIN7 &&
-	     (x > SYNTHVID_WIDTH_MAX_WIN7 || y > SYNTHVID_HEIGHT_MAX_WIN7))) {
+	     x * y * screen_depth / 8 > SYNTHVID_FB_SIZE_WIN8)) {
 		pr_err("Screen resolution option is out of range: skipped\n");
 		return;
 	}
-- 
1.8.3.1

[PATCH 4/4] drm/hyperv: Remove support for Hyper-V 2008 and 2008R2/Win7

[Michael Kelley]

The DRM Hyper-V driver has special case code for running on the first
released versions of Hyper-V: 2008 and 2008 R2/Windows 7.  These versions
are now out of support (except for extended security updates) and lack
support for performance features that are needed for effective production
usage of Linux guests.

The negotiation of the VMbus protocol versions required by these old
Hyper-V versions has been removed from the VMbus driver.  So now remove
the handling of these VMbus protocol versions from the DRM Hyper-V
driver.

Signed-off-by: Michael Kelley <mikelley@microsoft.com>
---
 drivers/gpu/drm/hyperv/hyperv_drm_proto.c | 23 +++++++----------------
 1 file changed, 7 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_proto.c b/drivers/gpu/drm/hyperv/hyperv_drm_proto.c
index c0155c6..76a182a 100644
--- a/drivers/gpu/drm/hyperv/hyperv_drm_proto.c
+++ b/drivers/gpu/drm/hyperv/hyperv_drm_proto.c
@@ -18,16 +18,16 @@
 #define SYNTHVID_VERSION(major, minor) ((minor) << 16 | (major))
 #define SYNTHVID_VER_GET_MAJOR(ver) (ver & 0x0000ffff)
 #define SYNTHVID_VER_GET_MINOR(ver) ((ver & 0xffff0000) >> 16)
+
+/* Support for VERSION_WIN7 is removed. #define is retained for reference. */
 #define SYNTHVID_VERSION_WIN7 SYNTHVID_VERSION(3, 0)
 #define SYNTHVID_VERSION_WIN8 SYNTHVID_VERSION(3, 2)
 #define SYNTHVID_VERSION_WIN10 SYNTHVID_VERSION(3, 5)
 
-#define SYNTHVID_DEPTH_WIN7 16
 #define SYNTHVID_DEPTH_WIN8 32
-#define SYNTHVID_FB_SIZE_WIN7 (4 * 1024 * 1024)
+#define SYNTHVID_WIDTH_WIN8 1600
+#define SYNTHVID_HEIGHT_WIN8 1200
 #define SYNTHVID_FB_SIZE_WIN8 (8 * 1024 * 1024)
-#define SYNTHVID_WIDTH_MAX_WIN7 1600
-#define SYNTHVID_HEIGHT_MAX_WIN7 1200
 
 enum pipe_msg_type {
 	PIPE_MSG_INVALID,
@@ -496,12 +496,6 @@ int hyperv_connect_vsp(struct hv_device *hdev)
 	case VERSION_WIN8:
 	case VERSION_WIN8_1:
 		ret = hyperv_negotiate_version(hdev, SYNTHVID_VERSION_WIN8);
-		if (!ret)
-			break;
-		fallthrough;
-	case VERSION_WS2008:
-	case VERSION_WIN7:
-		ret = hyperv_negotiate_version(hdev, SYNTHVID_VERSION_WIN7);
 		break;
 	default:
 		ret = hyperv_negotiate_version(hdev, SYNTHVID_VERSION_WIN10);
@@ -513,18 +507,15 @@ int hyperv_connect_vsp(struct hv_device *hdev)
 		goto error;
 	}
 
-	if (hv->synthvid_version == SYNTHVID_VERSION_WIN7)
-		hv->screen_depth = SYNTHVID_DEPTH_WIN7;
-	else
-		hv->screen_depth = SYNTHVID_DEPTH_WIN8;
+	hv->screen_depth = SYNTHVID_DEPTH_WIN8;
 
 	if (hyperv_version_ge(hv->synthvid_version, SYNTHVID_VERSION_WIN10)) {
 		ret = hyperv_get_supported_resolution(hdev);
 		if (ret)
 			drm_err(dev, "Failed to get supported resolution from host, use default\n");
 	} else {
-		hv->screen_width_max = SYNTHVID_WIDTH_MAX_WIN7;
-		hv->screen_height_max = SYNTHVID_HEIGHT_MAX_WIN7;
+		hv->screen_width_max = SYNTHVID_WIDTH_WIN8;
+		hv->screen_height_max = SYNTHVID_HEIGHT_WIN8;
 	}
 
 	hv->mmio_megabytes = hdev->channel->offermsg.offer.mmio_megabytes;
-- 
1.8.3.1

Re: [PATCH 0/4] Remove support for Hyper-V 2008 and 2008R2/Win7

[Wei Liu]

On Mon, May 02, 2022 at 09:36:27AM -0700, Michael Kelley wrote:
> Linux code for running as a Hyper-V guest includes special cases for the
> first released versions of Hyper-V: 2008 and 2008R2/Windows 7. These
> versions were very thinly used for running Linux guests when first
> released more than 12 years ago, and they are now out of support
> (except for extended security updates). As initial versions, they
> lack the performance features needed for effective production usage
> of Linux guests. In total, there's no need to continue to support
> the latest Linux kernels on these versions of Hyper-V.
> 
> Simplify the code for running on Hyper-V by removing the special
> cases. This includes removing the negotiation of the VMbus protocol
> versions for 2008 and 2008R2, and the special case code based on
> those VMbus protocol versions. Changes are in the core VMbus code and
> several drivers for synthetic VMbus devices.
> 
> Some drivers have driver-specific protocols with the Hyper-V host and
> may have versions of those protocols that are limited to 2008 and
> 2008R2. This patch set does the clean-up only for the top-level
> VMbus protocol versions, and not the driver-specific protocols.
> Cleaning up the driver-specific protocols can be done with
> follow-on patches.
> 
> There's no specific urgency to removing the special case code for
> 2008 and 2008R2, so if the broader Linux kernel community surfaces
> a reason why this clean-up should not be done now, we can wait.
> But I think we want to eventually stop carrying around this extra
> baggage, and based on discussions with the Hyper-V team within
> Microsoft, we're already past the point that it has any value.
> 

I will wait for a week for people to voice their opinions. If I hear no
objection I will apply this series to hyperv-next.

Thanks,
Wei.

> Michael Kelley (4):
>   Drivers: hv: vmbus: Remove support for Hyper-V 2008 and Hyper-V
>     2008R2/Win7
>   scsi: storvsc: Remove support for Hyper-V 2008 and 2008R2/Win7
>   video: hyperv_fb: Remove support for Hyper-V 2008 and 2008R2/Win7
>   drm/hyperv: Remove support for Hyper-V 2008 and 2008R2/Win7
> 
>  drivers/gpu/drm/hyperv/hyperv_drm_proto.c | 23 ++++--------
>  drivers/hv/channel_mgmt.c                 | 29 ++++++---------
>  drivers/hv/connection.c                   |  6 ++--
>  drivers/hv/vmbus_drv.c                    | 60 +++++++------------------------
>  drivers/scsi/storvsc_drv.c                | 36 +++++--------------
>  drivers/video/fbdev/hyperv_fb.c           | 23 ++----------
>  include/linux/hyperv.h                    | 10 ++++--
>  7 files changed, 52 insertions(+), 135 deletions(-)
> 
> -- 
> 1.8.3.1
> 

Re: [PATCH 0/4] Remove support for Hyper-V 2008 and 2008R2/Win7

[Wei Liu]

On Mon, May 02, 2022 at 09:36:27AM -0700, Michael Kelley wrote:
> Linux code for running as a Hyper-V guest includes special cases for the
> first released versions of Hyper-V: 2008 and 2008R2/Windows 7. These
> versions were very thinly used for running Linux guests when first
> released more than 12 years ago, and they are now out of support
> (except for extended security updates). As initial versions, they
> lack the performance features needed for effective production usage
> of Linux guests. In total, there's no need to continue to support
> the latest Linux kernels on these versions of Hyper-V.
> 
> Simplify the code for running on Hyper-V by removing the special
> cases. This includes removing the negotiation of the VMbus protocol
> versions for 2008 and 2008R2, and the special case code based on
> those VMbus protocol versions. Changes are in the core VMbus code and
> several drivers for synthetic VMbus devices.
> 
> Some drivers have driver-specific protocols with the Hyper-V host and
> may have versions of those protocols that are limited to 2008 and
> 2008R2. This patch set does the clean-up only for the top-level
> VMbus protocol versions, and not the driver-specific protocols.
> Cleaning up the driver-specific protocols can be done with
> follow-on patches.
> 
> There's no specific urgency to removing the special case code for
> 2008 and 2008R2, so if the broader Linux kernel community surfaces
> a reason why this clean-up should not be done now, we can wait.
> But I think we want to eventually stop carrying around this extra
> baggage, and based on discussions with the Hyper-V team within
> Microsoft, we're already past the point that it has any value.
> 

I will wait for a week for people to voice their opinions. If I hear no
objection I will apply this series to hyperv-next.

Thanks,
Wei.

> Michael Kelley (4):
>   Drivers: hv: vmbus: Remove support for Hyper-V 2008 and Hyper-V
>     2008R2/Win7
>   scsi: storvsc: Remove support for Hyper-V 2008 and 2008R2/Win7
>   video: hyperv_fb: Remove support for Hyper-V 2008 and 2008R2/Win7
>   drm/hyperv: Remove support for Hyper-V 2008 and 2008R2/Win7
> 
>  drivers/gpu/drm/hyperv/hyperv_drm_proto.c | 23 ++++--------
>  drivers/hv/channel_mgmt.c                 | 29 ++++++---------
>  drivers/hv/connection.c                   |  6 ++--
>  drivers/hv/vmbus_drv.c                    | 60 +++++++------------------------
>  drivers/scsi/storvsc_drv.c                | 36 +++++--------------
>  drivers/video/fbdev/hyperv_fb.c           | 23 ++----------
>  include/linux/hyperv.h                    | 10 ++++--
>  7 files changed, 52 insertions(+), 135 deletions(-)
> 
> -- 
> 1.8.3.1
> 

Re: [PATCH 0/4] Remove support for Hyper-V 2008 and 2008R2/Win7

[Andrea Parri]

On Mon, May 02, 2022 at 09:36:27AM -0700, Michael Kelley wrote:
> Linux code for running as a Hyper-V guest includes special cases for the
> first released versions of Hyper-V: 2008 and 2008R2/Windows 7. These
> versions were very thinly used for running Linux guests when first
> released more than 12 years ago, and they are now out of support
> (except for extended security updates). As initial versions, they
> lack the performance features needed for effective production usage
> of Linux guests. In total, there's no need to continue to support
> the latest Linux kernels on these versions of Hyper-V.
> 
> Simplify the code for running on Hyper-V by removing the special
> cases. This includes removing the negotiation of the VMbus protocol
> versions for 2008 and 2008R2, and the special case code based on
> those VMbus protocol versions. Changes are in the core VMbus code and
> several drivers for synthetic VMbus devices.
> 
> Some drivers have driver-specific protocols with the Hyper-V host and
> may have versions of those protocols that are limited to 2008 and
> 2008R2. This patch set does the clean-up only for the top-level
> VMbus protocol versions, and not the driver-specific protocols.
> Cleaning up the driver-specific protocols can be done with
> follow-on patches.
> 
> There's no specific urgency to removing the special case code for
> 2008 and 2008R2, so if the broader Linux kernel community surfaces
> a reason why this clean-up should not be done now, we can wait.
> But I think we want to eventually stop carrying around this extra
> baggage, and based on discussions with the Hyper-V team within
> Microsoft, we're already past the point that it has any value.
> 
> Michael Kelley (4):
>   Drivers: hv: vmbus: Remove support for Hyper-V 2008 and Hyper-V
>     2008R2/Win7
>   scsi: storvsc: Remove support for Hyper-V 2008 and 2008R2/Win7
>   video: hyperv_fb: Remove support for Hyper-V 2008 and 2008R2/Win7
>   drm/hyperv: Remove support for Hyper-V 2008 and 2008R2/Win7

For the series,

Reviewed-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com>

Thanks,
  Andrea


>  drivers/gpu/drm/hyperv/hyperv_drm_proto.c | 23 ++++--------
>  drivers/hv/channel_mgmt.c                 | 29 ++++++---------
>  drivers/hv/connection.c                   |  6 ++--
>  drivers/hv/vmbus_drv.c                    | 60 +++++++------------------------
>  drivers/scsi/storvsc_drv.c                | 36 +++++--------------
>  drivers/video/fbdev/hyperv_fb.c           | 23 ++----------
>  include/linux/hyperv.h                    | 10 ++++--
>  7 files changed, 52 insertions(+), 135 deletions(-)
> 
> -- 
> 1.8.3.1
> 

Re: [PATCH 0/4] Remove support for Hyper-V 2008 and 2008R2/Win7

[Andrea Parri]

On Mon, May 02, 2022 at 09:36:27AM -0700, Michael Kelley wrote:
> Linux code for running as a Hyper-V guest includes special cases for the
> first released versions of Hyper-V: 2008 and 2008R2/Windows 7. These
> versions were very thinly used for running Linux guests when first
> released more than 12 years ago, and they are now out of support
> (except for extended security updates). As initial versions, they
> lack the performance features needed for effective production usage
> of Linux guests. In total, there's no need to continue to support
> the latest Linux kernels on these versions of Hyper-V.
> 
> Simplify the code for running on Hyper-V by removing the special
> cases. This includes removing the negotiation of the VMbus protocol
> versions for 2008 and 2008R2, and the special case code based on
> those VMbus protocol versions. Changes are in the core VMbus code and
> several drivers for synthetic VMbus devices.
> 
> Some drivers have driver-specific protocols with the Hyper-V host and
> may have versions of those protocols that are limited to 2008 and
> 2008R2. This patch set does the clean-up only for the top-level
> VMbus protocol versions, and not the driver-specific protocols.
> Cleaning up the driver-specific protocols can be done with
> follow-on patches.
> 
> There's no specific urgency to removing the special case code for
> 2008 and 2008R2, so if the broader Linux kernel community surfaces
> a reason why this clean-up should not be done now, we can wait.
> But I think we want to eventually stop carrying around this extra
> baggage, and based on discussions with the Hyper-V team within
> Microsoft, we're already past the point that it has any value.
> 
> Michael Kelley (4):
>   Drivers: hv: vmbus: Remove support for Hyper-V 2008 and Hyper-V
>     2008R2/Win7
>   scsi: storvsc: Remove support for Hyper-V 2008 and 2008R2/Win7
>   video: hyperv_fb: Remove support for Hyper-V 2008 and 2008R2/Win7
>   drm/hyperv: Remove support for Hyper-V 2008 and 2008R2/Win7

For the series,

Reviewed-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com>

Thanks,
  Andrea


>  drivers/gpu/drm/hyperv/hyperv_drm_proto.c | 23 ++++--------
>  drivers/hv/channel_mgmt.c                 | 29 ++++++---------
>  drivers/hv/connection.c                   |  6 ++--
>  drivers/hv/vmbus_drv.c                    | 60 +++++++------------------------
>  drivers/scsi/storvsc_drv.c                | 36 +++++--------------
>  drivers/video/fbdev/hyperv_fb.c           | 23 ++----------
>  include/linux/hyperv.h                    | 10 ++++--
>  7 files changed, 52 insertions(+), 135 deletions(-)
> 
> -- 
> 1.8.3.1
> 

Re: [PATCH 4/4] drm/hyperv: Remove support for Hyper-V 2008 and 2008R2/Win7

[Deepak Rawat]

On Mon, May 2, 2022 at 9:37 AM Michael Kelley <mikelley@microsoft.com> wrote:
>
> The DRM Hyper-V driver has special case code for running on the first
> released versions of Hyper-V: 2008 and 2008 R2/Windows 7.  These versions
> are now out of support (except for extended security updates) and lack
> support for performance features that are needed for effective production
> usage of Linux guests.
>
> The negotiation of the VMbus protocol versions required by these old
> Hyper-V versions has been removed from the VMbus driver.  So now remove
> the handling of these VMbus protocol versions from the DRM Hyper-V
> driver.
>
> Signed-off-by: Michael Kelley <mikelley@microsoft.com>
> ---
>  drivers/gpu/drm/hyperv/hyperv_drm_proto.c | 23 +++++++----------------
>  1 file changed, 7 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_proto.c b/drivers/gpu/drm/hyperv/hyperv_drm_proto.c
> index c0155c6..76a182a 100644
> --- a/drivers/gpu/drm/hyperv/hyperv_drm_proto.c
> +++ b/drivers/gpu/drm/hyperv/hyperv_drm_proto.c
> @@ -18,16 +18,16 @@
>  #define SYNTHVID_VERSION(major, minor) ((minor) << 16 | (major))
>  #define SYNTHVID_VER_GET_MAJOR(ver) (ver & 0x0000ffff)
>  #define SYNTHVID_VER_GET_MINOR(ver) ((ver & 0xffff0000) >> 16)
> +
> +/* Support for VERSION_WIN7 is removed. #define is retained for reference. */
>  #define SYNTHVID_VERSION_WIN7 SYNTHVID_VERSION(3, 0)
>  #define SYNTHVID_VERSION_WIN8 SYNTHVID_VERSION(3, 2)
>  #define SYNTHVID_VERSION_WIN10 SYNTHVID_VERSION(3, 5)
>
> -#define SYNTHVID_DEPTH_WIN7 16
>  #define SYNTHVID_DEPTH_WIN8 32
> -#define SYNTHVID_FB_SIZE_WIN7 (4 * 1024 * 1024)
> +#define SYNTHVID_WIDTH_WIN8 1600
> +#define SYNTHVID_HEIGHT_WIN8 1200
>  #define SYNTHVID_FB_SIZE_WIN8 (8 * 1024 * 1024)
> -#define SYNTHVID_WIDTH_MAX_WIN7 1600
> -#define SYNTHVID_HEIGHT_MAX_WIN7 1200
>
>  enum pipe_msg_type {
>         PIPE_MSG_INVALID,
> @@ -496,12 +496,6 @@ int hyperv_connect_vsp(struct hv_device *hdev)
>         case VERSION_WIN8:
>         case VERSION_WIN8_1:
>                 ret = hyperv_negotiate_version(hdev, SYNTHVID_VERSION_WIN8);
> -               if (!ret)
> -                       break;
> -               fallthrough;
> -       case VERSION_WS2008:
> -       case VERSION_WIN7:
> -               ret = hyperv_negotiate_version(hdev, SYNTHVID_VERSION_WIN7);
>                 break;
>         default:
>                 ret = hyperv_negotiate_version(hdev, SYNTHVID_VERSION_WIN10);
> @@ -513,18 +507,15 @@ int hyperv_connect_vsp(struct hv_device *hdev)
>                 goto error;
>         }
>
> -       if (hv->synthvid_version == SYNTHVID_VERSION_WIN7)
> -               hv->screen_depth = SYNTHVID_DEPTH_WIN7;
> -       else
> -               hv->screen_depth = SYNTHVID_DEPTH_WIN8;
> +       hv->screen_depth = SYNTHVID_DEPTH_WIN8;
>
>         if (hyperv_version_ge(hv->synthvid_version, SYNTHVID_VERSION_WIN10)) {
>                 ret = hyperv_get_supported_resolution(hdev);
>                 if (ret)
>                         drm_err(dev, "Failed to get supported resolution from host, use default\n");
>         } else {
> -               hv->screen_width_max = SYNTHVID_WIDTH_MAX_WIN7;
> -               hv->screen_height_max = SYNTHVID_HEIGHT_MAX_WIN7;
> +               hv->screen_width_max = SYNTHVID_WIDTH_WIN8;
> +               hv->screen_height_max = SYNTHVID_HEIGHT_WIN8;
>         }
>
>         hv->mmio_megabytes = hdev->channel->offermsg.offer.mmio_megabytes;

Do we need a new version for Windows 11? If the synthetic device
version is decoupled from Windows version, then I guess we can rename
the macro to reflect that.

Reviewed-by: Deepak Rawat <drawat.floss@gmail.com>

> --
> 1.8.3.1
>

Re: [PATCH 4/4] drm/hyperv: Remove support for Hyper-V 2008 and 2008R2/Win7

[Deepak Rawat]

On Mon, May 2, 2022 at 9:37 AM Michael Kelley <mikelley@microsoft.com> wrote:
>
> The DRM Hyper-V driver has special case code for running on the first
> released versions of Hyper-V: 2008 and 2008 R2/Windows 7.  These versions
> are now out of support (except for extended security updates) and lack
> support for performance features that are needed for effective production
> usage of Linux guests.
>
> The negotiation of the VMbus protocol versions required by these old
> Hyper-V versions has been removed from the VMbus driver.  So now remove
> the handling of these VMbus protocol versions from the DRM Hyper-V
> driver.
>
> Signed-off-by: Michael Kelley <mikelley@microsoft.com>
> ---
>  drivers/gpu/drm/hyperv/hyperv_drm_proto.c | 23 +++++++----------------
>  1 file changed, 7 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_proto.c b/drivers/gpu/drm/hyperv/hyperv_drm_proto.c
> index c0155c6..76a182a 100644
> --- a/drivers/gpu/drm/hyperv/hyperv_drm_proto.c
> +++ b/drivers/gpu/drm/hyperv/hyperv_drm_proto.c
> @@ -18,16 +18,16 @@
>  #define SYNTHVID_VERSION(major, minor) ((minor) << 16 | (major))
>  #define SYNTHVID_VER_GET_MAJOR(ver) (ver & 0x0000ffff)
>  #define SYNTHVID_VER_GET_MINOR(ver) ((ver & 0xffff0000) >> 16)
> +
> +/* Support for VERSION_WIN7 is removed. #define is retained for reference. */
>  #define SYNTHVID_VERSION_WIN7 SYNTHVID_VERSION(3, 0)
>  #define SYNTHVID_VERSION_WIN8 SYNTHVID_VERSION(3, 2)
>  #define SYNTHVID_VERSION_WIN10 SYNTHVID_VERSION(3, 5)
>
> -#define SYNTHVID_DEPTH_WIN7 16
>  #define SYNTHVID_DEPTH_WIN8 32
> -#define SYNTHVID_FB_SIZE_WIN7 (4 * 1024 * 1024)
> +#define SYNTHVID_WIDTH_WIN8 1600
> +#define SYNTHVID_HEIGHT_WIN8 1200
>  #define SYNTHVID_FB_SIZE_WIN8 (8 * 1024 * 1024)
> -#define SYNTHVID_WIDTH_MAX_WIN7 1600
> -#define SYNTHVID_HEIGHT_MAX_WIN7 1200
>
>  enum pipe_msg_type {
>         PIPE_MSG_INVALID,
> @@ -496,12 +496,6 @@ int hyperv_connect_vsp(struct hv_device *hdev)
>         case VERSION_WIN8:
>         case VERSION_WIN8_1:
>                 ret = hyperv_negotiate_version(hdev, SYNTHVID_VERSION_WIN8);
> -               if (!ret)
> -                       break;
> -               fallthrough;
> -       case VERSION_WS2008:
> -       case VERSION_WIN7:
> -               ret = hyperv_negotiate_version(hdev, SYNTHVID_VERSION_WIN7);
>                 break;
>         default:
>                 ret = hyperv_negotiate_version(hdev, SYNTHVID_VERSION_WIN10);
> @@ -513,18 +507,15 @@ int hyperv_connect_vsp(struct hv_device *hdev)
>                 goto error;
>         }
>
> -       if (hv->synthvid_version == SYNTHVID_VERSION_WIN7)
> -               hv->screen_depth = SYNTHVID_DEPTH_WIN7;
> -       else
> -               hv->screen_depth = SYNTHVID_DEPTH_WIN8;
> +       hv->screen_depth = SYNTHVID_DEPTH_WIN8;
>
>         if (hyperv_version_ge(hv->synthvid_version, SYNTHVID_VERSION_WIN10)) {
>                 ret = hyperv_get_supported_resolution(hdev);
>                 if (ret)
>                         drm_err(dev, "Failed to get supported resolution from host, use default\n");
>         } else {
> -               hv->screen_width_max = SYNTHVID_WIDTH_MAX_WIN7;
> -               hv->screen_height_max = SYNTHVID_HEIGHT_MAX_WIN7;
> +               hv->screen_width_max = SYNTHVID_WIDTH_WIN8;
> +               hv->screen_height_max = SYNTHVID_HEIGHT_WIN8;
>         }
>
>         hv->mmio_megabytes = hdev->channel->offermsg.offer.mmio_megabytes;

Do we need a new version for Windows 11? If the synthetic device
version is decoupled from Windows version, then I guess we can rename
the macro to reflect that.

Reviewed-by: Deepak Rawat <drawat.floss@gmail.com>

> --
> 1.8.3.1
>

Re: [PATCH 0/4] Remove support for Hyper-V 2008 and 2008R2/Win7

[Pavel Machek]

Hi!

> Linux code for running as a Hyper-V guest includes special cases for the
> first released versions of Hyper-V: 2008 and 2008R2/Windows 7. These
> versions were very thinly used for running Linux guests when first
> released more than 12 years ago, and they are now out of support
> (except for extended security updates). As initial versions, they
> lack the performance features needed for effective production usage
> of Linux guests. In total, there's no need to continue to support
> the latest Linux kernels on these versions of Hyper-V.
> 
> Simplify the code for running on Hyper-V by removing the special
> cases. This includes removing the negotiation of the VMbus protocol
> versions for 2008 and 2008R2, and the special case code based on
> those VMbus protocol versions. Changes are in the core VMbus code and
> several drivers for synthetic VMbus devices.

> 2008 and 2008R2, so if the broader Linux kernel community surfaces
> a reason why this clean-up should not be done now, we can wait.
> But I think we want to eventually stop carrying around this extra
> baggage, and based on discussions with the Hyper-V team within
> Microsoft, we're already past the point that it has any value.

Normal way to do such deprecations is to put printks in first, then hide it
under config option noone sets, and wait for year or so if anyone complains.

We can't really remove code that is in use.

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 0/4] Remove support for Hyper-V 2008 and 2008R2/Win7

[Pavel Machek]

Hi!

> Linux code for running as a Hyper-V guest includes special cases for the
> first released versions of Hyper-V: 2008 and 2008R2/Windows 7. These
> versions were very thinly used for running Linux guests when first
> released more than 12 years ago, and they are now out of support
> (except for extended security updates). As initial versions, they
> lack the performance features needed for effective production usage
> of Linux guests. In total, there's no need to continue to support
> the latest Linux kernels on these versions of Hyper-V.
> 
> Simplify the code for running on Hyper-V by removing the special
> cases. This includes removing the negotiation of the VMbus protocol
> versions for 2008 and 2008R2, and the special case code based on
> those VMbus protocol versions. Changes are in the core VMbus code and
> several drivers for synthetic VMbus devices.

> 2008 and 2008R2, so if the broader Linux kernel community surfaces
> a reason why this clean-up should not be done now, we can wait.
> But I think we want to eventually stop carrying around this extra
> baggage, and based on discussions with the Hyper-V team within
> Microsoft, we're already past the point that it has any value.

Normal way to do such deprecations is to put printks in first, then hide it
under config option noone sets, and wait for year or so if anyone complains.

We can't really remove code that is in use.

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

RE: [PATCH 0/4] Remove support for Hyper-V 2008 and 2008R2/Win7

[Michael Kelley (LINUX)]

From: Pavel Machek <pavel@ucw.cz> Sent: Wednesday, May 4, 2022 10:23 AM
> 
> Hi!
> 
> > Linux code for running as a Hyper-V guest includes special cases for the
> > first released versions of Hyper-V: 2008 and 2008R2/Windows 7. These
> > versions were very thinly used for running Linux guests when first
> > released more than 12 years ago, and they are now out of support
> > (except for extended security updates). As initial versions, they
> > lack the performance features needed for effective production usage
> > of Linux guests. In total, there's no need to continue to support
> > the latest Linux kernels on these versions of Hyper-V.
> >
> > Simplify the code for running on Hyper-V by removing the special
> > cases. This includes removing the negotiation of the VMbus protocol
> > versions for 2008 and 2008R2, and the special case code based on
> > those VMbus protocol versions. Changes are in the core VMbus code and
> > several drivers for synthetic VMbus devices.
> 
> > 2008 and 2008R2, so if the broader Linux kernel community surfaces
> > a reason why this clean-up should not be done now, we can wait.
> > But I think we want to eventually stop carrying around this extra
> > baggage, and based on discussions with the Hyper-V team within
> > Microsoft, we're already past the point that it has any value.
> 
> Normal way to do such deprecations is to put printks in first, then hide it
> under config option noone sets, and wait for year or so if anyone complains.
> 

Are there any examples of doing these deprecation steps that you can
point me to?  I did not see anything in the Documentation directory
covering the deprecation process you describe.

I'd also make the case that we are already well down the deprecation
path.  For at least the last 5 years, the public Microsoft documentation
for Linux guests has listed Hyper-V 2012 R2 as the earliest supported
Hyper-V version.  Other current and new Microsoft products aren't
supported on Hyper-V 2008/Win7 either -- the usual Word/Excel/
PowerPoint, etc. fall into this category as well as Windows 10 and Windows
11 as guests.  So for a rare user who might still be using Hyper-V
2008/Win7, there's no reasonable expectation of being able to run
the latest upstream Linux kernel on Hyper-V 2008/Win7.  Other
current software doesn't.

Given that running Linux guests on Hyper-V sort of implicitly
combines Microsoft commercial thinking and Linux open source
thinking about version support, I could see putting the old Hyper-V
version support under a config option that defaults to "no", with a 
deprecation comment, and seeing if that garners any complaints.
But given the broader situation with Hyper-V 2008/Win7, in my
judgment even that is more cautious than we need to be.

Michael

> We can't really remove code that is in use.
> 
> Best regards,
> 									Pavel

RE: [PATCH 0/4] Remove support for Hyper-V 2008 and 2008R2/Win7

[Michael Kelley (LINUX)]

From: Pavel Machek <pavel@ucw.cz> Sent: Wednesday, May 4, 2022 10:23 AM
> 
> Hi!
> 
> > Linux code for running as a Hyper-V guest includes special cases for the
> > first released versions of Hyper-V: 2008 and 2008R2/Windows 7. These
> > versions were very thinly used for running Linux guests when first
> > released more than 12 years ago, and they are now out of support
> > (except for extended security updates). As initial versions, they
> > lack the performance features needed for effective production usage
> > of Linux guests. In total, there's no need to continue to support
> > the latest Linux kernels on these versions of Hyper-V.
> >
> > Simplify the code for running on Hyper-V by removing the special
> > cases. This includes removing the negotiation of the VMbus protocol
> > versions for 2008 and 2008R2, and the special case code based on
> > those VMbus protocol versions. Changes are in the core VMbus code and
> > several drivers for synthetic VMbus devices.
> 
> > 2008 and 2008R2, so if the broader Linux kernel community surfaces
> > a reason why this clean-up should not be done now, we can wait.
> > But I think we want to eventually stop carrying around this extra
> > baggage, and based on discussions with the Hyper-V team within
> > Microsoft, we're already past the point that it has any value.
> 
> Normal way to do such deprecations is to put printks in first, then hide it
> under config option noone sets, and wait for year or so if anyone complains.
> 

Are there any examples of doing these deprecation steps that you can
point me to?  I did not see anything in the Documentation directory
covering the deprecation process you describe.

I'd also make the case that we are already well down the deprecation
path.  For at least the last 5 years, the public Microsoft documentation
for Linux guests has listed Hyper-V 2012 R2 as the earliest supported
Hyper-V version.  Other current and new Microsoft products aren't
supported on Hyper-V 2008/Win7 either -- the usual Word/Excel/
PowerPoint, etc. fall into this category as well as Windows 10 and Windows
11 as guests.  So for a rare user who might still be using Hyper-V
2008/Win7, there's no reasonable expectation of being able to run
the latest upstream Linux kernel on Hyper-V 2008/Win7.  Other
current software doesn't.

Given that running Linux guests on Hyper-V sort of implicitly
combines Microsoft commercial thinking and Linux open source
thinking about version support, I could see putting the old Hyper-V
version support under a config option that defaults to "no", with a 
deprecation comment, and seeing if that garners any complaints.
But given the broader situation with Hyper-V 2008/Win7, in my
judgment even that is more cautious than we need to be.

Michael

> We can't really remove code that is in use.
> 
> Best regards,
> 									Pavel

Re: [PATCH 0/4] Remove support for Hyper-V 2008 and 2008R2/Win7

[Wei Liu]

On Sun, May 08, 2022 at 03:43:26PM +0000, Michael Kelley (LINUX) wrote:
> From: Pavel Machek <pavel@ucw.cz> Sent: Wednesday, May 4, 2022 10:23 AM
> > 
> > Hi!
> > 
> > > Linux code for running as a Hyper-V guest includes special cases for the
> > > first released versions of Hyper-V: 2008 and 2008R2/Windows 7. These
> > > versions were very thinly used for running Linux guests when first
> > > released more than 12 years ago, and they are now out of support
> > > (except for extended security updates). As initial versions, they
> > > lack the performance features needed for effective production usage
> > > of Linux guests. In total, there's no need to continue to support
> > > the latest Linux kernels on these versions of Hyper-V.
> > >
> > > Simplify the code for running on Hyper-V by removing the special
> > > cases. This includes removing the negotiation of the VMbus protocol
> > > versions for 2008 and 2008R2, and the special case code based on
> > > those VMbus protocol versions. Changes are in the core VMbus code and
> > > several drivers for synthetic VMbus devices.
> > 
> > > 2008 and 2008R2, so if the broader Linux kernel community surfaces
> > > a reason why this clean-up should not be done now, we can wait.
> > > But I think we want to eventually stop carrying around this extra
> > > baggage, and based on discussions with the Hyper-V team within
> > > Microsoft, we're already past the point that it has any value.
> > 
> > Normal way to do such deprecations is to put printks in first, then hide it
> > under config option noone sets, and wait for year or so if anyone complains.
> > 
> 
> Are there any examples of doing these deprecation steps that you can
> point me to?  I did not see anything in the Documentation directory
> covering the deprecation process you describe.
> 
> I'd also make the case that we are already well down the deprecation
> path.  For at least the last 5 years, the public Microsoft documentation
> for Linux guests has listed Hyper-V 2012 R2 as the earliest supported
> Hyper-V version.  Other current and new Microsoft products aren't
> supported on Hyper-V 2008/Win7 either -- the usual Word/Excel/
> PowerPoint, etc. fall into this category as well as Windows 10 and Windows
> 11 as guests.  So for a rare user who might still be using Hyper-V
> 2008/Win7, there's no reasonable expectation of being able to run
> the latest upstream Linux kernel on Hyper-V 2008/Win7.  Other
> current software doesn't.
> 
> Given that running Linux guests on Hyper-V sort of implicitly
> combines Microsoft commercial thinking and Linux open source
> thinking about version support, I could see putting the old Hyper-V
> version support under a config option that defaults to "no", with a 
> deprecation comment, and seeing if that garners any complaints.
> But given the broader situation with Hyper-V 2008/Win7, in my
> judgment even that is more cautious than we need to be.
> 

In general we should trust the judgement from the main developers.

There have been recent examples that things are dropped without any
deprecation warnings. See below.

By and large the usefulness of the code in kernel relies on a lot of
factors. In this particular case, I don't think adding a KCONFIG makes
sense. Printing a warning in _guest_ won't help. Whoever still runs
these ancient versions has had ample warnings.

Thanks,
Wei.

commit c645a883df34ee10b884ec921e850def54b7f461
Author:     NeilBrown <neilb@suse.de>
AuthorDate: Thu Sep 2 11:15:29 2021 +1000
Commit:     J. Bruce Fields <bfields@redhat.com>
CommitDate: Sat Oct 2 15:51:10 2021 -0400

    NFSD: drop support for ancient filehandles

    Filehandles not in the "new" or "version 1" format have not been handed
    out for new mounts since Linux 2.4 which was released 20 years ago.
    I think it is safe to say that no such file handles are still in use,
    and that we can drop support for them.

    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>

commit 9b472e85d098a40b84dd8b33fbf8a15ab1452025
Author:     Nick Desaulniers <ndesaulniers@google.com>
AuthorDate: Thu May 6 18:04:54 2021 -0700
Commit:     Linus Torvalds <torvalds@linux-foundation.org>
CommitDate: Fri May 7 00:26:32 2021 -0700

    gcov: clang: drop support for clang-10 and older

    LLVM changed the expected function signatures for llvm_gcda_start_file()
    and llvm_gcda_emit_function() in the clang-11 release.  Drop the older
    implementations and require folks to upgrade their compiler if they're
    interested in GCOV support.

    Link: https://reviews.llvm.org/rGcdd683b516d147925212724b09ec6fb792a40041
    Link: https://reviews.llvm.org/rG13a633b438b6500ecad9e4f936ebadf3411d0f44
    Link: https://lkml.kernel.org/r/20210312224132.3413602-3-ndesaulniers@google.com
    Link: https://lkml.kernel.org/r/20210413183113.2977432-1-ndesaulniers@google.com
    Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
    Suggested-by: Nathan Chancellor <nathan@kernel.org>
    Acked-by: Peter Oberparleiter <oberpar@linux.ibm.com>
    Reviewed-by: Nathan Chancellor <nathan@kernel.org>
    Reviewed-by: Fangrui Song <maskray@google.com>
    Cc: Prasad Sodagudi <psodagud@quicinc.com>
    Cc: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Re: [PATCH 0/4] Remove support for Hyper-V 2008 and 2008R2/Win7

[Wei Liu]

On Sun, May 08, 2022 at 03:43:26PM +0000, Michael Kelley (LINUX) wrote:
> From: Pavel Machek <pavel@ucw.cz> Sent: Wednesday, May 4, 2022 10:23 AM
> > 
> > Hi!
> > 
> > > Linux code for running as a Hyper-V guest includes special cases for the
> > > first released versions of Hyper-V: 2008 and 2008R2/Windows 7. These
> > > versions were very thinly used for running Linux guests when first
> > > released more than 12 years ago, and they are now out of support
> > > (except for extended security updates). As initial versions, they
> > > lack the performance features needed for effective production usage
> > > of Linux guests. In total, there's no need to continue to support
> > > the latest Linux kernels on these versions of Hyper-V.
> > >
> > > Simplify the code for running on Hyper-V by removing the special
> > > cases. This includes removing the negotiation of the VMbus protocol
> > > versions for 2008 and 2008R2, and the special case code based on
> > > those VMbus protocol versions. Changes are in the core VMbus code and
> > > several drivers for synthetic VMbus devices.
> > 
> > > 2008 and 2008R2, so if the broader Linux kernel community surfaces
> > > a reason why this clean-up should not be done now, we can wait.
> > > But I think we want to eventually stop carrying around this extra
> > > baggage, and based on discussions with the Hyper-V team within
> > > Microsoft, we're already past the point that it has any value.
> > 
> > Normal way to do such deprecations is to put printks in first, then hide it
> > under config option noone sets, and wait for year or so if anyone complains.
> > 
> 
> Are there any examples of doing these deprecation steps that you can
> point me to?  I did not see anything in the Documentation directory
> covering the deprecation process you describe.
> 
> I'd also make the case that we are already well down the deprecation
> path.  For at least the last 5 years, the public Microsoft documentation
> for Linux guests has listed Hyper-V 2012 R2 as the earliest supported
> Hyper-V version.  Other current and new Microsoft products aren't
> supported on Hyper-V 2008/Win7 either -- the usual Word/Excel/
> PowerPoint, etc. fall into this category as well as Windows 10 and Windows
> 11 as guests.  So for a rare user who might still be using Hyper-V
> 2008/Win7, there's no reasonable expectation of being able to run
> the latest upstream Linux kernel on Hyper-V 2008/Win7.  Other
> current software doesn't.
> 
> Given that running Linux guests on Hyper-V sort of implicitly
> combines Microsoft commercial thinking and Linux open source
> thinking about version support, I could see putting the old Hyper-V
> version support under a config option that defaults to "no", with a 
> deprecation comment, and seeing if that garners any complaints.
> But given the broader situation with Hyper-V 2008/Win7, in my
> judgment even that is more cautious than we need to be.
> 

In general we should trust the judgement from the main developers.

There have been recent examples that things are dropped without any
deprecation warnings. See below.

By and large the usefulness of the code in kernel relies on a lot of
factors. In this particular case, I don't think adding a KCONFIG makes
sense. Printing a warning in _guest_ won't help. Whoever still runs
these ancient versions has had ample warnings.

Thanks,
Wei.

commit c645a883df34ee10b884ec921e850def54b7f461
Author:     NeilBrown <neilb@suse.de>
AuthorDate: Thu Sep 2 11:15:29 2021 +1000
Commit:     J. Bruce Fields <bfields@redhat.com>
CommitDate: Sat Oct 2 15:51:10 2021 -0400

    NFSD: drop support for ancient filehandles

    Filehandles not in the "new" or "version 1" format have not been handed
    out for new mounts since Linux 2.4 which was released 20 years ago.
    I think it is safe to say that no such file handles are still in use,
    and that we can drop support for them.

    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>

commit 9b472e85d098a40b84dd8b33fbf8a15ab1452025
Author:     Nick Desaulniers <ndesaulniers@google.com>
AuthorDate: Thu May 6 18:04:54 2021 -0700
Commit:     Linus Torvalds <torvalds@linux-foundation.org>
CommitDate: Fri May 7 00:26:32 2021 -0700

    gcov: clang: drop support for clang-10 and older

    LLVM changed the expected function signatures for llvm_gcda_start_file()
    and llvm_gcda_emit_function() in the clang-11 release.  Drop the older
    implementations and require folks to upgrade their compiler if they're
    interested in GCOV support.

    Link: https://reviews.llvm.org/rGcdd683b516d147925212724b09ec6fb792a40041
    Link: https://reviews.llvm.org/rG13a633b438b6500ecad9e4f936ebadf3411d0f44
    Link: https://lkml.kernel.org/r/20210312224132.3413602-3-ndesaulniers@google.com
    Link: https://lkml.kernel.org/r/20210413183113.2977432-1-ndesaulniers@google.com
    Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
    Suggested-by: Nathan Chancellor <nathan@kernel.org>
    Acked-by: Peter Oberparleiter <oberpar@linux.ibm.com>
    Reviewed-by: Nathan Chancellor <nathan@kernel.org>
    Reviewed-by: Fangrui Song <maskray@google.com>
    Cc: Prasad Sodagudi <psodagud@quicinc.com>
    Cc: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Re: [PATCH 0/4] Remove support for Hyper-V 2008 and 2008R2/Win7

[Wei Liu]

On Mon, May 02, 2022 at 09:36:27AM -0700, Michael Kelley wrote:
> Linux code for running as a Hyper-V guest includes special cases for the
> first released versions of Hyper-V: 2008 and 2008R2/Windows 7. These
> versions were very thinly used for running Linux guests when first
> released more than 12 years ago, and they are now out of support
> (except for extended security updates). As initial versions, they
> lack the performance features needed for effective production usage
> of Linux guests. In total, there's no need to continue to support
> the latest Linux kernels on these versions of Hyper-V.
> 
> Simplify the code for running on Hyper-V by removing the special
> cases. This includes removing the negotiation of the VMbus protocol
> versions for 2008 and 2008R2, and the special case code based on
> those VMbus protocol versions. Changes are in the core VMbus code and
> several drivers for synthetic VMbus devices.
> 
> Some drivers have driver-specific protocols with the Hyper-V host and
> may have versions of those protocols that are limited to 2008 and
> 2008R2. This patch set does the clean-up only for the top-level
> VMbus protocol versions, and not the driver-specific protocols.
> Cleaning up the driver-specific protocols can be done with
> follow-on patches.
> 
> There's no specific urgency to removing the special case code for
> 2008 and 2008R2, so if the broader Linux kernel community surfaces
> a reason why this clean-up should not be done now, we can wait.
> But I think we want to eventually stop carrying around this extra
> baggage, and based on discussions with the Hyper-V team within
> Microsoft, we're already past the point that it has any value.
> 
> Michael Kelley (4):
>   Drivers: hv: vmbus: Remove support for Hyper-V 2008 and Hyper-V
>     2008R2/Win7
>   scsi: storvsc: Remove support for Hyper-V 2008 and 2008R2/Win7
>   video: hyperv_fb: Remove support for Hyper-V 2008 and 2008R2/Win7
>   drm/hyperv: Remove support for Hyper-V 2008 and 2008R2/Win7

Applied to hyperv-next.

Re: [PATCH 0/4] Remove support for Hyper-V 2008 and 2008R2/Win7

[Wei Liu]

On Mon, May 02, 2022 at 09:36:27AM -0700, Michael Kelley wrote:
> Linux code for running as a Hyper-V guest includes special cases for the
> first released versions of Hyper-V: 2008 and 2008R2/Windows 7. These
> versions were very thinly used for running Linux guests when first
> released more than 12 years ago, and they are now out of support
> (except for extended security updates). As initial versions, they
> lack the performance features needed for effective production usage
> of Linux guests. In total, there's no need to continue to support
> the latest Linux kernels on these versions of Hyper-V.
> 
> Simplify the code for running on Hyper-V by removing the special
> cases. This includes removing the negotiation of the VMbus protocol
> versions for 2008 and 2008R2, and the special case code based on
> those VMbus protocol versions. Changes are in the core VMbus code and
> several drivers for synthetic VMbus devices.
> 
> Some drivers have driver-specific protocols with the Hyper-V host and
> may have versions of those protocols that are limited to 2008 and
> 2008R2. This patch set does the clean-up only for the top-level
> VMbus protocol versions, and not the driver-specific protocols.
> Cleaning up the driver-specific protocols can be done with
> follow-on patches.
> 
> There's no specific urgency to removing the special case code for
> 2008 and 2008R2, so if the broader Linux kernel community surfaces
> a reason why this clean-up should not be done now, we can wait.
> But I think we want to eventually stop carrying around this extra
> baggage, and based on discussions with the Hyper-V team within
> Microsoft, we're already past the point that it has any value.
> 
> Michael Kelley (4):
>   Drivers: hv: vmbus: Remove support for Hyper-V 2008 and Hyper-V
>     2008R2/Win7
>   scsi: storvsc: Remove support for Hyper-V 2008 and 2008R2/Win7
>   video: hyperv_fb: Remove support for Hyper-V 2008 and 2008R2/Win7
>   drm/hyperv: Remove support for Hyper-V 2008 and 2008R2/Win7

Applied to hyperv-next.