[vfio-users] problem with passthrough and unsafe interrupts

[Blank Field]

When you specify the -smp option, it's threads per core, cores per socket.
So saying threads=2, cores=3, you allow the VM to use 6 logical vCPUs.
Usually windows doesn't care much about CPU topology changes, except
activation issues.
On Sep 13, 2015 2:21 PM, "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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20150913/269dc85a/attachment.htm>