Bug 216644 - Host OS hangs when enabling VMD in UEFI setup
Summary: Host OS hangs when enabling VMD in UEFI setup
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: PCI (show other bugs)
Hardware: All Linux
: P1 high
Assignee: drivers_pci@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-10-31 06:05 UTC by Adrian Huang
Modified: 2022-12-02 03:12 UTC (History)
4 users (show)

See Also:
Kernel Version: 6.1-rc2
Subsystem:
Regression: No
Bisected commit-id:


Attachments
OS Log (Serial Log) (131.75 KB, text/plain)
2022-10-31 06:05 UTC, Adrian Huang
Details
[dmesg] apply-vmd-Fix-secondary-bus-reset-for-Intel-bridges (132.36 KB, text/plain)
2022-11-03 05:06 UTC, Adrian Huang
Details

Description Adrian Huang 2022-10-31 06:05:43 UTC
Created attachment 303108 [details]
OS Log (Serial Log)

When enabling VMD in BIOS setup, the host OS cannot boot successfully with the following error message:

[    8.986310] vmd 0000:64:05.5: PCI host bridge to bus 10000:00
...
[    9.674113] vmd 0000:64:05.5: Bound to PCI domain 10000
...
[   33.592638] DMAR: VT-d detected Invalidation Queue Error: Reason f
[   33.592640] DMAR: VT-d detected Invalidation Time-out Error: SID ffff
[   33.599853] DMAR: VT-d detected Invalidation Completion Error: SID ffff
[   33.607339] DMAR: QI HEAD: UNKNOWN qw0 = 0x0, qw1 = 0x0
[   33.621143] DMAR: QI PRIOR: UNKNOWN qw0 = 0x0, qw1 = 0x0
[   33.627366] DMAR: Invalidation Time-out Error (ITE) cleared


*** Hardware Info ***
Platform: skylake-D purley platform
VMD: 8086:201d
    # lspci -s 0000:64:05.5 -nn
    0000:64:05.5 RAID bus controller [0104]: Intel Corporation Volume Management 
    Device NVMe RAID Controller [8086:201d] (rev 04)


*** Detail Info ***
`git bisect` points the following offending patch (commit: 6aab5622296b):

commit 6aab5622296b990024ee67dd7efa7d143e7558d0
Author: Nirmal Patel <nirmal.patel@linux.intel.com>
Date:   Tue Nov 16 15:11:36 2021 -0700

    PCI: vmd: Clean up domain before enumeration

    During VT-d pass-through, the VMD driver occasionally fails to
    enumerate underlying NVMe devices when repetitive reboots are
    performed in the guest OS. The issue can be resolved by resetting
    VMD root ports for proper enumeration and triggering secondary bus
    reset which will also propagate reset through downstream bridges.

    Link: https://lore.kernel.org/r/20211116221136.85134-1-nirmal.patel@linux.intel.com
    Signed-off-by: Nirmal Patel <nirmal.patel@linux.intel.com>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Reviewed-by: Jon Derrick <jonathan.derrick@linux.dev>


*** Debugging Info ***
1. Reverting 6aab5622296b on top of 6.1-rc2 can fix the issue.

2. Comment out for calling vmd_domain_reset() can also fix the issue. So, it looks like the function memset_io() causes the issue.

static void vmd_domain_reset(struct vmd_dev *vmd)
{
        ...
        for (bus = 0; bus < max_buses; bus++) {
                for (dev = 0; dev < 32; dev++) {
                                ...

                                memset_io(base + PCI_IO_BASE, 0,
                                          PCI_ROM_ADDRESS1 - PCI_IO_BASE);
                        }
                }
        }
}

3. pci_reset_bus() returns -25 because 'slot' or 'bus->self' is NULL. 

4. We have 4 disks attached to VMD:
# nvme list
Node                  Generic               SN                   Model                                    Namespace Usage                      Format           FW Rev
--------------------- --------------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
/dev/nvme3n1          /dev/ng3n1            222639A46A39         Micron_7450_MTFDKBA960TFR                1          11.48  GB / 960.20  GB    512   B +  0 B   E2MU111
/dev/nvme2n1          /dev/ng2n1            222639A46A30         Micron_7450_MTFDKBA960TFR                1           4.18  GB / 960.20  GB    512   B +  0 B   E2MU111
/dev/nvme1n1          /dev/ng1n1            BTLJ849201CE1P0I     SSDPELKX010T8L                           1           1.00  TB /   1.00  TB    512   B +  0 B   VCV1LZ37
/dev/nvme0n1          /dev/ng0n1            BTLJ849201BS1P0I     SSDPELKX010T8L                           1           1.00  TB /   1.00  TB    512   B +  0 B   VCV1LZ37

Any thoughts? Thanks for the help.
Comment 1 Adrian Huang 2022-11-03 05:06:31 UTC
Created attachment 303124 [details]
[dmesg] apply-vmd-Fix-secondary-bus-reset-for-Intel-bridges

Tried to apply the upstream discussion: https://lore.kernel.org/all/20220923203757.4918-1-francisco.munoz.ruiz@linux.intel.com/

The patch gets worse (without reverting 6aab5622296b: apply the patch on top of 6.1-rc3). The bus reset spends about 65 seconds until it gives up (timeout = 60 ms --> PCIE_RESET_READY_POLL_MS)

And, the original issue is still there.

...
[    9.097319] vmd 0000:64:05.5: PCI host bridge to bus 10000:00
...
[   11.580708] pci 10000:00:00.0: not ready 1023ms after bus reset; waiting
[   12.668707] pci 10000:00:00.0: not ready 2047ms after bus reset; waiting
[   14.780708] pci 10000:00:00.0: not ready 4095ms after bus reset; waiting
[   19.260716] pci 10000:00:00.0: not ready 8191ms after bus reset; waiting
[   27.964707] pci 10000:00:00.0: not ready 16383ms after bus reset; waiting
[   44.860707] pci 10000:00:00.0: not ready 32767ms after bus reset; waiting
[   81.212716] pci 10000:00:00.0: not ready 65535ms after bus reset; giving up
...
[  104.424169] DMAR: VT-d detected Invalidation Queue Error: Reason f
[  104.424172] DMAR: VT-d detected Invalidation Time-out Error: SID ffff
[  104.431382] DMAR: VT-d detected Invalidation Completion Error: SID ffff
[  104.438919] DMAR: QI HEAD: UNKNOWN qw0 = 0x0, qw1 = 0x0
[  104.452790] DMAR: QI PRIOR: UNKNOWN qw0 = 0x0, qw1 = 0x0
[  104.459042] DMAR: Invalidation Time-out Error (ITE) cleared
...
Comment 2 Bjorn Helgaas 2022-11-03 16:38:36 UTC
I forwarded the original report to the VMD folks and the linux mailing lists: https://lore.kernel.org/r/20221031113924.GA1081013@bhelgaas

Most people don't follow bugzilla, so you might want to follow-up to that message and cc: Francisco to make sure he sees it.
Comment 3 Nirmal Patel 2022-11-03 23:11:03 UTC
We are looking into this issue. I will get back to you as soon as I get some update. Does disabling Interrupt remap under T-d setting in BIOS make any difference?
Comment 4 Francisco Munoz-Ruiz 2022-12-01 00:16:45 UTC
Adrian,

Did you try what Nirmal suggested?

--Francisco.
Comment 5 Francisco Munoz-Ruiz 2022-12-01 00:41:42 UTC
Hi Adrian,

I'd like to add that it seems you are using a non-Intel BIOS. Can we rule out a BIOS problem first?

--Francisco.
Comment 6 Adrian Huang 2022-12-01 01:44:47 UTC
(In reply to Francisco Munoz-Ruiz from comment #4)
> Adrian,
> 
> Did you try what Nirmal suggested?
> 
> --Francisco.

Hi Francisco,

Yes, I tried and replied the result on Nov 4: https://lore.kernel.org/all/TYZPR03MB6192E7E96D51489ABF38C4CCB33B9@TYZPR03MB6192.apcprd03.prod.outlook.com/
Comment 7 Francisco Munoz-Ruiz 2022-12-02 03:12:00 UTC
Adrian,

Can you check with your BIOS provider.?

Thanks,
Francisco.

Note You need to log in before you can comment on or make changes to this bug.