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?
> >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?
-- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
