On 23/10/2015 21:24, Eduardo Habkost wrote:
>> >
>> > Valerio, would an command line option to share guest memory suffice, or
>> > does it have to be a monitor command? If the latter, why?
>> >
>> > Eduardo, I'm not sure writing to guest memory behind TCG's back will
>> > work. Do you know?
>
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
Valerio Aimale writes:
> On 10/27/15 9:00 AM, Markus Armbruster wrote:
>> Valerio Aimale writes:
>>
>>> On 10/26/15 11:52 AM, Eduardo Habkost wrote:
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 virtualize
On 10/27/15 9:00 AM, Markus Armbruster wrote:
Valerio Aimale writes:
On 10/26/15 11:52 AM, Eduardo Habkost wrote:
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 ther
On 10/27/15 9:18 AM, Valerio Aimale wrote:
I did not try to mmap'ing to a file on a RAMdisk. Without physical
disk I/O, the VM might run faster.
I did try with the file on a ramdisk
$ sudo mount -o size=3G -t tmpfs none /ramdisk
$ /usr/local/bin/qemu-system-x86_64 -name Windows10 -S -mac
Valerio Aimale writes:
> On 10/26/15 11:52 AM, Eduardo Habkost wrote:
>>
>>
>> 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 arg
On 10/26/15 11:52 AM, Eduardo Habkost wrote:
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 "
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
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 h
Valerio Aimale writes:
> 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
On 10/23/2015 09:24 AM, Eduardo Habkost wrote:
On Fri, Oct 23, 2015 at 08:35:15AM +0200, Markus Armbruster wrote:
Eduardo Habkost writes:
On Wed, Oct 21, 2015 at 12:54:23PM +0200, Markus Armbruster wrote:
Valerio Aimale writes:
[...]
There's also a similar patch, floating around the inter
On Fri, Oct 23, 2015 at 08:35:15AM +0200, Markus Armbruster wrote:
> Eduardo Habkost writes:
>
> > On Wed, Oct 21, 2015 at 12:54:23PM +0200, Markus Armbruster wrote:
> >> Valerio Aimale writes:
> > [...]
> >> > There's also a similar patch, floating around the internet, the uses
> >> > shared me
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:23
On Fri, Oct 23, 2015 at 09:25:03AM +0100, Daniel P. Berrange 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 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:
>
On 10/23/15 8:56 AM, Eric Blake wrote:
On 10/23/2015 08:44 AM, Valerio Aimale wrote:
Libvmi dependence on virsh is so strict, that libvmi does not even know
if the QEMU VM has an open qmp unix socket or inet socket, to send
commands through. Thus, libvmi sends qmp commands (to query registers
On 10/23/2015 08:44 AM, Valerio Aimale wrote:
>
> Libvmi dependence on virsh is so strict, that libvmi does not even know
> if the QEMU VM has an open qmp unix socket or inet socket, to send
> commands through. Thus, libvmi sends qmp commands (to query registers,
> as an example) via
>
> virsh q
On 10/23/15 2:18 AM, Daniel P. Berrange wrote:
[...]
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
On 10/23/15 12:35 AM, Markus Armbruster wrote:
Eduardo Habkost writes:
On Wed, Oct 21, 2015 at 12:54:23PM +0200, Markus Armbruster wrote:
Valerio Aimale writes:
[...]
There's also a similar patch, floating around the internet, the uses
shared memory, instead of sockets, as inter-process
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:
>
On Fri, Oct 23, 2015 at 08:35:15AM +0200, Markus Armbruster wrote:
> Eduardo Habkost writes:
>
> > On Wed, Oct 21, 2015 at 12:54:23PM +0200, Markus Armbruster wrote:
> >> Valerio Aimale writes:
> > [...]
> >> > There's also a similar patch, floating around the internet, the uses
> >> > shared me
Eduardo Habkost writes:
> On Wed, Oct 21, 2015 at 12:54:23PM +0200, Markus Armbruster wrote:
>> Valerio Aimale 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
Valerio Aimale writes:
> On 10/22/15 5:50 AM, Markus Armbruster wrote:
>> Valerio Aimale writes:
>>
>>> On 10/21/15 4:54 AM, Markus Armbruster wrote:
[...]
Can you give an example?
>>> Yes. I was trying to dump the full extent of physical memory of a VM
>>> that has 8GB memory space (balloo
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 writes:
[...]
There's also a similar patch, floating arou
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 writes:
> >[...]
> >>>There's also a similar patch, floating around the internet, the uses
> >>>sha
On 10/22/15 2:03 PM, Eric Blake wrote:
On 10/22/2015 01:57 PM, Valerio Aimale wrote:
pmemmap would return the following json
{
'success' : 'true',
'map_filename' : '/tmp/QEM_mmap_1234567'
}
In general, it is better if the client controls the filename, and not
qemu. This is because
On 10/22/2015 01:57 PM, Valerio Aimale wrote:
>
> pmemmap would return the following json
>
> {
> 'success' : 'true',
> 'map_filename' : '/tmp/QEM_mmap_1234567'
> }
In general, it is better if the client controls the filename, and not
qemu. This is because things like libvirt like to r
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 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
On Wed, Oct 21, 2015 at 12:54:23PM +0200, Markus Armbruster wrote:
> Valerio Aimale 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.
>
> B
On 10/22/2015 12:43 PM, Valerio Aimale wrote:
>
> What if there was a qmp command, say 'pmemmap' then when invoked,
> performs the following:
>
> qmp_pmemmap( [...]) {
>
> char *template = "/tmp/QEM_mmap_XXX";
Why not let the caller pass in the file name, rather than opening it
ourselv
On 10/21/15 4:54 AM, Markus Armbruster wrote:
Valerio Aimale writes:
On 10/19/15 1:52 AM, Markus Armbruster wrote:
Valerio Aimale writes:
On 10/16/15 2:15 AM, Markus Armbruster wrote:
vale...@aimale.com writes:
All-
I've produced a patch for the current QEMU HEAD, for libvmi to
introsp
On 10/22/15 5:50 AM, Markus Armbruster wrote:
Valerio Aimale writes:
On 10/21/15 4:54 AM, Markus Armbruster wrote:
Valerio Aimale writes:
On 10/19/15 1:52 AM, Markus Armbruster wrote:
Valerio Aimale writes:
On 10/16/15 2:15 AM, Markus Armbruster wrote:
vale...@aimale.com writes:
All
Valerio Aimale writes:
> On 10/21/15 4:54 AM, Markus Armbruster wrote:
>> Valerio Aimale writes:
>>
>>> On 10/19/15 1:52 AM, Markus Armbruster wrote:
Valerio Aimale writes:
> On 10/16/15 2:15 AM, Markus Armbruster wrote:
>> vale...@aimale.com writes:
>>
>>> All-
>>
On 10/21/15 4:54 AM, Markus Armbruster wrote:
Valerio Aimale writes:
On 10/19/15 1:52 AM, Markus Armbruster wrote:
Valerio Aimale writes:
On 10/16/15 2:15 AM, Markus Armbruster wrote:
vale...@aimale.com writes:
All-
I've produced a patch for the current QEMU HEAD, for libvmi to
introsp
Valerio Aimale writes:
> On 10/19/15 1:52 AM, Markus Armbruster wrote:
>> Valerio Aimale writes:
>>
>>> On 10/16/15 2:15 AM, Markus Armbruster wrote:
vale...@aimale.com writes:
> All-
>
> I've produced a patch for the current QEMU HEAD, for libvmi to
> introspect QEMU/K
On 10/19/15 1:52 AM, Markus Armbruster wrote:
Valerio Aimale writes:
On 10/16/15 2:15 AM, Markus Armbruster wrote:
vale...@aimale.com writes:
All-
I've produced a patch for the current QEMU HEAD, for libvmi to
introspect QEMU/KVM VMs.
Libvmi has patches for the old qeum-kvm fork, inside i
Valerio Aimale writes:
> On 10/16/15 2:15 AM, Markus Armbruster wrote:
>> vale...@aimale.com writes:
>>
>>> All-
>>>
>>> I've produced a patch for the current QEMU HEAD, for libvmi to
>>> introspect QEMU/KVM VMs.
>>>
>>> Libvmi has patches for the old qeum-kvm fork, inside its source tree:
>>> ht
On 10/16/15 2:15 AM, Markus Armbruster wrote:
vale...@aimale.com writes:
All-
I've produced a patch for the current QEMU HEAD, for libvmi to
introspect QEMU/KVM VMs.
Libvmi has patches for the old qeum-kvm fork, inside its source tree:
https://github.com/libvmi/libvmi/tree/master/tools/qemu-k
vale...@aimale.com writes:
> All-
>
> I've produced a patch for the current QEMU HEAD, for libvmi to
> introspect QEMU/KVM VMs.
>
> Libvmi has patches for the old qeum-kvm fork, inside its source tree:
> https://github.com/libvmi/libvmi/tree/master/tools/qemu-kvm-patch
>
> This patch adds a hmp an
All-
I've produced a patch for the current QEMU HEAD, for libvmi to introspect
QEMU/KVM VMs.
Libvmi has patches for the old qeum-kvm fork, inside its source tree:
https://github.com/libvmi/libvmi/tree/master/tools/qemu-kvm-patch
This patch adds a hmp and a qmp command, "pmemaccess". When the
40 matches
Mail list logo
