linux-kernel - Re: [PATCH v6 0/9] Fix kdump faults on system with amd iommu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20161104052913.GC4314@x1>
Date:   Fri, 4 Nov 2016 13:29:13 +0800
From:   Baoquan He <bhe@...hat.com>
To:     joro@...tes.org
Cc:     iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
        kexec@...ts.infradead.org, Vincent.Wan@....com, dyoung@...hat.com,
        xlpang@...hat.com
Subject: Re: [PATCH v6 0/9] Fix kdump faults on system with amd iommu

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
> >