On Tue, May 24, 2022 at 05:43:33AM +0000, Michael Kelley (LINUX) wrote: > > > > > > 2/ The Lock bit (bit 1) is ignored in the Linux implementation. If the > > > hypervisor starts with Lock bit set, the init function allocates the > > > hv_hypercall_pg and writes the value to the MSR, then: > > > a/ If the hypervisor ignores the write, the MSR remains unchanged, > > > but the global variable is already set. Attempt to do a > > > hypercall ends with call to undefined memory, because the code > > > in hv_do_hypercall() checks the global variable against NULL, > > > which will pass. > > > b/ The hypervisor injects #GP, in which case the guest crashes. > > > > I would need to confirm with the Hyper-V team, but I think the Lock > > bit would only be set *after* the guest OS has provided a guest page > > to be used as the hypercall page. > > > > There is code in Linux to clear the MSR and disable the hypercall > > page when doing a kexec or kdump. This is done so that the new > > kernel can start "fresh" and establish its own hypercall page. That > > kexec/kdump code does not check the Lock bit, and I'm not sure of > > the implications if the Lock bit were found to be set in such a case. > > > > I'll check with the Hyper-V team to get clarity on the handling > > of the Lock bit in the case of trying to disable the hypercall page. > > > > Michael > > The Hyper-V team clarified that the Locked bit is never set by > the hypervisor. The bit is there for the guest to set if it chooses. > The TLFS is indeed not clear on this point. Thank you for the clarification. I'll update our implementation accordingly :) -- Best regards, Vit Kabele
