From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47684) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z4tKh-0001dA-WB for qemu-devel@nongnu.org; Tue, 16 Jun 2015 12:03:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z4tKd-0007zH-Ue for qemu-devel@nongnu.org; Tue, 16 Jun 2015 12:03:27 -0400 Received: from mail.emea.novell.com ([130.57.118.101]:51983) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z4tKd-0007yj-Ij for qemu-devel@nongnu.org; Tue, 16 Jun 2015 12:03:23 -0400 Message-Id: <558064E80200007800085ACE@mail.emea.novell.com> Date: Tue, 16 Jun 2015 17:03:20 +0100 From: "Jan Beulich" References: <5571AA3B020000780008152E@mail.emea.novell.com> <5571ABBA0200007800081543@mail.emea.novell.com> <55804CAF0200007800085917@mail.emea.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Re: [Qemu-devel] [PATCH 2/6] xen/MSI-X: drive maskall and enable bits through hypercalls List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefano Stabellini Cc: xen-devel , qemu-devel@nongnu.org >>> On 16.06.15 at 16:56, wrote: > On Tue, 16 Jun 2015, Jan Beulich wrote: >> >>> On 16.06.15 at 16:03, wrote: >> > On Fri, 5 Jun 2015, Jan Beulich wrote: >> >> --- a/qemu/upstream/hw/xen/xen_pt_msi.c >> >> +++ b/qemu/upstream/hw/xen/xen_pt_msi.c >> >> @@ -301,8 +301,11 @@ static int msix_set_enable(XenPCIPassthr >> >> return -1; >> >> } >> >> =20 >> >> - return msi_msix_enable(s, s->msix->ctrl_offset, PCI_MSIX_FLAGS_E= NABLE, >> >> - enabled); >> >=20 >> > Would it make sense to remove msi_msix_enable completely to avoid any >> > further mistakes? >>=20 >> Perhaps, yes. I think I actually had suggested so quite a while back. >> But I don't see myself wasting much more time on this, ehm, code. >=20 > Isn't it just a matter of removing msi_msix_enable? It has another caller xen_pt_msi_set_enable(). If we went down the route of what this patch does, then MSI's enable bit should ultimately also be driven through a hypercall, and that would then be the point where the function would naturally disappear. But as said, it looks like we're intending to go a different route anyway. Jan From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH 2/6] xen/MSI-X: drive maskall and enable bits through hypercalls Date: Tue, 16 Jun 2015 17:03:20 +0100 Message-ID: <558064E80200007800085ACE@mail.emea.novell.com> References: <5571AA3B020000780008152E@mail.emea.novell.com> <5571ABBA0200007800081543@mail.emea.novell.com> <55804CAF0200007800085917@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Z4tKe-0006WM-67 for xen-devel@lists.xenproject.org; Tue, 16 Jun 2015 16:03:24 +0000 In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefano Stabellini Cc: xen-devel , qemu-devel@nongnu.org List-Id: xen-devel@lists.xenproject.org >>> On 16.06.15 at 16:56, wrote: > On Tue, 16 Jun 2015, Jan Beulich wrote: >> >>> On 16.06.15 at 16:03, wrote: >> > On Fri, 5 Jun 2015, Jan Beulich wrote: >> >> --- a/qemu/upstream/hw/xen/xen_pt_msi.c >> >> +++ b/qemu/upstream/hw/xen/xen_pt_msi.c >> >> @@ -301,8 +301,11 @@ static int msix_set_enable(XenPCIPassthr >> >> return -1; >> >> } >> >> >> >> - return msi_msix_enable(s, s->msix->ctrl_offset, PCI_MSIX_FLAGS_ENABLE, >> >> - enabled); >> > >> > Would it make sense to remove msi_msix_enable completely to avoid any >> > further mistakes? >> >> Perhaps, yes. I think I actually had suggested so quite a while back. >> But I don't see myself wasting much more time on this, ehm, code. > > Isn't it just a matter of removing msi_msix_enable? It has another caller xen_pt_msi_set_enable(). If we went down the route of what this patch does, then MSI's enable bit should ultimately also be driven through a hypercall, and that would then be the point where the function would naturally disappear. But as said, it looks like we're intending to go a different route anyway. Jan