Re: [PATCH 2/2][RFC] KVM: Emulate MSI-X table and PBA in kernel

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Dec 30, 2010 at 01:27:15PM +0200, Avi Kivity wrote:
> On 12/30/2010 01:07 PM, Michael S. Tsirkin wrote:
> >On Thu, Dec 30, 2010 at 12:37:18PM +0200, Avi Kivity wrote:
> >>  On 12/30/2010 12:32 PM, Michael S. Tsirkin wrote:
> >>  >On Thu, Dec 30, 2010 at 11:30:12AM +0200, Avi Kivity wrote:
> >>  >>   On 12/30/2010 09:47 AM, Michael S. Tsirkin wrote:
> >>  >>   >I am not really suggesting this. What I say is PBA is unimplemented
> >>  >>   >let us not commit to an interface yet.
> >>  >>
> >>  >>   What happens to a guest that tries to use PBA?
> >>  >>   It's a mandatory part of MSI-X, no?
> >>  >
> >>  >Yes. Unfortunately the pending bit is in fact a communication channel
> >>  >used for function specific purposes when mask bit is set,
> >>  >and 0 when unset. The spec even seems to *require* this use:
> >>  >
> >>  >I refer to this:
> >>  >
> >>  >	For MSI and MSI-X, while a vector is masked, the function is prohibited
> >>  >	from sending the associated message, and the function must set the
> >>  >	associated Pending bit whenever the function would otherwise send the
> >>  >	message. When software unmasks a vector whose associated Pending bit is
> >>  >	set, the function must schedule sending the associated message, and
> >>  >	clear the Pending bit as soon as the message has been sent. Note that
> >>  >	clearing the MSI-X Function Mask bit may result in many messages needing
> >>  >	to be sent.
> >>  >
> >>  >
> >>  >	If a masked vector has its Pending bit set, and the associated
> >>  >	underlying interrupt events are somehow satisfied (usually by software
> >>  >	though the exact manner is function-specific), the function must clear
> >>  >	the Pending bit, to avoid sending a spurious interrupt message later
> >>  >	when software unmasks the vector. However, if a subsequent interrupt
> >>  >	event occurs while the vector is still masked, the function must again
> >>  >	set the Pending bit.
> >>  >
> >>  >
> >>  >	Software is permitted to mask one or more vectors indefinitely, and
> >>  >	service their associated interrupt events strictly based on polling
> >>  >	their Pending bits. A function must set and clear its Pending bits as
> >>  >	necessary to support this “pure polling” mode of operation.
> >>  >
> >>  >For assigned devices, supporting this would require
> >>  >that the mask bits on the device are set if the mask bit in
> >>  >guest is set (otherwise pending bits are disabled).
> >>
> >>  Can't this be done by setting the real mask bit when the guest reads
> >>  the virtual pending bit, then reading the real pending bit?
> >
> >Function specific is function-specific, but most likely not,
> >by that time the pending bit in the device might be clear:
> >'clear the Pending bit as soon as the message has been sent'
> 
> But when we set the mask bit, it must change the pending bit back to
> the function-specific condition?

All it says is 'whenever the function would otherwise send a message'.
So this is function-specific, generally functions only send a message
once per event, they don't resend it assuming that it was queued
and will eventually be handled.


> >>  >Existing code does not support PBA in assigned devices, so at least it's
> >>  >not a regression there, and the virtio spec says nothing about this so
> >>  >we should be fine.
> >>
> >>  Why isn't it subject to the pci spec?
> >>
> >>  If an interrupt condition exits, the bit should be set.
> >
> >I wish. But this is not what the spec says above. It says if vector is
> >unmasked, bit must be cleared.
> 
> If interrupt condition exists, and the vector is masked, the pending
> bit is set.  Otherwise the pending bit is clear.  Better?

'whenever the function would otherwise send a message'
does not seem to match this description:
functions do not generally keep sending messages as long as
condition is satisfied (if you think about this, the optimization
of not masking immediately in hardware relies on this).

> -- 
> error compiling committee.c: too many arguments to function