On 13.09.23 07:27, Saurabh Singh Sengar wrote: > On Mon, Sep 11, 2023 at 10:00:59AM +0200, Mathias Krause wrote: >> On 08.09.23 17:02, Saurabh Singh Sengar wrote: >>> On Fri, Sep 08, 2023 at 12:26:10PM +0200, Mathias Krause wrote: >>>> Booting a CONFIG_HYPERV_VTL_MODE=y enabled kernel on bare metal or a >>>> non-Hyper-V hypervisor leads to serve memory corruption as >>> >>> FWIW, CONFIG_HYPERV_VTL_MODE is not expected to be enabled for non VTL >>> platforms. >> >> Fair enough, but there's really no excuse to randomly crashing the >> kernel if one forgot to RTFM like I did. The code should (and easily >> can) handle such situations, especially if it's just a matter of a two >> line change. > > Thanks, I understand your concern. We don't want people to enable this > flag by mistake and see unexpected behaviours. Unexpected behaviour like randomly crashing the kernel? ;) > To add extra safety for this flag, we can make this flag dependent on > EXPERT config. Well, if you want to prevent people from using it, make it depend on BROKEN, because that's what it is. All the other hypervisor support in the kernel (Xen, VMware, KVM, ACRN, Jailhouse, even plain Hyper-V) can perfectly cope with getting booted on a different hypervisor or bare metal. Why is Hyper-V's VTL mode such a special snow flake that it has to cause random memory corruption and, in turn, crash the kernel with spectacular (and undebugable) fireworks if it's not booted under Hyper-V? Thanks, Mathias
