On Fri, Sep 15, 2023 at 09:06:15AM +0200, Mathias Krause wrote: > 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. <snip> > > 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? 'BROKEN' is certainly not the right choice here. If it is used on the correct platform as it is designed to be nothing is broken. The default option for CONFIG_HYPERV_VTL_MODE is set to 'N', there is sufficient documentation for it as well. I agree there can be cases where people can still end up enabling it, for that EXPERT is a reasonable solution. - Saurabh > > Thanks, > Mathias
