RE: [RESEND PATCH 0/6] Remove support for Windows Server 2012/2012R2 & Win8/Win8.1 versions of Hyper-V
Michael Kelley <[email protected]> Fri, 31 Jul 2026 03:12:31 +0000
| Newsgroups | org.kernel.vger.linux-hyperv,dev.linux.lists.virtualization,org.freedesktop.lists.dri-devel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-scsi,org.kernel.vger.netdev |
|---|---|
| Message-ID | <SN6PR02MB4157F550021CBCBCD8C9BEBAD4C82@SN6PR02MB4157.namprd02.prod.outlook.com> |
From: Hamza Mahfooz <[email protected]> Sent: Thursday, July= 30, 2026 3:24 PM >=20 > On Thu, Jul 30, 2026 at 01:11:17PM -0700, Michael Kelley wrote: > > Linux code for running as a Hyper-V guest includes special cases for > > running on Hyper-V in WS2012/2012R2 and Windows 8/8.1. These versions > > were initially released 14 years ago, and official support ended in 202= 3 > > (unless a customer has contracted for extended security updates). Given > > the release of subsequent versions with improved functionality, there's > > no need to continue to support the latest Linux kernels on these versio= ns > > of Hyper-V. If someone is running Linux on one of these older Hyper-V > > versions and doesn't want to upgrade, they can continue to do so as > > presumably they don't want upgrade the Linux version either. > > > > Simplify Linux code by removing special cases for running on these > > old versions of Hyper-V. This includes removing the negotiation of the > > VMBus protocol versions for WS2012/Win8, and the special case code base= d > > on those VMBus protocol versions. Changes are in the core VMBus code an= d > > several drivers for synthetic VMBus devices. > > > > Some VMBus drivers have device-specific protocols with the Hyper-V host= . > > Further simplify the code by removing the use of protocol versions that > > are specific to WS2012/Win8 and earlier. > > > > Finally, the WS2012/Win8 versions of Hyper-V were the last to use > > messages to deliver synthetic timer interrupts. Starting in WS2016/Win1= 0, > > stimer interrupts are delivered to their own assigned interrupt vector > > (called "Direct Mode"). So remove the code for handling timer interrupt= s > > delivered as messages. This removal has a broader benefit in removing > > a key blocker to disentangling VMBus code (which handles the messages) > > and stimer code, as they should be independent of each other. The > > final disentangling will come as a follow-on patch set. > > > > Testing: > > * VM on local Hyper-V on up-to-date Windows 11 > > * Added temp debug code to suppress Direct Mode enumeration. Fallback > > to LAPIC timer worked as expected (x86/x64 only) > > * Azure VM DC16eds v6: TDX CoCo VM with HvLite paravisor > > * Azure VM DC16ads v6: SEV-SNP VM with an older paravisor > > * Azure VM D16alds_v7: normal AMD x86 VM with HvLite paravisor > > * Azure VM D16plds v6: normal ARM64 VM with MSFT Cobalt processor > > * Not tested running in VTL2 > > > > There's no specific urgency to removing the special case code for > > WS2012/Win8, 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 past the point that it has any value. >=20 > I do feel that this is a nice cleanup overall, however do we really want > things to break silently if someone does attempt running the latest > kernel on older hosts? or do we want to include (at the very least) a > warning message that indicates that things might be broken (and or > that we don't make any guarantees of future support)? If one tried to boot a Linux guest with these patches on Hyper-V from WS2012/2012R2 or Win8/8.1, at least two error messages would occur during boot and Linux will fail to boot. First, the stimers would fail to initialize because of lacking Direct Mode, but Linux would continue to boot using the LAPIC timer. Second, VMBus would fail to initialize because of not being able to negotiate the protocol version, and that would prevent the VM from booting at all. It would be reasonable to enhance the VMBus protocol negotiation failure message to indicate that a likely cause is due to running on an old version of Hyper-V that Linux guests no longer support. I'll do that in the next version. I'm not sure what to say about "no guarantees of future support" -- that seems like a given. Michael