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