On a Xen dom0 boot, this feature does not behave, and we end up calculating:
num_roots = 1 num_nodes = 2 roots_per_node = 0
This causes a divide-by-zero in the modulus inside the loop.
This change adds a couple of guards for invalid states where we might get a divide-by-zero.
Signed-off-by: Steven Noonan steven@uplinklabs.net Signed-off-by: Ariadne Conill ariadne@ariadne.space CC: Yazen Ghannam yazen.ghannam@amd.com CC: x86@vger.kernel.org CC: stable@vger.kernel.org --- arch/x86/kernel/amd_node.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
diff --git a/arch/x86/kernel/amd_node.c b/arch/x86/kernel/amd_node.c index 3d0a4768d603c..cdc6ba224d4ad 100644 --- a/arch/x86/kernel/amd_node.c +++ b/arch/x86/kernel/amd_node.c @@ -282,6 +282,17 @@ static int __init amd_smn_init(void) return -ENODEV;
num_nodes = amd_num_nodes(); + + if (!num_nodes) + return -ENODEV; + + /* Possibly a virtualized environment (e.g. Xen) where we wi ll get + * roots_per_node=0 if the number of roots is fewer than number of + * nodes + */ + if (num_roots < num_nodes) + return -ENODEV; + amd_roots = kcalloc(num_nodes, sizeof(*amd_roots), GFP_KERNEL); if (!amd_roots) return -ENOMEM;
We should be checking the `smn_exclusive` flag before anything else, because that indicates whether we got through `amd_smn_init` successfully.
Without this change, we dereference `amd_roots` even though it may not be allocated.
Signed-off-by: Steven Noonan steven@uplinklabs.net Signed-off-by: Ariadne Conill ariadne@ariadne.space CC: Yazen Ghannam yazen.ghannam@amd.com CC: x86@vger.kernel.org CC: stable@vger.kernel.org --- arch/x86/kernel/amd_node.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/amd_node.c b/arch/x86/kernel/amd_node.c index cdc6ba224d4ad..919932339f4a2 100644 --- a/arch/x86/kernel/amd_node.c +++ b/arch/x86/kernel/amd_node.c @@ -88,6 +88,9 @@ static int __amd_smn_rw(u8 i_off, u8 d_off, u16 node, u32 address, u32 *value, b struct pci_dev *root; int err = -ENODEV;
+ if (!smn_exclusive) + return err; + if (node >= amd_num_nodes()) return err;
@@ -95,9 +98,6 @@ static int __amd_s mn_rw(u8 i_off, u8 d_off, u16 node, u32 address, u32 *value, b if (!root) return err;
- if (!smn_exclusive) - return err; - guard(mutex)(&smn_mutex);
err = pci_write_config_dword(root, i_off, address);
On Fri, Nov 14, 2025 at 07:57:35PM +0000, Steven Noonan wrote:
Thanks Steven for the patch.
On a Xen dom0 boot, this feature does not behave, and we end up calculating:
num_roots = 1 num_nodes = 2 roots_per_node = 0This causes a divide-by-zero in the modulus inside the loop.
Can you please share more details of the system topology?
I think the list of PCI devices is a good start.
This change adds a couple of guards for invalid states where we might get a divide-by-zero.
This statement should be imperative, ex. "Add a couple of guards...".
Also, the commit message should generally be in a passive voice (no "we"), ex. "...where a divide-by-zero may result."
Signed-off-by: Steven Noonan steven@uplinklabs.net Signed-off-by: Ariadne Conill ariadne@ariadne.space
The Signed-off-by lines should be in the order of handling. If you are sending the patch, then your line should be last. If there are other contributors, then they should have a Co-developed-by tag in addition to Signed-off-by.
CC: Yazen Ghannam yazen.ghannam@amd.com CC: x86@vger.kernel.org CC: stable@vger.kernel.org
There should be a Fixes tag along with "Cc: stable", if possible.
arch/x86/kernel/amd_node.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
diff --git a/arch/x86/kernel/amd_node.c b/arch/x86/kernel/amd_node.c index 3d0a4768d603c..cdc6ba224d4ad 100644 --- a/arch/x86/kernel/amd_node.c +++ b/arch/x86/kernel/amd_node.c @@ -282,6 +282,17 @@ static int __init amd_smn_init(void) return -ENODEV; num_nodes = amd_num_nodes();
- if (!num_nodes)
return -ENODEV;
This is generally a good check. But I think it is unnecessary in this case, since the minimum value is '1'. The topology init code initializes the factors used in amd_num_nodes() to '1' before trying to find the true values from CPUID, etc.
- /* Possibly a virtualized environment (e.g. Xen) where we wi
Multi-line comments should start on the next line according to kernel coding style.
/* * Comment * Info */
ll get
* roots_per_node=0 if the number of roots is fewer than number of* nodes*/- if (num_roots < num_nodes)
return -ENODEV;
I think this is a fair check. But I'd like to understand how the topology looks in this case.
Thanks, Yazen
On Fri, Nov 14, 2025 at 07:57:46PM +0000, Steven Noonan wrote:
We should be checking the `smn_exclusive` flag before anything else, because that indicates whether we got through `amd_smn_init` successfully.
Without this change, we dereference `amd_roots` even though it may not be allocated.
Signed-off-by: Steven Noonan steven@uplinklabs.net Signed-off-by: Ariadne Conill ariadne@ariadne.space CC: Yazen Ghannam yazen.ghannam@amd.com CC: x86@vger.kernel.org CC: stable@vger.kernel.org
Same feedback here as for patch 1.
arch/x86/kernel/amd_node.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/amd_node.c b/arch/x86/kernel/amd_node.c index cdc6ba224d4ad..919932339f4a2 100644 --- a/arch/x86/kernel/amd_node.c +++ b/arch/x86/kernel/amd_node.c @@ -88,6 +88,9 @@ static int __amd_smn_rw(u8 i_off, u8 d_off, u16 node, u32 address, u32 *value, b struct pci_dev *root; int err = -ENODEV;
- if (!smn_exclusive)
return err;- if (node >= amd_num_nodes()) return err;
@@ -95,9 +98,6 @@ static int __amd_s mn_rw(u8 i_off, u8 d_off, u16 node, u32 address, u32 *value, b if (!root) return err;
- if (!smn_exclusive)
return err;- guard(mutex)(&smn_mutex);
err = pci_write_config_dword(root, i_off, address); --
This change looks good.
Did you encounter a NULL pointer dereference? Or did you find this by code inspection?
Thanks, Yazen
On Fri, Nov 14, 2025 at 07:57:35PM +0000, Steven Noonan wrote:
On a Xen dom0 boot, this feature does not behave, and we end up calculating:
num_roots = 1 num_nodes = 2 roots_per_node = 0This causes a divide-by-zero in the modulus inside the loop.
This change adds a couple of guards for invalid states where we might get a divide-by-zero.
Signed-off-by: Steven Noonan steven@uplinklabs.net Signed-off-by: Ariadne Conill ariadne@ariadne.space CC: Yazen Ghannam yazen.ghannam@amd.com CC: x86@vger.kernel.org CC: stable@vger.kernel.org
arch/x86/kernel/amd_node.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
diff --git a/arch/x86/kernel/amd_node.c b/arch/x86/kernel/amd_node.c index 3d0a4768d603c..cdc6ba224d4ad 100644 --- a/arch/x86/kernel/amd_node.c +++ b/arch/x86/kernel/amd_node.c @@ -282,6 +282,17 @@ static int __init amd_smn_init(void)
That better not be loading at all on a X86_FEATURE_HYPERVISOR configuration.
On Wed, Dec 03, 2025 at 10:18:13PM +0100, Borislav Petkov wrote:
On Fri, Nov 14, 2025 at 07:57:35PM +0000, Steven Noonan wrote:
On a Xen dom0 boot, this feature does not behave, and we end up calculating:
num_roots = 1 num_nodes = 2 roots_per_node = 0This causes a divide-by-zero in the modulus inside the loop.
This change adds a couple of guards for invalid states where we might get a divide-by-zero.
Signed-off-by: Steven Noonan steven@uplinklabs.net Signed-off-by: Ariadne Conill ariadne@ariadne.space CC: Yazen Ghannam yazen.ghannam@amd.com CC: x86@vger.kernel.org CC: stable@vger.kernel.org
arch/x86/kernel/amd_node.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
diff --git a/arch/x86/kernel/amd_node.c b/arch/x86/kernel/amd_node.c index 3d0a4768d603c..cdc6ba224d4ad 100644 --- a/arch/x86/kernel/amd_node.c +++ b/arch/x86/kernel/amd_node.c @@ -282,6 +282,17 @@ static int __init amd_smn_init(void)
That better not be loading at all on a X86_FEATURE_HYPERVISOR configuration.
Right, so we need a !hypervisor check.
I'm not familiar with the Xen implementation. Does it expect the dom0 guest to be effectively the same as bare metal? Basically, this would act as the 'management' VM that touch hardware?
Thanks, Yazen
(I apologize in advance if my email comes out formatted strangely, I haven't used ProtonMail for LKML before. I don't think it is line-wrapping properly.)
On Wednesday, December 3rd, 2025 at 12:45 PM, Yazen Ghannam yazen.ghannam@amd.com wrote:
On Fri, Nov 14, 2025 at 07:57:35PM +0000, Steven Noonan wrote:
Thanks Steven for the patch.
On a Xen dom0 boot, this feature does not behave, and we end up calculating:
num_roots = 1 num_nodes = 2 roots_per_node = 0
This causes a divide-by-zero in the modulus inside the loop.
Can you please share more details of the system topology?
I think the list of PCI devices is a good start.
Sure, but it's running as the paravirtual control domain for Xen. The `lspci` topology output won't differ between bare-metal and dom0, but dom0's accesses to certain MSRs and PCI registers may be masked and manipulated, which is probably why this is breaking.
I've attached `lspci -nn` and a CPUID dump from CPU0 -- both of these are while running under Xen.
This change adds a couple of guards for invalid states where we might get a divide-by-zero.
This statement should be imperative, ex. "Add a couple of guards...".
Also, the commit message should generally be in a passive voice (no "we"), ex. "...where a divide-by-zero may result."
Ack. I can fix these and the subsequent suggestions for version 2.
Signed-off-by: Steven Noonan steven@uplinklabs.net Signed-off-by: Ariadne Conill ariadne@ariadne.space
The Signed-off-by lines should be in the order of handling. If you are sending the patch, then your line should be last. If there are other contributors, then they should have a Co-developed-by tag in addition to Signed-off-by.
CC: Yazen Ghannam yazen.ghannam@amd.com CC: x86@vger.kernel.org CC: stable@vger.kernel.org
There should be a Fixes tag along with "Cc: stable", if possible.
Ack.
arch/x86/kernel/amd_node.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
diff --git a/arch/x86/kernel/amd_node.c b/arch/x86/kernel/amd_node.c index 3d0a4768d603c..cdc6ba224d4ad 100644 --- a/arch/x86/kernel/amd_node.c +++ b/arch/x86/kernel/amd_node.c @@ -282,6 +282,17 @@ static int __init amd_smn_init(void) return -ENODEV;
num_nodes = amd_num_nodes();
- if (!num_nodes)
- return -ENODEV;
This is generally a good check. But I think it is unnecessary in this case, since the minimum value is '1'. The topology init code initializes the factors used in amd_num_nodes() to '1' before trying to find the true values from CPUID, etc.
- /* Possibly a virtualized environment (e.g. Xen) where we wi
Multi-line comments should start on the next line according to kernel coding style.
/*
- Comment
- Info
*/
ll get
- roots_per_node=0 if the number of roots is fewer than number of
- nodes
- */
- if (num_roots < num_nodes)
- return -ENODEV;
I think this is a fair check. But I'd like to understand how the topology looks in this case.
Thanks, Yazen
On Thu, Dec 04, 2025 at 08:16:36PM +0000, Steven Noonan wrote:
(I apologize in advance if my email comes out formatted strangely, I haven't used ProtonMail for LKML before. I don't think it is line-wrapping properly.)
On Wednesday, December 3rd, 2025 at 12:45 PM, Yazen Ghannam yazen.ghannam@amd.com wrote:
On Fri, Nov 14, 2025 at 07:57:35PM +0000, Steven Noonan wrote:
Thanks Steven for the patch.
On a Xen dom0 boot, this feature does not behave, and we end up calculating:
num_roots = 1 num_nodes = 2 roots_per_node = 0
This causes a divide-by-zero in the modulus inside the loop.
Can you please share more details of the system topology?
I think the list of PCI devices is a good start.
Sure, but it's running as the paravirtual control domain for Xen. The `lspci` topology output won't differ between bare-metal and dom0, but dom0's accesses to certain MSRs and PCI registers may be masked and manipulated, which is probably why this is breaking.
I've attached `lspci -nn` and a CPUID dump from CPU0 -- both of these are while running under Xen.
There is only one "Root Complex [1022:1480]" in the lspci output. And there is only one "Data Fabric: Device 18h;", so that's good.
And this is a desktop Ryzen system, so this makes sense.
So this system should *not* have "num_nodes=2".
CPUID 0x80000008 ECX shows that there are 32 threads per package. CPUID 0x8000001E ECX shows that here is 1 AMD node per package.
I suspect this is a known issue related to ACPI tables and topology.
Can you please try with this patch? https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=x86/boot 845ed7e04d9a ("x86/acpi/boot: Correct acpi_is_processor_usable() check again")
Thanks, Yazen
[...]
CPU 0: CPUID 00000000:00 = 00000010 68747541 444d4163 69746e65 | ....AuthcAMDenti CPUID 00000001:00 = 00a20f12 00200800 fef83203 1789c3f5 | ...... ..2...... CPUID 00000002:00 = 00000000 00000000 00000000 00000000 | ................ CPUID 00000003:00 = 00000000 00000000 00000000 00000000 | ................ CPUID 00000004:00 = 00000000 00000000 00000000 00000000 | ................ CPUID 00000005:00 = 00000040 00000040 00000003 00000011 | @...@........... CPUID 00000006:00 = 00000004 00000000 00000001 00000000 | ................ CPUID 00000007:00 = 00000000 218c0329 0040068c 00000010 | ....)..!..@..... CPUID 00000008:00 = 00000000 00000000 00000000 00000000 | ................ CPUID 00000009:00 = 00000000 00000000 00000000 00000000 | ................ CPUID 0000000a:00 = 00000000 00000000 00000000 00000000 | ................ CPUID 0000000b:00 = 00000001 00000002 00000100 00000000 | ................ CPUID 0000000b:01 = 00000005 00000020 00000201 00000000 | .... ........... CPUID 0000000c:00 = 00000000 00000000 00000000 00000000 | ................ CPUID 0000000d:00 = 00000207 00000340 00000988 00000000 | ....@........... CPUID 0000000d:01 = 0000000f 00000340 00001800 00000000 | ....@........... CPUID 0000000d:02 = 00000100 00000240 00000000 00000000 | ....@........... CPUID 0000000e:00 = 00000000 00000000 00000000 00000000 | ................ CPUID 0000000f:00 = 00000000 000000ff 00000000 00000002 | ................ CPUID 0000000f:01 = 00000000 00000040 000000ff 00000007 | ....@........... CPUID 00000010:00 = 00000000 00000002 00000000 00000000 | ................ CPUID 00000010:01 = 0000000f 00000000 00000004 0000000f | ................ CPUID 40000000:00 = 00000000 00000000 00000000 00000000 | ................ CPUID 80000000:00 = 80000023 68747541 444d4163 69746e65 | #...AuthcAMDenti CPUID 80000001:00 = 00a20f12 20000000 440001e3 2bd1cbf5 | ....... ...D...+ CPUID 80000002:00 = 20444d41 657a7952 2039206e 30353935 | AMD Ryzen 9 5950 CPUID 80000003:00 = 36312058 726f432d 72502065 7365636f | X 16-Core Proces CPUID 80000004:00 = 20726f73 20202020 20202020 00202020 | sor . CPUID 80000005:00 = ff40ff40 ff40ff40 20080140 20080140 | @.@.@.@.@.. @.. CPUID 80000006:00 = 48002200 68004200 02006140 02009140 | .".H.B.h@a..@... CPUID 80000007:00 = 00000000 0000003b 00000000 00006799 | ....;........g.. CPUID 80000008:00 = 00003030 111ef657 0000501f 00010000 | 00..W....P...... CPUID 80000009:00 = 00000000 00000000 00000000 00000000 | ................ CPUID 8000000a:00 = 00000001 00008000 00000000 101bbcff | ................ CPUID 8000000b:00 = 00000000 00000000 00000000 00000000 | ................ CPUID 8000000c:00 = 00000000 00000000 00000000 00000000 | ................ CPUID 8000000d:00 = 00000000 00000000 00000000 00000000 | ................ CPUID 8000000e:00 = 00000000 00000000 00000000 00000000 | ................ CPUID 8000000f:00 = 00000000 00000000 00000000 00000000 | ................ CPUID 80000010:00 = 00000000 00000000 00000000 00000000 | ................ CPUID 80000011:00 = 00000000 00000000 00000000 00000000 | ................ CPUID 80000012:00 = 00000000 00000000 00000000 00000000 | ................ CPUID 80000013:00 = 00000000 00000000 00000000 00000000 | ................ CPUID 80000014:00 = 00000000 00000000 00000000 00000000 | ................ CPUID 80000015:00 = 00000000 00000000 00000000 00000000 | ................ CPUID 80000016:00 = 00000000 00000000 00000000 00000000 | ................ CPUID 80000017:00 = 00000000 00000000 00000000 00000000 | ................ CPUID 80000018:00 = 00000000 00000000 00000000 00000000 | ................ CPUID 80000019:00 = f040f040 f0400000 00000000 00000000 | @.@...@......... CPUID 8000001a:00 = 00000006 00000000 00000000 00000000 | ................ CPUID 8000001b:00 = 000003ff 00000000 00000000 00000000 | ................ CPUID 8000001c:00 = 00000000 00000000 00000000 00000000 | ................ CPUID 80000001:00 = 00004121 01c0003f 0000003f 00000000 | !A..?...?....... CPUID 8000001e:00 = 00000000 00000100 00000000 00000000 | ................ CPUID 8000001f:00 = 0001780f 00000173 000001fd 00000001 | .x..s........... CPUID 80000020:00 = 00000000 00000002 00000000 00000000 | ................ CPUID 80000020:01 = 0000000b 00000000 00000000 0000000f | ................ CPUID 80000021:00 = 0000004d 00000000 00000000 00000000 | M............... CPUID 80000022:00 = 00000000 00000000 00000000 00000000 | ................ CPUID 80000023:00 = 00000000 00000000 00000000 00000000 | ................ CPUID 80860000:00 = 00000000 00000000 00000000 00000000 | ................ CPUID c0000000:00 = 00000000 00000000 00000000 00000000 | ................
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Root Complex [1022:1480] 00:00.2 IOMMU [0806]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse IOMMU [1022:1481] 00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482] 00:01.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge [1022:1483] 00:01.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge [1022:1483] 00:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482] 00:03.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482] 00:03.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge [1022:1483] 00:04.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482] 00:05.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482] 00:07.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482] 00:07.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B] [1022:1484] 00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482] 00:08.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B] [1022:1484] 00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller [1022:790b] (rev 61) 00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge [1022:790e] (rev 51) 00:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Matisse/Vermeer Data Fabric: Device 18h; Function 0 [1022:1440] 00:18.1 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Matisse/Vermeer Data Fabric: Device 18h; Function 1 [1022:1441] 00:18.2 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Matisse/Vermeer Data Fabric: Device 18h; Function 2 [1022:1442] 00:18.3 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Matisse/Vermeer Data Fabric: Device 18h; Function 3 [1022:1443] 00:18.4 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Matisse/Vermeer Data Fabric: Device 18h; Function 4 [1022:1444] 00:18.5 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Matisse/Vermeer Data Fabric: Device 18h; Function 5 [1022:1445] 00:18.6 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Matisse/Vermeer Data Fabric: Device 18h; Function 6 [1022:1446] 00:18.7 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Matisse/Vermeer Data Fabric: Device 18h; Function 7 [1022:1447] 01:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller S4LV008[Pascal] [144d:a80c] 20:00.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Matisse Switch Upstream [1022:57ad] 21:02.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Matisse PCIe GPP Bridge [1022:57a3] 21:04.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Matisse PCIe GPP Bridge [1022:57a3] 21:05.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Matisse PCIe GPP Bridge [1022:57a3] 21:06.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Matisse PCIe GPP Bridge [1022:57a3] 21:08.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Matisse PCIe GPP Bridge [1022:57a4] 24:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller X550 [8086:1563] (rev 01) 24:00.1 Ethernet controller [0200]: Intel Corporation Ethernet Controller X550 [8086:1563] (rev 01) 25:10.0 Ethernet controller [0200]: Intel Corporation X550 Virtual Function [8086:1565] 25:10.2 Ethernet controller [0200]: Intel Corporation X550 Virtual Function [8086:1565] 26:00.0 Ethernet controller [0200]: Intel Corporation I210 Gigabit Network Connection [8086:1533] (rev 03) 27:00.0 Ethernet controller [0200]: Intel Corporation I210 Gigabit Network Connection [8086:1533] (rev 03) 28:00.0 PCI bridge [0604]: ASPEED Technology, Inc. AST1150 PCI-to-PCI Bridge [1a03:1150] (rev 04) 29:00.0 VGA compatible controller [0300]: ASPEED Technology, Inc. ASPEED Graphics Family [1a03:2000] (rev 41) 2a:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP [1022:1485] 2a:00.1 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller [1022:149c] 2a:00.3 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller [1022:149c] 2b:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU102 [GeForce RTX 2080 Ti Rev. A] [10de:1e07] (rev a1) 2b:00.1 Audio device [0403]: NVIDIA Corporation TU102 High Definition Audio Controller [10de:10f7] (rev a1) 2b:00.2 USB controller [0c03]: NVIDIA Corporation TU102 USB 3.1 Host Controller [10de:1ad6] (rev a1) 2b:00.3 Serial bus controller [0c80]: NVIDIA Corporation TU102 USB Type-C UCSI Controller [10de:1ad7] (rev a1) 2c:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Function [1022:148a] 2d:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP [1022:1485] 2d:00.1 Encryption controller [1080]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Cryptographic Coprocessor PSPCPP [1022:1486] 2d:00.3 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller [1022:149c]
linux-stable-mirror@lists.linaro.org
-
Borislav Petkov -
Steven Noonan -
Yazen Ghannam