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

[Jon Doron <arilou@gmail.com>]

On 16/04/2020, Roman Kagan wrote:
>On Thu, Apr 16, 2020 at 11:38:46AM +0300, Jon Doron wrote:
>> According to the TLFS:
>> "A write to the end of message (EOM) register by the guest causes the
>> hypervisor to scan the internal message buffer queue(s) associated with
>> the virtual processor.
>>
>> If a message buffer queue contains a queued message buffer, the hypervisor
>> attempts to deliver the message.
>>
>> Message delivery succeeds if the SIM page is enabled and the message slot
>> corresponding to the SINTx is empty (that is, the message type in the
>> header is set to HvMessageTypeNone).
>> If a message is successfully delivered, its corresponding internal message
>> buffer is dequeued and marked free.
>> If the corresponding SINTx is not masked, an edge-triggered interrupt is
>> delivered (that is, the corresponding bit in the IRR is set).
>>
>> This register can be used by guests to poll for messages. It can also be
>> used as a way to drain the message queue for a SINTx that has
>> been disabled (that is, masked)."
>
>Doesn't this work already?
>

Well if you dont have SCONTROL and a GSI associated with the SINT then 
it does not...

>> So basically this means that we need to exit on EOM so the hypervisor
>> will have a chance to send all the pending messages regardless of the
>> SCONTROL mechnaisim.
>
>I might be misinterpreting the spec, but my understanding is that
>SCONTROL {en,dis}ables the message queueing completely.  What the quoted
>part means is that a write to EOM should trigger the message source to
>push a new message into the slot, regardless of whether the SINT was
>masked or not.
>
>And this (I think, haven't tested) should already work.  The userspace
>just keeps using the SINT route as it normally does, posting
>notifications to the corresponding irqfd when posting a message, and
>waiting on the resamplerfd for the message slot to become free.  If the
>SINT is masked KVM will skip injecting the interrupt, that's it.
>
>Roman.

That's what I was thinking originally as well, but then i noticed KDNET 
as a VMBus client (and it basically runs before anything else) is 
working in this polling mode, where SCONTROL is disabled and it just 
loops, and if it saw there is a PENDING message flag it will issue an 
EOM to indicate it has free the slot.
(There are a bunch of patches i sent on the QEMU mailing list as well 
  where i CCed you, I will probably revise it a bit but was hoping to get 
  KVM sorted out first).

Cheers,
-- Jon.