At init, qemu_chr_reset is always called with initial_reset_issued set to 1.
So checking for it to be set is not necessary.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
qemu-char.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/qemu-char.c b/qemu-char.c
index
The char event RESET is emitted when a char device is opened.
Give it a better name.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
gdbstub.c |2 +-
hw/baum.c |2 +-
hw/usb-serial.c |2 +-
monitor.c |2 +-
qemu-char.c |2 +-
qemu-char.h |2
.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
console.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/console.c b/console.c
index 9bbef59..a4e0d64 100644
--- a/console.c
+++ b/console.c
@@ -1403,6 +1403,7 @@ CharDriverState *text_console_init(QemuOpts *opts
The OPENED event gets sent also when qemu resets its state initially.
The consumers of the event aren't interested in receiving this event
on reset.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
qemu-char.c |7 ++-
qemu-char.h |2 ++
2 files changed, 8 insertions(+), 1 deletions
://fedorapeople.org/gitweb?p=amitshah/public_git/test-virtserial.git
These patches are based on top of the char patches I've sent
previously.
Amit Shah (2):
virtio-console: Add a virtio-serial bus, support for multiple ports
virtio-console: Add a new virtserialport device for generic serial
port
From: Gerd Hoffmann kra...@redhat.com
Signed-off-by: Gerd Hoffmann kra...@redhat.com
Signed-off-by: Amit Shah amit.s...@redhat.com
---
hw/qdev-properties.c | 28
hw/qdev.h|4
2 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/hw
-by: Amit Shah amit.s...@redhat.com
---
Makefile.target|2 +-
hw/pc.c|9 -
hw/ppc440_bamboo.c |7 -
hw/qdev.c |8 +-
hw/virtio-console.c| 180 +---
hw/virtio-console.h| 19 --
hw/virtio-pci.c|8 +-
hw/virtio
://www.linux-kvm.org/page/VMchannel_Requirements
Signed-off-by: Amit Shah amit.s...@redhat.com
---
hw/virtio-console.c | 38 ++
1 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/hw/virtio-console.c b/hw/virtio-console.c
index ef32820..fec346c 100644
On (Tue) Oct 20 2009 [10:51:30], Gerd Hoffmann wrote:
@@ -107,3 +107,41 @@ static void virtcon_register(void)
virtio_serial_port_qdev_register(virtcon_info);
}
device_init(virtcon_register)
+static VirtIOSerialPortInfo virtserial_port_info = {
+.qdev.name = virtserialport,
On (Tue) Oct 20 2009 [10:56:40], Gerd Hoffmann wrote:
Hi,
This patch series fixes a few problems since the last send, mainly in
the save/restore code and a few bugs shown by the automated test suite
(located in a separate git repo, link below).
A bit hard to review in this form,
On (Tue) Oct 20 2009 [12:08:06], Richard W.M. Jones wrote:
On Tue, Oct 20, 2009 at 12:43:44PM +0530, Amit Shah wrote:
DEF(virtioconsole, HAS_ARG, QEMU_OPTION_virtiocon, \
-virtioconsole c\n \
-set virtio console\n)
+define virtio console\n
On (Tue) Oct 20 2009 [13:54:33], Dor Laor wrote:
On 10/20/2009 09:13 AM, Amit Shah wrote:
Hello,
This patch series fixes a few problems since the last send, mainly in
the save/restore code and a few bugs shown by the automated test suite
(located in a separate git repo, link below
On (Tue) Oct 20 2009 [13:05:59], Richard W.M. Jones wrote:
On Tue, Oct 20, 2009 at 05:31:23PM +0530, Amit Shah wrote:
How about (deprecated)? (We need to have this in some general policy of
deprecating command-line options.)
No, the important thing is that we can detect somehow
On (Tue) Oct 20 2009 [16:02:16], Gerd Hoffmann wrote:
On 10/20/09 11:48, Amit Shah wrote:
On (Tue) Oct 20 2009 [10:51:30], Gerd Hoffmann wrote:
@@ -107,3 +107,41 @@ static void virtcon_register(void)
virtio_serial_port_qdev_register(virtcon_info);
}
device_init(virtcon_register
On (Mon) Oct 19 2009 [09:18:19], Anthony Liguori wrote:
+ * This work is licensed under the terms of the GNU GPL, version 2. See
+ * the COPYING file in the top-level directory.
+ *
+ * Copyright IBM, Corp. 2009
+ *
+ * Authors:
+ * Anthony Liguori aligu...@us.ibm.com
+ *
+ * This
On (Thu) Oct 22 2009 [09:01:48], Anthony Liguori wrote:
Amit Shah wrote:
On (Mon) Oct 19 2009 [09:18:19], Anthony Liguori wrote:
+ * This work is licensed under the terms of the GNU GPL, version 2. See
+ * the COPYING file in the top-level directory.
+ *
+ * Copyright IBM, Corp. 2009
On (Sat) Oct 24 2009 [12:36:54], Jan Kiszka wrote:
Amit Shah wrote:
The OPENED event gets sent also when qemu resets its state initially.
The consumers of the event aren't interested in receiving this event
on reset.
The monitor was. Now its initial prompt on activation is broken
On (Mon) Oct 26 2009 [08:40:12], Jan Kiszka wrote:
Amit Shah wrote:
On (Sat) Oct 24 2009 [12:36:54], Jan Kiszka wrote:
Amit Shah wrote:
The OPENED event gets sent also when qemu resets its state initially.
The consumers of the event aren't interested in receiving this event
on reset
that are presented here from the
testsuite at
http://fedorapeople.org/gitweb?p=amitshah/public_git/test-virtserial.git
The testsuite tests for host-guest interaction as well as qemu
chardev-virtioserial interaction.
Amit Shah (2):
virtio-console: Add a virtio-serial bus, support for multiple
://www.linux-kvm.org/page/VMchannel_Requirements
Signed-off-by: Amit Shah amit.s...@redhat.com
---
hw/virtio-console.c | 38 ++
1 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/hw/virtio-console.c b/hw/virtio-console.c
index a14133b..c27e556 100644
-by: Amit Shah amit.s...@redhat.com
---
Makefile.target|2 +-
hw/pc.c|9 -
hw/ppc440_bamboo.c |7 -
hw/qdev.c |8 +-
hw/virtio-console.c| 180 +---
hw/virtio-console.h| 19 --
hw/virtio-pci.c|8 +-
hw/virtio
On (Mon) Oct 26 2009 [21:15:57], Jan Kiszka wrote:
However, with the qcow2 synchronous patch, the monitor prompt doesn't
come up again -- which shows there is a problem with the way the bhs
work and also the initial resets.
Then the qcow2 patch is already in? At least applying your patch
On (Tue) Oct 27 2009 [09:40:27], Kevin Wolf wrote:
All that said, I'm ok with reverting that patch now till I find some
kind of a solution to this.
Which patch do you want to revert? You're aware that the qcow2 patch is
a data corruption fix?
Ah, no. Reverting my patch that causes this
On (Tue) Oct 27 2009 [09:04:50], Anthony Liguori wrote:
Amit Shah wrote:
On (Tue) Oct 27 2009 [09:40:27], Kevin Wolf wrote:
All that said, I'm ok with reverting that patch now till I find some
kind of a solution to this.
Which patch do you want to revert? You're aware
A bus may have hotplugging enabled but not have the 'unplug'
callback defined, which would lead to a crash on trying to
unplug a device on the bus.
Fix by checking if the callback is valid
Signed-off-by: Amit Shah amit.s...@redhat.com
---
hw/qdev.c |5 +
1 files changed, 5 insertions
A bus may have hotplugging enabled but not have the 'unplug'
callback defined, which would lead to a crash on trying to
unplug a device on the bus.
Fix by introducing an assert to check if the callback is valid.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
hw/qdev.c |2 ++
1 files
1k is too less; at least send out 4k of data from a chardev.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
qemu-char.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/qemu-char.c b/qemu-char.c
index 0fd402c..34c0a63 100644
--- a/qemu-char.c
+++ b/qemu-char.c
On (Mon) Nov 02 2009 [21:59:58], Amit Shah wrote:
1k is too less; at least send out 4k of data from a chardev.
This one only touches unix/tcp sockets; the others use a 1k buffer as
well; I'll send a new patch that converts all the users to a consistent
buffer size.
Signed-off-by: Amit Shah
On (Mon) Nov 02 2009 [10:52:02], Anthony Liguori wrote:
Amit Shah wrote:
1k is too less; at least send out 4k of data from a chardev.
Why is 1k too small?
Definitely depends on the apps that pump in the data. If an app has data
to pump, it will keep pumping as much data as possible (eg
Hello,
These patches, all independent of each other, make the char backend a
little better by removing the initial_reset handling that's unnecessary,
bump up the amount of data that's sent per write() call to 4k from the
current 1k and also renames the generic char open() command to reflect
is to allocate s-max_size bytes from
the heap on each call (which is the number returned by the
backend from the can_read call).
This is an intermediate step to bump up the bytes written in
each call to 4k.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
qemu-char.c | 14 --
1 files
The initial_reset sent to chardevs doesn't do much other than setting
a bool to true. Char devices are interested in the open event and
that gets sent whenever the device is opened.
Moreover, the reset logic breaks as and when qemu's bh scheduling
changes.
Signed-off-by: Amit Shah amit.s
This function sends out the OPENED event to backends that
have drive the chardevs. The 'reset' is now a historical
artifact and we can now just call the function for what it
is.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
console.c |2 +-
hw/baum.c |2 +-
qemu-char.c | 22
On (Tue) Nov 03 2009 [18:08:57], Jan Kiszka wrote:
Amit Shah wrote:
The initial_reset sent to chardevs doesn't do much other than setting
a bool to true. Char devices are interested in the open event and
that gets sent whenever the device is opened.
Have you checked with the monitor
On (Tue) Nov 03 2009 [23:25:52], Amit Shah wrote:
On (Tue) Nov 03 2009 [18:08:57], Jan Kiszka wrote:
Amit Shah wrote:
The initial_reset sent to chardevs doesn't do much other than setting
a bool to true. Char devices are interested in the open event and
that gets sent whenever
On (Tue) Nov 03 2009 [19:53:43], Jan Kiszka wrote:
Amit Shah wrote:
On (Tue) Nov 03 2009 [23:25:52], Amit Shah wrote:
On (Tue) Nov 03 2009 [18:08:57], Jan Kiszka wrote:
Amit Shah wrote:
The initial_reset sent to chardevs doesn't do much other than setting
a bool to true. Char devices
On (Wed) Nov 04 2009 [10:39:39], Jan Kiszka wrote:
Amit Shah wrote:
On (Tue) Nov 03 2009 [19:53:43], Jan Kiszka wrote:
Amit Shah wrote:
On (Tue) Nov 03 2009 [23:25:52], Amit Shah wrote:
On (Tue) Nov 03 2009 [18:08:57], Jan Kiszka wrote:
Amit Shah wrote:
The initial_reset sent
On (Mon) Nov 16 2009 [17:58:22], Ian Molton wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gerd Hoffmann wrote:
Maybe ...
-chardev socket,id=egd,host=egd.domain.tld,port=whatever
-device virtio-rng,chardev=egd
I've had a go at modifying virtio-console.c to use these
On (Tue) Nov 17 2009 [11:10:32], Ian Molton wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Amit Shah wrote:
(Any reason to take this off-list?)
None other than hitting reply rather than reply-all. CCing list once
more :-)
Either way, you still need to specify the properties
On (Wed) Nov 18 2009 [16:17:02], Markus Armbruster wrote:
Luiz Capitulino lcapitul...@redhat.com writes:
@@ -176,8 +177,7 @@ DeviceState *qdev_device_add(QemuOpts *opts)
/* find driver */
info = qdev_find_info(NULL, driver);
if (!info) {
-qemu_error(Device \%s\
On (Wed) Nov 18 2009 [10:42:59], Kevin Wolf wrote:
Signed-off-by: Kevin Wolf kw...@redhat.com
---
qemu-io.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/qemu-io.c b/qemu-io.c
index cac72e9..c84b361 100644
--- a/qemu-io.c
+++ b/qemu-io.c
@@ -129,7
net.c used a constant to signify no MSI vectors were specified. Extend
that to all qdev devices.
Signed-off-by: Amit Shah amit.s...@redhat.com
Reported-by: Michael S. Tsirkin m...@redhat.com
---
hw/qdev.c |2 +-
hw/qdev.h |4
net.c |6 --
net.h |3 ---
4 files
Use the named constant instead of -1.
Signed-off-by: Amit Shah amit.s...@redhat.com
Reported-by: Michael S. Tsirkin m...@redhat.com
---
hw/virtio-pci.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
index bcd40f7..799f664 100644
Hello,
This series fixes a compile error and adds 0.12 and 0.13 machine
types, disabling newer virtio-serial features for 0.12.
Note: The name for the machine type changes from s390-virtio to
s390-virtio-vXX, this may not be compatible for 0.12.
Amit Shah (3):
s390-virtio: Fix compile error
Add a 0.12 s390-virtio machine type for compatibility with older
versions.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
hw/s390-virtio.c | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/hw/s390-virtio.c b/hw/s390-virtio.c
index 3582728..a3cbfb6 100644
Disable the MULTIPORT feature and MSI vectors for the 0.12 machine
types; those features are added only for 0.13 onwards.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
hw/s390-virtio.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/hw/s390-virtio.c b/hw
Commit 428c149b0be790b440e1cbee185b152cdb22feec modified the argument
that virtio_blk_init takes. Update the s390 bus code that calls this
function.
Signed-off-by: Amit Shah amit.s...@redhat.com
CC: Christoph Hellwig h...@lst.de
---
hw/s390-virtio-bus.c |2 +-
1 files changed, 1 insertions
Add a 0.12 machine type for compatibility with older versions. Mark the
default one as 0.13.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
hw/ppc440_bamboo.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/hw/ppc440_bamboo.c b/hw/ppc440_bamboo.c
index
Disable the MULTIPORT feature and MSI vectors for the 0.12 machine
types; those features are added only for 0.13 onwards.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
hw/ppc440_bamboo.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/hw/ppc440_bamboo.c b
Commit b5ec5ce0 broke 'make install' from non source-dir build. Fix.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
Makefile |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 296f500..14c1930 100644
--- a/Makefile
+++ b/Makefile
@@ -207,7
On (Wed) Mar 03 2010 [19:16:28], Michael S. Tsirkin wrote:
make it possible to use type without header include
Why?
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
hw/virtio.h |1 -
qemu-common.h |1 +
2 files changed, 1 insertions(+), 1 deletions(-)
diff --git
On (Thu) Mar 04 2010 [14:19:58], Michael S. Tsirkin wrote:
On Thu, Mar 04, 2010 at 05:50:19PM +0530, Amit Shah wrote:
On (Wed) Mar 03 2010 [19:16:28], Michael S. Tsirkin wrote:
make it possible to use type without header include
Why?
So that vhost.h does not need to include virtio.h
On (Wed) Mar 03 2010 [19:16:04], Michael S. Tsirkin wrote:
Add binding API to set host/guest notifiers.
Will be used by vhost.
I've already mentioned this on IRC, but I'll put it here too, for
tracking.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
hw/virtio.c |5 -
On (Wed) Mar 03 2010 [19:16:09], Michael S. Tsirkin wrote:
vhost needs physical addresses for ring and other queue fields,
so add APIs for these.
Already discussed on IRC, but mentioning here so that it doesn't get
lost:
+target_phys_addr_t virtio_queue_get_desc(VirtIODevice *vdev, int n)
+{
On (Wed) Mar 03 2010 [19:16:35], Michael S. Tsirkin wrote:
+static int vhost_virtqueue_init(struct vhost_dev *dev,
+struct VirtIODevice *vdev,
+struct vhost_virtqueue *vq,
+unsigned idx)
+{
+
On (Sat) Mar 06 2010 [21:07:57], Michael S. Tsirkin wrote:
On Fri, Mar 05, 2010 at 06:38:35PM +0530, Amit Shah wrote:
On (Wed) Mar 03 2010 [19:16:09], Michael S. Tsirkin wrote:
+
+EventNotifier *virtio_queue_guest_notifier(VirtQueue *vq)
+{
+return vq-guest_notifier
On (Sat) Mar 06 2010 [21:06:35], Michael S. Tsirkin wrote:
+r = vhost_virtqueue_set_addr(dev, vq, idx, dev-log_enabled);
+if (r 0) {
+r = -errno;
+goto fail_alloc;
+}
+if (!vdev-binding-guest_notifier || !vdev-binding-host_notifier)
{
+
MSR HID0 0300 HF idx 0
Segmentation fault
It has been broken by the following patch:
commit 977b6b91cee1132f8c7b12d22f4b273091598e44
Author: Amit Shah amit.s...@redhat.com
Date: Thu Feb 25 19:26:11 2010 +0530
ppc440_bamboo: Add 0.12 and 0.13 machine
On (Tue) Mar 09 2010 [14:15:45], Juan Quintela wrote:
Hi Amit
Hey Juan,
Checking migration, I just found this problem:
I don't know what to put there. a return -EINVAL or continue?
Looking more at the code, I am not sure what checks:
a- that bus-max_nr_ports is the same in both sides
On (Thu) Mar 11 2010 [23:45:51], Marcelo Tosatti wrote:
Wake up iothread when buffers are consumed.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
Index: qemu-ioworker/hw/virtio-serial-bus.c
===
---
On (Tue) Mar 16 2010 [19:10:58], Michael S. Tsirkin wrote:
diff --git a/hw/virtio.c b/hw/virtio.c
index 7c020a3..f54129f 100644
--- a/hw/virtio.c
+++ b/hw/virtio.c
@@ -73,6 +73,9 @@ struct VirtQueue
int inuse;
uint16_t vector;
void (*handle_output)(VirtIODevice *vdev,
On (Tue) Mar 09 2010 [20:59:58], Amit Shah wrote:
On (Tue) Mar 09 2010 [14:15:45], Juan Quintela wrote:
Hi Amit
Hey Juan,
Checking migration, I just found this problem:
I don't know what to put there. a return -EINVAL or continue?
Looking more at the code, I am not sure what
The target could be started with max_nr_ports for a virtio-serial device
lesser than what was available on the source machine. Fail the migration
in such a case.
Signed-off-by: Amit Shah amit.s...@redhat.com
Reported-by: Juan Quintela quint...@redhat.com
---
hw/virtio-serial-bus.c | 10
The number of ports on the source as well as the destination machines
should match. If they don't, it means some ports that got hotplugged on
the source aren't instantiated on the destination. Or that ports that
were hot-unplugged on the source are created on the destination.
Signed-off-by: Amit
and also hot-plug/unplug cases and fixes presented here.
Amit Shah (9):
virtio-serial-bus: save/load: Ensure target has enough ports
virtio-serial-bus: save/load: Ensure nr_ports on src and dest are
same.
virtio-serial: save/load: Ensure we have hot-plugged ports
instantiated
If some ports that were hot-plugged on the source are not available on
the destination, fail migration instead of trying to deref a NULL
pointer.
Signed-off-by: Amit Shah amit.s...@redhat.com
Reported-by: Juan Quintela quint...@redhat.com
---
hw/virtio-serial-bus.c |7 +++
1 files
expect
otherwise we risk accessing memory that we don't own.
Signed-off-by: Amit Shah amit.s...@redhat.com
CC: Avi Kivity a...@redhat.com
Reported-by: Avi Kivity a...@redhat.com
---
hw/virtio-serial-bus.c | 43 ---
1 files changed, 40 insertions(+), 3
The check for a 0-sized write request to a guest port is not necessary;
the while loop below won't be executed in this case and all will be
fine.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
hw/virtio-serial-bus.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/hw
Signed-off-by: Amit Shah amit.s...@redhat.com
---
hw/virtio-console.c|2 +-
hw/virtio-serial-bus.c |2 +-
hw/virtio-serial.h |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/virtio-console.c b/hw/virtio-console.c
index bd44ec6..e915491 100644
--- a/hw
If the host connection to a port is closed on the destination machine
after migration, when the connection was open on the source, the host
has to be informed of that.
Similar for a host connection open on the destination.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
hw/virtio-serial-bus.c
a bitmap for active
ports instead of a number indicating active ports.
This also means we can just update the config for port hot-plug and
hot-unplug.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
hw/virtio-console.c|2 +
hw/virtio-serial-bus.c | 141
On (Sun) Mar 21 2010 [15:47:53], Michael S. Tsirkin wrote:
On Fri, Mar 19, 2010 at 05:28:37PM +0530, Amit Shah wrote:
Hello,
This series fixes a few issues pointed out by Avi and Juan. Avi
pointed out we should do full scatter/gather processing of guest data
even if current (well
On (Sat) Mar 20 2010 [09:40:50], Avi Kivity wrote:
On 03/19/2010 01:58 PM, Amit Shah wrote:
+
+offset = 0;
+for (i = 0; i elem.out_num; i++) {
+memcpy(buf + offset, elem.out_sg[i].iov_base,
+ elem.out_sg[i].iov_len);
+offset
a virtio ethernet device using
model=virtio.
Which qemu version are you using?
Simultaneously, I have the a look at the code. The function pc_init1()
seem not change the network model as the option assigned.
Do you ever meet this case?
I've not seen this.
On Tue, Mar 23, 2010 at 9:08 PM, Amit
several hotplug/unplug operations and
migrations.
The ability to assign a particular port number to ports is also added
so that management software can control the placement of ports.
The other patches to handle scatter/gather for guest data and
migration fixes remain the same.
Please review.
Amit
The target could be started with max_nr_ports for a virtio-serial device
lesser than what was available on the source machine. Fail the migration
in such a case.
Signed-off-by: Amit Shah amit.s...@redhat.com
Reported-by: Juan Quintela quint...@redhat.com
---
hw/virtio-serial-bus.c | 10
The number of ports on the source as well as the destination machines
should match. If they don't, it means some ports that got hotplugged on
the source aren't instantiated on the destination. Or that ports that
were hot-unplugged on the source are created on the destination.
Signed-off-by: Amit
The check for a 0-sized write request to a guest port is not necessary;
the while loop below won't be executed in this case and all will be
fine.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
hw/virtio-serial-bus.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/hw
Signed-off-by: Amit Shah amit.s...@redhat.com
---
hw/virtio-console.c|2 +-
hw/virtio-serial-bus.c |2 +-
hw/virtio-serial.h |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/virtio-console.c b/hw/virtio-console.c
index bd44ec6..e915491 100644
--- a/hw
If some ports that were hot-plugged on the source are not available on
the destination, fail migration instead of trying to deref a NULL
pointer.
Signed-off-by: Amit Shah amit.s...@redhat.com
Reported-by: Juan Quintela quint...@redhat.com
---
hw/virtio-serial-bus.c |7 +++
1 files
to the guest
indicating addition of new ports (hot-plug) or notifying the guest of
the available ports when the guest sends us a DEVICE_READY control
message.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
hw/virtio-console.c|2 +
hw/virtio-serial-bus.c | 182
expect
otherwise we risk accessing memory that we don't own.
Signed-off-by: Amit Shah amit.s...@redhat.com
CC: Avi Kivity a...@redhat.com
Reported-by: Avi Kivity a...@redhat.com
---
hw/virtio-serial-bus.c | 44 +---
1 files changed, 41 insertions(+), 3
Current guests don't send more than one iov but it can change later.
Ensure we handle that case.
Signed-off-by: Amit Shah amit.s...@redhat.com
CC: Avi Kivity a...@redhat.com
---
hw/virtio-serial-bus.c | 22 +++---
1 files changed, 15 insertions(+), 7 deletions(-)
diff --git
On (Tue) Mar 23 2010 [20:00:19], Amit Shah wrote:
@@ -369,16 +370,23 @@ static void handle_output(VirtIODevice *vdev, VirtQueue
*vq)
* with it. Just ignore the data in that case.
*/
if (!port-info-have_data) {
-ret = 0;
goto next_buf
On (Tue) Mar 23 2010 [17:51:26], Michael S. Tsirkin wrote:
On Mon, Mar 22, 2010 at 10:48:02AM +0530, Amit Shah wrote:
On (Sat) Mar 20 2010 [09:40:50], Avi Kivity wrote:
On 03/19/2010 01:58 PM, Amit Shah wrote:
+
+offset = 0;
+for (i = 0; i elem.out_num; i
On (Wed) Mar 24 2010 [11:35:09], Liang YANG wrote:
Last, start the image Guest use qemu-system-x86_64 -net nic,
model=virtio. This time I can see virtio_net module in GuestOS, but it
doesn't work. The qemu didn't emulate the virtio net device. So I
update the code located in pc_init1(),
The target could be started with max_nr_ports for a virtio-serial device
lesser than what was available on the source machine. Fail the migration
in such a case.
Signed-off-by: Amit Shah amit.s...@redhat.com
Reported-by: Juan Quintela quint...@redhat.com
---
hw/virtio-serial-bus.c | 13
The number of ports on the source as well as the destination machines
should match. If they don't, it means some ports that got hotplugged on
the source aren't instantiated on the destination. Or that ports that
were hot-unplugged on the source are created on the destination.
Signed-off-by: Amit
If the host connection to a port is closed on the destination machine
after migration, whereas the connection was open on the source, the
guest has to be informed of that.
Similar for a host connection open on the destination.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
hw/virtio-serial
to the guest
indicating addition of new ports (hot-plug) or notifying the guest of
the available ports when the guest sends us a DEVICE_READY control
message.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
hw/virtio-console.c|2 +
hw/virtio-serial-bus.c | 181
The virtio-serial code doesn't mix declarations and definitions, so
separate them out on different lines.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
hw/virtio-serial-bus.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/hw/virtio-serial-bus.c b/hw/virtio
Signed-off-by: Amit Shah amit.s...@redhat.com
---
hw/virtio-console.c|2 +-
hw/virtio-serial-bus.c |2 +-
hw/virtio-serial.h |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/virtio-console.c b/hw/virtio-console.c
index 17b221d..6b8 100644
--- a/hw
If adding of ports or devices in the guest fails we can send out a QMP
event so that management software can deal with it.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
hw/virtio-serial-bus.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/hw/virtio-serial
The check for a 0-sized write request to a guest port is not necessary;
the while loop below won't be executed in this case and all will be
fine.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
hw/virtio-serial-bus.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/hw
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 amit.s...@redhat.com
CC: Luiz Capitulino lcapitul...@redhat.com
---
QMP/qmp
Data should be written only when ports are open.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
hw/virtio-serial-bus.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c
index efcc66c..80fbff4 100644
--- a/hw/virtio
to hold sizes, the new function is going to use
size_t types.
Later commits will add the opposite functionality -- going from an iov
to a linear buffer.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
Makefile.objs |1 +
hw/iov.c | 33
iov_to_buf() puts the buffer contents in the iov in a linearized buffer.
iov_size() gets the length of the contents in the iov.
The iov_to_buf() function is the memcpy_to_iovec() function that was
used in virtio-ballon.c.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
hw/iov.c
expect
otherwise we risk accessing memory that we don't own.
Signed-off-by: Amit Shah amit.s...@redhat.com
CC: Avi Kivity a...@redhat.com
Reported-by: Avi Kivity a...@redhat.com
---
hw/virtio-serial-bus.c | 34 +++---
1 files changed, 31 insertions(+), 3 deletions
Current guests don't send more than one iov but it can change later.
Ensure we handle that case.
Signed-off-by: Amit Shah amit.s...@redhat.com
CC: Avi Kivity a...@redhat.com
---
hw/virtio-serial-bus.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/hw/virtio
401 - 500 of 1938 matches
Mail list logo
