[vfio-users] problem with passthrough and unsafe interrupts

[Janusz]

W dniu 13.09.2015 o 15:08, Okky Hendriansyah pisze:
> Hi Janus,
>
> Are you trying to upgrade to Windows 10? I had issues when upgrading from Windows 8.1 to Windows 10, after changing the cpu to "core2duo", the upgrade finished and I quickly revert back to "host" on my first reboot.
>
> Best regards,
> Okky Hendriansyah
no upgrade, I had clean installation on uefi platform done without
passing through my gpu, but when I limited threads to 1 windows was
unable to boot - every time it reboots it self. I reinstalled windows
10, but still have problem that its sometimes reseting it self while
loading (no bsod just reset), and just installed windows 8.1, the same
problem. The installation both win10 and win8.1 went without problems.

>
>> On Sep 13, 2015, at 18:21, Janusz <januszmk6 at gmail.com> wrote:
>>
>> W dniu 13.09.2015 o 00:28, Blank Field pisze:
>>> Looking at IOMMU groups, his lspci and his problems, there's no way
>>> anyone would want to take intel for VFIO usage.
>>> Good lord, that's worse than my system...
>>>> No BSOD, only silent reboot or reset on uefi bios display, also reset
>>>> issue for gpu (that was already fixed I think in some kernel/qemu
>>>> version for hawaii, monitor still gets old display sometimes after
>>>> turining off or reset VM), in dmesg I found only those:
>>>>
>>>> [10145.621272] vgaarb: device changed decodes:
>>>> PCI:0000:01:00.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
>>>> [10145.641778] vgaarb: device changed decodes:
>>>> PCI:0000:01:00.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
>>>> [10145.760058] [drm:check_wm_state] *ERROR* mismatch in DDB state
>>>> pipe A plane 1 (expected (0,0), found (0,289))
>>>> [10145.760061] [drm:check_wm_state] *ERROR* mismatch in DDB state
>>>> pipe A cursor (expected (0,0), found (289,297))
>>>> [10145.760062] [drm:check_wm_state] *ERROR* mismatch in DDB state
>>>> pipe B plane 1 (expected (0,0), found (297,586))
>>>> [10145.760063] [drm:check_wm_state] *ERROR* mismatch in DDB state
>>>> pipe B cursor (expected (0,0), found (586,594))
>>>> [10148.490876] vfio_ecap_init: 0000:01:00.0 hiding ecap 0x19 at 0x270
>>>> [10148.490881] vfio_ecap_init: 0000:01:00.0 hiding ecap 0x1b at 0x2d0
>>>> [10154.080574] usb 1-12: reset low-speed USB device number 5 using
>>>> xhci_hcd
>>>> [10154.372122] usb 1-12: ep 0x81 - rounding interval to 64
>>>> microframes, ep desc says 80 microframes
>>>> [10194.443399] kvm: zapping shadow pages for mmio generation wraparound
>>>> [10194.453708] kvm: zapping shadow pages for mmio generation wraparound
>>>> [10165.930150] usb 1-12: ep 0x81 - rounding interval to 64
>>>> microframes, ep desc says 80 microframes
>>>> [10168.912066] usb 1-12: reset low-speed USB device number 5 using
>>>> xhci_hcd
>>>> [10169.203902] usb 1-12: ep 0x81 - rounding interval to 64
>>>> microframes, ep desc says 80 microframes
>>>>
>>>>
>>>> I can be missing something as I get lot of warnings from i915 driver
>>>> (known bug for i915 and skylake), but I did grep for kvm and vfio and
>>>> didn't find anything else
>>>>
>>>> I am running now dev version of qemu because I wanted to test if
>>>> newer version will give better result (it didn't), and didn't
>>>> compiled back the stable version yet
>>> And yes, I have AMD Catalyst drivers installed in the guest, but as
>>> this also happening before it starts to boot windows and when starting
>>> windows installation, I don't think this is the reason
>> I think I found some solution. I changed number of threads on cpu from 2
>> to 1, and windows installation is starting every time now. problem still
>> is with installed windows - its rebooting every time it wants to start
>> win10, is windows sensitive for such changes?
>> When I changed number of threads to 2 and number of cores to 3, problem
>> still occurs
>>
>> Also, I upgraded to kernel 4.3-r1
>>
>> I find that someone reported issue to OVMF that it has problems with
>> kernel >= 4.2 https://github.com/tianocore/edk2/issues/21, unfortunately
>> I am not able to test it on 4.1 or 4.0 as on 4.1 I get some weird
>> operations on null pointer in kernel at boot - segfault, and in 4.0 I
>> don't even get signal to monitor - probably hardware is too new for
>> those versions (I know about i915 preliminary support but its not working)
>>
>> anyway, I am gonna test futher later,  and see if with threads=1,cores=4
>> will problem still occur after reinstalling win10
>>
>> _______________________________________________
>> vfio-users mailing list
>> vfio-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/vfio-users