Re: [PATCH v5 01/10] hyperv: Convert Hyper-V status codes to strings
From: Roman Kisel <hidden>
Date: 2025-02-28 17:20:13
Also in:
linux-acpi, linux-arch, linux-hyperv, lkml
On 2/27/2025 3:25 PM, Easwar Hariharan wrote:
On 2/27/2025 3:08 PM, Roman Kisel wrote:
[...]
quoted
Would be great to learn the details to understand how this function is going to improve the situation: 1. How come the hex error code was useless, what is not matching anything in the Linux headers?It doesn't match anything in the Linux headers, but it's an NTSTATUS, not HVSTATUS.
That is what it looks like from the code, I posted the details in the parallel thread. Here is a fix: https://lore.kernel.org/linux-hyperv/20250227233110.36596-1-romank@linux.microsoft.com/ (local) Also I think the commit description in your patch https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d2138eab8cde61e0e6f62d0713e45202e8457d6d conflates the hypervisor (ours runs bare-metal, Type 1) and the VMMs (Virtual Machine Monitors)+VSPs (Virtual Service Providers, e.g StorVSP that implements SCSI) running in the host/root/dom0 partition.
Coming from the PoV of a user, it would be a much more useful message to see: [ 249.512760] hv_storvsc fd1d2cbd-ce7c-535c-966b-eb5f811c95f0: tag#683 cmd 0x28 status: scsi 0x2 srb 0x4 hv STATUS_UNSUCCESSFUL than [ 249.512760] hv_storvsc fd1d2cbd-ce7c-535c-966b-eb5f811c95f0: tag#683 cmd 0x28 status: scsi 0x2 srb 0x4 hv 0xc0000001
It is likely that the PoV of a user that you've mentioned is actually a PoV of a (kernel) developer. It is hard to imagine that folks running web sites, DB servers, LoBs, LLMs, etc. in Hyper-V VMs care about the lowest software level of the virt stack in the form of the symbolic name or the hex code. They need their VMs to be reliable or suggest what the user may try if a configuration error is suspected. To make the error log message useful to the user, the message should mention ways of remediation or at least hint what might've gotten wedged. Without that, that's only useful for the people who work with the kernel code proper or the kernel interface to the user land. So I'd think that the hex error codes from the hypervisor give the user exactly as much as the error symbolic names do to get the system to the desired state: nothing. Even less when the error reported "Unknown" :)
quoted
2. How having "Unknown" in the log can possibly be better?IMHO, seeing "Unknown" in an error report means that there's a new return value that needs to be mapped to errno in hv_status_to_errno() and updated here as well.
It means that to the developer. To the user, it means the developers messed something up and to make matters even worse they didn't leave any breadcrumbs (e.g. the hex code) to see what's wrong to help the user and themselves: there is just that "Unknown" thing in the log.
quoted
3. Given that the select hv status codes and the proposed strings have 1:1 correspondence, and there is the 1:N catch-all case for the "Unknown", how's that better?I didn't really follow this question, but I suppose the answer to Q2 answers this as well. If not, please expand and I'll try to answer.
Sorry about that chunk, hit "Send" without looking the e-mail over another time. Appreciate the discussion very much!
Thanks, Easwar (he/him)
-- Thank you, Roman