Re: [Qemu-devel] QEMU patch to allow VM introspection via libvmi

[Eduardo Habkost]

On Mon, Oct 26, 2015 at 11:37:04AM -0600, Valerio Aimale wrote:
> On 10/26/15 3:09 AM, Markus Armbruster wrote:
> >[...]
> >
> >>Eduardo, I think it would be a common rule of politeness not to pass
> >>any judgement on a person that you don't know, but for some texts in a
> >>mailing list. I think I understand how mmap() works, and very well.
> >>
> >>Participating is this discussion has been a struggle for me. For the
> >>good of the libvmi users, I have been trying to ignore the judgements,
> >>the comments and so on. But, alas, I throw my hands up in the air, and
> >>I surrender.
> >I'm sorry we exceeded your tolerance for frustration.  This mailing list
> >can be tough.  We try to be welcoming (believe it or not), but we too
> >often fail (okay, that part is easily believable).
> >
> >To be honest, I had difficulties understanding your explanation, and
> >ended up guessing.  I figure Eduardo did the same, and guessed
> >incorrectly.  There but for the grace of God go I.
> Well, I did scribble my C sample excerpt too fast. Participating in mailing
> list is not part of my job description - I was short on time, I admit to
> that. However, there is a big difference in saying "I do no understand your
> explanation, please try again" and saying "you're confused about mmap()"
> 
> I was trying to advocate the use of a shared mmap'ed region. The sharing
> would be two-ways (RW for both) between the QEMU virtualizer and the libvmi
> process. I envision that there could be a QEMU command line argument, such
> as "--mmap-guest-memory <filename>" Understand that Eric feels strongly the
> libvmi client should own the file name - I have not forgotten that. When
> that command line argument is given, as part of the guest initialization,
> QEMU creates a file of size equal to the size of the guest memory containing
> all zeros, mmaps that file to the guest memory with  PROT_READ|PROT_WRITE
> and MAP_FILE|MAP_SHARED, then starts the guest.

This is basically what memory-backend-file (and the legacy -mem-path
option) already does today, but it unlinks the file just after opening
it. We can change it to accept a full filename and/or an option to make
it not unlink the file after opening it.

I don't remember if memory-backend-file is usable without -numa, but we
could make it possible somehow.


> And, if at all possible,
> makes the filename querable via qmp and/or hmp, so that the filename of the
> mmap would not need to be maintained in two different places, leading to
> maintenance nightmares.

You can probably query the memory-backend-file QOM properties using QMP,
already. Then the filename could be exposed as a QOM property.

-- 
Eduardo