On Wed, 21 Sep 2016 11:52:31 +0800
Wei Xu <w...@redhat.com> wrote:
> On 2016年09月21日 02:59, Nick Sarnie wrote:
> > Hi Wei,
> > My system is a desktop, so it must just be a general Gigabyte BIOS bug.
> > I submitted a help ticket about this issue and just gave a brief
> > explanation and then sent Alex's explanation. Hopefully it will be
> > escalated correctly.
> Thanks for your feedback, i'm also using a Gigabyte board, i have
> checked out the firmware update history and updated my firmware to the
> latest one which was released at March, looks it's a long way to get a
> feedback for this issue from them.
> It's a hard time for us to do nothing but wait, the reason why i use my
> desktop is i got a com console on it, so it's quite convenient to
> debugging kernel via kgdb, and i want to keep my realtek nic for ssh
> access from my notebook, anyway to workaround it to just bypass the
> wireless nic only as a temporary experiment?
> I'm trying VirtIO DMAR patch with vIOMMU in the guest recently, which
> need pass through a pcie unit from host, and one more virtio nic for the
> guest due to the feedbacks, maybe i can pass through a device in other
> groups instead of a nic?
Sure, but skylake platforms are notoriously bad for their lack of
device isolation, even things like USB controllers and audio devices
are now part of multifunction packages that do not expose isolation
through ACS. If you can't resolve the IOMMU grouping otherwise, your
choices are as I told Nick in the other thread:
"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
It's unfortunate that Intel provides VT-d on consumer platforms without
sufficient device isolation to really make it usable, but that's often
the state of things. The workstation and server class platforms,
supporting Xeon E5 or High End Desktop Processors provide the necessary
vfio-users mailing list