Juan:
It's especailly important for ft to be a standalone thread, as it
may cause monitor to be blocked by network problems. what's your
schedule, maybe I can help some.
Yoshi:
in the following code:
+
+s->file = qemu_fopen_ops(s, ft_trans_put_buffer, ft_trans_get_buffer,
+
On Friday 04 March 2011 4:36:35 pm Stefan Hajnoczi wrote:
> On Fri, Mar 4, 2011 at 9:25 AM, M. Mohan Kumar wrote:
> > +static int chroot_do_create_special(V9fsFileObjectRequest *request)
> > +{
> > +int cur_uid, cur_gid;
> > +int retval = -1;
> > +
> > +cur_uid = geteuid();
> > +c
Thanks Stefan for your review!
On Friday 04 March 2011 5:22:00 pm Stefan Hajnoczi wrote:
>
> Is this code supposed to build on non-Linux hosts? If so, then please
> confirm that the *at() system calls used are standard and available on
> other hosts (e.g. FreeBSD, Darwin, Solaris).
>
No, this
sendkey is a very good command for human using it in their monitor,
but it is not a good idea to port it to qmp, because qmp is a machine
protocol. So we introduce keydown and keyup command for qmp, they
simulate the events that keyboard send to the system.
Example, simulates ctrl+alt+f1:
{ "execu
Yoshi:
I meet one problem if I killed a ft source VM, the dest ft VM will
return errors as the following:
qemu-system-x86_64: fill buffer failed, Resource temporarily unavailable
qemu-system-x86_64: recv header failed
the problem is that the dest VM can not continue to run, as it is
inte
Am 09.03.2011 00:04, schrieb Peter Lieven:
>
> Am 07.10.2010 um 13:27 schrieb Kevin Wolf:
>
>> Am 06.09.2010 16:42, schrieb Bernhard Kohl:
>>> If these messages are not handled correctly the guest driver may hang.
>>>
>>> Always mandatory:
>>> - ABORT
>>> - BUS DEVICE RESET
>>>
>>> Mandatory if t
On Wed, Mar 9, 2011 at 7:37 AM, Jan Kiszka wrote:
> On 2011-03-08 23:53, Peter Lieven wrote:
>> Hi,
>>
>> during testing of qemu-kvm-0.14.0 i can reproduce the following segfault. i
>> have seen similar crash already in 0.13.0, but had no time to debug.
>> my guess is that this segfault is relate
On 03/08/2011 09:19 PM, Anthony Liguori wrote:
Both the guest and the management agent (and both can listen for
events). I don't see why guest->qemu RPC is problematic for
migration - at least when qemu terminates it.
If it's terminated in QEMU, it's fine, but then it's not QMP anymore.
Le
ya su wrote:
Yoshi:
I meet one problem if I killed a ft source VM, the dest ft VM will
return errors as the following:
qemu-system-x86_64: fill buffer failed, Resource temporarily unavailable
qemu-system-x86_64: recv header failed
the problem is that the dest VM can not continue to r
On 2011-03-09 09:50, Corentin Chary wrote:
> On Wed, Mar 9, 2011 at 7:37 AM, Jan Kiszka wrote:
>> On 2011-03-08 23:53, Peter Lieven wrote:
>>> Hi,
>>>
>>> during testing of qemu-kvm-0.14.0 i can reproduce the following segfault. i
>>> have seen similar crash already in 0.13.0, but had no time to
Am 09.03.2011 08:39, schrieb Michael Tokarev:
09.03.2011 10:26, Stefan Weil wrote:
Am 08.03.2011 23:53, schrieb Peter Lieven:
Hi,
during testing of qemu-kvm-0.14.0 i can reproduce the following
segfault. i have seen similar crash already in 0.13.0, but had no time
to debug.
my guess is that th
Am 08.03.2011 16:50, schrieb Chris Wright:
> QAPI merge plans
> - should be 100% back compat
> - qmp moved over
> - hmp moved over
> - 1st pass, core infrastructure (includes test framework)
> - 2nd pass, command conversion
> - 3rd pass, more controversial bits
> - adds dependencies: glib and pytho
Am 09.03.2011 09:47, schrieb ext Kevin Wolf:
Am 09.03.2011 00:04, schrieb Peter Lieven:
Am 07.10.2010 um 13:27 schrieb Kevin Wolf:
Am 06.09.2010 16:42, schrieb Bernhard Kohl:
If these messages are not handled correctly the guest driver may hang.
Always mandatory:
- ABORT
- BUS DEVICE RESET
Am 09.03.2011 05:26, schrieb Ryan Harper:
> * Brian Wheeler [2011-03-01 07:35]:
>> This patch fixes two things:
>>
>> 1) CHECK POWER MODE
>>
>> The error return value wasn't always zero, so it would show up as
>> offline. Error is now explicitly set to zero.
>>
>> 2) SMART
>>
>> The smart value
Hi Stefan
Thanks for the reply.
Sure, I will look into TCG for improvement as a long term plan.
But for now, I have to solve this memcpy performance issue.
Regarding calculating host virtual address from guest virtual address, I
think, QEMU must be doing this somehow.
I would like to know how QEM
Am 09.03.2011 um 10:25 schrieb Bernhard Kohl:
> Am 09.03.2011 09:47, schrieb ext Kevin Wolf:
>> Am 09.03.2011 00:04, schrieb Peter Lieven:
>>> Am 07.10.2010 um 13:27 schrieb Kevin Wolf:
>>>
Am 06.09.2010 16:42, schrieb Bernhard Kohl:
> If these messages are not handled correctly the gue
Re-reading:
>> So we are calling a IOHandlerRecord::fd_write handler that is NULL.
>> Looking at qemu_set_fd_handler2, this may happen if that function is
>> called for an existing io-handler entry with non-NULL write handler,
>> passing a NULL write and a non-NULL read handler. And all this witho
On 2011-03-09 10:54, Corentin Chary wrote:
> Re-reading:
>
>>> So we are calling a IOHandlerRecord::fd_write handler that is NULL.
>>> Looking at qemu_set_fd_handler2, this may happen if that function is
>>> called for an existing io-handler entry with non-NULL write handler,
>>> passing a NULL wr
Am 09.03.2011 um 08:26 schrieb Stefan Weil:
> Am 08.03.2011 23:53, schrieb Peter Lieven:
>> Hi,
>>
>> during testing of qemu-kvm-0.14.0 i can reproduce the following segfault. i
>> have seen similar crash already in 0.13.0, but had no time to debug.
>> my guess is that this segfault is related
On 2011-03-09 10:58, Jan Kiszka wrote:
> On 2011-03-09 10:54, Corentin Chary wrote:
>> Re-reading:
>>
So we are calling a IOHandlerRecord::fd_write handler that is NULL.
Looking at qemu_set_fd_handler2, this may happen if that function is
called for an existing io-handler entry with
Am 09.03.2011 um 08:37 schrieb Jan Kiszka:
> On 2011-03-08 23:53, Peter Lieven wrote:
>> Hi,
>>
>> during testing of qemu-kvm-0.14.0 i can reproduce the following segfault. i
>> have seen similar crash already in 0.13.0, but had no time to debug.
>> my guess is that this segfault is related to
> Probably the best way is to make vnc stop fiddling with
> qemu_set_fd_handler2, specifically in threaded mode.
> Why does it need to set/reset the write handler all the time?
I didn't write the original code, but it's probably to avoid calling a
write handler when there is no data to write. That
On 2011-03-09 11:06, Corentin Chary wrote:
>> Probably the best way is to make vnc stop fiddling with
>> qemu_set_fd_handler2, specifically in threaded mode.
>> Why does it need to set/reset the write handler all the time?
>
> I didn't write the original code, but it's probably to avoid calling a
>> Cheap stuff is done by the main thread (cursor, etc...). The thread
>> only do framebuffer updates.
>
> And both are synchronized with a vnc-private lock only?
Yes
> The problem with this model is the non-threaded qemu execution model.
> Even if we acquire the global mutex to protect handler u
On 2011-03-09 11:14, Corentin Chary wrote:
>>> Cheap stuff is done by the main thread (cursor, etc...). The thread
>>> only do framebuffer updates.
>>
>> And both are synchronized with a vnc-private lock only?
>
> Yes
>
>> The problem with this model is the non-threaded qemu execution model.
>> E
On Tue, Mar 08, 2011 at 09:13:38AM -0800, Jordan Justen wrote:
> 2011/3/8 Gleb Natapov :
> > On Tue, Mar 08, 2011 at 07:18:09AM +, Stefan Hajnoczi wrote:
> >> > Regarding the non-volatile variables issue, I have been trying to
> >> > develop a proposal for addressing this with a change to QEMU'
From: Jes Sorensen
In case we cannot open the newly created snapshot image, try to fall
back to the original image file and continue running on that, which
should prevent the guest from aborting.
This is a corner case which can happen if the admin by mistake
specifies the snapshot file on a virt
On 2011-03-09 11:16, Peter Lieven wrote:
>
> Am 09.03.2011 um 08:37 schrieb Jan Kiszka:
>
>> On 2011-03-08 23:53, Peter Lieven wrote:
>>> Hi,
>>>
>>> during testing of qemu-kvm-0.14.0 i can reproduce the following segfault. i
>>> have seen similar crash already in 0.13.0, but had no time to debu
Am 09.03.2011 um 08:37 schrieb Jan Kiszka:
> On 2011-03-08 23:53, Peter Lieven wrote:
>> Hi,
>>
>> during testing of qemu-kvm-0.14.0 i can reproduce the following segfault. i
>> have seen similar crash already in 0.13.0, but had no time to debug.
>> my guess is that this segfault is related to
On 03/08/11 18:46, Anthony Liguori wrote:
> On 03/08/2011 10:44 AM, Jes Sorensen wrote:
>> On 03/08/11 14:42, Anthony Liguori wrote:
>> It kinda sorta covers it. The problem with that is that you then have to
>> do a string match of the return values to determine which of the cases
>> happened, whi
Am 09.03.2011 um 11:20 schrieb Jan Kiszka:
> On 2011-03-09 11:16, Peter Lieven wrote:
>>
>> Am 09.03.2011 um 08:37 schrieb Jan Kiszka:
>>
>>> On 2011-03-08 23:53, Peter Lieven wrote:
Hi,
during testing of qemu-kvm-0.14.0 i can reproduce the following segfault.
i have seen
On 03/07/11 21:10, Michael Roth wrote:
> To be able to use qemu_mod_timer() and friends to register timeout
> events for virtagent's qemu-va tool, we need to do the following:
>
> Move several blocks of code out of cpus.c that handle initialization
> of qemu's io_thread_fd and working with it via
On 03/07/11 21:10, Michael Roth wrote:
> +#define VA_PIDFILE "/var/run/qemu-va.pid"
> +#define VA_HDR_LEN_MAX 4096 /* http header limit */
> +#define VA_CONTENT_LEN_MAX 2*1024*1024 /* rpc/http send limit */
> +#define VA_CLIENT_JOBS_MAX 5 /* max client rpcs we can queue */
> +#define VA_SERVER_JOBS
The threaded VNC servers messed up with QEMU fd handlers without
any kind of locking, and that can cause some nasty race conditions.
The IO-Thread provides appropriate locking primitives to avoid that.
This patch makes CONFIG_VNC_THREAD depends on CONFIG_IO_THREAD,
and add lock and unlock calls ar
On 03/07/11 21:10, Michael Roth wrote:
> Signed-off-by: Michael Roth
> ---
> qemu-va.c | 247
> +
> 1 files changed, 247 insertions(+), 0 deletions(-)
> create mode 100644 qemu-va.c
>
> diff --git a/qemu-va.c b/qemu-va.c
> new file m
Am 09.03.2011 um 11:41 schrieb Corentin Chary:
> The threaded VNC servers messed up with QEMU fd handlers without
> any kind of locking, and that can cause some nasty race conditions.
>
> The IO-Thread provides appropriate locking primitives to avoid that.
> This patch makes CONFIG_VNC_THREAD de
>> The threaded VNC servers messed up with QEMU fd handlers without
>> any kind of locking, and that can cause some nasty race conditions.
>>
>> The IO-Thread provides appropriate locking primitives to avoid that.
>> This patch makes CONFIG_VNC_THREAD depends on CONFIG_IO_THREAD,
>> and add lock an
On Wed, Mar 9, 2011 at 10:57 AM, Corentin Chary
wrote:
>>> The threaded VNC servers messed up with QEMU fd handlers without
>>> any kind of locking, and that can cause some nasty race conditions.
>>>
>>> The IO-Thread provides appropriate locking primitives to avoid that.
>>> This patch makes CONF
On 03/09/2011 08:37 AM, Jan Kiszka wrote:
It's probably worth validating that the iothread lock is
always held when qemu_set_fd_handler2 is invoked to confirm this race
theory, adding something like
assert(pthread_mutex_trylock(&qemu_mutex) != 0);
(that's for qemu-kvm only)
Alternatively, ioha
Am 09.03.2011 um 12:25 schrieb Jan Kiszka:
> On 2011-03-09 12:05, Stefan Hajnoczi wrote:
>> On Wed, Mar 9, 2011 at 10:57 AM, Corentin Chary
>> wrote:
> The threaded VNC servers messed up with QEMU fd handlers without
> any kind of locking, and that can cause some nasty race conditions.
>
On 2011-03-09 12:05, Stefan Hajnoczi wrote:
> On Wed, Mar 9, 2011 at 10:57 AM, Corentin Chary
> wrote:
The threaded VNC servers messed up with QEMU fd handlers without
any kind of locking, and that can cause some nasty race conditions.
The IO-Thread provides appropriate locking
On 2011-03-09 12:32, Peter Lieven wrote:
>
> Am 09.03.2011 um 12:25 schrieb Jan Kiszka:
>
>> On 2011-03-09 12:05, Stefan Hajnoczi wrote:
>>> On Wed, Mar 9, 2011 at 10:57 AM, Corentin Chary
>>> wrote:
>> The threaded VNC servers messed up with QEMU fd handlers without
>> any kind of locki
On Wed, Mar 9, 2011 at 9:34 AM, Gunasekaran Dharman wrote:
> Regarding calculating host virtual address from guest virtual address, I
> think, QEMU must be doing this somehow.
> I would like to know how QEMU is handling the guest virtual address?
> It will be very much helpful if you can throw som
On 2011-03-09 11:41, Corentin Chary wrote:
> The threaded VNC servers messed up with QEMU fd handlers without
> any kind of locking, and that can cause some nasty race conditions.
>
> The IO-Thread provides appropriate locking primitives to avoid that.
> This patch makes CONFIG_VNC_THREAD depends
andrzej zaborowski wrote:
> On 24 February 2011 18:57, Juan Quintela wrote:
>> Signed-off-by: Juan Quintela
>> ---
>> hw/pxa2xx_pic.c | 52
>> 1 files changed, 20 insertions(+), 32 deletions(-)
>
> Hi Juan,
Hi andrzej
> I pushed an earlie
On 2011-03-09 12:20, Paolo Bonzini wrote:
> On 03/09/2011 08:37 AM, Jan Kiszka wrote:
>> It's probably worth validating that the iothread lock is
>> always held when qemu_set_fd_handler2 is invoked to confirm this race
>> theory, adding something like
>>
>> assert(pthread_mutex_trylock(&qemu_mutex)
Hi,
On Thu, Jan 20, 2011 at 9:05 PM, Michael S. Tsirkin wrote:
> When MSI is off, each interrupt needs to be bounced through the io
> thread when it's set/cleared, so vhost-net causes more context switches and
> higher CPU utilization than userspace virtio which handles networking in
> the same
This adds a description of the qcow2 file format to the docs/ directory.
Besides documenting what's there, which is never wrong, the document should
provide a good basis for the discussion of format extensions (called "qcow3"
in previous discussions)
Signed-off-by: Kevin Wolf
---
docs/specs/qcow
Am 09.03.2011 um 12:42 schrieb Jan Kiszka:
> On 2011-03-09 11:41, Corentin Chary wrote:
>> The threaded VNC servers messed up with QEMU fd handlers without
>> any kind of locking, and that can cause some nasty race conditions.
>>
>> The IO-Thread provides appropriate locking primitives to avoid
On 03/09/2011 04:33 AM, Jes Sorensen wrote:
On 03/07/11 21:10, Michael Roth wrote:
To be able to use qemu_mod_timer() and friends to register timeout
events for virtagent's qemu-va tool, we need to do the following:
Move several blocks of code out of cpus.c that handle initialization
of qemu's
On 03/09/11 14:04, Michael Roth wrote:
> On 03/09/2011 04:33 AM, Jes Sorensen wrote:
>>> diff --git a/qemu-ioh.c b/qemu-ioh.c
>>> index cc71470..5c3f94c 100644
>>> --- a/qemu-ioh.c
>>> +++ b/qemu-ioh.c
>>> @@ -113,3 +117,94 @@ void qemu_process_fd_handlers2(void
>>> *ioh_record_list, const fd_set *
On Wed, Mar 9, 2011 at 12:30 PM, Kevin Wolf wrote:
> This adds a description of the qcow2 file format to the docs/ directory.
> Besides documenting what's there, which is never wrong, the document should
> provide a good basis for the discussion of format extensions (called "qcow3"
> in previous d
On 03/09/2011 02:24 AM, Lai Jiangshan wrote:
sendkey is a very good command for human using it in their monitor,
but it is not a good idea to port it to qmp, because qmp is a machine
protocol. So we introduce keydown and keyup command for qmp, they
simulate the events that keyboard send to the sy
On 03/09/2011 02:51 AM, Avi Kivity wrote:
On 03/08/2011 09:19 PM, Anthony Liguori wrote:
Both the guest and the management agent (and both can listen for
events). I don't see why guest->qemu RPC is problematic for
migration - at least when qemu terminates it.
If it's terminated in QEMU, it'
On 03/09/2011 03:25 AM, Kevin Wolf wrote:
Am 08.03.2011 16:50, schrieb Chris Wright:
QAPI merge plans
- should be 100% back compat
- qmp moved over
- hmp moved over
- 1st pass, core infrastructure (includes test framework)
- 2nd pass, command conversion
- 3rd pass, more controversial bits
- adds
On 03/09/2011 03:12 PM, Anthony Liguori wrote:
On 03/09/2011 02:51 AM, Avi Kivity wrote:
On 03/08/2011 09:19 PM, Anthony Liguori wrote:
Both the guest and the management agent (and both can listen for
events). I don't see why guest->qemu RPC is problematic for
migration - at least when qemu t
On 03/09/2011 04:20 AM, jes.soren...@redhat.com wrote:
From: Jes Sorensen
In case we cannot open the newly created snapshot image, try to fall
back to the original image file and continue running on that, which
should prevent the guest from aborting.
This is a corner case which can happen if th
On 03/09/2011 04:38 AM, Jes Sorensen wrote:
On 03/07/11 21:10, Michael Roth wrote:
+#define VA_PIDFILE "/var/run/qemu-va.pid"
+#define VA_HDR_LEN_MAX 4096 /* http header limit */
+#define VA_CONTENT_LEN_MAX 2*1024*1024 /* rpc/http send limit */
+#define VA_CLIENT_JOBS_MAX 5 /* max client rpcs we
The threaded VNC servers messed up with QEMU fd handlers without
any kind of locking, and that can cause some nasty race conditions.
The IO-Thread provides appropriate locking primitives to avoid that.
This patch makes CONFIG_VNC_THREAD depends on CONFIG_IO_THREAD,
and add lock and unlock calls ar
In hw/xen_disk.c, async writing ioreq is leaked when
ioreq->req.nr_segments==0, because `aio_inflight` flag is not released
properly (skipped by misplaced "break").
Signed-off-by: Feiran Zheng
---
hw/xen_disk.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/xen_disk
On 03/07/2011 03:41 PM, Anthony Liguori wrote:
On 03/07/2011 07:35 AM, Stefan Hajnoczi wrote:
On Mon, Mar 7, 2011 at 1:22 AM, Anthony Liguori
wrote:
diff --git a/qmp-schema.json b/qmp-schema.json
index e69de29..b343f5e 100644
--- a/qmp-schema.json
+++ b/qmp-schema.json
@@ -0,0 +1,38 @@
+# *-*-
On 03/07/2011 03:23 AM, Anthony Liguori wrote:
This is needed for libqmp to support events. put-event is used to disconnect
from signals.
Signed-off-by: Anthony Liguori
diff --git a/qmp-schema.json b/qmp-schema.json
index 3f2dd4e..a13885f 100644
--- a/qmp-schema.json
+++ b/qmp-schema.json
@@ -
From: Jes Sorensen
client_migrate_info was put into qmp-commands.hx in the middle of
migrate_set_speed, between the command and it's description. In
addition client_migrate_info put the description before the command
itself, which is the wrong order.
Signed-off-by: Jes Sorensen
---
qmp-command
On 03/07/2011 03:22 AM, Anthony Liguori wrote:
This is used internally by QMP. It's also a pretty good example of a typical
command conversion.
+##
+{ 'VersionInfo': {'qemu': {'major': 'int', 'minor': 'int', 'micro': 'int'},
+ 'package': 'str'} }
+
+##
+# @query-version:
+#
+#
On 03/05/2011 07:07 PM, Jan Kiszka wrote:
On 2011-03-05 18:14, Paolo Bonzini wrote:
It is purely for icount-based virtual timers.
How about renaming the function to clarify its scope?
Will do.
Paolo
On Wed, Mar 9, 2011 at 1:21 PM, Corentin Chary wrote:
> The threaded VNC servers messed up with QEMU fd handlers without
> any kind of locking, and that can cause some nasty race conditions.
>
> The IO-Thread provides appropriate locking primitives to avoid that.
> This patch makes CONFIG_VNC_THRE
On 03/09/2011 07:28 AM, Avi Kivity wrote:
On 03/07/2011 03:41 PM, Anthony Liguori wrote:
On 03/07/2011 07:35 AM, Stefan Hajnoczi wrote:
On Mon, Mar 7, 2011 at 1:22 AM, Anthony
Liguori wrote:
diff --git a/qmp-schema.json b/qmp-schema.json
index e69de29..b343f5e 100644
--- a/qmp-schema.json
+++
Hi all,
This may come late in the discussion, but, has OVMF been tested with Mac OS X?
A decent Intel Macintosh emulation requires of course EFI + HFS.
Regards,
Natalia Portillo
El 09/03/2011, a las 05:34, Jordan Justen escribió:
> On Tue, Mar 8, 2011 at 18:23, Kevin O'Connor wrote:
>> On Tue
On 03/09/2011 07:31 AM, Avi Kivity wrote:
On 03/07/2011 03:23 AM, Anthony Liguori wrote:
This is needed for libqmp to support events. put-event is used to
disconnect
from signals.
Signed-off-by: Anthony Liguori
diff --git a/qmp-schema.json b/qmp-schema.json
index 3f2dd4e..a13885f 100644
---
On 03/09/2011 07:14 AM, Avi Kivity wrote:
On 03/09/2011 03:12 PM, Anthony Liguori wrote:
On 03/09/2011 02:51 AM, Avi Kivity wrote:
On 03/08/2011 09:19 PM, Anthony Liguori wrote:
Both the guest and the management agent (and both can listen for
events). I don't see why guest->qemu RPC is proble
On 03/09/2011 02:21 PM, Corentin Chary wrote:
The threaded VNC servers messed up with QEMU fd handlers without
any kind of locking, and that can cause some nasty race conditions.
The IO-Thread provides appropriate locking primitives to avoid that.
This patch makes CONFIG_VNC_THREAD depends on CO
On 03/09/2011 07:14 AM, Avi Kivity wrote:
On 03/09/2011 03:12 PM, Anthony Liguori wrote:
On 03/09/2011 02:51 AM, Avi Kivity wrote:
On 03/08/2011 09:19 PM, Anthony Liguori wrote:
Both the guest and the management agent (and both can listen for
events). I don't see why guest->qemu RPC is problem
Am 09.03.2011 14:08, schrieb Stefan Hajnoczi:
> On Wed, Mar 9, 2011 at 12:30 PM, Kevin Wolf wrote:
>> This adds a description of the qcow2 file format to the docs/ directory.
>> Besides documenting what's there, which is never wrong, the document should
>> provide a good basis for the discussion o
On 03/09/2011 03:51 PM, Anthony Liguori wrote:
{ execute: 'write-keystore' arguments: { 'key': 'foo', 'value':
'bar' } }
This is coming from the guest?
Yes.
So what about:
{ 'KeyStore': { '*foo': 'str', '*otherkey': 'str' } }
[ 'guest-write-keystore', { 'keystore': 'KeyStore' }, 'none' ]
On 03/09/2011 03:44 PM, Anthony Liguori wrote:
Yeah, it's only loosely JSON as I don't use a JSON parser.
Goes kind of against all the buzzwords you're letting fly here...
The schema defines arguments in a dictionary because in QMP, the
argument order doesn't matter. But the argument order
On 03/07/2011 09:10 PM, Michael Roth wrote:
This allows us to implement an i/o loop outside of vl.c that can
interact with objects that use qemu_set_fd_handler()
I must say I really dislike the patches 1..3. It's _really_ getting the
QEMU NIH worse. While it is not really possible to get a n
On 03/09/2011 03:48 PM, Anthony Liguori wrote:
+[ 'put-event', {'tag': 'int'}, {}, 'none' ]
Why is tag an int?
+##
It's a handle so the type doesn't matter as long as I can make sure
values are unique. ints are easier to work with because they don't
require memory allocation.
I think it'
On Wed, Mar 9, 2011 at 1:51 PM, Paolo Bonzini wrote:
> On 03/09/2011 02:21 PM, Corentin Chary wrote:
>>
>> The threaded VNC servers messed up with QEMU fd handlers without
>> any kind of locking, and that can cause some nasty race conditions.
>>
>> The IO-Thread provides appropriate locking primit
On 03/07/2011 09:10 PM, Michael Roth wrote:
+
+/* XXX: fd_read_poll should be suppressed, but an API change is
+ necessary in the character devices to suppress fd_can_read(). */
+int qemu_set_fd_handler3(void *ioh_record_list,
+ int fd,
+ IOCanRea
On 03/09/2011 07:58 AM, Paolo Bonzini wrote:
On 03/07/2011 09:10 PM, Michael Roth wrote:
This allows us to implement an i/o loop outside of vl.c that can
interact with objects that use qemu_set_fd_handler()
I must say I really dislike the patches 1..3. It's _really_ getting the
QEMU NIH worse.
On 03/09/2011 07:51 AM, Avi Kivity wrote:
On 03/09/2011 03:44 PM, Anthony Liguori wrote:
Yeah, it's only loosely JSON as I don't use a JSON parser.
Goes kind of against all the buzzwords you're letting fly here...
The schema defines arguments in a dictionary because in QMP, the
argument or
On 03/09/2011 07:36 AM, Avi Kivity wrote:
On 03/07/2011 03:22 AM, Anthony Liguori wrote:
This is used internally by QMP. It's also a pretty good example of a
typical
command conversion.
+##
+{ 'VersionInfo': {'qemu': {'major': 'int', 'minor': 'int', 'micro':
'int'},
+ 'pack
On 03/09/2011 07:55 AM, Avi Kivity wrote:
On 03/09/2011 03:51 PM, Anthony Liguori wrote:
{ execute: 'write-keystore' arguments: { 'key': 'foo', 'value':
'bar' } }
This is coming from the guest?
Yes.
So what about:
{ 'KeyStore': { '*foo': 'str', '*otherkey': 'str' } }
[ 'guest-write-keys
On 03/09/2011 07:58 AM, Avi Kivity wrote:
On 03/09/2011 03:48 PM, Anthony Liguori wrote:
+[ 'put-event', {'tag': 'int'}, {}, 'none' ]
Why is tag an int?
+##
It's a handle so the type doesn't matter as long as I can make sure
values are unique. ints are easier to work with because they don'
On Wed, Mar 9, 2011 at 1:55 PM, Kevin Wolf wrote:
> Am 09.03.2011 14:08, schrieb Stefan Hajnoczi:
>> On Wed, Mar 9, 2011 at 12:30 PM, Kevin Wolf wrote:
>>> This adds a description of the qcow2 file format to the docs/ directory.
>>> Besides documenting what's there, which is never wrong, the docu
On 03/09/2011 07:58 AM, Paolo Bonzini wrote:
On 03/07/2011 09:10 PM, Michael Roth wrote:
This allows us to implement an i/o loop outside of vl.c that can
interact with objects that use qemu_set_fd_handler()
I must say I really dislike the patches 1..3. It's _really_ getting
the QEMU NIH wors
The following kernel panic occurs when the RHEL6 installer starts on
qemu.git/master:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [] floppy_ready+0xfb/0x730 [floppy]
For full details see http://pastebin.com/SYE5A6LA.
git-bisect revealed that the following commit causes th
On 03/09/2011 04:11 PM, Anthony Liguori wrote:
(just picking on a patch that has a bit of schema in it)
If you want to see more of the schema in action
http://repo.or.cz/w/qemu/aliguori.git/blob/refs/heads/glib:/qmp-schema.json
Thanks. Something a little worrying is the reliance on capital
On 03/09/2011 03:11 PM, Michael Roth wrote:
In the context of virtagent I would agree. The only complication there
being that a large part of the event-driven code (the async read/write
handlers for instance) is shared between virtagent and the host.
What exactly? The dependencies in 16/16 gi
On 03/09/2011 07:58 AM, Paolo Bonzini wrote:
On 03/07/2011 09:10 PM, Michael Roth wrote:
This allows us to implement an i/o loop outside of vl.c that can
interact with objects that use qemu_set_fd_handler()
I must say I really dislike the patches 1..3. It's _really_ getting
the QEMU NIH wors
On Wed, 9 Mar 2011, Feiran Zheng wrote:
> In hw/xen_disk.c, async writing ioreq is leaked when
> ioreq->req.nr_segments==0, because `aio_inflight` flag is not released
> properly (skipped by misplaced "break").
>
> Signed-off-by: Feiran Zheng
Acked-by: Stefano Stabellini
On 03/09/2011 08:37 AM, Avi Kivity wrote:
On 03/09/2011 04:11 PM, Anthony Liguori wrote:
(just picking on a patch that has a bit of schema in it)
If you want to see more of the schema in action
http://repo.or.cz/w/qemu/aliguori.git/blob/refs/heads/glib:/qmp-schema.json
Thanks. Something a
On 03/09/2011 03:40 PM, Anthony Liguori wrote:
I must say I really dislike the patches 1..3. It's _really_ getting
the QEMU NIH worse. While it is not really possible to get a new
shiny mainloop infrastructure in QEMU like snapping fingers (and I'm
not sure the glib mainloop will ever happen t
On Wed, Mar 9, 2011 at 2:42 PM, Stefano Stabellini
wrote:
> On Wed, 9 Mar 2011, Feiran Zheng wrote:
>> In hw/xen_disk.c, async writing ioreq is leaked when
>> ioreq->req.nr_segments==0, because `aio_inflight` flag is not released
>> properly (skipped by misplaced "break").
>>
>> Signed-off-by: Fei
On 03/09/2011 08:38 AM, Paolo Bonzini wrote:
On 03/09/2011 03:11 PM, Michael Roth wrote:
In the context of virtagent I would agree. The only complication there
being that a large part of the event-driven code (the async read/write
handlers for instance) is shared between virtagent and the host.
On 03/09/2011 04:01 PM, Michael Roth wrote:
These objs: virtagent.o virtagent-server.o virtagent-common.o
virtagent-transport.o virtagent-manager.o
Are shared by qemu and qemu-va.
Okay, that's what I missed. Then I guess it's a pity but there's a good
reason.
It seems like a more general o
From: Jes Sorensen
Add QMP bits for snapshot_blkdev_sync command. This is the same as
snapshot_blkdev in the human monitor, but added _sync to the name to
make it explicit that the command is synchronous and leave space for a
future async version.
Signed-off-by: Jes Sorensen
---
qmp-commands.h
On 03/09/2011 08:45 AM, Paolo Bonzini wrote:
On 03/09/2011 03:40 PM, Anthony Liguori wrote:
I must say I really dislike the patches 1..3. It's _really_ getting
the QEMU NIH worse. While it is not really possible to get a new
shiny mainloop infrastructure in QEMU like snapping fingers (and I'm
On 03/09/2011 09:37 AM, jes.soren...@redhat.com wrote:
From: Jes Sorensen
Add QMP bits for snapshot_blkdev_sync command. This is the same as
snapshot_blkdev in the human monitor, but added _sync to the name to
make it explicit that the command is synchronous and leave space for a
future async ve
Am 09.03.2011 14:19, schrieb Feiran Zheng:
> In hw/xen_disk.c, async writing ioreq is leaked when
> ioreq->req.nr_segments==0, because `aio_inflight` flag is not released
> properly (skipped by misplaced "break").
>
> Signed-off-by: Feiran Zheng
Thanks, applied to the block branch.
Kevin
1 - 100 of 147 matches
Mail list logo
