to even further encourage this.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
,
Anthony Liguori
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
you see as requirements.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/22/2010 10:55 AM, Ingo Molnar wrote:
* Anthony Liguorianth...@codemonkey.ws wrote:
[...]
I've been trying very hard to turn this into a productive thread attempting
to capture your feedback and give clear suggestions about how you can solve
achieve your desired functionality.
to change it.
Regards,
Anthony Liguori
Ingo
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
some type
of device. All of the interesting devices are implemented in qemu so
you're going to have to interact with qemu if you want meaningful
interaction with a guest.
Regards,
Anthony Liguori
Thanks,
Ingo
--
To unsubscribe from this list: send the line unsubscribe kvm
. In this case, there is no kernel and there
are no devices.
That's what I mean by a guest being a userspace context. KVM simply
provides a new CPU mode to userspace in the same way that vm8086 mode.
Regards,
Anthony Liguori
- There is no guarantee for the Qemu process to reply to a request - while
with an infrastructure that satisfies your
actual requirements within qemu but if you're also insisting upon the
above implementation detail then there's nothing I can do.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message
in
qemu with respect to usability. We can't just punt to libvirt.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
a very kernel centric view and doesn't consider the interactions
between userspace.
Regards,
Anthony Liguori
Ingo
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
On 03/22/2010 02:31 PM, Daniel P. Berrange wrote:
On Mon, Mar 22, 2010 at 02:15:35PM -0500, Anthony Liguori wrote:
On 03/22/2010 12:55 PM, Avi Kivity wrote:
Lets look at the ${HOME}/.qemu/qmp/ enumeration method suggested by
Anthony.
There's numerous ways that this can break
On 03/11/2010 08:45 PM, Marcelo Tosatti wrote:
This can be used later to introduce generic iothread workers.
Signed-off-by: Marcelo Tosattimtosa...@redhat.com
Could you rebase this? It failed to apply in a strange way that made me
nervous...
Regards,
Anthony Liguori
Index: qemu
. libvirtd can monitor the host file system
to participate in these activities but ultimately, moving this
functionality out of libvirtd means that it becomes the standard
mechanism for all qemu instances regardless of how they're launched.
Regards,
Anthony Liguori
A userspace system-wide entity
On 03/22/2010 08:00 PM, Badari Pulavarty wrote:
Forgot to CC: KVM list earlier
These virtio results are still with a 2.6.18 kernel with no aio, right?
Regards,
Anthony LIguori
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord
On 03/22/2010 08:45 PM, Badari Pulavarty wrote:
Anthony Liguori wrote:
On 03/22/2010 08:00 PM, Badari Pulavarty wrote:
Forgot to CC: KVM list earlier
These virtio results are still with a 2.6.18 kernel with no aio, right?
Results are on 2.6.33-rc8-net-next kernel. But not using AIO.
Can
and that someone sends out notes afterwards :-)
Regards,
Anthony Liguori
thanks,
-chris
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from
prefer to see us fix qemu.
After that, we can look at in-kernel pit and see if there are any
remaining advantages (like performance). If it's significant, we can
still merge in-kernel pit.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body
On 03/23/2010 04:07 AM, Avi Kivity wrote:
On 03/23/2010 12:06 AM, Anthony Liguori wrote:
Having qemu enumerate guests one way or another is not a good idea
IMO since it is focused on one guest and doesn't have a system-wide
entity.
There always needs to be a system wide entity
of cache
coherent shared memory but it's not strictly required.
Memory sharing in virtio would be a layering violation because it forces
cache coherent shared memory for all virtio transports.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body
, and MIGRATION bitmaps together?
Regards,
Anthony Liguori
Replaces direct phys_ram_dirty access with wrapper functions to
prevent direct access to the phys_ram_dirty bitmap.
Signed-off-by: Yoshiaki Tamuratamura.yoshi...@lab.ntt.co.jp
Signed-off-by: OHMURA Keiohmura@lab.ntt.co.jp
---
cpu
...@lab.ntt.co.jp
I don't get it. What's this protecting against?
Regards,
Anthony Liguori
---
hw/hw.h |2 ++
savevm.c | 53 +
2 files changed, 55 insertions(+), 0 deletions(-)
diff --git a/hw/hw.h b/hw/hw.h
index 921cf90..10e6dda
Tamuratamura.yoshi...@lab.ntt.co.jp
Signed-off-by: OHMURA Keiohmura@lab.ntt.co.jp
Perf data?
Regards,
Anthony Liguori
---
vl.c | 221 ++---
1 files changed, 197 insertions(+), 24 deletions(-)
diff --git a/vl.c b/vl.c
index 729c955
() to detect real EOF and treat
that the same as QEMU_VM_EOF (provided it occurred at a section boundary).
Of course, this should be a flag to qemu_loadvm_state() as it's not
always the right behavior.
Regards,
Anthony Liguori
---
migration-exec.c |2 +-
migration-fd.c |2
could also do this by just having a new -incoming option, right?
All you really need is to indicate that this is for high frequency
checkpointing, right?
Regards,
Anthony Liguori
Signed-off-by: Yoshiaki Tamuratamura.yoshi...@lab.ntt.co.jp
---
savevm.c | 76
On 04/21/2010 12:57 AM, Yoshiaki Tamura wrote:
Signed-off-by: Yoshiaki Tamuratamura.yoshi...@lab.ntt.co.jp
No need for this.
Regards,
Anthony Liguori
---
configure |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/configure b/configure
index 046c591
). Then it would work with virtio and emulated devices.
Regards,
Anthony Liguori
diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
index b80402d..1dd1c31 100644
--- a/hw/virtio-blk.c
+++ b/hw/virtio-blk.c
@@ -327,6 +327,8 @@ static void virtio_blk_handle_output(VirtIODevice *vdev,
VirtQueue *vq
and it doesn't
seem to be necessary if we're willing to add options to the -incoming
flag. We also want to be a bit more generic with respect to IO.
Otherwise, the series looks very close to being mergable.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line unsubscribe kvm
QEMUFile uses a
linear buffer for most operations that's limited to 16k, I suspect you
wouldn't be able to observe a difference in practice.
Regards,
Anthony Liguori
---
buffered_file.c |2 +-
hw/hw.h | 16
savevm.c| 43
On 04/22/2010 07:45 PM, Yoshiaki Tamura wrote:
Anthony Liguori wrote:
I think it would make sense to separate out the things that are actually
optimizations (like the dirty bitmap changes and the writev/readv
changes) and to attempt to justify them with actual performance data.
I agree
On 04/22/2010 08:53 PM, Yoshiaki Tamura wrote:
Anthony Liguori wrote:
On 04/22/2010 08:16 AM, Yoshiaki Tamura wrote:
2010/4/22 Dor Laordl...@redhat.com:
On 04/22/2010 01:35 PM, Yoshiaki Tamura wrote:
Dor Laor wrote:
On 04/21/2010 08:57 AM, Yoshiaki Tamura wrote:
Hi all,
We have been
On 04/22/2010 10:37 PM, Yoshiaki Tamura wrote:
Anthony Liguori wrote:
On 04/21/2010 12:57 AM, Yoshiaki Tamura wrote:
QEMUFile currently doesn't support writev(). For sending multiple
data, such as pages, using writev() should be more efficient.
Signed-off-by: Yoshiaki Tamuratamura.yoshi
On 04/22/2010 11:02 PM, Yoshiaki Tamura wrote:
Anthony Liguori wrote:
On 04/21/2010 12:57 AM, Yoshiaki Tamura wrote:
For fool proof purpose, qemu_put_vector_parepare should be called
before qemu_put_vector. Then, if qemu_put_* functions except this is
called after qemu_put_vector_prepare
() syscalls.
With vmstate, we really shouldn't need to do this magic anymore as an
optimization.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
vs. pull and call for stable volunteers)
Regards,
Anthony Liguori
thanks,
-chris
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from
this should only
be added when there's an actual consumer.
Regards,
Anthony Liguori
CC: Cam Macdonellc...@cs.ualberta.ca
Signed-off-by: Marcelo Tosattimtosa...@redhat.com
---
cpu-common.h |1 +
exec.c | 28
2 files changed, 29 insertions(+), 0
On 04/26/2010 01:49 PM, Marcelo Tosatti wrote:
On Mon, Apr 26, 2010 at 01:27:30PM -0500, Anthony Liguori wrote:
On 04/26/2010 12:59 PM, Marcelo Tosatti wrote:
Which allows drivers to register an mmaped region into ram block mappings.
To be used by device assignment driver
On 04/26/2010 01:50 PM, Marcelo Tosatti wrote:
On Mon, Apr 26, 2010 at 01:29:06PM -0500, Anthony Liguori wrote:
On 04/26/2010 12:59 PM, Marcelo Tosatti wrote:
Which allows drivers to register an mmaped region into ram block mappings.
To be used by device assignment driver
On 04/26/2010 02:14 PM, Marcelo Tosatti wrote:
On Mon, Apr 26, 2010 at 01:57:37PM -0500, Anthony Liguori wrote:
On 04/26/2010 01:50 PM, Marcelo Tosatti wrote:
On Mon, Apr 26, 2010 at 01:29:06PM -0500, Anthony Liguori wrote:
On 04/26/2010 12:59 PM, Marcelo Tosatti wrote
On 04/26/2010 05:12 PM, Chris Wright wrote:
* Anthony Liguori (anth...@codemonkey.ws) wrote:
On 04/26/2010 12:26 PM, Chris Wright wrote:
Please send in any agenda items you are interested in covering.
While I don't expect it to be the case this week, if we have a
lack of agenda
similar.
More importantly, I don't see what the burden is of polling when you're
talking about a very unusual statistic that has a very limited use case.
Regards,
Anthony Liguori
--
Gleb.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body
On 04/27/2010 03:14 AM, Avi Kivity wrote:
On 04/27/2010 01:36 AM, Anthony Liguori wrote:
A few comments:
1) The problem was not block watermark itself but generating a
notification on the watermark threshold. It's a heuristic and should
be implemented based on polling block stats
On 04/27/2010 03:53 AM, Kevin Wolf wrote:
Am 27.04.2010 00:36, schrieb Anthony Liguori:
On 04/26/2010 05:12 PM, Chris Wright wrote:
* Anthony Liguori (anth...@codemonkey.ws) wrote:
On 04/26/2010 12:26 PM, Chris Wright wrote:
Please send in any agenda items you
five seconds would be
completely reasonable in addressing the use-case. It might not be as
sexy as a generic event notification mechanism but not everything can't
be JSON.
Regards,
Anthony Liguori
Kevin
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body
On 04/27/2010 08:05 AM, Gleb Natapov wrote:
On Tue, Apr 27, 2010 at 08:00:02AM -0500, Anthony Liguori wrote:
On 04/27/2010 06:11 AM, Gleb Natapov wrote:
Network cards have low number of rx/tx buffers interrupt. This is also
heuristic. Do you think driver should poll for this event
,
Anthony Liguori
Kevin
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 04/27/2010 08:42 AM, Kevin Wolf wrote:
Am 27.04.2010 15:21, schrieb Anthony Liguori:
On 04/27/2010 08:18 AM, Kevin Wolf wrote:
The watermark is not some complex computed value, but actually the
statistic itself. We can get rid of handling a threshold in qemu by just
signalling
On 04/27/2010 08:58 AM, Kevin Wolf wrote:
Am 27.04.2010 15:48, schrieb Anthony Liguori:
On 04/27/2010 08:42 AM, Kevin Wolf wrote:
Am 27.04.2010 15:21, schrieb Anthony Liguori:
On 04/27/2010 08:18 AM, Kevin Wolf wrote:
The watermark is not some complex computed
in upstream qemu. No progress is ever made in
the guest.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 04/28/2010 11:22 AM, Marcelo Tosatti wrote:
On Wed, Apr 28, 2010 at 10:39:06AM -0500, Anthony Liguori wrote:
On 04/26/2010 12:59 PM, Marcelo Tosatti wrote:
This is now done via the initialization's qemu_system_reset call.
Signed-off-by: Avi Kivitya...@redhat.com
---
kvm-all.c
On 05/03/2010 04:32 AM, Yoshiaki Tamura wrote:
2010/4/23 Avi Kivitya...@redhat.com:
On 04/23/2010 04:22 PM, Anthony Liguori wrote:
I currently don't have data, but I'll prepare it.
There were two things I wanted to avoid.
1. Pages to be copied to QEMUFile buf through qemu_put_buffer
Liguori
Thanks,
Yoshi
Regards,
Anthony Liguori
Thanks,
Yoshi
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
/master already
have an in-kernel apic)?
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
copyrights, no?
Regards,
Anthony Liguori
+#include hw.h
+#include console.h
+#include pc.h
+#include pci.h
+#include sysemu.h
+
+#include msix.h
+#include qemu-kvm.h
+#include libkvm.h
+
+#includesys/eventfd.h
+#includesys/mman.h
+#includesys/socket.h
+#includesys/ioctl.h
+
+#define IVSHMEM_IRQFD 0
disconnect/reconnect during live migration asynchronously to the actual
qemu live migration.
Regards,
Anthony Liguori
So it's a good idea to make the initialization process atomic.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord
libvirt
if we didn't.
Regards,
Anthony Liguori
---
Changelog:
v1-v2:
- free memory in case of vq initialization error.
- change license of virtio ring/pci to LGPLv3 with permission
of Laurent Vivier (aka the author).
diff --git a/Makefile b/Makefile
index 327a1bf..d0b8881 100644
On 05/10/2010 10:54 AM, Gleb Natapov wrote:
On Mon, May 10, 2010 at 10:48:42AM -0500, Anthony Liguori wrote:
On 05/10/2010 03:11 AM, Gleb Natapov wrote:
This patch adds native support for booting from virtio disks to Seabios.
Signed-off-by: Gleb Natapovg...@redhat.com
that the shared region is now mapped?
You know it's mapped because it's mapped when the pci map function
returns. You don't need the guest to explicitly tell you.
Regards,
Anthony Liguori
Cam
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message
On 05/10/2010 11:59 AM, Avi Kivity wrote:
On 05/10/2010 06:38 PM, Anthony Liguori wrote:
Otherwise, if the BAR is allocated during initialization, I would have
to use MAP_FIXED to mmap the memory. This is what I did before the
qemu_ram_mmap() function was added.
What would happen to any
On 05/10/2010 12:43 PM, Cam Macdonell wrote:
On Mon, May 10, 2010 at 11:25 AM, Anthony Liguorianth...@codemonkey.ws wrote:
On 05/10/2010 11:59 AM, Avi Kivity wrote:
On 05/10/2010 06:38 PM, Anthony Liguori wrote:
Otherwise, if the BAR is allocated during
,
Anthony Liguori
Testing... It wont be fast because I want to hear
from the OP.
Thanks!
/mjt
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
of a use of multiple peers via shared memory today with
virtualization. I know lots of master/slave uses of shared memory
though. I agree that it's useful to support from an academic
perspective but I don't believe it's going to be the common use.
Regards,
Anthony Liguori
--
To unsubscribe from
between guests is all that interesting compared to shared memory to an
external process on the host.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
I'd prefer to avoid at it introduces additional down time.
Regards,
Anthony Liguori
I think abstractions on top of shared memory could handle
disconnection issues (sort of how TCP handles them for networks) if
the application needs it. Again, my opinion is to leave it to the
application
On 05/12/2010 04:24 PM, Marcelo Tosatti wrote:
The following changes since commit 54d7cf136f040713095cbc064f62d753bff6f9d2:
Markus Armbruster (1):
doc: Clean up monitor command function index
Pulled. Thanks.
Regards,
Anthony Liguori
are available in the git repository
the able to mark bugs as affecting many users which help
raise visibility. I can't speak for the source forge tracker, but I do
regular triage on launchpad for qemu bugs.
Regards,
Anthony Liguori
This can wait for a later call if necessary... not worth a call on it's own.
Etc:
[1]
http
On 05/17/2010 10:23 PM, Chris Wright wrote:
Please send in any agenda items you are interested in covering.
If we have a lack of agenda items I'll cancel the week's call.
- Slipping 0.13 release out to July 1st.
- Block I/O performance (high CPU consumption)
Regards,
Anthony Liguori
on June 28th
- 0.13.0 release on July 1st
Any feedback and/or suggestions would be appreciated.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
On 05/18/2010 09:09 AM, Daniel P. Berrange wrote:
On Tue, May 18, 2010 at 08:53:19AM -0500, Anthony Liguori wrote:
On 05/17/2010 10:23 PM, Chris Wright wrote:
Please send in any agenda items you are interested in covering.
If we have a lack of agenda items I'll cancel the week's
be great but it's definitely a tough job.
I'm going to setup a wiki page with some information about how to
participate in the Bug Day and then I'll send out another note later today.
Regards,
Anthony Liguori
- Freeze stable-0.13 on June 21st and release 0.13.0-rc
- Accept only bug fixes
On 05/18/2010 09:55 AM, Daniel P. Berrange wrote:
On Tue, May 18, 2010 at 09:34:06AM -0500, Anthony Liguori wrote:
On 05/18/2010 09:09 AM, Daniel P. Berrange wrote:
On Tue, May 18, 2010 at 08:53:19AM -0500, Anthony Liguori wrote:
On 05/17/2010 10:23 PM, Chris Wright wrote
using yet more QEMU monitor commands.
libvirt could just stop taking patches that use monitor commands.
There's no way we're going to break the deadlock if we don't work
together here.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body
On 05/18/2010 12:31 PM, Avi Kivity wrote:
On 05/18/2010 05:34 PM, Anthony Liguori wrote:
No. I don't think our goal is to ever fully convert monitor commands
to QMP. Some commands simply don't make sense as QMP commands (like
x and xp).
Examining memory does make sense for QMP, although
interest is to
get as many people involved in testing and bug fixing as possible. If
folks are interested in testing specific things like unusual or older
OSes, I'm happy to see it!
Regards,
Anthony Liguori
Unfortunately I doubt I will have time to participate in the Bug Day.
Thanks,
-- Jamie
On 05/19/2010 08:19 AM, Michael Tokarev wrote:
Anthony Liguori wrote:
[]
For the Bug Day, anything is interesting IMHO. My main interest is to
get as many people involved in testing and bug fixing as possible. If
folks are interested in testing specific things like unusual or older
OSes
On 05/19/2010 12:04 AM, Aurelien Jarno wrote:
On Tue, May 18, 2010 at 05:38:27PM -0500, Anthony Liguori wrote:
Hi,
In an effort to improve the 0.13 release quality, I'd like to host a
Bug Day on June 1st, 2010. I've setup a quick wiki page with some
more info (http://wiki.qemu.org/BugDay
.
Of course :-)
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
to compare against privileges from when the file was
opened.
Signed-off-by: Chris Wrightchr...@redhat.com
An fd as a qdev property seems like a bad idea to me. I'm not sure I
have a better suggestion though.
Regards,
Anthony Liguori
---
hw/device-assignment.c | 12
1
On 05/19/2010 03:20 AM, Christoph Hellwig wrote:
On Tue, May 18, 2010 at 08:52:36AM -0500, Anthony Liguori wrote:
This should be filed in launchpad as a qemu bug and it should be tested
against the latest git. This bug sounds like we're using an int to
represent sector offset somewhere
On 05/19/2010 04:10 PM, Chris Wright wrote:
* Anthony Liguori (anth...@codemonkey.ws) wrote:
An fd as a qdev property seems like a bad idea to me.
What is your concern?
qdev properties are supposed to represent device tunables. A file
descriptor is not a tunable.
It's like
;
+}
Very nice.
Regards,
Anthony Liguori
static inline void set_gsi(kvm_context_t kvm, unsigned int gsi)
{
@@ -586,7 +600,7 @@ int kvm_run(CPUState *env)
r = handle_unhandled(run-hw.hardware_exit_reason);
break;
case KVM_EXIT_FAIL_ENTRY:
-r
side).
Regards,
Anthony Liguori
thanks,
-chris
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
flexibility in defining custom machine types
so you could just do qemu -M win98.
Regards,
Anthony Liguori
BTW: Does anyone knows what the problem with Windows95/98 on KVM is? I
tried some tracing today, but couldn't find a hint.
Regards,
Andre.
--
To unsubscribe from this list: send the line
.
Then the message can be much more definitive too.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
?
Regards,
Anthony Liguori
Christian
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe kvm
x4, unsigned long x5);
Looks good. I think we definitely need something like this.
Regards,
Anthony Liguori
diff --git a/trace.py b/trace.py
new file mode 100755
index 000..f38ab6b
--- /dev/null
+++ b/trace.py
@@ -0,0 +1,30 @@
+#!/usr/bin/env python
+import sys
+import struct
On 05/21/2010 08:46 AM, Jan Kiszka wrote:
Anthony Liguori wrote:
On 05/21/2010 04:42 AM, Stefan Hajnoczi wrote:
Trace events should be defined in trace.h. Events are written to
/tmp/trace.log and can be formatted using trace.py. Remember to add
events to trace.py for pretty
be filed in LaunchPad.
Regards,
Anthony Liguori
Thanks!
/mjt
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line
On 05/21/2010 11:52 AM, Jan Kiszka wrote:
Anthony Liguori wrote:
On 05/21/2010 08:46 AM, Jan Kiszka wrote:
Anthony Liguori wrote:
On 05/21/2010 04:42 AM, Stefan Hajnoczi wrote:
Trace events should be defined in trace.h. Events are written to
/tmp/trace.log
On 05/21/2010 04:41 PM, Jan Kiszka wrote:
Anthony Liguori wrote:
I'm not opposed to using a framework, but I'd rather have an equivalent
to kvm_stat tomorrow than wait 3 years for LTTng to not get merged.
So let's have a dirt-simple tracing mechanism and focus on adding useful
trace points
not sure how we would
handle that (unless we forced all block plugins to be in a separate thread).
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
On 05/24/2010 06:03 AM, Avi Kivity wrote:
On 05/24/2010 11:27 AM, Stefan Hajnoczi wrote:
On Sun, May 23, 2010 at 1:01 PM, Avi Kivitya...@redhat.com wrote:
On 05/21/2010 12:29 AM, Anthony Liguori wrote:
I'd be more interested in enabling people to build these types of
storage
systems without
to
introduce a new, reduced functionality block API that was supported for
plugins. Otherwise, the only way a plugin could keep up with our API
changes would be if it was in tree which defeats the purpose of having
plugins.
Regards,
Anthony Liguori
Are you planing to use this for all block
that the new
behavior is really what's desired. It's certainly going to break
compatibility since -M pc-0.12 is going to show a different vendor_id by
default.
Regards,
Anthony Liguori
---
target-i386/cpuid.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Hi,
this hasn't been
/dev/null 2 /dev/null
This will fail if objdir != srcdir. You have to qualify tracetool with
the path to srcdir.
Regards,
Anthony Liguori
+if test $? -ne 0 ; then
+ echo
+ echo Error: invalid trace backend
+ echo Please choose a supported trace backend.
+ echo
+ exit 1
+fi
:-)
This is a problem specific to vdesktop because they're using a very
outdated version of kvm. The kernel code was split from the userspace
code a long time ago.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
On 05/25/2010 04:14 AM, Avi Kivity wrote:
On 05/24/2010 10:38 PM, Anthony Liguori wrote:
- Building a plugin API seems a bit simpler to me, although I'm to
sure if I'd get the
idea correctly:
The block layer has already some kind of api (.bdrv_file_open,
.bdrv_read). We
could simply
as a plugin, it's a preferable approach.
Plugins that just expose chunks of QEMU internal state directly (like
BlockDriver) are a really bad idea IMHO.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
On 05/25/2010 08:25 AM, Avi Kivity wrote:
On 05/25/2010 04:17 PM, Anthony Liguori wrote:
On 05/25/2010 04:14 AM, Avi Kivity wrote:
On 05/24/2010 10:38 PM, Anthony Liguori wrote:
- Building a plugin API seems a bit simpler to me, although I'm to
sure if I'd get the
idea correctly
. And no inlines.
Yeah, if we did plugins, this would be a key requirement.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
also allows this.
This reasoning also applies to qcow2, btw.
I know.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
1 - 100 of 2144 matches
Mail list logo
