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

[Markus Armbruster]

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

>>
>> Can you explain again why the existing commands to read guest memory
>> (from the top of my head: dump-guest-memory, memsave, pmemsave) are
>> insufficient?  How does your solution improve on them?  What exactly can
>> it do what these commands can't?  What exactly can't it do what these
>> commands can?
>>
>> I feel we need to understand the answers to these questions to sensibly
>> evolve the API in this area.
>
>
> Certainly.  The main issue with this series of commands is that they dump
> the memory to a file on disk.  What I'm trying to facilitate here is an
> application that monitors the guest memory in real time while the guest is
> running (likely with brief pauses during memory analysis periods).  Writing
> all of this data to disk, and then reading it back again for the analysis
> application is several orders of magnitude too slow for these types of
> applications.
>
> This new method that I'm proposing here keeps everything in memory, which
> makes it much faster.

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 think you could make another supporting argument: the socket is easier
to use than futzing around with files.

> Tldr; existing solutions are suitable for forensic analysis, whereas I'm
> looking to solve the runtime analysis problem.

Understood.

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.

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.

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.