Bug 196979
Summary: | IDT switch causes an ACS source valdation violation | ||
---|---|---|---|
Product: | Drivers | Reporter: | James Puthukattukaran (james.puthukattukaran) |
Component: | PCI | Assignee: | drivers_pci (drivers_pci) |
Status: | NEW --- | ||
Severity: | high | CC: | james.puthukattukaran |
Priority: | P1 | ||
Hardware: | x86-64 | ||
OS: | Linux | ||
Kernel Version: | 4.12 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: | v7 of the patch. |
Description
James Puthukattukaran
2017-09-18 15:37:23 UTC
Created attachment 258461 [details]
v7 of the patch.
Bjorn had asked for an investigation on how Windows implements this workaround. https://lkml.org/lkml/2017/7/13/810 "I suspect instead that Windows does something slightly different in enumeration that happens to avoid the problem. Maybe it always does a config write before the first config read. Maybe there's something else, like always leaving ACS SV off while enumerating. Can you trace a Windows boot in a VM that contains an IDT switch and figure out what they're doing? This just doesn't feel right. Presumably IDT tested the workaround, and if the workaround required ACS twiddling, they would have mentioned that in the errata." ------------------- I finally found a Windows expert in house to carry out the experiment for me to empirically deduce what it means that the ACS workaround as specified in the IDT errata was "implemented" in Windows. It turns out that on Windows does not enable ACS source validation on switches in a bare metal environment. It only enables ACS source validation in a virtualized environment (Hyper-V). Furthermore, Hyper-V expects all devices to be present at boot and not physically hot plugged. Then, using powreshell or Hyper-V manager, you can assign a device to a guest (dynamic device assignment in Windows lingo). It is when this iccurs that the ACS feature is enabled on the switch. However, note that since the device has already been present and "configured" at boot, the source id has been latched and consequently, this avoids exposing the actual IDT issue. I found additional information here on Hyper-V and direct device assignment here - https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/plan/plan-for-deploying-devices-using-discrete-device-assignment |