Roman Kagan <rvkagan@xxxxxxxxxxxxxx> writes: > On Sat, Apr 25, 2020 at 09:16:37AM +0300, Jon Doron wrote: > >> If that's indeed the case then probably the only thing needs fixing in my >> scenario is in QEMU where it should not really care for the SCONTROL if it's >> enabled or not. > > Right. However, even this shouldn't be necessary as SeaBIOS from that > branch would enable SCONTROL and leave it that way when passing the > control over to the bootloader, so, unless something explicitly clears > SCONTROL, it should remain set thereafter. I'd rather try going ahead > with that scheme first, because making QEMU ignore SCONTROL appears to > violate the spec. FWIW, I just checked 'genuine' Hyper-V 2016 with diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c index fd51bac11b46..c5ea759728d9 100644 --- a/arch/x86/hyperv/hv_init.c +++ b/arch/x86/hyperv/hv_init.c @@ -314,10 +314,14 @@ void __init hyperv_init(void) u64 guest_id, required_msrs; union hv_x64_msr_hypercall_contents hypercall_msr; int cpuhp, i; + u64 val; if (x86_hyper_type != X86_HYPER_MS_HYPERV) return; + hv_get_synic_state(val); + printk("Hyper-V: SCONTROL state: %llx\n", val); + /* Absolutely required MSRs */ required_msrs = HV_X64_MSR_HYPERCALL_AVAILABLE | HV_X64_MSR_VP_INDEX_AVAILABLE; and it seems the default state of HV_X64_MSR_SCONTROL is '1', we should probably do the same. Is there any reason to *not* do this in KVM when KVM_CAP_HYPERV_SYNIC[,2] is enabled? -- Vitaly