linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <bhelgaas@google.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Gavin Shan <shangw@linux.vnet.ibm.com>,
	xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH v4 18/22] xen/pci: Pay attention to PCI_MSIX_TABLE_OFFSET
Date: Thu, 25 Apr 2013 10:42:38 -0600	[thread overview]
Message-ID: <20130425164238.GA3052@google.com> (raw)
In-Reply-To: <5179164902000078000D0A26@nat28.tlf.novell.com>

On Thu, Apr 25, 2013 at 10:40:57AM +0100, Jan Beulich wrote:
> >>> On 24.04.13 at 18:34, Bjorn Helgaas <bhelgaas@google.com> wrote:
> > On Mon, Apr 22, 2013 at 5:12 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> >> The MSI-X Table structure may be at a non-zero offset into the
> >> device BAR, and we should account for that.
> 
> NAK: The base is just being use to pass to the hypervisor, which
> then takes care to add the offset.

Thanks for noticing this.  I updated the patch to just add a comment to
avert future confusion, and refreshed the subsequent xen patches as below.

> Recent hypervisors will actually
> only consume this to issue a warning if not matching what gets
> read from the corresponding BAR. Earlier hypervisors used this
> instead of reading the BAR.

Note that pci_resource_start() gives you a CPU address, and what you
read from the BAR is a PCI bus address.  These are not in the same
address space and can't be directly compared.  I assume the
hypervisors take that into account and do the appropriate
conversions?

Bjorn


commit 34f394aad6706a42fb69922ed184c918ec9f9f81
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Thu Apr 18 15:02:34 2013 -0600

    xen/pci: Comment on unusual PCI_MSIX_TABLE usage
    
    To find the MSI-X Table structure, you look at the BAR specified
    by PCI_MSIX_FLAGS_BIRMASK, then apply the PCI_MSIX_TABLE_OFFSET to
    the address from the BAR.  So most readers of PCI_MSIX_TABLE use
    PCI_MSIX_TABLE_OFFSET, but in xen's case, the hypervisor takes
    care of applying the offset, so we don't need to do it here.
    
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    CC: Jan Beulich <JBeulich@suse.com>

diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 94e7662..96e44fc 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -301,6 +301,7 @@ static int xen_initdom_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
 					      &table_offset);
 			bir = (u8)(table_offset & PCI_MSIX_FLAGS_BIRMASK);
 
+			/* Hypervisor takes care of PCI_MSIX_TABLE_OFFSET */
 			map_irq.table_base = pci_resource_start(dev, bir);
 			map_irq.entry_nr = msidesc->msi_attrib.entry_nr;
 		}

commit 311d82d74afa19cb0ea03c516e290457f9aab63d
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Thu Apr 18 12:40:33 2013 -0600

    xen/pci: Use PCI_MSIX_TABLE_BIR, not PCI_MSIX_FLAGS_BIRMASK
    
    PCI_MSIX_FLAGS_BIRMASK is mis-named because the BIR mask is in the
    Table Offset register, not the flags ("Message Control" per spec)
    register.
    
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    CC: Jan Beulich <JBeulich@suse.com>

diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 96e44fc..bec03d4 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -299,7 +299,7 @@ static int xen_initdom_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
 
 			pci_read_config_dword(dev, pos + PCI_MSIX_TABLE,
 					      &table_offset);
-			bir = (u8)(table_offset & PCI_MSIX_FLAGS_BIRMASK);
+			bir = (u8)(table_offset & PCI_MSIX_TABLE_BIR);
 
 			/* Hypervisor takes care of PCI_MSIX_TABLE_OFFSET */
 			map_irq.table_base = pci_resource_start(dev, bir);

commit 4a5b938fe2ed3e5f5c51f4906c0d1c1486f37e49
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Thu Apr 18 15:10:58 2013 -0600

    xen/pci: Used cached MSI-X capability offset
    
    We now cache the MSI-X capability offset in the struct pci_dev, so no
    need to find the capability again.
    
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    CC: Jan Beulich <JBeulich@suse.com>

diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index bec03d4..a151b02 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -295,8 +295,7 @@ static int xen_initdom_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
 			int pos;
 			u32 table_offset, bir;
 
-			pos = pci_find_capability(dev, PCI_CAP_ID_MSIX);
-
+			pos = dev->msix_cap;
 			pci_read_config_dword(dev, pos + PCI_MSIX_TABLE,
 					      &table_offset);
 			bir = (u8)(table_offset & PCI_MSIX_TABLE_BIR);

  reply	other threads:[~2013-04-25 16:42 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-22 23:10 [PATCH v4 00/22] PCI: Cache MSI/MSI-X capability offsets, other cleanup Bjorn Helgaas
2013-04-22 23:10 ` [PATCH v4 01/22] [SCSI] megaraid_sas: Use correct #define for MSI-X capability Bjorn Helgaas
2013-04-22 23:52   ` Radford, Adam
2013-04-22 23:10 ` [PATCH v4 02/22] PCI: Use u8, not int, for PM capability offset Bjorn Helgaas
2013-04-22 23:32   ` Rafael J. Wysocki
2013-04-22 23:10 ` [PATCH v4 03/22] PCI: Cache MSI/MSI-X capability offsets in struct pci_dev Bjorn Helgaas
2013-04-22 23:10 ` [PATCH v4 04/22] PCI: Remove MSI/MSI-X cap check in pci_msi_check_device() Bjorn Helgaas
2013-04-22 23:10 ` [PATCH v4 05/22] PCI: Use cached MSI cap while enabling MSI interrupts Bjorn Helgaas
2013-04-22 23:10 ` [PATCH v4 06/22] PCI: Use cached MSI-X cap while enabling MSI-X Bjorn Helgaas
2013-04-22 23:11 ` [PATCH v4 07/22] PCI: Clean up MSI/MSI-X capability #defines Bjorn Helgaas
2013-04-22 23:11 ` [PATCH v4 08/22] PCI: Use cached MSI/MSI-X offsets from dev, not from msi_desc Bjorn Helgaas
2013-04-22 23:11 ` [PATCH v4 09/22] PCI: Drop msi_control_reg() macro and use PCI_MSI_FLAGS directly Bjorn Helgaas
2013-04-22 23:11 ` [PATCH v4 10/22] PCI: Drop msi_lower_address_reg() and msi_upper_address_reg() macros Bjorn Helgaas
2013-04-22 23:11 ` [PATCH v4 11/22] PCI: Drop msi_data_reg() macro Bjorn Helgaas
2013-04-22 23:11 ` [PATCH v4 12/22] PCI: Drop is_64bit_address() and is_mask_bit_support() macros Bjorn Helgaas
2013-04-22 23:11 ` [PATCH v4 13/22] PCI: Drop msix_table_offset_reg() and msix_pba_offset_reg() macros Bjorn Helgaas
2013-04-22 23:11 ` [PATCH v4 14/22] PCI: Use msix_table_size() directly, drop multi_msix_capable() Bjorn Helgaas
2013-04-22 23:11 ` [PATCH v4 15/22] PCI: Drop msi_mask_reg() and remove drivers/pci/msi.h Bjorn Helgaas
2013-04-22 23:12 ` [PATCH v4 16/22] PCI: Use PCI_MSIX_TABLE_BIR, not PCI_MSIX_FLAGS_BIRMASK Bjorn Helgaas
2013-04-22 23:12 ` [PATCH v4 17/22] PCI: Remove "extern" from function declarations Bjorn Helgaas
2013-04-22 23:12 ` [PATCH v4 18/22] xen/pci: Pay attention to PCI_MSIX_TABLE_OFFSET Bjorn Helgaas
2013-04-24 16:34   ` Bjorn Helgaas
2013-04-25  9:40     ` [Xen-devel] " Jan Beulich
2013-04-25 16:42       ` Bjorn Helgaas [this message]
2013-04-26  7:16         ` Jan Beulich
2013-04-26 14:50           ` Bjorn Helgaas
2013-04-22 23:12 ` [PATCH v4 19/22] xen/pci: Use PCI_MSIX_TABLE_BIR, not PCI_MSIX_FLAGS_BIRMASK Bjorn Helgaas
2013-04-24 16:35   ` Bjorn Helgaas
2013-04-22 23:12 ` [PATCH v4 20/22] xen/pci: Used cached MSI-X capability offset Bjorn Helgaas
2013-04-24 16:35   ` Bjorn Helgaas
2013-04-22 23:12 ` [PATCH v4 21/22] vfio-pci: Use PCI_MSIX_TABLE_BIR, not PCI_MSIX_FLAGS_BIRMASK Bjorn Helgaas
2013-04-23 20:12   ` Alex Williamson
2013-04-22 23:12 ` [PATCH v4 22/22] vfio-pci: Use cached MSI/MSI-X capabilities Bjorn Helgaas
2013-04-23 20:13   ` Alex Williamson
2013-04-24 17:48 ` [PATCH v4 00/22] PCI: Cache MSI/MSI-X capability offsets, other cleanup Bjorn Helgaas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130425164238.GA3052@google.com \
    --to=bhelgaas@google.com \
    --cc=JBeulich@suse.com \
    --cc=jeremy@goop.org \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=shangw@linux.vnet.ibm.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).