From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH v2] interrupts: allow guest to set and clear MSI-X mask bit Date: Tue, 6 Aug 2013 10:52:58 +0100 Message-ID: <5200C77A.2020404@citrix.com> References: <20130719150726.GA25302@citrix.com> <20130723105441.GE31939@citrix.com> <20130723132842.GB2504@phenom.dumpdata.com> <20130723175902.GE20810@citrix.com> <51FF9E3002000078000E9338@nat28.tlf.novell.com> <51FF8608.7070905@citrix.com> <51FFAD5F02000078000E93F1@nat28.tlf.novell.com> <51FFCCD3.9090109@citrix.com> <5200D00202000078000E98A6@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5200D00202000078000E98A6@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: keir@xen.org, Ian.Campbell@citrix.com, xen-devel@lists.xen.org, Joby Poriyath , malcolm.crossley@citrix.com List-Id: xen-devel@lists.xenproject.org On 06/08/13 09:29, Jan Beulich wrote: >>>> On 05.08.13 at 18:03, Andrew Cooper wrote: >> On 05/08/13 12:49, Jan Beulich wrote: >>> But a proper solution would of course be preferred. That may involve >>> notifying Xen of the reset from the PF driver. >> That is making the assumption that the PF driver is even aware that the >> reset has occurred. If the PF driver can get at the reset information, >> I still cant see Xen specific hooks being accepted upstream. > You sort of contradict your earlier statement here that "the VF > requests the PF to reset itself" (where you probably meant "it", > as the VF is hardly allowed to cause a reset of the PF): Such an > operation should imo be visible to the PF driver. > > And then, even if the reset is being done, shouldn't the interrupt > setup occur _after_ the reset? Which would make Xen clear the > flag... The observed behaviour is this: On startup, the VF driver issues this backchannel reset of itself (the VF) which, amongst other things, sets the mask bit. It leaves the MSI/MSI-X addr and data fields alone, but on further consideration, relying on this behaviour might not be a good idea. The VF is then expected to re-enable the interrupt at its convenience. There are no obvious hooks in the PF driver to receive notification of these backchannel resets. ~Andrew > >> Fundamentally, given that only the VM is in a position to actually know >> about the state of the mask bit (As we cant possibly have Xen polling >> for the state), then the guest has to have access to the mask bit. > No, that continues to not be an option as long as Xen uses the mask > bit itself. Once again, the obvious immediate solution would appear > to be to carry out the write with the OR of both the guest intended > and the hypervisor required mask bits, thus allowing the bit to get > cleared immediately if Xen doesn't need it to be set (and the clearing > would happen subsequently if Xen needs the flag to be set at the > point of the guest write). This requires associating back the table > entry to the IRQ in question (if any), in order to look at > irq_desc->msi_desc->msi_attrib.masked. > > Jan >