[vfio-users] regression from linux 4.0.4 to 4.2.0

Thu Oct 1 16:27:30 UTC 2015

Hmm, my intention is to replicate the physical Intel Core i7-4770 which has 4 cores with 8 threads in a single socket. I just double checked if I use cpus=8,cores=4,threads=2,sockets=1 my Windows 10 detects 8 processors in the Device Manager, 8 virtual processors in Task Manager, and CPU-Z also detects 4 cores with 8 threads just like I want to.

If I change the config to cpus=8,cores=4,threads=1,sockets=2, Device Manager detects the same, CPU-Z detects 2 socket of 4 single threaded cores, but Task Manager is smart it knows that it only runs in 1 socket with 8 virtual processors.

Best regards,
Okky Hendriansyah

> On Oct 1, 2015, at 12:05, Blank Field <ihatethisfield at gmail.com> wrote:
> 
> Just a side-note:
> AFAIR -smp option ignores topology specs(sockets-cores-threads) if abregular value is specified.
> And doing cores=8 threads=2 should give you a 16 (logical) core vcpu. I'm pretty sure that's not what you want to do. Consult qemu-system-x86_64 help to make sure.
> 
>> On Oct 1, 2015 3:26 AM, "Okky Hendriansyah" <okky at nostratech.com> wrote:
>> Hi Alex,
>> 
>> I have experienced my setup is also not working as it used to after upgrading from 4.1.6 to 4.2.1. After reading on the list mentioned I googled around and found [1].
>> 
>> Changing my processor and memory settings from -smp cpus=8,cores=4,threads=2,sockets=1 -m size=16G to -smp cpus=4,cores=4,threads=1,sockets=1 -m size=8G resulting the VM successfully boots like normal. But changing to other values did not always succeeded. I did not now the formula so I kind of brute forcing my way. I think I managed to boot the VM also with -smp cpus=8,cores=4,threads=2,sockets=1 -m size=4G. I forgot the details.
>> 
>> Currently I’m rolling back to 4.1.6, but if there’s something that I could provide to help finding out the issue, I can upgrade it and test it again. Please let me know.
>> 
>> [1] https://github.com/tianocore/edk2/issues/21
>> 
>> -- 
>> Okky Hendriansyah
>>> On September 28, 2015 at 23:53:08, globalgorrilla at fastmail.fm (globalgorrilla at fastmail.fm) wrote:
>>> 
>>> Alex,
>>> 
>>> I reported this on 08/18. It's been echoed several times on this list 
>>> since.
>>> 
>>> You've said everything is working for you and you appear to have a very 
>>> similar setup to us others (passing through devices with VFIO to QEMU 
>>> and using OVMF).
>>> 
>>> Circumstantial evidence is that there is something in > 4.1 that (often) 
>>> breaks OVMF in QEMU.
>>> 
>>> How could we dig into this? Perhaps it's not related to vfio?
>>> 
>>> Regarding the MTRR patch, I had made the fix myself in the 4.2 RCs and I 
>>> believe the patch is merged in already to 4.2 +. I don't think that is 
>>> the culprit ...?
>>> 
>>> Thoughts?
>>> 
>>> On 20 Sep 2015, at 9:09, Kővágó Zoltán wrote:
>>> 
>>> > Hello,
>>> >
>>> > I've been using vfio-pci to passthrough a GPU to virtual machine since 
>>> > some time now, and it worked great. But this weekend I've finally had 
>>> > enough time to update kernel, and things are completely broken with 
>>> > the new kernel...
>>> >
>>> > I've been using the ACS override patch (and a quick-and-dirty fix for 
>>> > multiple GOPs, but created a proper-ish patch yesterday, see 
>>> > http://article.gmane.org/gmane.linux.kernel.efi/6332 ), CSM disabled 
>>> > in UEFI and using OVMF virtual machines. The motherboard is an ASRock 
>>> > Z87M Extreme4, with two PCI video cards (an NVidia GT640 (the primary 
>>> > card, used for linux), for which I almost had to beg at Gigabyte 
>>> > support to send an UEFI compatible VBIOS, and a GTX980 (secondary 
>>> > card, to passthrough)). The integrated Intel GPU is diabled in UEFI 
>>> > settings. I'm not sure if it's supposed to work, but with 4.0.4 
>>> > kernels it worked like a charm.
>>> >
>>> > Now with 4.2.0, when I start qemu the monitor attached to the 
>>> > secondary card powers down, and then nothing happens, except qemu 
>>> > eating about 150% cpu. I've started bisecting the kernel, and found 
>>> > out that
>>> >
>>> > d69afbc6b1b5d0579f13d1a6339d952c4f60a9f4 KVM: MMU: fix decoding cache 
>>> > type from MTRR
>>> >
>>> > is the culprit. When mtrr is diabled, the old code returns 0xFF while 
>>> > the new returns MTRR_TYPE_UNCACHABLE. I have absolutely no idea what 
>>> > the hell is going on here, but changing that return statement back 
>>> > solves the problem, until
>>> >
>>> > b18d5431acc7a2fd22767925f3a6f597aa4bd29e KVM: x86: fix CR0.CD 
>>> > virtualization
>>> >
>>> > If I comment out the if kvm_read_cd0 part it will work.. until 
>>> > 4e241557fc1cb560bd9e77ca1b4a9352732a5427, which is a merge commit(!). 
>>> > I'm attaching a patch, it fixes the problem until 
>>> > f2ae45edbca7ba5324eef01719ede0151dc5cead for me. But as I said 
>>> > earlier I have no freakin' idea what's going on here.
>>> >
>>> > I have recompiled OVMF from svn yesterday evening, and have a 
>>> > recent-ish qemu master (with some audio related patches). Tell me if 
>>> > you need any more information.
>>> >
>>> > Thanks,
>>> > Zoltan
>>> >
>>> > [magic.patch]
>>> > _______________________________________________
>>> > 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
>> 
>> _______________________________________________
>> 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/20151001/142e79ae/attachment.htm>