[vfio-users] Z170X IOMMU Groups
Brett Peckinpaugh
bp10 at erylflynn.com
Fri Sep 23 04:06:29 UTC 2016
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 <wexu at 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
>> lspci: 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 <commendsarnex at gmail.com
>> <mailto:commendsarnex at 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.williamson at gmail.com
><mailto:alex.l.williamson at gmail.com>>
>> wrote:
>>
>> On Sat, Sep 17, 2016 at 12:29 PM, Nick Sarnie
>> <commendsarnex at gmail.com <mailto:commendsarnex at gmail.com>>
>wrote:
>>
>> Hi Alex,
>>
>> The output is here: 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>),
>> 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>
>> 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 at redhat.com
>> https://www.redhat.com/mailman/listinfo/vfio-users
>>
>
>_______________________________________________
>vfio-users mailing list
>vfio-users at redhat.com
>https://www.redhat.com/mailman/listinfo/vfio-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20160922/db49bccb/attachment.htm>
More information about the vfio-users
mailing list