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.william...@gmail.com> wrote: > On Wed, May 18, 2016 at 1:33 PM, Abdulla Bubshait <darkst...@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 <k...@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 >
_______________________________________________ vfio-users mailing list vfio-users@redhat.com https://www.redhat.com/mailman/listinfo/vfio-users
