From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Cc: linux-pci@vger.kernel.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
xen-devel <xen-devel@lists.xen.org>,
bhelgaas@google.com, Feng Jin <joe.jin@oracle.com>,
Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
Subject: Re: [PATCH 2/3] Refactor msi/msix restore code Part2
Date: Wed, 24 Jul 2013 09:46:22 -0400 [thread overview]
Message-ID: <20130724134622.GC2518@phenom.dumpdata.com> (raw)
In-Reply-To: <51EF451A.8050003@oracle.com>
On Wed, Jul 24, 2013 at 11:08:10AM +0800, Zhenzhong Duan wrote:
> xen_initdom_restore_msi_irqs trigger a hypercall to restore addr/data/mask
> in dom0. It's better to do the same for default_restore_msi_irqs in baremetal.
>
> Move restore of mask in default_restore_msi_irqs, this could avoid mask
> restored twice in dom0, once in hypercall, the other in kernel.
Why not remove the hypercall then? Or alter the function to detect
whether the restore of the mask has occurred?
>
> Without that, qlcnic driver calling pci_reset_function will lost interrupt
> in dom0.
>
> Tested-by: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
> ---
> drivers/pci/msi.c | 17 ++++++++++++++---
> 1 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index 87223ae..922fb49 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -216,6 +216,8 @@ void unmask_msi_irq(struct irq_data *data)
> #ifdef HAVE_DEFAULT_MSI_RESTORE_IRQS
> void default_restore_msi_irqs(struct pci_dev *dev, int irq)
> {
> + int pos;
> + u16 control;
> struct msi_desc *entry;
>
> entry = NULL;
> @@ -228,8 +230,19 @@ void default_restore_msi_irqs(struct pci_dev *dev, int irq)
> entry = irq_get_msi_desc(irq);
> }
>
> - if (entry)
> + if (entry) {
> write_msi_msg(irq, &entry->msg);
> + if (dev->msix_enabled) {
> + msix_mask_irq(entry, entry->masked);
> + readl(entry->mask_base);
> + } else {
> + pos = entry->msi_attrib.pos;
> + pci_read_config_word(dev, pos + PCI_MSI_FLAGS,
> + &control);
> + msi_mask_irq(entry, msi_capable_mask(control),
> + entry->masked);
> + }
> + }
> }
> #endif
>
> @@ -406,7 +419,6 @@ static void __pci_restore_msi_state(struct pci_dev *dev)
> arch_restore_msi_irqs(dev, dev->irq);
>
> pci_read_config_word(dev, dev->msi_cap + PCI_MSI_FLAGS, &control);
> - msi_mask_irq(entry, msi_capable_mask(control), entry->masked);
Before this patch we had:
write_msi_msg(..)
pci_read_config_work(PCI_MSI_FLAGS, &control)
pci_write_config_dword(~msi_capable_mask(control) | entry->masked)
control &= ~_PCI_MSI_FLAGS_QSIZE;
control |= ...
pci_write_config_dword(PCI_MSI_FLAGS, control)
while with this you have now:
write_msi_msg(..)
pci_read_config_work(PCI_MSI_FLAGS, &_control)
pci_write_config_dword(~msi_capable_mask(_control) | entry->masked)
--> pci_read_config_work(PCI_MSI_FLAGS, &control)
control &= ~_PCI_MSI_FLAGS_QSIZE;
control |= ...
pci_write_config_dword(PCI_MSI_FLAGS, control)
see the problem? The 'control' value in __pci_restore_msi_state reads the
value _after_ it has been masked (which is now done in default_restore_msi_irqs).
Wouldn't that cause problems?
> control &= ~PCI_MSI_FLAGS_QSIZE;
> control |= (entry->msi_attrib.multiple << 4) | PCI_MSI_FLAGS_ENABLE;
> pci_write_config_word(dev, dev->msi_cap + PCI_MSI_FLAGS, control);
> @@ -430,7 +442,6 @@ static void __pci_restore_msix_state(struct pci_dev *dev)
>
> list_for_each_entry(entry, &dev->msi_list, list) {
> arch_restore_msi_irqs(dev, entry->irq);
> - msix_mask_irq(entry, entry->masked);
> }
>
> control &= ~PCI_MSIX_FLAGS_MASKALL;
> --
> 1.7.3
>
next prev parent reply other threads:[~2013-07-24 13:46 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-24 3:08 [PATCH 2/3] Refactor msi/msix restore code Part2 Zhenzhong Duan
2013-07-24 13:46 ` Konrad Rzeszutek Wilk [this message]
2013-07-25 6:52 ` Zhenzhong Duan
2013-07-25 12:25 ` Konrad Rzeszutek Wilk
2013-07-26 3:01 ` Zhenzhong Duan
2013-07-31 22:41 ` Bjorn Helgaas
2013-08-01 15:16 ` Konrad Rzeszutek Wilk
2013-08-02 9:16 ` Zhenzhong Duan
2013-08-02 12:01 ` Konrad Rzeszutek Wilk
2013-08-05 7:19 ` Zhenzhong Duan
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=20130724134622.GC2518@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=bhelgaas@google.com \
--cc=joe.jin@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=sucheta.chakraborty@qlogic.com \
--cc=xen-devel@lists.xen.org \
--cc=zhenzhong.duan@oracle.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).