> The improper grouping is probably somewhere in AGESA, which is provided
> > to the manufacturers by AMD. It could be because of hardware related > > limitations, which again are supplied by AMD. Sometimes vendors take > > liberties (cost cutting measures) with both and break functionality, as > > their primary/sole concern is that Windows boots. This can especially be > > the case with consumer class machines such as Ryzen. Agree it would be > > nice if Xen handled this failure mode more gracefully. Not sure there is > > much Qubes can do here, though. On the other hand, my older AMD > > (pre-Ryzen) consumer laptop running Coreboot has correct groupings. > I could be wrong, but aren't these PCI assignments and hierarchies coded within the ACPI DSDT table in BIOS? I remember as if in UEFI the ACPI tables could be overridden somehow... Or - since kernel 5.3.x(?) you can supply certain ACPI tables (as files, stored in initrd) to the kernel using commandline parameters* (some additional acpi manipulations are needed to extract the current dsdt to see what is in there and make changes in aml...) Or - before all - you can simply try to boot the kernel with cmdline: acpi=nocrs (or off) and let the kernel "enroll" the PCI devices. Maybe worth to try - just one reboot... *:https://www.kernel.org/doc/html/latest/admin-guide/acpi/initrd_table_override.html -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/604f5799-c810-468b-82f9-95bf5b340640%40googlegroups.com.
