qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Fam Zheng
Subject: Re: [Qemu-devel] [PATCH] qmp: extend QMP to provide read/write access to physical memory
Date: Thu, 11 Dec 2014 13:45:08 +0800
User-agent: Mutt/1.5.23 (2014-03-12)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]