From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [PATCH 2/2][RFC] KVM: Emulate MSI-X table and PBA in kernel Date: Thu, 30 Dec 2010 14:17:02 +0200 Message-ID: <20101230121702.GA22289@redhat.com> References: <1293007495-32325-1-git-send-email-sheng@linux.intel.com> <201012291655.19535.sheng@linux.intel.com> <20101229092824.GA2876@redhat.com> <201012301532.42341.sheng@linux.intel.com> <20101230074748.GB7889@redhat.com> <4D1C5124.2090409@redhat.com> <20101230103256.GB6441@redhat.com> <4D1C60DE.4020800@redhat.com> <20101230110728.GC6441@redhat.com> <4D1C6C93.8090703@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Sheng Yang , Marcelo Tosatti , kvm@vger.kernel.org, Alex Williamson To: Avi Kivity Return-path: Received: from mx1.redhat.com ([209.132.183.28]:5762 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751682Ab0L3MSJ (ORCPT ); Thu, 30 Dec 2010 07:18:09 -0500 Content-Disposition: inline In-Reply-To: <4D1C6C93.8090703@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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 unimp= lemented > >> >> >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 ch= annel > >> >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 pr= ohibited > >> > from sending the associated message, and the function must set = the > >> > associated Pending bit whenever the function would otherwise se= nd the > >> > message. When software unmasks a vector whose associated Pendin= g bit is > >> > set, the function must schedule sending the associated message,= and > >> > clear the Pending bit as soon as the message has been sent. Not= e that > >> > clearing the MSI-X Function Mask bit may result in many message= s needing > >> > to be sent. > >> > > >> > > >> > If a masked vector has its Pending bit set, and the associated > >> > underlying interrupt events are somehow satisfied (usually by s= oftware > >> > though the exact manner is function-specific), the function mus= t clear > >> > the Pending bit, to avoid sending a spurious interrupt message = later > >> > when software unmasks the vector. However, if a subsequent inte= rrupt > >> > event occurs while the vector is still masked, the function mus= t again > >> > set the Pending bit. > >> > > >> > > >> > Software is permitted to mask one or more vectors indefinitely,= and > >> > service their associated interrupt events strictly based on pol= ling > >> > their Pending bits. A function must set and clear its Pending b= its as > >> > necessary to support this =E2=80=9Cpure polling=E2=80=9D mode o= f 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 re= ads > >> 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' >=20 > 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 le= ast it's > >> >not a regression there, and the virtio spec says nothing about t= his 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. >=20 > 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). > --=20 > error compiling committee.c: too many arguments to function