https://bugzilla.suse.com/show_bug.cgi?id=1189965 https://bugzilla.suse.com/show_bug.cgi?id=1189965#c1 --- Comment #1 from Jeff Mahoney <jeffm@suse.com> --- Created attachment 852159 --> https://bugzilla.suse.com/attachment.cgi?id=852159&action=edit [PATCH] hv: set guest os id Give the host more detailed info about the running guest. Provide the guest OS id. A better change is pending. Acked-by: Olaf Hering <ohering@suse.de> -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1189965 https://bugzilla.suse.com/show_bug.cgi?id=1189965#c3 Michael H. Kelley <mikelley@microsoft.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(mikelley@microsof | |t.com) | --- Comment #3 from Michael H. Kelley <mikelley@microsoft.com> --- Per the Hyper-V TLFS, the guest OS ID is required to be set before performing any Hyper-V related operations such as making hypercalls. The guest OS ID is not consumed anywhere within the Linux guest OS. There are a few situations where Hyper-V looks at the value of the guest OS ID and makes decisions about its behavior. The decisions could be based on whether the flag is set to indicate an open source operating system vs. Windows. In the specific case where the open source operating system is Linux, there is a Hyper-V behavior that is based on the Linux kernel version that is included in the guest OS ID. Hyper-V tries to avoid making decisions on info in the guest OS ID, but there are a few cases where correctly supporting certain old Linux kernel versions has been problematic without such a dependency. Is the patch in question visible somewhere that I can see it? I don't remember what this patch is about. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1189965 https://bugzilla.suse.com/show_bug.cgi?id=1189965#c5 --- Comment #5 from Michael H. Kelley <mikelley@microsoft.com> --- There is a subfield in the guest OS ID to allow a distro to be specifically identified. That's what this patch does -- it codes the subfield to indicate "SUSE". This kind of change obviously won't go upstream, and we never did come up with a better scheme for setting the subfield on a per-distro basis. There is internal Microsoft telemetry based on the guest OS ID. In the kernel panic path, the guest OS ID value is recorded and logged by Hyper-V, and it is useful to be able to know the distro that was running, independent of the kernel version number. If SUSE is willing to continue to carry this one-off patch for the purposes described here, we think it would be useful to continue to do so. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1189965 https://bugzilla.suse.com/show_bug.cgi?id=1189965#c7 Michal Kube��ek <mkubecek@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mkubecek@suse.com --- Comment #7 from Michal Kube��ek <mkubecek@suse.com> --- (In reply to Michael H. Kelley from comment #5)

There is a subfield in the guest OS ID to allow a distro to be specifically identified. That's what this patch does -- it codes the subfield to indicate "SUSE". This kind of change obviously won't go upstream, and we never did come up with a better scheme for setting the subfield on a per-distro basis.

There is internal Microsoft telemetry based on the guest OS ID. In the kernel panic path, the guest OS ID value is recorded and logged by Hyper-V, and it is useful to be able to know the distro that was running, independent of the kernel version number.

If SUSE is willing to continue to carry this one-off patch for the purposes described here, we think it would be useful to continue to do so.

I don't think that's the point. Some time ago, a similar patch was submitted to upstream, only with the id values defined as config options rather than hardwired (so that we would only set those CONFIG_* to correct values in our kernel configs). The patch was not accepted and what I remember from reading the discussion, the objection was that there were absolutely no guidelines telling people what to set the OS id values to for a specific distribution. So e.g. we somehow know that 0x10 is supposed to mean "SUSE" but kernel package maintainers in other distributions have no idea what values to use. It seemed that vendors just claim random values and hope they won't collide. In other words, there was/is no central registry saying that SUSE has 0x10, Red Hat some other value, Canonical another etc. and no process of applying for a registered value. Maybe there is such registry but if that is the case, the submitter (not sure if it was Olaf or someone from Microsoft) was not able to point to it at that time. So I believe if such registry exists or if Microsoft (as Hyper-V vendor) is willing to create and run such registry, there is a good chance the Kconfig based verion of this patch could be upstreamed. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1189965 https://bugzilla.suse.com/show_bug.cgi?id=1189965#c15 Michal Kube��ek <mkubecek@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED |--- --- Comment #15 from Michal Kube��ek <mkubecek@suse.com> --- Looking at mainline commit d5ebde1e2b46 ("hyperv: simplify and rename generate_guest_id") (to appear in 6.1-rc1), it seems that - Microsoft does not seem to have any plans to formalize the vendor fields in guest os id - we only set d1 on x86_64 and leave it zero on arm64 without anyone noticing or complaining - d2 was always zero anywhere and we never attempted to set it to anything meaningful Therefore I believe it's time to revisit the question if our patch patches.suse/suse-hv-guest-os-id.patch is still useful and worth dragging and refreshing. My suggestion would be to keep it in SLE15 (all current and future service packs) for backward compatibility but to drop it in master (i.e. Tubmleweed in near future) and also in ALP. Any objections or other ideas? -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1189965 https://bugzilla.suse.com/show_bug.cgi?id=1189965#c17 --- Comment #17 from Michael H. Kelley <mikelley@microsoft.com> --- I'm OK (somewhat reluctantly) with Michal Kube��ek's proposal to stop setting the "d1" value in the Hyper-V guest OS id. Michal is probably correct that Microsoft isn't going to formalize the values designated for the vendor fields. In practice, having the kernel major/minor/update versions has been sufficient to identify the distro. For example, we know that 4.12.14 is SUSE Linux. :-) There could be a collision at some point in the future, but the issue isn't significant enough that we will try to organize and publish the allocation of specific values. d2 is similarly unspecified. It would be nice to capture the additional sub-versions and build #'s in a string like "4.12.14-197.26-default", but d2 is only 16 bits and it's not clear how to do that. RHEL has a similar problem with versions like 4.18.0-305.25.1 and we haven't come up with a good solution there either. Splitting the 16-bit field into two 8-bit fields doesn't work because some of the sub-version values are greater than 255. Storing just the "197" from "4.12.14-197.26-default" in the 16-bit field would be a very modest incremental improvement, but I doubt it's worth the trouble. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1189965 https://bugzilla.suse.com/show_bug.cgi?id=1189965#c19 --- Comment #19 from Michael H. Kelley <mikelley@microsoft.com> --- The benefit would be that the version information is available directly to Hyper-V. There have been one or two times in the past where Hyper-V needed to do something different based on the version information in the Linux guest ID because of a bug in certain Linux versions or because of a need to maintain some other backwards compatibility. It's a mechanism of last resort, but we've gotten stuck in a couple of cases. There is also VM telemetry that we get directly from the Hyper-V on the Azure hosts. The guest OS ID helps us bucket the data by Linux kernel version, without having to do a costly cross-reference to find the image that was deployed, especially if it was a custom image from the customer. But notwithstanding all that, my previous comments still stand. I don't think the marginal benefit is necessarily worth the effort of putting a valid value in the "d2" field. -- You are receiving this mail because: You are on the CC list for the bug.