There has been cases reported where HYPERV_VTL_MODE is enabled by mistake,
on a non Hyper-V platforms. This causes the hv_vtl_early_init function to
be called in an non Hyper-V/VTL platforms which results the memory
corruption.
Remove the early_initcall for vhv_vtl_early_init and call it at the en
When Linux runs in a non-default VTL (CONFIG_HYPERV_VTL_MODE=y),
get_vtl() must never fail as its return value is used in negotiations
with the host. In the more generic case, (CONFIG_HYPERV_VTL_MODE=n) the
VTL is always zero so there's no need to do the hypercall.
Make get_vtl() BUG() in case of
Thanks for the confirmation KY.
And sorry for the HTML email, fixed.
Best regards,
Alex Ionescu
On Tue, Sep 19, 2023 at 1:10 PM KY Srinivasan wrote:
>
> Linux support for Hyper-V has been completely upstreamed and our goal is to
> upstream all new development we do in this space. We welcome c
Add "#define pr_fmt()" in hv_init.c to use "Hyper-V:" as common
print prefix for all pr_*() statements in this file.
Remove the "Hyper-V:" already prefixed in couple of prints.
Signed-off-by: Saurabh Sengar
---
arch/x86/hyperv/hv_init.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-
Saurabh Sengar writes:
> For non VTL platforms vtl is always 0, and there is no need of
> get_vtl function. For VTL platforms get_vtl should always succeed
> and should return the correct VTL.
Nitpicking, an alternative summary:
"""
When Linux runs in a non-default VTL (CONFIG_HYPERV_VTL_MODE=y
Tue, 19 Sep 2023 06:18:53 + Dexuan Cui :
> How about moving the 'vtl' field to an even earlier place:
I have not tried it, but I think this would just move the hole up.
The end result will likely be the same, pahole -E vmlinux will show it.
Olaf
pgpDmiOmWAMyl.pgp
Description: Digitale Sig
