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

[Bryan D. Payne]

Actually, it sends it through a UNIX domain socket.  Still I/O, just
different I/O.  "Faster" is plausible, but by how much I can't say
without measurements.  "Several orders of magnitude" needs evidence.

I've been testing introspection performance on both Xen and KVM for over 5 years now, and I'm pretty comfortable with this statement.  Bottom line is that sending lots of data through a disk is much slower than sending lots of data through memory (for example, see Figure 3 in http://queue.acm.org/detail.cfm?id=1563874, which shows about 5 orders of magnitude difference for random access data@).  A UNIX domain socket is just going through memory.

I have other Qemu modifications that can reduce the use of the memory bus by using shared memory instead.  This provides another big bump in performance.  However, this work is still in earlier stages.

Based on your qapi-schema.json change only, I figure your new command
sets up a special-purpose monitor-like thing on a newly created a UNIX
domain socket.  This monitor-like thing talks its own language, which is
so far undocmented.

Correct.  Per request from one of the reviewers in this thread, I have an updated patch that has full documentation on this protocol.  I've been waiting to push that as I try to sort out some of the remaining discussion in this thread, though.

 

Why restrict this to a UNIX domain socket?  In other places involving
byte streams we use a QEMU character device.

Can you explain why you need a separate stream instead of embedding the
conversation in QMP?  We already have such embedded I/O: ringbuf-read,
ringbuf-write.  Yes, it got multiple documented bugs, but that's because
it was badly done, not because such a thing couldn't be done nicely.

I think that it could be done in QMP.  I would want to validate the performance of that approach though as there will be some extra overhead.  I would also be concerned about access to this data over a network.

For security reasons, it feels better to me to restrict this feature to someone that is on the local machine.  Using a UNIX domain socket forces this constraint.  I don't believe that is the case with QMP, but please correct me if I'm wrong about that.

 

If you add a separate stream talking its own language, you get to
document the language.  A file in docs/ should do.  The QMP command
documentation should point to it.

My updated patch documents it as a comment directly in the C source, as that is what I felt a previous reviewer was asking for.  Is docs more appropriate or ??

Cheers,

-bryan