[lkml]   [2021]   [May]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 5.10 392/530] iommu/vt-d: Preset Access/Dirty bits for IOVA over FL

    First of all, apologies if this is the wrong place to post a problem
    report. I figured since I was going to reference a particular commit
    anyway I might as well reply to the patch series that (seemed to have)
    introduced the problem.

    > From: Lu Baolu <>
    > [ Upstream commit a8ce9ebbecdfda3322bbcece6b3b25888217f8e3 ]
    > The Access/Dirty bits in the first level page table entry will be set
    > whenever a page table entry was used for address translation or write
    > permission was successfully translated. This is always true when using
    > the first-level page table for kernel IOVA. Instead of wasting hardware
    > cycles to update the certain bits, it's better to set them up at the
    > beginning.

    This commit seems to trigger a kernel panic very early in boot for me in
    5.10.37 (36 is fine):

    Call Trace:
    ? e820__memblock_setup+0x76/0x76
    ? rest_init+0xa4/0xa4
    Modules linked in:
    CR2: 0000000000000000
    ---[ end trace 0904a2a0169baf8a ]--
    RIP: 0010:__domain_mapping+0xa1/0x3a0
    Code: 02 4d 63 ff 0f 85 1b 02 00 00 4c 89 d3 48 c1 e3 0c 4c 09 fb 4d 85 c0 0f 84
    2e 01 00 00 45 31 e4 31 ed 45 31 c9 4d 85 e4 75 58 <49> 8b 5d 00 41 8b 45 08 41
    8b 4d 0c 48 83 e3 fc 48 2b 1d 28 8f b8
    RSP: 0000:ffffafc54002bc00 EFLAGS: 00010246
    RAX: 0000000000000000 RBX: 00000000dd7e4003 RCX: 000000000000002d
    RDX: 0000000000000000 RSI: 00000000000dd7e4 RDI: ffff8b260108ac00
    RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
    R10: 00000000000dd7e4 R11: ffff8b260108ac00 R12: 0000000000000000
    R13: 0000000000000000 R14: 00000000000dd7e4 R15: 0000000000000003
    FS: 0000000000000000(0000) GS:ffff8b290ec80000(0000) knlGS: 000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 00000000080050033
    CR2: 000000000000000 CR3: 0000000009700c001 CR4: 00000000001706e0
    Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009

    I managed to build the kernel with debug info, and could trace the
    problem to drivers/iommu/intel/iommu.c:

    (gdb) l *__domain_mapping+0xa1
    0xffffffff8146b171 is in __domain_mapping (drivers/iommu/intel/iommu.c:2381).

    I then had a look at the commits for v5.10.36..v5.10.37 that touched
    that file, and on a complete hunch reverted this one (there were only 4,
    and this one looked the most suspect to my eyes). I could successfully
    boot into the system again after that.

    I'm unsure what other information about my system to include, please
    advise. Something to note is that I am compiling the 5.10 series with
    GCC 11 for which I'm manually pulling in the following commits:


    I have not yet tried building 5.10.37 with GCC 10 because I already
    cleaned the old compiler from my system. I don't think the compiler is
    to blame here, however.

    Thanks a lot,


     \ /
      Last update: 2021-05-15 15:39    [W:2.311 / U:0.068 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site