Bug #284
openlenovo/g505s: no IOMMU while using CONFIG_SECURITY_CLEAR_DRAM_ON_REGULAR_BOOT
20%
Description
JDC_SEC_RLS:
# dmesg | grep -i iommu
[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.19.0-9-amd64 root=/dev/mapper/vg1-root ro amd_iommu=on iommu=pt ipv6.disable=1 quiet
[ 0.156855] Kernel command line: BOOT_IMAGE=/vmlinuz-4.19.0-9-amd64 root=/dev/mapper/vg1-root ro amd_iommu=on iommu=pt ipv6.disable=1 quiet
[ 1.113669] AMD IOMMUv2 driver by Joerg Roedel <jroedel@suse.de>
[ 1.113670] AMD IOMMUv2 functionality not available on this system
JDC_SUS_RLS:
# dmesg | grep -i iommu
[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.19.0-9-amd64 root=/dev/mapper/vg1-root ro amd_iommu=on iommu=pt ipv6.disable=1 quiet
[ 0.004034] ACPI: IVRS 0x000000005FE24B80 000070 (v02 AMD AMDIOMMU 00000001 AMD 00000000)
[ 0.461293] Kernel command line: BOOT_IMAGE=/vmlinuz-4.19.0-9-amd64 root=/dev/mapper/vg1-root ro amd_iommu=on iommu=pt ipv6.disable=1 quiet
[ 2.688739] AMD-Vi: Applying erratum 746 workaround for IOMMU at 0000:00:00.2
[ 2.689601] iommu: Adding device 0000:00:01.0 to group 0
[ 2.689632] iommu: Using direct mapping for device 0000:00:01.0
[ 2.689675] iommu: Adding device 0000:00:01.1 to group 0
[ 2.689804] iommu: Adding device 0000:00:02.0 to group 1
[ 2.689829] iommu: Using direct mapping for device 0000:00:02.0
[ 2.689954] iommu: Adding device 0000:00:04.0 to group 2
[ 2.689978] iommu: Using direct mapping for device 0000:00:04.0
[ 2.690103] iommu: Adding device 0000:00:11.0 to group 3
[ 2.690127] iommu: Using direct mapping for device 0000:00:11.0
[ 2.690285] iommu: Adding device 0000:00:12.0 to group 4
[ 2.690309] iommu: Using direct mapping for device 0000:00:12.0
[ 2.690350] iommu: Adding device 0000:00:12.2 to group 4
[ 2.690504] iommu: Adding device 0000:00:13.0 to group 5
[ 2.690527] iommu: Using direct mapping for device 0000:00:13.0
[ 2.690570] iommu: Adding device 0000:00:13.2 to group 5
[ 2.690745] iommu: Adding device 0000:00:14.0 to group 6
[ 2.690769] iommu: Using direct mapping for device 0000:00:14.0
[ 2.690812] iommu: Adding device 0000:00:14.2 to group 6
[ 2.690855] iommu: Adding device 0000:00:14.3 to group 6
[ 2.690975] iommu: Adding device 0000:00:14.4 to group 7
[ 2.690999] iommu: Using direct mapping for device 0000:00:14.4
[ 2.691152] iommu: Adding device 0000:00:16.0 to group 8
[ 2.691176] iommu: Using direct mapping for device 0000:00:16.0
[ 2.691225] iommu: Adding device 0000:00:16.2 to group 8
[ 2.691448] iommu: Adding device 0000:00:18.0 to group 9
[ 2.691471] iommu: Using direct mapping for device 0000:00:18.0
[ 2.691517] iommu: Adding device 0000:00:18.1 to group 9
[ 2.691564] iommu: Adding device 0000:00:18.2 to group 9
[ 2.691611] iommu: Adding device 0000:00:18.3 to group 9
[ 2.691658] iommu: Adding device 0000:00:18.4 to group 9
[ 2.691705] iommu: Adding device 0000:00:18.5 to group 9
[ 2.691732] iommu: Adding device 0000:01:00.0 to group 1
[ 2.691759] iommu: Adding device 0000:02:00.0 to group 2
[ 2.692874] AMD-Vi: Found IOMMU at 0000:00:00.2 cap 0x40
[ 3.425040] AMD IOMMUv2 driver by Joerg Roedel <jroedel@suse.de>
Configs of JDC_SEC_RLS and JDC_SUS_RLS could be found here. I can reproduce this behavior with self-compiled build of stable 4.12 (12 May), config attached.
Related bug: Low uptime while using YABEL on g505s
Files
Updated by Mike Banon about 4 years ago
- File cbmem_sec.txt cbmem_sec.txt added
- File kernel_sec.txt kernel_sec.txt added
- Assignee set to Kyösti Mälkki
- % Done changed from 0 to 10
Similar to https://ticket.coreboot.org/issues/283 , it's not a yabel's fault - instead, CONFIG_SECURITY_CLEAR_DRAM_ON_REGULAR_BOOT seems to be breaking not just S3 Suspend (which is expected) but also IOMMU and maybe something else! Please see the attached logs of a SEC build:
1) cbmem_sec.txt - coreboot's log obtained with cbmem utility
2) kernel_sec.txt - just the first 3.5 seconds of a kernel log (to avoid a boring manual removal of many serial numbers)
Compare them with these logs of an "ordinary" build I've submitted here - https://coreboot.org/status/board-status.html#lenovo/g505s . You'd see that ACPI tables are smaller in a SEC build - no IOMMU entry. Looking at lspci, 24 IRQ hasn't been assigned to 00:00.2 IOMMU device, "24: 0 0 0 0 PCI-MSI 4096-edge AMD-Vi" line is missing from /proc/interrupts and many interrupt numbers have shifted.
To me it seems that some parts of AGESA got accidentally corrupted during this DRAM clearing - and, until someone will investigate this more and maybe introduce some "protected regions" belonging to AGESA which shouldn't be cleared, there will be the problems with CONFIG_SECURITY_CLEAR_DRAM_ON_REGULAR_BOOT. I'm surprised the whole thing still boots, although a coreinfo payload breaks down maybe because of that. I even got a Could not open /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq: No such file or directory error while trying to use a cbmem - had to workaround this manually, but that this device's virtual file was missing while running such a build - clearly is a sign of these bigger problems.
Updated by Mike Banon over 3 years ago
- Subject changed from No IOMMU while using YABEL on g505s to lenovo/g505s: no IOMMU while using CONFIG_SECURITY_CLEAR_DRAM_ON_REGULAR_BOOT
- Category set to chipset configuration
- Status changed from New to In Progress
- % Done changed from 10 to 20