"Bryan D. Payne" <bdpa...@acm.org> 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.
