From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joby Poriyath Subject: Re: [PATCH v2] interrupts: allow guest to set and clear MSI-X mask bit Date: Tue, 13 Aug 2013 18:08:30 +0100 Message-ID: <20130813170830.GF27370@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: Content-Disposition: inline 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, Andrew Cooper , xen-devel@lists.xen.org, malcolm.crossley@citrix.com List-Id: xen-devel@lists.xenproject.org Hi Jan, On Tue, Aug 06, 2013 at 09:29:22AM +0100, 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... > > > 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. Thanks for the suggestion. The reason why guest was allowed to modify MSIX control bit, was to reduce the load on qemu-dm (see http://zhenxiao.com/read/SR-IOV.pdf). I'll post the updated patch. > > Jan > Thanks, Joby