On Tue, May 05, 2020 at 01:38:21PM +0300, Jon Doron wrote:

On 05/05/2020, Roman Kagan wrote:

quoted

On Mon, May 04, 2020 at 05:55:10PM +0200, Vitaly Kuznetsov wrote:

quoted

and it seems the default state of HV_X64_MSR_SCONTROL is '1', we should
probably do the same.

This is the state the OS sees, after the firmware.  You'd see the same
with QEMU/KVM if you used Hyper-V-aware SeaBIOS or OVMF.

quoted

Is there any reason to *not* do this in KVM when
KVM_CAP_HYPERV_SYNIC[,2] is enabled?

Yes there is: quoting Hyper-V TLFS v6.0 11.8.1:

 At virtual processor creation time and upon processor reset, the value
 of this SCONTROL (SynIC control register) is 0x0000000000000000. Thus,
 message queuing and event flag notifications will be disabled.

And, even if we decide to violate the spec it's better done in
userspace, loading the initial value and adjusting the synic state at
vcpu reset.

However leaving it up to the guest (firmware or OS) looks more natural
to me.

I under where you are coming from in the idea of leaving it to the OS

I'm coming from the HyperV spec, see the quote above.

but I think in this specific case it does not make much sense, after
all HyperV has it's own proprietary BIOS which Windows assumes has
setup some of the MSRs, since we dont have that BIOS we need to
"emulate" it's behaviour.

We don't have that BIOS, but we have another BIOS which does the same
and is not proprietary.  Using it allows to do synic message posting
even with a non-compliant guest OS which doesn't properly enable
SCONTROL on its own.  (Note that there used to be no problem with this
so far, this must be specific to your use case.)

I'm failing to see why this is a stumbling block for the work you're
doing.

And I'm not convinced we need to work around a non-compliant guest with
kludges to KVM or QEMU (including back-compat stuff as that would change
the existing behavior), when the desired effect can be achieved with the
existing code.

Thanks,
Roman.