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

[Roman Kagan <rvkagan@yandex-team.ru>]

On Thu, Apr 16, 2020 at 03:54:30PM +0300, Jon Doron wrote:
> 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...

Yes you do need both of these.

> > > 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.

Who sets up the message page then?  Doesn't it enabe SCONTROL as well?

Note that, even if you don't see it being enabled by Windows, it can be
enabled by the firmware and/or by the bootloader.

Can you perhaps try with the SeaBIOS from
https://src.openvz.org/projects/UP/repos/seabios branch hv-scsi?  It
enables SCONTROL and leaves it that way.

I'd also suggest tracing kvm_msr events (both reads and writes) for
SCONTROL and SIMP msrs, to better understand the picture.

So far the change you propose appears too heavy to work around the
problem of disabled SCONTROL.  You seem to be better off just making
sure it's enabled (either by the firmware or slighly violating the spec
and initializing to enabled from the start), and sticking to the
existing infrastructure for posting messages.

> (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).

I'll look through the archive, should be there, thanks.

Roman.