[PATCH v2 0/3][f/j/l/m linux] UBUNTU: SAUCE: (no-up) hv: Fix supply vendor ID

[Tim Gardner]

BugLink: https://bugs.launchpad.net/bugs/2036600

SRU Justification

[Impact]

The linux-azure 6.2 kernel doesn't report a correct GUEST_ID

There is a mistake in the commit (https://git.launchpad.net/~canonical-kernel/ubuntu/+source/linux-azure/+git/jammy/commit/?id=5dd24f2df3280d4354641f4687dbb36e418e7de8) :

Before the commit, the good guest_id is 0x8180000602100000.

With the commit, the generated guest_id is incorrect: 0x0080000602100000, i.e. the 0x81 from bit 56~63 are dropped.

See "include/asm-generic/hyperv-tlfs.h" for the definition of the bits:
* Bit(s)
* 63 - Indicates if the OS is Open Source or not; 1 is Open Source

* 62:56 - Os Type; Linux is 0x100 !!!!! Dexuan: this should be 0x1. I'll post a patch to LKML to fix this typo.

* 55:48 - Distro specific identification
* 47:16 - Linux kernel version number
* 15:0 - Distro specific identification

See https://learn.microsoft.com/en-us/virtualization/hyper-v-on-windows/tlfs/tlfs ("February, 2020: Released Version 6.0b", page 15)

As a result, the host thinks that the VM is not an open-source OS, and it's not Linux. Consequently, the "VM Availability" fron Azure portal is 0 (unhealthy): some users rely on the info to manage their VMs, e.g. if the VM is erroneously reported "unhealthy", the VM may be killed and re-created, and the new VM is still "unhealthy", and the VM may be killed and re-created again...

Please consider integrating the below fix ASAP. This affects regular VMs, and I think this affects CVMs as well.

The fix should be:

diff --git a/include/asm-generic/hyperv-tlfs.h b/include/asm-generic/hyperv-tlfs.h
@@ -135,7 +135,7 @@ union hv_reference_tsc_msr {
*
*/

-#define HV_LINUX_VENDOR_ID 0x80 /* Canonical */
+#define HV_LINUX_VENDOR_ID 0x8180 /* Canonical */

[Test Plan]

Microsoft tested

[Regression Potential]

This (incorrect) patch has been in place for 10 years. Its possible that some consumers have come to rely on this VM identifier.
I am reluctant to fix the ESM kernels for that very reason, plus nobody has ever complained about an incorrect vendor ID.

[Other Info]

SF: #00368936