<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, May 18, 2016 at 1:33 PM, Abdulla Bubshait <span dir="ltr"><<a href="mailto:darkstego@gmail.com" target="_blank">darkstego@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>Maybe someone with more experience with the inner workings of virtualization could be more useful here.</div></div></blockquote><div><br></div><div>This is where you probably want to post your analysis to the KVM mailing list <<a href="mailto:kvm@vger.kernel.org">kvm@vger.kernel.org</a>>.  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,</div><div><br></div><div>Alex</div></div></div></div>