[vfio-users] Looking for performance tips, qemu machine type and pci/pcie-root questionning?

thibaut noah thibaut.noah at gmail.com
Tue Apr 19 21:58:42 UTC 2016

On the left is native windows and on the right my last score with the
virtual machine (the gpu wasn't properly detected, that happens sometimes
though it does not change anything to the result, this is the best bench i
got on native windows by the way).

I didn't play with native windows actually, as you can see on the picture
there is almost no difference in graphics, the difference comes mainly from
not having arch linux running at the same time than windows, thus allowing
the cpu to take more load.
And as the difference is mainly cpu, even though it will impact benchmark i
will not see any difference while gaming as i didn't find any game who
could load my 8 cores at 100% (don't even know if that is possible with a

I will need heaven benchmark wheni have the time as it is almost graphics
only, my guess is the difference should be less than 2%.

Also speaking of optimization, i didn't notice any performance gain with
hyperv features, i'm thinking most of the tweaks we are doing mostly
increase the vm stability and remove things like stutter, glitchy audio etc.

Following the example (and with some help) of someone from the mailing list
i configured qemu hooks, that works like a charm and automatize every
configuration one has to run before and after the vm process (mostly screen
and processor configuration)


2016-04-19 23:08 GMT+02:00 Will Marler <will at wmarler.com>:

> I'm glad you shared your process & experience, good job getting it
> working, and interesting 3dmark benchmark. How do you feel about game
> performance? I'm guessing 3% isn't noticeable.
> Will
> On Tue, Apr 19, 2016 at 3:01 PM, thibaut noah <thibaut.noah at gmail.com>
> wrote:
>> So, i switch my vm container to bare metal in order to do some bench with
>> native windows install.
>> Seems the difference between vm and native in 3dmark firestrike is about
>> 3%, just so you know.
>> 2016-04-15 8:17 GMT+02:00 Blank Field <ihatethisfield at gmail.com>:
>>> On Apr 15, 2016 9:01 AM, "thibaut noah" <thibaut.noah at gmail.com> wrote:
>>> > Speaking of drives, it seems from what i read that it is possible for
>>> qemu/kvm to read a native (non virtualize) install of windows from a
>>> passthrough drive.
>>> > If so is there something special to do? Might go to the hassle of
>>> reinstalling my all windows system by i prefer to be sure before touching
>>> anything (though i might just backup the image, boot my vm from it and
>>> clone windows, much easier than reinstalling).
>>> There is a problem, that i've promised to git bisect, but trashed my
>>> fedora instead.
>>> The thing is, you give the whole drive (or just the necessary
>>> partitions) to the vm, and you can either boot the OS inside a VM, or run
>>> it bare-metal.
>>> There are some culprits, for example:
>>> If using UEFI, in order to properly mirror the install, you have to copy
>>> the efivars. Windows relies on them to activate itself.
>>> If using not virtio-scsi, you don't send the scsi commands. The most
>>> noteworthy are SMART and TRIM.
>>> And the final one, since some version of OVMF, GPT formatted drive gets
>>> checked for valid MBR and it fails to boot.
>>> But the performance is closest i could get to native, my HDD gets around
>>> 150-180MBps, just as it does baremetal.
>>> Not sure about IOPS though.
>>> This kind of setup is useful for AB testing.
>> _______________________________________________
>> 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/20160419/8d9e9a08/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BenchDiff.png
Type: image/png
Size: 76504 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20160419/8d9e9a08/attachment.png>

More information about the vfio-users mailing list