Re: [Qemu-devel] [PATCH] qmp: extend QMP to provide read/write access to physical memory

> > > For those that prefer text, here's the numbers (in microseconds): > > QMP/pmemsave: 77706 > > HMC/xp command: 92552 > > QMP/pmemaccess: 95 > I completed a proof of concept implementation for doing this memory access completely over QMP. Basically, it works much like pmemsave except instead

Re: [Qemu-devel] [PATCH] qmp: extend QMP to provide read/write access to physical memory

> > Look good. I believe QMP will be in between, and if it doesn't work as > well, > could you also try to use QEMU's char dev instead of limit this to unix > socket? > Sure, I'll look into that as well. -bryan

Re: [Qemu-devel] [PATCH] qmp: extend QMP to provide read/write access to physical memory

> By "evidence", I mean actual numbers for actual QEMU code. Nothing >> sophisticated, just use your new interface in a way you consider >> relevant for your own use case, then approximate this use with existing >> interfaces. The approximation can be very rough. For instance, showing >> that do

Re: [Qemu-devel] [PATCH] qmp: extend QMP to provide read/write access to physical memory

> > By "evidence", I mean actual numbers for actual QEMU code. Nothing > sophisticated, just use your new interface in a way you consider > relevant for your own use case, then approximate this use with existing > interfaces. The approximation can be very rough. For instance, showing > that doin

Re: [Qemu-devel] [PATCH] qmp: extend QMP to provide read/write access to physical memory

> > 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've been testing introspection performance on both Xen and KVM for over 5 years no

Re: [Qemu-devel] [PATCH] qmp: extend QMP to provide read/write access to physical memory

> > Off the top of my head, I know the -tpm command line options (related to > the 'query-tpm' QMP command) do this; look at hw/tpm/tpm_passthrough.c > for that implementation. So now I do see what you are talking about. But I don't think it applies to this patch. I'm not using qemu_open in thi

Re: [Qemu-devel] [PATCH] qmp: extend QMP to provide read/write access to physical memory

> > Off the top of my head, I know the -tpm command line options (related to > the 'query-tpm' QMP command) do this; look at hw/tpm/tpm_passthrough.c > for that implementation. > Thanks, I'll check that out. Cheers, -bryan

Re: [Qemu-devel] [PATCH] qmp: extend QMP to provide read/write access to physical memory

> > 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 > command

Re: [Qemu-devel] [PATCH] qmp: extend QMP to provide read/write access to physical memory

> > This doesn't stop the client from using a different alignment than we > expect. > It's necessary to be explicit as a binary protocol. > Ok, I'll move ahead with packing the data and sort out the backwards compat issues on the client side. -bryan

Re: [Qemu-devel] [PATCH] qmp: extend QMP to provide read/write access to physical memory

> > It is critical as a transport data structure. You have to define a > byte-by-byte > layout (concerning endianness and padding) and use padding fields together > with > QEMU_PACKED, so the representation is not dependent on alignment This makes sense for network protocols. But, in this case,

Re: [Qemu-devel] [PATCH] qmp: extend QMP to provide read/write access to physical memory

> > Out of curiosity, what are existing solutions? > Basically just attaching gdb and pulling memory out manually (or writing a program to do the same). > +struct request { > > +uint8_t type; /* 0 quit, 1 read, 2 write, ... rest reserved */ > > +uint64_t address; /* address to read

Re: [Qemu-devel] [PATCH] qmp: extend QMP to provide read/write access to physical memory

> > In addition to Fam's review, I have a question - does this code properly > use qemu_open() so that I can use 'add-fd' to pass in a pre-opened > socket fd into fdset 1, then call pmemaccess with '/dev/fdset/1'? If > not, can you please fix it to allow this usage? > I'm not familiar with this s

Re: [Qemu-devel] [PATCH v2] qmp: extend QMP to provide read/write access to physical memory

Ok thanks for the advice, I'll adjust for v3. This is (clearly!) my first contribution to Qemu so I'm still learning how you guys operate. Cheers, -bryan On Mon, Dec 1, 2014 at 2:12 PM, Eric Blake wrote: > On 11/26/2014 01:27 PM, Bryan D. Payne wrote: > > Thanks for the

[Qemu-devel] [PATCH] qmp: extend QMP to provide read/write access to physical memory

B/sec, depending on the hardware. Existing solutions only achieve a small fraction of this speed. Signed-off-by: Bryan D. Payne --- Makefile.target | 2 +- memory-access.c | 200 +++ memory-access.h | 11 +++ monitor.c| 6 ++ qapi-schema

[Qemu-devel] [PATCH v2] qmp: extend QMP to provide read/write access to physical memory

Thanks for the feedback Eric, I've updated the patch. v2 changes: - added QMP command contract to qapi-schema.json - corrected some comments - rewired QMP command to use schema code

[Qemu-devel] [PATCH 0/1] qmp: extend QMP to provide read/write access to physical memory

aims to conform to the Qemu coding guidelines. It is my hope that we can include this in Qemu so that LibVMI users can leverage this faster access without needing to do custom Qemu builds on their KVM systems. Bryan D. Payne (1): qmp: extend QMP to provide read/write access to physical memory

[Qemu-devel] [PATCH 1/1] qmp: extend QMP to provide read/write access to physical memory

B/sec, depending on the hardware. Existing solutions only achieve a small fraction of this speed. Signed-off-by: Bryan D. Payne --- Makefile.target | 2 +- memory-access.c | 200 memory-access.h | 11 monitor.c | 10 +++ qmp-comman

[Qemu-devel] [Bug 1091115] Re: windowsXP install in qemu-system-i386 1.3.0 ends with a BSOD 0x7E in acpi.sys

I have also verified that the BIOS above works with Windows XP (SP2). -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1091115 Title: windowsXP install in qemu-system-i386 1.3.0 ends with a BSOD 0x7E

[Qemu-devel] [Bug 1096712] Re: qemu 1.3.0: Windows XP doesn't boot with BSOD STOP 7E in acpi.sys

*** This bug is a duplicate of bug 1091115 *** https://bugs.launchpad.net/bugs/1091115 I'm seeing this too. Any known work arounds? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1096712 Title: