<div dir="ltr"><div><div><div>Wei, <br><br></div>I submitted a ticket here: <a href="http://www.gigabyte.us/support-downloads/support-downloads.aspx">http://www.gigabyte.us/support-downloads/support-downloads.aspx</a><br><br></div>Thanks,<br></div>Nick<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 23, 2016 at 12:06 AM, Brett Peckinpaugh <span dir="ltr"><<a href="mailto:bp10@erylflynn.com" target="_blank">bp10@erylflynn.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Same here I have a ud5 that I would like a bios that does not need the ACS patch. <br><br><div class="gmail_quote"><div><div class="h5">On September 22, 2016 8:59:57 PM PDT, Wei Xu <<a href="mailto:wexu@redhat.com" target="_blank">wexu@redhat.com</a>> wrote:</div></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<pre><div><div class="h5"><br><br>On 2016年09月23日 02:47, Nick Sarnie wrote:<br><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #729fcf;padding-left:1ex"> Hi again,<br><br> Very much to my surprise, Gigabyte replied and sent me a fixed BIOS. The<br> new IOMMU groups (with ACS override patch kernel commandline removed for<br> this boot), as well as my lspci information are below. I see four<br> messages the following messages in dmesg now:<br><br> [    0.523892] pci 0000:00:1c.0: Intel SPT PCH root port ACS workaround<br> enabled<br> [    0.524031] pci 0000:00:1c.4: Intel SPT PCH root port ACS workaround<br> enabled<br> [    0.524159] pci 0000:00:1c.5: Intel SPT PCH root port ACS workaround<br> enabled<br> [    0.524292] pci 0000:00:1d.0: Intel SPT PCH root port ACS workaround<br> enabled<br><br><br> IOMMU Groups: <a href="http://pastebin.com/raw/0dcHk8Xk" target="_blank">http://pastebin.com/raw/<wbr>0dcHk8Xk</a><br>
lspci: <a href="http://pastebin.com/raw/1zAZuPBM" target="_blank">http://pastebin.com/raw/<wbr>1zAZuPBM</a><br></blockquote><br>That's cool, how did you report your issue to Gigabyte? I'd like to have <br>a try as well.<br><br>Wei<br><br></div></div><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #729fcf;padding-left:1ex"><div><div class="h5"><br> Alex, please let me know if they missed anything else, so I can report<br> it to them.<br><br> Thanks,<br> Nick<br><br> On Sun, Sep 18, 2016 at 4:03 PM, Nick Sarnie <<a href="mailto:commendsarnex@gmail.com" target="_blank">commendsarnex@gmail.com</a><br> <mailto:<a href="mailto:commendsarnex@gmail.com" target="_blank">commendsarnex@gmail.<wbr>com</a>>> wrote:<br><br>     Hi again,<br><br>     Thanks a lot for investigating. I've reported the issue to the<br>     manufacturer.<br><br><br>     Thanks,<br>     sarnex<br><br>     On Sat, Sep 17, 2016 at 5:35 PM, Alex Williamson<br>     <<a href="mailto:alex.l.williamson@gmail.com" target="_blank">alex.l.williamson@gmail.com</a> <mailto:<a href="mailto:alex.l.williamson@gmail.com" target="_blank">alex.l.williamson@<wbr>gmail.com</a>>><br>     wrote:<br><br>         On Sat, Sep
17, 2016 at 12:29 PM, Nick Sarnie<br>         <<a href="mailto:commendsarnex@gmail.com" target="_blank">commendsarnex@gmail.com</a> <mailto:<a href="mailto:commendsarnex@gmail.com" target="_blank">commendsarnex@gmail.<wbr>com</a>>> wrote:<br><br>             Hi Alex,<br><br>             The output is here: <a href="http://pastebin.com/raw/qjnpuaVr" target="_blank">http://pastebin.com/raw/<wbr>qjnpuaVr</a><br>             <<a href="http://pastebin.com/raw/qjnpuaVr" target="_blank">http://pastebin.com/raw/<wbr>qjnpuaVr</a>><br><br><br>         Ok, you need to go complain to your motherboard manufacturer,<br>         they're the ones hiding the ACS capability.  PCIe capabilities<br>         always start at 0x100, the dword there is:<br><br>         100: 01 00 01 22 = 0x22010001<br><br>         Breaking that down, the capability at 0x100 is ID 0x0001 (AER),<br>         version 0x1, and the next capability is at 0x220.  So we do the<br>         same there:<br><br>         220: 19 00 01 00 = 0x00010019<br><br>         Capability ID 0x0019 (Secondary PCIe), version 0x1, next<br>        
capability 0x0, terminating the capability list.<br><br>         Per Intel documentation for the chipset<br>         (<a href="http://www.intel.com/content/www/us/en/chipsets/100-series-chipset-datasheet-vol-2.html" target="_blank">http://www.intel.com/content/<wbr>www/us/en/chipsets/100-series-<wbr>chipset-datasheet-vol-2.html</a><br>         <<a href="http://www.intel.com/content/www/us/en/chipsets/100-series-chipset-datasheet-vol-2.html" target="_blank">http://www.intel.com/content/<wbr>www/us/en/chipsets/100-series-<wbr>chipset-datasheet-vol-2.html</a>>)<wbr>,<br>         the ACS capability and control registers live at 0x144 and 0x148<br>         respectively and we can see that you do have data here matching<br>         the default value of the capability register:<br><br>         140: 00 00 00 00 0f 00 00 00 00 00 00 00 00 00 00 00<br><br>         ie. default value of 0x144 is 0xf.  It appears that this BIOS<br>         vendor didn't connect the capability into the chain or fill in<br>         the
capability header.  The registers to do this are RW/O, ie.<br>         Read-Write-Once.  IOW, the registers can only be written once,<br>         which is intended to be used by the BIOS.  The capability bits<br>         themselves are RW/O, allowing vendors to expose different sets<br>         of ACS capabilities.  Given that this vendor has not exposed the<br>         capability, we have no basis to believe that the default value<br>         of the register represents the real capabilities of the system<br>         and therefore we cannot assume we're able to control ACS.  File<br>         a bug with the vendor or look for a BIOS update where they may<br>         have already fixed this.<br><br>             Also, is there any way we could move the USB controller into<br>             its own group, or remove the Ethernet and SATA controller<br>             into a seperate group? Ideally, I could pass the USB<br>             Controller in group 7 without
the ACS patch.<br><br><br>         That's not how IOMMU groups works.  See<br>         <a href="http://vfio.blogspot.com/2014/08/iommu-groups-inside-and-out.html" target="_blank">http://vfio.blogspot.com/2014/<wbr>08/iommu-groups-inside-and-<wbr>out.html</a> <<a href="http://vfio.blogspot.com/2014/08/iommu-groups-inside-and-out.html" target="_blank">http://vfio.blogspot.com/<wbr>2014/08/iommu-groups-inside-<wbr>and-out.html</a>><br>           We aren't creating these groups arbitrarily, we base them on<br>         the information provided to use by the IOMMU driver and PCI<br>         topology features, including ACS.  If we cannot determine that<br>         there is isolation between components, we must assume that they<br>         are not isolated.  Your choices are to run an unsupported (and<br>         unsupportable) configuration using the ACS override patch, get<br>         your hardware vendor to fix their platform, or upgrade to better<br>         hardware with better isolation
characteristics.<br><br><br><br><br><br><hr><br></div></div><span class=""> vfio-users mailing list<br> <a href="mailto:vfio-users@redhat.com" target="_blank">vfio-users@redhat.com</a><br> <a href="https://www.redhat.com/mailman/listinfo/vfio-users" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/vfio-users</a></span></blockquote><span class=""><br><br><hr><br>vfio-users mailing list<br><a href="mailto:vfio-users@redhat.com" target="_blank">vfio-users@redhat.com</a><br><a href="https://www.redhat.com/mailman/listinfo/vfio-users" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/vfio-users</a><br></span></pre></blockquote></div></div></blockquote></div><br></div>