> By "evidence", I mean actual numbers for actual QEMU code. Nothing >> sophisticated, just use your new interface in a way you consider >> relevant for your own use case, then approximate this use with existing >> interfaces. The approximation can be very rough. For instance, showing >> that doing the whole job with your approach is a much faster than doing >> a necessary part of the job with existing commands would do. >> > > Sure, I can put together some numbers to help with this discussion. >
I've done some performance testing on my laptop. I have setup LibVMI to access KVM guest memory using one of three different options: QMP/pmemsave (dump bytes to a file and then read that back into memory) HMC/xp command (dump bytes via human monitor command and repack the output to binary form) QMP/pmemaccess (access bytes through a Unix socket, this is the patch we are discussing in this thread) For each of these I measured the time required to translate a guest kernel virtual address into a guest physical address. This is done with a 64-bit Ubuntu Trusty guest and the addresses are translated by walking the page tables in the guest using the selected memory access technique. You can see the graph here: http://cl.ly/image/322a3s0h1V05 For those that prefer text, here's the numbers (in microseconds): QMP/pmemsave: 77706 HMC/xp command: 92552 QMP/pmemaccess: 95 As you can see, the technique proposed in this patch is about 3 orders of magnitude faster than the options available in Qemu today. I will also note that this is for a _single_ virtual address translation. A typical introspection application will be doing much more work than this, which will only compound the problem. Hopefully this helps to explain why I believe that this is an improvement to the existing mechanisms. Please let me know if you have any questions about these results. I'll continue some exploration of doing the pmemaccess bulk data transfer over QMP, instead of the UNIX socket. And I'll report back here once I've come up with some thoughts on the best way to proceed. Cheers, -bryan
