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

[Markus Armbruster]

"Bryan D. Payne" <address@hidden> writes:

>>
>> 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.

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.

> 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.

Makes sense.

>> 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.

The QMP overhead could be too high.  QMP is control plane, not data
plane.  How much data do you envisage flowing here?

In theory, even the character device overhead could be too high.
Measuring it shouldn't be too hard.

> 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 control a QMP monitor, you own the guest.  If you set up your QMP
monitor in a way that permits untrusted users to control it, you're
giving away the guest.  Adding more commands to access guest memory
doesn't really make this worse.  It could perhaps make p0wning more
efficient.

> 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 ??

I feel code comment is find for internal interfaces, but for external
interfaces, a separate interface document is more appropriate.