[vfio-users] VGA Passthrough limitations?

Andrei Grigore andrei.grg at gmail.com
Wed May 18 20:27:44 UTC 2016


There is absolutely nothing in dmesg. I have also tried pinning the CPU and
it doesn't make any difference. I will forward this to to the kvm mailing
list. Thank you all for your support!

On Wed, May 18, 2016 at 9:53 PM, Alex Williamson <
alex.l.williamson at gmail.com> wrote:

> On Wed, May 18, 2016 at 1:33 PM, Abdulla Bubshait <darkstego at gmail.com>
> wrote:
>
>> I don't think this is an identical MSRS spam, but it might be caused by
>> the same underlying principal. I think the bottleneck here is the CPU,
>> since Virtual CPUs are not exactly like CPUs.
>>
>> Take the Heroes MSRS spam. Each event is a register read in hardware, but
>> since these are unique registers they will be emulated (if function works)
>> as software in KVM. What I am guessing is happening here is the 3D code is
>> running something that requires KVM to do things, which ends up being much
>> slower than hardware.
>>
>> I would suggest trying to do something like CPU pinning to see if you can
>> bump up performance a bit. But if this thing turns out to be a code path
>> that isn't using hardware virtualization then you might never get the
>> performance you are looking for.
>>
>> Maybe someone with more experience with the inner workings of
>> virtualization could be more useful here.
>>
>
> This is where you probably want to post your analysis to the KVM mailing
> list <kvm at vger.kernel.org>.  There are folks there with quite a bit more
> knowledge of the low level processor details than me.  Device assignment
> itself can almost entirely get out of the way, the limitations are
> interrupt latency (which has hardware solutions in newer processors for
> some cases) and device regions that are partially emulated or virtualized,
> like device quirks or msi-x vector pages.  Actual processor virtualization
> is material for the KVM list.  Thanks,
>
> Alex
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20160518/88302410/attachment.htm>


More information about the vfio-users mailing list