From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH v2 2/4] x86/MSI-X: access MSI-X table only after having enabled MSI-X Date: Thu, 16 Apr 2015 14:21:47 -0400 Message-ID: <20150416182147.GB7388@x230.dumpdata.com> References: <5512F1B3020000780006D924@mail.emea.novell.com> <5512F2E5020000780006D945@mail.emea.novell.com> <20150410200218.GA1814@l.oracle.com> <552BA2EA02000078000715D3@mail.emea.novell.com> <20150415174120.GO31387@l.oracle.com> <552F84420200007800072922@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YioQH-0001FR-HG for xen-devel@lists.xenproject.org; Thu, 16 Apr 2015 18:21:57 +0000 Content-Disposition: inline In-Reply-To: <552F84420200007800072922@mail.emea.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: Andrew Cooper , Keir Fraser , xen-devel List-Id: xen-devel@lists.xenproject.org On Thu, Apr 16, 2015 at 08:43:30AM +0100, Jan Beulich wrote: > >>> On 15.04.15 at 19:41, wrote: > > On Mon, Apr 13, 2015 at 10:05:14AM +0100, Jan Beulich wrote: > >> You mentioning XSA-120 and its addendum - are these requirements > >> for the problem to be seen? I admit I may have tested a PV guest > >> only with an SR-IOV VF (and only a HVM guest also with an "ordinary" > >> device), but I'd like to be clear about the validity of the connection. > > > > No. I just tried with v4.0-rc5 (and then also v4.0) and just > > using SR-IOV to make this simpler. > > Good. > > > With staging + two of your patches: > > a10cc68 TODO: drop //temp-s > > 1b8721c x86/MSI-X: be more careful during teardown > > > > When trying to enable SR-IOV I get this error: > > Okay, this definitely works for me, albeit I know I had to do > adjustments to avoid running into the (debug) warning you've > hit. But (looking at the call stack) it surely would be a mistake to > set up an MSI-X IRQ on the device without first enabling MSI-X > on the it (i.e. the error returned could be considered legitimate). > While we may want the hypervisor to cope with this (by enabling > MSI-X on this path, which I'd have to add to that patch), is this > hypervisor change perhaps uncovering a pv-ops kernel issue (in > that other than what drivers/pci/msi.c does as of the commit > mentioned in the description of that second patch some Xen- > specific path fails to enable MSI-X before setting up any of the > entries)? Everything is possible :-) What kernel are you using? Or better yet - what branch/tree could one find it at? > > Jan >