From: Baoquan He <bhe-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org
Cc: kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Vincent.Wan-5C7GfCeVMHo@public.gmane.org,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
Subject: Re: [PATCH v6 0/9] Fix kdump faults on system with amd iommu
Date: Fri, 4 Nov 2016 13:29:13 +0800 [thread overview]
Message-ID: <20161104052913.GC4314@x1> (raw)
In-Reply-To: <20161104051459.GB4314@x1>
On 11/04/16 at 01:14pm, Baoquan He wrote:
> Hi Joerg,
>
> Ping!
>
> About the v6 post, do you have any suggestions?
>
> Because of GCR3 special handling in patch 9/9, I spent several days to
> study the knowledge and change code. Then when I tried to post, the
> virtual interrupt remapping feature caused kernel hang with this pachset
> applied. So it took me days to study spec and find it out. Finally it's
> very late to post.
>
> Coule it be possibe that we review and merge patch 9/1~8, and leave the
> patch 9/9 which includes GCR3 special handling as 2nd step issue? Then
> I can back port patch 9/1~8 to our distro. Since this bug has been
> discussed so long time, and currently almost all system are deployed
> with amd iommu v1 hardware. It would be great if they can be accepted
~~~~~~~~~~~~~~~~~~~~~~~~~~~ Here I meant in our Redhat lab almost all
system are only deployed with amd iommu v1 support.
> into 4.9 or 4.10-rc phase.
>
> About patch 9/9, its code is a little complicated and not being
> reviewed, I am not sure if I understand your suggestion and GCR3 code
> well. What's your opinion?
>
> Thanks
> Baoquan
>
>
> On 10/20/16 at 07:37pm, Baoquan He wrote:
> > This is v6 post.
> >
> > The principle of the fix is similar to intel iommu. Just defer the assignment
> > of device to domain to device driver init. But there's difference than
> > intel iommu. AMD iommu create protection domain and assign device to
> > domain in iommu driver init stage. So in this patchset I just allow the
> > assignment of device to domain in software level, but defer updating the
> > domain info, especially the pte_root to dev table entry to device driver
> > init stage.
> >
> > v5:
> > bnx2 NIC can't reset itself during driver init. Post patch to reset
> > it during driver init. IO_PAGE_FAULT can't be seen anymore.
> >
> > Below is link of v5 post.
> > https://lists.linuxfoundation.org/pipermail/iommu/2016-September/018527.html
> >
> > v5->v6:
> > According to Joerg's comments made several below main changes:
> > - Add sanity check when copy old dev tables.
> >
> > - Discard the old patch 6/8.
> >
> > - If a device is set up with guest translations (DTE.GV=1), then don't
> > copy that information but move the device over to an empty guest-cr3
> > table and handle the faults in the PPR log (which just answer them
> > with INVALID).
> >
> > Issues need be discussed:
> > - Joerg suggested hooking the behaviour that updates domain info into
> > dte entry into the set_dma_mask call-back. I tried, but on my local
> > machine with amd iommu v2, an ohci pci device doesn't call set_dma_mask.
> > Then IO_PAGE_FAULT printing flooded.
> >
> > 00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller (rev 11)
> >
> > - About GCR3 root pointer copying issue, I don't know how to setup the
> > test environment and haven't tested yet. Hope Joerg or Zongshun can
> > tell what steps should be taken to test it, or help take a test in your
> > test environemnt.
> >
> > Baoquan He (9):
> > iommu/amd: Detect pre enabled translation
> > iommu/amd: add several helper function
> > iommu/amd: Define bit fields for DTE particularly
> > iommu/amd: Add function copy_dev_tables
> > iommu/amd: copy old trans table from old kernel
> > iommu/amd: Don't update domain info to dte entry at iommu init stage
> > iommu/amd: Update domain into to dte entry during device driver init
> > iommu/amd: Add sanity check of irq remap information of old dev table
> > entry
> > iommu/amd: Don't copy GCR3 table root pointer
> >
> > drivers/iommu/amd_iommu.c | 93 +++++++++++++-------
> > drivers/iommu/amd_iommu_init.c | 189 +++++++++++++++++++++++++++++++++++++---
> > drivers/iommu/amd_iommu_proto.h | 2 +
> > drivers/iommu/amd_iommu_types.h | 53 ++++++++++-
> > drivers/iommu/amd_iommu_v2.c | 18 +++-
> > 5 files changed, 307 insertions(+), 48 deletions(-)
> >
> > --
> > 2.5.5
> >
next prev parent reply other threads:[~2016-11-04 5:29 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-20 11:37 [PATCH v6 0/9] Fix kdump faults on system with amd iommu Baoquan He
2016-10-20 11:37 ` [PATCH v6 1/9] iommu/amd: Detect pre enabled translation Baoquan He
[not found] ` <1476963440-23039-1-git-send-email-bhe-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-10-20 11:37 ` [PATCH v6 2/9] iommu/amd: add several helper function Baoquan He
2016-10-20 11:37 ` [PATCH v6 3/9] iommu/amd: Define bit fields for DTE particularly Baoquan He
2016-10-20 11:37 ` [PATCH v6 4/9] iommu/amd: Add function copy_dev_tables Baoquan He
2016-10-20 11:37 ` [PATCH v6 5/9] iommu/amd: copy old trans table from old kernel Baoquan He
2016-10-20 11:37 ` [PATCH v6 6/9] iommu/amd: Don't update domain info to dte entry at iommu init stage Baoquan He
2016-10-20 11:37 ` [PATCH v6 7/9] iommu/amd: Update domain into to dte entry during device driver init Baoquan He
2016-11-10 11:48 ` Joerg Roedel
[not found] ` <20161110114816.GE9996-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2016-11-13 5:17 ` Baoquan He
2016-10-20 11:37 ` [PATCH v6 8/9] iommu/amd: Add sanity check of irq remap information of old dev table entry Baoquan He
2016-10-20 11:37 ` [PATCH v6 9/9] iommu/amd: Don't copy GCR3 table root pointer Baoquan He
2016-11-04 5:14 ` [PATCH v6 0/9] Fix kdump faults on system with amd iommu Baoquan He
2016-11-04 5:29 ` Baoquan He [this message]
2016-11-10 11:52 ` Joerg Roedel
[not found] ` <20161110115218.GF9996-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2016-11-13 5:07 ` Baoquan He
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=20161104052913.GC4314@x1 \
--to=bhe-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
--cc=Vincent.Wan-5C7GfCeVMHo@public.gmane.org \
--cc=dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org \
--cc=kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
/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).