From: Baoquan He <bhe@redhat.com>
To: Joerg Roedel <joro@8bytes.org>
Cc: Dept-HSGLinuxNICDev@qlogic.com, sony.chacko@qlogic.com,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
dyoung@redhat.com, kexec@lists.infradead.org
Subject: Re: [PATCH] bnx2: Reset device during driver initialization
Date: Fri, 9 Sep 2016 16:50:05 +0800 [thread overview]
Message-ID: <20160909085005.GG11356@x1.redhat.com> (raw)
In-Reply-To: <20160909084106.GY1437@8bytes.org>
On 09/09/16 at 10:41am, Joerg Roedel wrote:
>
> Hi Baoquan,
>
> On Fri, Sep 09, 2016 at 04:22:25PM +0800, Baoquan He wrote:
> > Recently I tried to fix the kdump failure in amd iommu system again, and
> > now the latest code works, IO_PAGE_FAULT can't be seen any more. But on
> > several amd iommu system with bnx2 NIC, always IO_PAGE_FAULT will be
> > printed out. After investegating I found out bnx2 driver doesn't reset
> > hardware/reg like other pci device, it does the reset job in bnx2_open
> > which is the net device up stage. So with this patch the IO_PAGE_FAULT
> > is away too on the system with bnx2 NIC. I will
> >
> > However when I got a intel system with vt-d and bnx2 NIC, kdump works
> > well, and no any error message can be seen. From code it clearly shows
> > the domain assignment is done in __intel_map_single, at this time bnx2
> > driver hasn't reset device, the on-flight DMA should still exist. Do you
> > have any idea on this? Or I missed anything? I also deferred the
> > set_dte_entry calling to __map_single calling, the principal should be
> > similar.
>
> Did you make sure that all unity-mappings are in place in the newly
> assigned domain for the bnx2 device before domains are switched?
About unity-mappings, are you saying it for intel iommu or amd iommu?
For amd iommu, I just skip call set_dte_entry calling during iommu
device init stage. Then in device init stage, namely __map_single, judge
and call set_dte_entry there to install the new pt_root into the related
dev table entry.
Thought you mention it, let me look into the unity-mappings of amd iommu
again.
Thanks a lot!
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: Joerg Roedel <joro@8bytes.org>
Cc: sony.chacko@qlogic.com, Dept-HSGLinuxNICDev@qlogic.com,
linux-kernel@vger.kernel.org, kexec@lists.infradead.org,
netdev@vger.kernel.org, dyoung@redhat.com
Subject: Re: [PATCH] bnx2: Reset device during driver initialization
Date: Fri, 9 Sep 2016 16:50:05 +0800 [thread overview]
Message-ID: <20160909085005.GG11356@x1.redhat.com> (raw)
In-Reply-To: <20160909084106.GY1437@8bytes.org>
On 09/09/16 at 10:41am, Joerg Roedel wrote:
>
> Hi Baoquan,
>
> On Fri, Sep 09, 2016 at 04:22:25PM +0800, Baoquan He wrote:
> > Recently I tried to fix the kdump failure in amd iommu system again, and
> > now the latest code works, IO_PAGE_FAULT can't be seen any more. But on
> > several amd iommu system with bnx2 NIC, always IO_PAGE_FAULT will be
> > printed out. After investegating I found out bnx2 driver doesn't reset
> > hardware/reg like other pci device, it does the reset job in bnx2_open
> > which is the net device up stage. So with this patch the IO_PAGE_FAULT
> > is away too on the system with bnx2 NIC. I will
> >
> > However when I got a intel system with vt-d and bnx2 NIC, kdump works
> > well, and no any error message can be seen. From code it clearly shows
> > the domain assignment is done in __intel_map_single, at this time bnx2
> > driver hasn't reset device, the on-flight DMA should still exist. Do you
> > have any idea on this? Or I missed anything? I also deferred the
> > set_dte_entry calling to __map_single calling, the principal should be
> > similar.
>
> Did you make sure that all unity-mappings are in place in the newly
> assigned domain for the bnx2 device before domains are switched?
About unity-mappings, are you saying it for intel iommu or amd iommu?
For amd iommu, I just skip call set_dte_entry calling during iommu
device init stage. Then in device init stage, namely __map_single, judge
and call set_dte_entry there to install the new pt_root into the related
dev table entry.
Thought you mention it, let me look into the unity-mappings of amd iommu
again.
Thanks a lot!
next prev parent reply other threads:[~2016-09-09 8:50 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-09 8:11 [PATCH] bnx2: Reset device during driver initialization Baoquan He
2016-09-09 8:11 ` Baoquan He
2016-09-09 8:22 ` Baoquan He
2016-09-09 8:22 ` Baoquan He
2016-09-09 8:41 ` Joerg Roedel
2016-09-09 8:50 ` Baoquan He [this message]
2016-09-09 8:50 ` Baoquan He
2016-09-09 9:28 ` Baoquan He
2016-09-09 9:28 ` Baoquan He
2016-09-09 9:50 ` Baoquan He
2016-09-09 9:50 ` Baoquan He
2016-09-13 15:25 ` David Miller
2016-09-13 15:25 ` David Miller
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=20160909085005.GG11356@x1.redhat.com \
--to=bhe@redhat.com \
--cc=Dept-HSGLinuxNICDev@qlogic.com \
--cc=dyoung@redhat.com \
--cc=joro@8bytes.org \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=sony.chacko@qlogic.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.