December 30, 2019 7:12 PM, "qubes123" <[email protected]> wrote:
>> 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 guess in some cases they are, and in other cases they're in hardware. For
example if you have two devices between a physical PCI bridge, communication
between those two devices might be sent across the bridge without ever making
it to the IOMMU. I don't think there's any software approach could do anything
about that kind of situation.
In my case, the USB controllers and most of the other devices are functions of
the same PCI device, 00:03.0{1,2,3,4,6}. Therefore most likely any
communication between them is happening within the device and not going to the
IOMMU (00:00.2). However I don't know if this is because of the physical
structure, or if it could be changed by modifying ACPI tables. I guess the only
way to know would be to try it.
> 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...)
I understand the part about uploading the ACPI tables via initrd, but I would
have no idea how to extract them, what they mean, or what changes to make to
them.
Also, I haven't figured out if ACPI override actually changes the behavior of
PCI devices, or if it just spoofs the information provided to the
kernel/hypervisor (which would make it unnecessary/ineffective on Xen).
According to the OSDev wiki: "AML interpreter can build up a database of all
devices within a system and the properties and functions they support (in
reference to configuration and power management)."
> 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...
I did some tests by playing sound in a VM and then binding pciback to the USB
controllers to simulate passthru. None of them were successful. At the time of
the bind command, audio stopped, and the screen would freeze unless nomodeset
was on. I did the testing in the 4.1 pre-release.
I tested four combinations of parameters: (none), acpi=off, acpi=nocrs, and
acpi=nocrs pci=nocrs, each with and without Xen. In the non-Xen tests,
iommu_groups was the same every time. In the Xen tests, xl dmesg and xl info
were identical every time. In all tests, lspci and lspci -t were identical.
Kernel logs and lspci -kvvnn had some differences each time, but nothing that
looked important. If I should look for anything specific please let me know.
Note, the data was collected right after I logged in, before I performed the
passthru. Not one of my better decisions.
However the only thing I recall seeing in the logs at the time of the passthru
was this, with acpi=nocrs pci=nocrs:
xhci_hcd 0000:03:00.4: Host halt failed, -110
xhci_hcd 0000:03:00.4: Host controller not halted, aborting reset.
xhci_hcd 0000:03:00.4: USB bus 3 deregistered
pciback 0000:03:00.3: seizing device
xen: registering gsi 55 triggering 0 polarity 1
Already setup the GSI :55
pciback 0000:03:00.4: seizing device
xen: registering gsi 52 triggering 0 polarity 1
Already setup the GSI :52
Could it be a PCI reset related problem?
Finally, a possible workaround I thought of is putting sys-usb into PV mode,
since PV passthru doesn't use the IOMMU. It wouldn't be quite as secure as HVM,
as it wouldn't prevent a DMA attack, but it would still be better than having
USB in dom0. However it looks like Qubes 4.1 isn't going to support any kind of
passthru for PVs, so I'll ultimately end up back where I started. I don't
currently have sys-usb installed, but I might try it when I have some time.
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/b88a85b62f2e84c57ec5fbf87f14b9ec%40disroot.org.
