From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:40292)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <valerio@aimale.com>) id 1Zr767-0007Ia-HB
	for qemu-devel@nongnu.org; Tue, 27 Oct 2015 12:27:44 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <valerio@aimale.com>) id 1Zr763-00084U-Dh
	for qemu-devel@nongnu.org; Tue, 27 Oct 2015 12:27:43 -0400
Received: from smtp.aimale.com ([166.78.138.199]:50693)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <valerio@aimale.com>) id 1Zr763-00084Q-5h
	for qemu-devel@nongnu.org; Tue, 27 Oct 2015 12:27:39 -0400
References: <56250035.40805@aimale.com> <87twpkqyow.fsf@blackfin.pond.sub.org>
	<20151022191203.GC3736@thinpad.lan.raisama.net>
	<56293F99.1060109@aimale.com>
	<20151022214719.GD3736@thinpad.lan.raisama.net>
	<56295A60.1040901@aimale.com>
	<20151023185504.GI3736@thinpad.lan.raisama.net>
	<562A85C9.6050309@aimale.com>
	<87ziz60zeg.fsf@blackfin.pond.sub.org> <562E64C0.1080509@aimale.com>
	<20151026175217.GC4180@thinpad.lan.raisama.net>
	<562F8796.4070503@aimale.com>
	<87wpu84arz.fsf@blackfin.pond.sub.org> <562F95C5.2020006@aimale.com>
	<87si4w1ebe.fsf@blackfin.pond.sub.org>
From: Valerio Aimale <valerio@aimale.com>
Message-ID: <562FA5F7.7060102@aimale.com>
Date: Tue, 27 Oct 2015 10:27:35 -0600
MIME-Version: 1.0
In-Reply-To: <87si4w1ebe.fsf@blackfin.pond.sub.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] QEMU patch to allow VM introspection via libvmi
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Markus Armbruster <armbru@redhat.com>
Cc: qemu-devel@nongnu.org, Eduardo Habkost <ehabkost@redhat.com>, lcapitulino@redhat.com

On 10/27/15 10:11 AM, Markus Armbruster wrote:
> [...]
>>>> Eduardo, I did try this approach. It takes 2 line changes in exec.c:
>>>> comment the unlink out, and making sure MAP_SHARED is used when
>>>> -mem-path and -mem-prealloc are given. It works beautifully, and
>>>> libvmi accesses are fast. However, the VM is slowed down to a crawl,
>>>> obviously, because each RAM access by the VM triggers a page fault on
>>>> the mmapped file. I don't think having a crawling VM is desirable, so
>>>> this approach goes out the door.
>>> Uh, I don't understand why "each RAM access by the VM triggers a page
>>> fault".  Can you show us the patch you used?
>> Sorry, too brief of an explanation. Every time the guest flips a byte in
>> physical RAM, I think that triggers a page write to the mmaped file. My
>> understanding is that, with MAP_SHARED, each write to RAM triggers a
>> file write, hence the slowness. These are the simple changes I made, to
>> test it - as a proof of concept.
> Ah, that actually makes sense.  Thanks!
>
> [...]
However, when the guest RAM mmap'ed file resides on a RAMdisk on the 
host, the guest OS responsiveness is more than acceptable. Perhaps this 
is a viable approach. It might requires a minimum of changes to the QEMU 
source and maybe 1 extra command line argument.