[vfio-users] VFIO + UEFI virt VS i915 arbiter patch and a few more questions

Milos Kaurin milos.kaurin at gmail.com
Wed Jan 6 00:50:11 UTC 2016


Hello again,

I failed to mention that my run with USB controller and onboard audio
was with stock FC23 kernel.

Please ignore the disk errors, they are not reproducible.

The rdmsr messages are reproducible, but from what I can see, they
don't seem to be an issue:
https://bugs.launchpad.net/qemu/+bug/1208540

I don't think we need to chase this rabbit further unless you guys
have anything to add.

Thank you!

On Wed, Jan 6, 2016 at 12:13 AM, Milos Kaurin <milos.kaurin at gmail.com> wrote:
> Hi Alex,
>
> Thank you for that very quick response.
>
> I have just tested passing through my onboard sound card and USB
> controller to the virt
> * Starting the virt - device handoff apparently flawless
> * Running 3dmark demo (with sound) and very high settings - flawless
> * Shutting down the virt - device handoff apparently flawless
>
> I am, however, concerned about the messages popping up in dmesg, though:
> https://gist.github.com/Kaurin/05cb3691a361a11502d0
>
> In fairness, I have not checked for these messages before without USB
> and onboard audio usage on the virt.
>
> I believe virt startup was at:
> [   30.032249] xhci_hcd 0000:00:14.0: remove, state 4
>
>
> Messages like:
> [  180.440234] kvm [2651]: vcpu0 unhandled rdmsr: 0x19a
> [  185.688347] kvm_get_msr_common: 366 callbacks suppressed
>
>
> And especially:
>  209.368402] ata1.00: exception Emask 0x10 SAct 0x7fff00ff SErr
> 0x280100 action 0x6 frozen
> [  209.368405] ata1.00: irq_stat 0x08000000, interface fatal error
> [  209.368407] ata1: SError: { UnrecovData 10B8B BadCRC }
> [  209.368408] ata1.00: failed command: READ FPDMA QUEUED
> [  209.368410] ata1.00: cmd 60/00:00:68:e8:0c/01:00:08:00:00/40 tag 0
> ncq 131072 in
>                         res 40/00:08:a0:31:0d/00:00:08:00:00/40 Emask
> 0x10 (ATA bus error)
> [  209.368411] ata1.00: status: { DRDY }
> ...
> ...
> [  209.368480] ata1.00: failed command: READ FPDMA QUEUED
> [  209.368482] ata1.00: cmd 60/00:f0:a0:30:0d/01:00:08:00:00/40 tag 30
> ncq 131072 in
>                         res 40/00:08:a0:31:0d/00:00:08:00:00/40 Emask
> 0x10 (ATA bus error)
> [  209.368483] ata1.00: status: { DRDY }
> [  209.368484] ata1: hard resetting link
> [  209.673526] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
> [  209.695536] ata1.00: configured for UDMA/133
> [  209.695568] ata1: EH complete
>
>
> After ATA errors, the rdmsr errors come back and repeat until I shut
> the virt down.
>
> Furthermore, comparing my two SSDs (that both sit on ata1.00),
> /dev/sda has this in smartctl output:
>   1 Raw_Read_Error_Rate     0x000f   110   110   050    Pre-fail
> Always       -       0/29315536 <--- that last number is 0 on /dev/sdb
>
> I understand that the ATA errors might be related to potential issues
> with my controller/disks/cables:
> https://bbs.archlinux.org/viewtopic.php?id=151642
> ...but thought I put it here in case you guys have maybe seen this
> before as related to virtualization.
>
> My apologies if the disk issues are a derail of what's important
>
> Current setup (screenshot):
> http://imgur.com/Yhb1mjT
>
> Current setup (virt XML):
> https://gist.github.com/Kaurin/ce71d8cc8432bfb93f6b
>
> Thanks!
>
> On Tue, Jan 5, 2016 at 11:05 PM, Alex Williamson
> <alex.l.williamson at gmail.com> wrote:
>> On Tue, Jan 5, 2016 at 3:57 PM, Milos Kaurin <milos.kaurin at gmail.com> wrote:
>>>
>>> Hello,
>>>
>>> Firstly, a big thanks to everyone contributing to VFIO and other
>>> virtualization technologies that are making my GPU pass-through dream
>>> come true.
>>>
>>> I currently have this:
>>>
>>> CPU: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
>>>
>>> ==================================
>>> -[0000:00]-+-00.0  Intel Corporation 4th Gen Core Processor DRAM
>>> Controller
>>>            +-01.0-[01]--+-00.0  NVIDIA Corporation GK104 [GeForce GTX 770]
>>>            |            \-00.1  NVIDIA Corporation GK104 HDMI Audio
>>> Controller
>>>            +-02.0  Intel Corporation Xeon E3-1200 v3/4th Gen Core
>>> Processor Integrated Graphics Controller
>>>            +-03.0  Intel Corporation Xeon E3-1200 v3/4th Gen Core
>>> Processor HD Audio Controller
>>>            +-14.0  Intel Corporation 8 Series/C220 Series Chipset
>>> Family USB xHCI
>>>            +-16.0  Intel Corporation 8 Series/C220 Series Chipset
>>> Family MEI Controller #1
>>>            +-19.0  Intel Corporation Ethernet Connection I217-LM
>>>            +-1b.0  Intel Corporation 8 Series/C220 Series Chipset High
>>> Definition Audio Controller
>>>            +-1c.0-[02]--
>>>            +-1c.1-[03-04]----00.0-[04]--
>>>            +-1f.0  Intel Corporation Q87 Express LPC Controller
>>>            +-1f.2  Intel Corporation 8 Series/C220 Series Chipset
>>> Family 6-port SATA Controller 1 [AHCI mode]
>>>            \-1f.3  Intel Corporation 8 Series/C220 Series Chipset
>>> Family SMBus Controller
>>> ====================================================================
>>>
>>> To avoid pasting iommu groups, every device is now in its own separate
>>> group due to ACS patch.
>>
>>
>> You don't need the ACS patch
>>
>>>
>>> Running on FC23 with a custom Kernel:
>>> Linux gammalinux 4.2.8-300.milos.fc23.x86_64 #1 SMP Sun Jan 3 23:38:23
>>> GMT 2016 x86_64 x86_64 x86_64 GNU/Linux
>>>
>>> Custom kernel:
>>> I have applied the ACS patch because my CPU root bridge (IIRC) was
>>> grouped with the NVIDIA GPU/audio. I have also applied the i915
>>> arbiter patch.
>>>
>>> My virt is UEFI based (virt-manager instructions from the blog),
>>> Windows 10 Guest, no audio (yet)
>>
>>
>> You don't need the i915 patch
>>
>>>
>>> >From what I understood from Alex's blog and some other material of his
>>> I found online, if you want to use an integrated Intel GPU for the
>>> host, you have to apply the arbiter patch to avoid display corruption
>>> etc because i915 driver is a liar.
>>>
>>> My first question is: Is this only true for BIOS-based guests or does
>>> it also go for UEFI based guests?
>>
>>
>> Only using BIOS, x-vga=on.  You have a UEFI guest, use the stock Fedora
>> kernel.
>>
>>>
>>> I'm asking because even though I applied the i915 arbiter patch, I
>>> disabled the entry in modprobe.d to test and see what will happen.
>>> Nothing happens on guest/host (Ran 3dmark extreme benchmarks multiple
>>> times now).
>>>
>>> Second question:
>>> I'm thinking of letting the guest have the "USB xHCI" controller(14.0
>>> from the lspci above). Due to some warnings from Alex on ACS being
>>> potentially dangerous, I wanted to ask you guys whether it's safe to
>>> use vfio-pci on that device.
>>
>>
>> You don't need the ACS patch to assign that device either.




More information about the vfio-users mailing list