Roman Kagan [off-list ref] writes:

On Sat, Apr 25, 2020 at 09:16:37AM +0300, Jon Doron wrote:

quoted

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