qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Valerio Aimale <valerio@aimale.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: lcapitulino@redhat.com, Markus Armbruster <armbru@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] QEMU patch to allow VM introspection via libvmi
Date: Fri, 23 Oct 2015 13:08:57 -0600	[thread overview]
Message-ID: <562A85C9.6050309@aimale.com> (raw)
In-Reply-To: <20151023185504.GI3736@thinpad.lan.raisama.net>

On 10/23/15 12:55 PM, Eduardo Habkost wrote:
> On Thu, Oct 22, 2015 at 03:51:28PM -0600, Valerio Aimale wrote:
>> On 10/22/15 3:47 PM, Eduardo Habkost wrote:
>>> On Thu, Oct 22, 2015 at 01:57:13PM -0600, Valerio Aimale wrote:
>>>> On 10/22/15 1:12 PM, Eduardo Habkost wrote:
>>>>> On Wed, Oct 21, 2015 at 12:54:23PM +0200, Markus Armbruster wrote:
>>>>>> Valerio Aimale <valerio@aimale.com> writes:
>>>>> [...]
>>>>>>> There's also a similar patch, floating around the internet, the uses
>>>>>>> shared memory, instead of sockets, as inter-process communication
>>>>>>> between libvmi and QEMU. I've never used that.
>>>>>> By the time you built a working IPC mechanism on top of shared memory,
>>>>>> you're often no better off than with AF_LOCAL sockets.
>>>>>>
>>>>>> Crazy idea: can we allocate guest memory in a way that support sharing
>>>>>> it with another process?  Eduardo, can -mem-path do such wild things?
>>>>> It can't today, but just because it creates a temporary file inside
>>>>> mem-path and unlinks it immediately after opening a file descriptor. We
>>>>> could make memory-backend-file also accept a full filename as argument,
>>>>> or add a mechanism to let QEMU send the open file descriptor to a QMP
>>>>> client.
>>>>>
>>>> Eduardo, would my "artisanal" idea of creating an mmap'ed image of the guest
>>>> memory footprint work, augmented by Eric's suggestion of having the qmp
>>>> client pass the filename?
>>> The code below doesn't make sense to me.
>> Ok. What I am trying to do is to create a mmapped() memory area of the guest
>> physical memory that can be shared between QEMU and an external process,
>> such that the external process can read arbitrary locations of the qemu
>> guest physical memory.
>> In short, I'm using mmap MAP_SHARED to share the guest memory area with a
>> process that is external to QEMU
>>
>> does it make better sense now?
> I think you are confused about what mmap() does. It will create a new
> mapping into the process address space, containing the data from an
> existing file, not the other way around.
>
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 think libvmi can live, as it has for the past years, by patching the 
QEMU source tree on as needed basis, and keeping the patch in the libvmi 
source tree, without disturbing any further the QEMU community.

  reply	other threads:[~2015-10-23 19:09 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-15 23:44 [Qemu-devel] QEMU patch to allow VM introspection via libvmi valerio
2015-10-15 23:44 ` [Qemu-devel] [PATCH] QEMU patch for libvmi to introspect QEMU/kvm virtual machines. Usually this patch is distributed with libvmi, but, it might be more useful to have it in the QEMU source permanently valerio
2015-10-19 21:33   ` Eric Blake
2015-10-21 15:11     ` Valerio Aimale
2015-10-16  8:15 ` [Qemu-devel] QEMU patch to allow VM introspection via libvmi Markus Armbruster
2015-10-16 14:30   ` Valerio Aimale
2015-10-19  7:52     ` Markus Armbruster
2015-10-19 14:37       ` Valerio Aimale
2015-10-21 10:54         ` Markus Armbruster
2015-10-21 15:50           ` Valerio Aimale
2015-10-22 11:50             ` Markus Armbruster
2015-10-22 18:11               ` Valerio Aimale
2015-10-23  6:31                 ` Markus Armbruster
2015-10-22 18:43           ` Valerio Aimale
2015-10-22 18:54             ` Eric Blake
2015-10-22 19:12           ` Eduardo Habkost
2015-10-22 19:57             ` Valerio Aimale
2015-10-22 20:03               ` Eric Blake
2015-10-22 20:45                 ` Valerio Aimale
2015-10-22 21:47               ` Eduardo Habkost
2015-10-22 21:51                 ` Valerio Aimale
2015-10-23  8:25                   ` Daniel P. Berrange
2015-10-23 19:00                     ` Eduardo Habkost
2015-10-23 18:55                   ` Eduardo Habkost
2015-10-23 19:08                     ` Valerio Aimale [this message]
2015-10-26  9:09                       ` Markus Armbruster
2015-10-26 17:37                         ` Valerio Aimale
2015-10-26 17:52                           ` Eduardo Habkost
2015-10-27 14:17                             ` Valerio Aimale
2015-10-27 15:00                               ` Markus Armbruster
2015-10-27 15:18                                 ` Valerio Aimale
2015-10-27 15:31                                   ` Valerio Aimale
2015-10-27 16:11                                   ` Markus Armbruster
2015-10-27 16:27                                     ` Valerio Aimale
2015-10-23  6:35             ` Markus Armbruster
2015-10-23  8:18               ` Daniel P. Berrange
2015-10-23 14:48                 ` Valerio Aimale
2015-10-23 14:44               ` Valerio Aimale
2015-10-23 14:56                 ` Eric Blake
2015-10-23 15:03                   ` Valerio Aimale
2015-10-23 19:24               ` Eduardo Habkost
2015-10-23 20:02                 ` Richard Henderson
2015-11-02 12:55                 ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=562A85C9.6050309@aimale.com \
    --to=valerio@aimale.com \
    --cc=armbru@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=lcapitulino@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).