From: Roman Kisel <romank@linux.microsoft.com>
To: hpa@zytor.com, kys@microsoft.com, bp@alien8.de,
dave.hansen@linux.intel.com, decui@microsoft.com,
eahariha@linux.microsoft.com, haiyangz@microsoft.com,
mingo@redhat.com, mhklinux@outlook.com,
nunodasneves@linux.microsoft.com, tglx@linutronix.de,
tiala@microsoft.com, wei.liu@kernel.org,
linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org,
x86@kernel.org
Cc: apais@microsoft.com, benhill@microsoft.com,
ssengar@microsoft.com, sunilmut@microsoft.com, vdso@hexbites.dev
Subject: [PATCH v6 0/5] hyperv: Fixes for get_vtl(), hv_vtl_apicid_to_vp_id()
Date: Wed, 8 Jan 2025 14:21:33 -0800 [thread overview]
Message-ID: <20250108222138.1623703-1-romank@linux.microsoft.com> (raw)
The get_vtl(void) function
* has got one bug when the code started using a wrong pointer type after
refactoring, and also
* the both function in question don't adhere to the requirements of
the Hypervisor Top-Level Funactional Specification[1, 2] as the code overlaps
the input and output areas for a hypercall.
The first issue leads to a wrong 100% reproducible computation due to reading
a byte worth of data at a wrong offset. That in turn leads to using a nonsensical
value ("fortunately", could catch it easily!) for the current VTL when initiating
VMBus communications. As a repercussion from that, the system wouldn't boot. The
fix is straightforward: use the correct pointer type.
The second issue doesn't seem to lead to any reproducible breakage just yet. It is
fixed with using the output hypercall pages allocated per-CPU, and that isn't the
only or the most obvious choice so let me elaborate why that fix appears to be the
best one in my opinion out of the options I could conceive of.
The approach chosen for fixing the second issue makes two things shine through:
* these functions just get a vCPU register, no special treatment needs to be
involved,
* VTLs and dom0 can and should share code as both exist to provide services to
a guest(s), be that from within the partition or from outside of it.
The projected benefits include replacing the functions in question with a future
`hv_get_vp_registers` one shared between dom0 and VTLs to allow for a better test
coverage.
I have validated the fixes by booting the fixed kernel in VTL2 up using OpenVMM and
OpenHCL[3, 4].
[1] https://learn.microsoft.com/en-us/virtualization/hyper-v-on-windows/tlfs/hypercall-interface
[2] https://github.com/MicrosoftDocs/Virtualization-Documentation/tree/main/tlfs
[3] https://openvmm.dev/guide/user_guide/openhcl.html
[4] https://github.com/microsoft/OpenVMM
[v6]
- Sending v6 a week after v5 to adhere to the requirements of the kernel
documentation,
- Added all tags the patches received prior to v6,
- Fixed the bitfield layout for the ARM64 structures (patch 1),
- Hoisted the common condition used in several if statements into
a separate function to improve code maintainability (patch 3).
[v5]: https://lore.kernel.org/lkml/20241230180941.244418-1-romank@linux.microsoft.com/
- In the first patch, removed some arch-specific #ifdef guards to fix the
arm64 build and stick to the direction chosen for the Hyper-V header files.
I could not remove all of them as some interrupt state structures
are defined differently for x64 and arm64 and are found in the same
enclosing `union hv_register_value`.
No changes to other patches (approved in v4).
[v4]: https://lore.kernel.org/lkml/20241227183155.122827-1-romank@linux.microsoft.com/
- Wrapped DECLARE_FLEX_ARRAY into a struct and added one more
member as the documentation requires,
- Removed superfluous type coercion,
- Fixed tags,
- Rebased onto the latest hyperv-next branch.
[v3]: https://lore.kernel.org/lkml/20241226213110.899497-1-romank@linux.microsoft.com/
- Added a fix for hv_vtl_apicid_to_vp_id(),
- Split out the patch for enabling the hypercall output page,
- Updated the title of the patch series,
[v2]: https://lore.kernel.org/lkml/20241226203050.800524-1-romank@linux.microsoft.com/
- Used the suggestions to define an additional structure to improve code readability,
- Split out the patch with that definition.
[v1]: https://lore.kernel.org/lkml/20241218205421.319969-1-romank@linux.microsoft.com/
Roman Kisel (5):
hyperv: Define struct hv_output_get_vp_registers
hyperv: Fix pointer type in get_vtl(void)
hyperv: Enable the hypercall output page for the VTL mode
hyperv: Do not overlap the hvcall IO areas in get_vtl()
hyperv: Do not overlap the hvcall IO areas in hv_vtl_apicid_to_vp_id()
arch/x86/hyperv/hv_init.c | 6 +++---
arch/x86/hyperv/hv_vtl.c | 2 +-
drivers/hv/hv_common.c | 11 +++++++---
include/hyperv/hvgdk_mini.h | 41 +++++++++++++++++++++++++++++++++++++
4 files changed, 53 insertions(+), 7 deletions(-)
base-commit: 26e1b813fcd02984b1cac5f3decdf4b0bb56fe02
--
2.34.1
next reply other threads:[~2025-01-08 22:21 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-08 22:21 Roman Kisel [this message]
2025-01-08 22:21 ` [PATCH v6 1/5] hyperv: Define struct hv_output_get_vp_registers Roman Kisel
2025-01-08 23:25 ` Nuno Das Neves
2025-01-09 5:50 ` Wei Liu
2025-01-09 17:25 ` Roman Kisel
2025-01-09 19:09 ` Wei Liu
2025-01-08 22:21 ` [PATCH v6 2/5] hyperv: Fix pointer type in get_vtl(void) Roman Kisel
2025-01-08 22:21 ` [PATCH v6 3/5] hyperv: Enable the hypercall output page for the VTL mode Roman Kisel
2025-01-08 23:27 ` Nuno Das Neves
2025-01-08 22:21 ` [PATCH v6 4/5] hyperv: Do not overlap the hvcall IO areas in get_vtl() Roman Kisel
2025-01-08 22:21 ` [PATCH v6 5/5] hyperv: Do not overlap the hvcall IO areas in hv_vtl_apicid_to_vp_id() Roman Kisel
2025-01-08 23:34 ` Nuno Das Neves
2025-01-09 20:18 ` [PATCH v6 0/5] hyperv: Fixes for get_vtl(), hv_vtl_apicid_to_vp_id() Wei Liu
2025-01-09 20:28 ` Nuno Das Neves
2025-01-09 21:28 ` Roman Kisel
2025-01-09 21:40 ` Roman Kisel
2025-01-09 21:56 ` Wei Liu
2025-01-09 22:19 ` Roman Kisel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250108222138.1623703-1-romank@linux.microsoft.com \
--to=romank@linux.microsoft.com \
--cc=apais@microsoft.com \
--cc=benhill@microsoft.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=decui@microsoft.com \
--cc=eahariha@linux.microsoft.com \
--cc=haiyangz@microsoft.com \
--cc=hpa@zytor.com \
--cc=kys@microsoft.com \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhklinux@outlook.com \
--cc=mingo@redhat.com \
--cc=nunodasneves@linux.microsoft.com \
--cc=ssengar@microsoft.com \
--cc=sunilmut@microsoft.com \
--cc=tglx@linutronix.de \
--cc=tiala@microsoft.com \
--cc=vdso@hexbites.dev \
--cc=wei.liu@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.