On Sat, 27 Mar 2010 13:33:22 +0530
Amit Shah amit.s...@redhat.com wrote:
On (Fri) Mar 26 2010 [14:52:36], Luiz Capitulino wrote:
My suggestion for the immediate term is to do what we have been doing
so
far, ie. call it VIRTIO_SERIAL_ADD. Worst case here is: we add a new way
to
Amit Shah wrote:
Without this specific thing, which is an indicator that guest has lost
state outside its control, the guest-host communication is
unreliable (even for things like cut and paste), so every app that
cares has to implement a packet framing protocol with no binary data
(to
On (Fri) Mar 26 2010 [14:52:36], Luiz Capitulino wrote:
My suggestion for the immediate term is to do what we have been doing so
far, ie. call it VIRTIO_SERIAL_ADD. Worst case here is: we add a new way
to group events which requires a new VIRTIO_SERIAL event, in this case we
could
On (Fri) Mar 26 2010 [10:05:07], Luiz Capitulino wrote:
On Fri, 26 Mar 2010 10:26:07 +0530
Amit Shah amit.s...@redhat.com wrote:
Also, if it might help, the 'guest device ready' and 'guest port ready'
QMP events can be sent on success as well (right now they're only sent
on failure).
On (Fri) Mar 26 2010 [10:14:02], Luiz Capitulino wrote:
+
+VIRTIO_SERIAL
+-
It should be VIRTIO_SERIAL_ADD.
What about other events that VIRTIO_SERIAL generates?
We don't address this problem currently, maybe an integration with qdev
will do, but I have to
On (Fri) Mar 26 2010 [05:23:25], Jamie Lokier wrote:
Amit Shah wrote:
Sure. Does the host app see an EOF on its input when that happens?
(I.e. *not* like a real serial port).
If it's an in-qemu app, it gets the guest_closed() callback. So I guess
qmp events for non-qemu apps is what
On Fri, 26 Mar 2010 18:56:20 +0530
Amit Shah amit.s...@redhat.com wrote:
On (Fri) Mar 26 2010 [10:14:02], Luiz Capitulino wrote:
+
+VIRTIO_SERIAL
+-
It should be VIRTIO_SERIAL_ADD.
What about other events that VIRTIO_SERIAL generates?
We don't
Amit Shah wrote:
Problem is we're going to have to maintain a lot of state if we're going
to provide guarantees.
One solution is to always have an in-qemu user of the serial
functionality that sits between the app and the guest and the in-qemu
user can signal to the app about such things.
On (Fri) Mar 26 2010 [11:29:03], Luiz Capitulino wrote:
On Fri, 26 Mar 2010 18:56:20 +0530
Amit Shah amit.s...@redhat.com wrote:
On (Fri) Mar 26 2010 [10:14:02], Luiz Capitulino wrote:
+
+VIRTIO_SERIAL
+-
It should be VIRTIO_SERIAL_ADD.
What
On (Fri) Mar 26 2010 [14:44:23], Jamie Lokier wrote:
Amit Shah wrote:
Problem is we're going to have to maintain a lot of state if we're going
to provide guarantees.
One solution is to always have an in-qemu user of the serial
functionality that sits between the app and the guest and
On Fri, 26 Mar 2010 20:13:09 +0530
Amit Shah amit.s...@redhat.com wrote:
On (Fri) Mar 26 2010 [11:29:03], Luiz Capitulino wrote:
On Fri, 26 Mar 2010 18:56:20 +0530
Amit Shah amit.s...@redhat.com wrote:
On (Fri) Mar 26 2010 [10:14:02], Luiz Capitulino wrote:
+
On Wed, 24 Mar 2010 20:19:28 +0530
Amit Shah amit.s...@redhat.com wrote:
When adding a port or a device to the guest fails, management software
might be interested in knowing and then cleaning up the host-side of the
port. Introduce QMP events to signal such errors.
Signed-off-by: Amit Shah
Luiz Capitulino wrote:
On Thu, 25 Mar 2010 09:17:17 +0530
Amit Shah amit.s...@redhat.com wrote:
On (Wed) Mar 24 2010 [17:34:15], Luiz Capitulino wrote:
On Wed, 24 Mar 2010 20:19:28 +0530
Amit Shah amit.s...@redhat.com wrote:
When adding a port or a device to the guest fails,
On (Thu) Mar 25 2010 [15:34:06], Luiz Capitulino wrote:
On Thu, 25 Mar 2010 09:17:17 +0530
Amit Shah amit.s...@redhat.com wrote:
On (Wed) Mar 24 2010 [17:34:15], Luiz Capitulino wrote:
On Wed, 24 Mar 2010 20:19:28 +0530
Amit Shah amit.s...@redhat.com wrote:
When adding a port
On (Fri) Mar 26 2010 [01:17:49], Jamie Lokier wrote:
Luiz Capitulino wrote:
On Thu, 25 Mar 2010 09:17:17 +0530
Amit Shah amit.s...@redhat.com wrote:
On (Wed) Mar 24 2010 [17:34:15], Luiz Capitulino wrote:
On Wed, 24 Mar 2010 20:19:28 +0530
Amit Shah amit.s...@redhat.com wrote:
On (Thu) Mar 25 2010 [15:55:41], Luiz Capitulino wrote:
On Wed, 24 Mar 2010 20:19:28 +0530
Amit Shah amit.s...@redhat.com wrote:
When adding a port or a device to the guest fails, management software
might be interested in knowing and then cleaning up the host-side of the
port. Introduce
Amit Shah wrote:
On (Fri) Mar 26 2010 [01:17:49], Jamie Lokier wrote:
Luiz Capitulino wrote:
On Thu, 25 Mar 2010 09:17:17 +0530
Amit Shah amit.s...@redhat.com wrote:
On (Wed) Mar 24 2010 [17:34:15], Luiz Capitulino wrote:
On Wed, 24 Mar 2010 20:19:28 +0530
Amit Shah
Amit Shah wrote:
Sure. Does the host app see an EOF on its input when that happens?
(I.e. *not* like a real serial port).
If it's an in-qemu app, it gets the guest_closed() callback. So I guess
qmp events for non-qemu apps is what you're looking for?
See below.
But what I really meant
On Wed, 24 Mar 2010 20:19:28 +0530
Amit Shah amit.s...@redhat.com wrote:
When adding a port or a device to the guest fails, management software
might be interested in knowing and then cleaning up the host-side of the
port. Introduce QMP events to signal such errors.
I'm completely unfamiliar
On (Wed) Mar 24 2010 [17:34:15], Luiz Capitulino wrote:
On Wed, 24 Mar 2010 20:19:28 +0530
Amit Shah amit.s...@redhat.com wrote:
When adding a port or a device to the guest fails, management software
might be interested in knowing and then cleaning up the host-side of the
port. Introduce
20 matches
Mail list logo
