Re: [Qemu-devel] [PATCH] qmp: extend QMP to provide read/write access to physical memory

[Fam Zheng <famz@redhat.com>]

On Wed, 12/10 21:33, Bryan D. Payne wrote:
> > 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.
> 

Look good. I believe QMP will be in between, and if it doesn't work as well,
could you also try to use QEMU's char dev instead of limit this to unix socket?

Fam