[vfio-users] Windows 10 guest refuses to boot when passed my NVIDIA graphics card

[Jasen Borisov]

On Wed, Sep 16, 2015 at 12:59 AM, Alex Williamson <
alex.l.williamson at gmail.com> wrote:

> On Tue, Sep 15, 2015 at 3:32 PM, Jasen Borisov <tajjada at gmail.com> wrote:
>
>> I managed to successfully boot Arch Linux in the VM. Turned out I wasn't
>> patient enough. With enough waiting, the same VM configuration as before
>> (including my passthrough NVIDIA *and* EHCI!) booted. But it is
>> *incredibly* slow. Took over 10 minutes to get to a login prompt, and a
>> couple of minutes to do its automatic root login. I plugged a USB keyboard
>> into the hardware port on my PC that belongs to the EHCI controller I
>> passed to the VM, and the keyboard worked as expected and I could type
>> inside the VM. I managed to mount a filesystem and dump `dmesg` to a file,
>> so I can get it on my desktop. Here is a pastebin of it:
>> https://bpaste.net/show/e6970c05aff5
>>
>> This makes me think that *maybe* if I leave Windows to boot overnight,
>> next morning I might be surprised by a desktop :)
>>
>> Anyway, it is unacceptably slow, and I would appreciate any help to
>> improve the situation.
>>
>> I noticed a lot of errors regarding msrr, both in the host and guest
>> dmesg, so I guess it would probably be a good idea to add that KVM option
>> you mentioned. However, I doubt that that is the cause of the performance
>> problems. When I remove all VFIO devices and replace them with emulated
>> ones, Arch Linux is very fast (or rather, normal, just very fast in
>> comparison) despite the same msrr errors appearing.
>>
>> Any ideas?
>>
>
> What if you downgrade to kernel 4.1?
>

As I said, I want to run Windows inside the VM, not Linux. I am just
testing with Linux to see if my VFIO setup is working. I am doing this
because troubleshooting with Linux is a lot easier (due to information from
things like dmesg) than with Windows. Once I know that VFIO is working fine
on my system, I will set up a Windows guest. Hence, kernel
regressions/bugs/features(?) in 4.2 that are not present in 4.1 are not
something I particularly care about. That said, if downgrading to linux 4.1
(not easy, because I was booting Linux from a live iso ... would have to
either install or get an older live iso to do that) would help me figure
out why my VM is slow and would provide worthwhile information, I would be
happy to do it. By now, I have wasted a lot more time waiting for the slow
VM to boot than it would take me to install Linux.


> The MTRR issue we've been battling generally resolves itself and the VM
> runs at full speed once passed firmware.  I'll see if I can make my box act
> this poorly.  Running 8 vCPUs on your system is surely not helping
> performance, but this sounds like orders of magnitude worse than that.
>

Do you mean that having fewer vCPUs will somehow be better for performance?
That seems counterintuitive ... I thought otherwise....

Well, my physical CPU has 8 physical cores with hyperthreading, so 16
logical cores. I thought it would make sense to give half of that to the VM
and have the rest available for the host. By saying that it is "not helping
performance", do you mean that there is some sort of significant overhead
involved with having more vCPUs?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20150916/45be9e2a/attachment.htm>