On 2016年09月21日 12:31, Alex Williamson wrote:
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.
Alex,
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
isolation characteristics."
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
isolation. Thanks,
Yes, fortunately i get it solved finally, i tried adding the 'r8169'
driver to the kernel group whitelist behind 'pci-stub' and recompile &
update the kernel firstly, and the VM boot up successfully, but a map
page to iova error for realtek nic during DMA crashed the system later,
looks it was caused by the group dependency, i remembered the vfio doc
tells the group is the minimum isolation unit.
Then i found there are 3 pci bridges on my board, 2 of them are with a
group, another is a separate group, after plug the iwl wlan nic to this
one, everything works well.
Wei
Alex
_______________________________________________
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users
