[vfio-users] Passthrough VGA on first slot

Sun Oct 4 23:57:21 UTC 2015

You don't happen to have more PCIE slots on that MB that you can also try?
I had a similar issue on the first slot and I believe I resolved it by
adding "nomodeset vga=normal vesafb:off" to the kernel cmd line in GRUB
config. I currently have it as
GRUB_CMDLINE_LINUX="nomodeset vga=normal video=vesafb:off"
and the boot is happening in the default text mode. Before I changed it the
boot sequence was somehow affecting that card performance. I am not sure
which one of these 3 settings helped, could be just one but I added them
all together. Blacklisting your card driver was also necessary but I
believe you have it done already.

On Sat, Oct 3, 2015 at 1:37 PM, Pedro Henrique Lara Campos <
pedro.laracampos at gmail.com> wrote:

> I didn't gave up hope yet, If it was a pci-e 3.0 to pci-e 2.0 I would be
> using the second slot without problems, but, in this case, it's from a
> pci-e 2.0 x16 to a x4. And yes, MSI was also reducing my performance, but
> if there is a way for me to guarantee 100% of the available GPU power
> available, why would I give up...
>
> I decided to change the GPUs again, log everything I could as well log
> when it doesn't work.
> I've resumed them all here:
> https://gist.github.com/PedroHLC/5c54785a00efa3f08154
> As well as I added relevant settings and some hardware specs.
>
> I've observed some things, while on PCIEX4 bus (secondary), I do not need
> a ROM, and if I pass one, even a downloaded one or one I ripped myself, It
> wouldn't work.
> QEMU only throws ROM errors when on PCIEX16 bus (primary), as well it
> seems to be missing this on dmesg: "vfio-pci 0000:0?:00.0: enabling device
> (???? -> ????)"
>
> So as, VFIO isn't enabling it, there is still something holding it up? If
> it was, shouldn't it appear on /proc/iomem? Is there a way to vfio verbose
> more intel?
>
>
> 2015-10-02 18:26 GMT-03:00 Blank Field <ihatethisfield at gmail.com>:
>
>> To answer your last question you must examine your dmesg.
>>
>> Don't worry, on a system level it is possible to eject any device in
>> windows. I've seen a hardware platform that could eject one of cpu's cores
>> and system boot drive too. As in Linux, when you do that either nothing
>> happens or nothing good happens.
>>
>> I personally would test if your GPU really needs the full pci-e 3.0
>> bandwidth. I mean, when you got it running, maybe it lags due to msi, cpu
>> latency issues or something else?
>> Because HDMI audio stuttering problem points me directly to alex's blog
>> post about message signalled interrupts.
>> And yeah, if you could switch the primary GPU the gigabyte way - that
>> would solve your initial problem. So consider updating your firmware...
>> Both Seabios and OVMF.
>> Turn on/off the machine? I did tried restarting it sometimes...
>> Attaching an QXL video I can see NVIDIA driver with the classic 43 error,
>> but I don't thing of it being qemu fault as when vga is in slot2 this
>> doesn't happen.
>> If I disable nvidia device and reenable it, it goes back to error 43.
>> Weird observation, I can eject the GTX780, and the SCSI drivers in
>> Windows eject tray icon....
>> For one last test, I uninstalled the drive in devmgmt, turned off the
>> machine, turned it on without QXL, waited a long time to IDK, maybe Windows
>> to reinstall the GPU, called "system_powerdown", ran it again in hope, but
>> none.
>>
>> Also, should my GPU still be the "target" of vga_arbiter?
>> If I'm using 'options vfio-pci ids=' should I also try pci-stub?
>>
>> 2015-10-02 13:47 GMT-03:00 Blank Field <ihatethisfield at gmail.com>:
>>
>>> Seabios? OVMF? Have you tried turining it on and off?^W^W^W^W^W
>>> reinstalling windows guest drivers? Attaching an emulated QXL device to see
>>> devmgmt.msc?
>>> On Oct 2, 2015 7:43 PM, "Pedro Henrique Lara Campos" <
>>> pedro.laracampos at gmail.com> wrote:
>>>
>>>> Yep, you both we're right, uvesafb was using GPU, now nothing besides
>>>> vfio is using it, yet I have no video, but there are no more mmap
>>>> unsupported errors, with a romcard there is no ROM error, there are also no
>>>> errors in AMD-Vi, qemu, IOMMU. Windows still loads fine, I can turn it off
>>>> through monitor, every qemu setting is identical it was when GTX was in
>>>> slot2 (in this slot I could see from OVMF bios until machine goes off) with
>>>> exception of host pci addr but in slot1 it doesn't seems to want to start
>>>> at all...
>>>>
>>>> 2015-10-02 10:27 GMT-03:00 Blank Field <ihatethisfield at gmail.com>:
>>>>
>>>>> Do cat /proc/iomem to find out who is using your GPU. I predict
>>>>> uvesafb or something like that. Disable or uninstall this.
>>>>> Also, don't you have pci-e 3.0 onboard?
>>>>> On Oct 2, 2015 4:22 PM, "Pedro Henrique Lara Campos" <
>>>>> pedro.laracampos at gmail.com> wrote:
>>>>>
>>>>>> Hello masters of vfio. I've been playing with vfio for 3 weeks now,
>>>>>> and here is a resume of what i got: When I put my loved GTX780 on the
>>>>>> second pci-e slot of my GA-970A-DS3P everything works on Windows (guest)
>>>>>> while my Linux (host) stays comfortable with a Radeon HD 6670.
>>>>>> But, as I wouldn't be writing this email if nothing was wrong, my
>>>>>> second pci-e slot is "PCIEX4" only, I believe that's because my FPS goes
>>>>>> down and HDMI audio keeps crackin. I had to change the slots, my bios
>>>>>> doesn't have an option to choose which GPU to use, so it uses the GTX, GRUB
>>>>>> does it too, then gpu gets binded by modprobe and I have no video until
>>>>>> XOrg starts on Radeon, if I start qemu, I've get:
>>>>>>   "vfio_ecap_init: 0000:01:00.0 hiding ecap 0x19 at 0x900"
>>>>>>   "BAR 3 mmap unsupported. Performance may be slow"
>>>>>>   "vfio-pci 0000:01:00.0: Invalid ROM contents"
>>>>>> No video on GTX, Windows boots normally, I can even hear
>>>>>> notifications sounds, I can turn it off through "system_powerdown".
>>>>>> Tried using a romfile, it only makes the third message goes away, no
>>>>>> other thing changes...
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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/20151004/ed114aba/attachment.htm>