Re: [PATCH v2 0/1] x86/kvm/hyper-v: Add support to SYNIC exit on EOM

[Vitaly Kuznetsov <vkuznets@xxxxxxxxxx>]

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