[Qemu-devel] [PATCH] COLO: remove the operation to clear connection list
When hash table is created with g_hash_table_new_full(),
the free function has been registered. So it isn't necessary
since g_hash_table_remove_all() will call connection_destroy()
for each connection struct automatically.
Signed-off-by: Zhi Yong Wu <zhiyong...@ucloud.cn>
---
net/colo.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/net/colo.c b/net/colo.c
index 28ce7c8..668abb7 100644
--- a/net/colo.c
+++ b/net/colo.c
@@ -197,12 +197,6 @@ Connection *connection_get(GHashTable
*connection_track_table,
trace_colo_proxy_main("colo proxy connection hashtable full,"
" clear it");
connection_hashtable_reset(connection_track_table);
-/*
- * clear the conn_list
- */
-while (!g_queue_is_empty(conn_list)) {
-connection_destroy(g_queue_pop_head(conn_list));
-}
}
g_hash_table_insert(connection_track_table, new_key, conn);
--
1.7.1
[Qemu-devel] [PATCH] COLO: remove the operation to clear connection list
From 4439e5853f98fb4b32f346245a46414d3c7e2221 Mon Sep 17 00:00:00 2001
From: Zhi Yong Wu <zhiyong...@ucloud.cn>
Date: Tue, 24 Oct 2017 03:19:00 +0800
Subject: [PATCH] COLO: remove the operation to clear connection list
When hash table is created with g_hash_table_new_full(),
the free function has been registered. So it isn't necessary
since g_hash_table_remove_all() will call connection_destroy()
for each connection struct automatically.
Signed-off-by: Zhi Yong Wu <zhiyong...@ucloud.cn>
---
net/colo.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/net/colo.c b/net/colo.c
index 28ce7c8..668abb7 100644
--- a/net/colo.c
+++ b/net/colo.c
@@ -197,12 +197,6 @@ Connection *connection_get(GHashTable
*connection_track_table,
trace_colo_proxy_main("colo proxy connection hashtable full,"
" clear it");
connection_hashtable_reset(connection_track_table);
-/*
- * clear the conn_list
- */
-while (!g_queue_is_empty(conn_list)) {
-connection_destroy(g_queue_pop_head(conn_list));
-}
}
g_hash_table_insert(connection_track_table, new_key, conn);
--
1.7.1
Re: [Qemu-devel] [for-2.10 PATCH v4] 9pfs: local: fix fchmodat_nofollow() limitations
Tested-by: Zhi Yong Wu <zhiyong...@ucloud.cn>
Regards,
Zhi Yong Wu
At 2017-08-10 00:40:57, "Greg Kurz" <gr...@kaod.org> wrote:
>This function has to ensure it doesn't follow a symlink that could be used
>to escape the virtfs directory. This could be easily achieved if fchmodat()
>on linux honored the AT_SYMLINK_NOFOLLOW flag as described in POSIX, but
>it doesn't. There was a tentative to implement a new fchmodat2() syscall
>with the correct semantics:
>
>https://patchwork.kernel.org/patch/9596301/
>
>but it didn't gain much momentum. Also it was suggested to look at an O_PATH
>based solution in the first place.
>
>The current implementation covers most use-cases, but it notably fails if:
>- the target path has access rights equal to (openat() returns EPERM),
> => once you've done chmod() on a file, you can never chmod() again
>- the target path is UNIX domain socket (openat() returns ENXIO)
> => bind() of UNIX domain sockets fails if the file is on 9pfs
>
>The solution is to use O_PATH: openat() now succeeds in both cases, and we
>can ensure the path isn't a symlink with fstat(). The associated entry in
>"/proc/self/fd" can hence be safely passed to the regular chmod() syscall.
>
>The previous behavior is kept for older systems that don't have O_PATH.
>
>Signed-off-by: Greg Kurz <gr...@kaod.org>
>Reviewed-by: Eric Blake <ebl...@redhat.com>
>---
>v4: - fixed #if condition
>- moved out: label above #endif
>- fixed typo in changelog
>- added Eric's r-b
>
>v3: - O_PATH in a separate block of code
>- added a reference to the fchmodat2() tentative in the changelog
>
>v2: - renamed OPENAT_DIR_O_PATH to O_PATH_9P_UTIL and use it as a replacement
> for O_PATH to avoid build breaks on O_PATH-less systems
>- keep current behavior for O_PATH-less systems
>- added comments
>- TODO in 2.11: add _nofollow suffix to openat_dir() and openat_file()
>---
> hw/9pfs/9p-local.c | 43 ---
> hw/9pfs/9p-util.h | 24 +++-
> 2 files changed, 51 insertions(+), 16 deletions(-)
>
>diff --git a/hw/9pfs/9p-local.c b/hw/9pfs/9p-local.c
>index 6e478f4765ef..d9ef57d343c9 100644
>--- a/hw/9pfs/9p-local.c
>+++ b/hw/9pfs/9p-local.c
>@@ -333,17 +333,27 @@ update_map_file:
>
> static int fchmodat_nofollow(int dirfd, const char *name, mode_t mode)
> {
>+struct stat stbuf;
> int fd, ret;
>
> /* FIXME: this should be handled with fchmodat(AT_SYMLINK_NOFOLLOW).
>- * Unfortunately, the linux kernel doesn't implement it yet. As an
>- * alternative, let's open the file and use fchmod() instead. This
>- * may fail depending on the permissions of the file, but it is the
>- * best we can do to avoid TOCTTOU. We first try to open read-only
>- * in case name points to a directory. If that fails, we try write-only
>- * in case name doesn't point to a directory.
>+ * Unfortunately, the linux kernel doesn't implement it yet.
> */
>-fd = openat_file(dirfd, name, O_RDONLY, 0);
>+
>+ /* First, we clear non-racing symlinks out of the way. */
>+if (fstatat(dirfd, name, , AT_SYMLINK_NOFOLLOW)) {
>+return -1;
>+}
>+if (S_ISLNK(stbuf.st_mode)) {
>+errno = ELOOP;
>+return -1;
>+}
>+
>+/* Access modes are ignored when O_PATH is supported. We try O_RDONLY and
>+ * O_WRONLY for old-systems that don't support O_PATH.
>+ */
>+fd = openat_file(dirfd, name, O_RDONLY | O_PATH_9P_UTIL, 0);
>+#if O_PATH_9P_UTIL == 0
> if (fd == -1) {
> /* In case the file is writable-only and isn't a directory. */
> if (errno == EACCES) {
>@@ -357,6 +367,25 @@ static int fchmodat_nofollow(int dirfd, const char *name,
>mode_t mode)
> return -1;
> }
> ret = fchmod(fd, mode);
>+#else
>+/* Now we handle racing symlinks. */
>+ret = fstat(fd, );
>+if (ret) {
>+goto out;
>+}
>+if (S_ISLNK(stbuf.st_mode)) {
>+errno = ELOOP;
>+ret = -1;
>+goto out;
>+}
>+
>+{
>+char *proc_path = g_strdup_printf("/proc/self/fd/%d", fd);
>+ret = chmod(proc_path, mode);
>+g_free(proc_path);
>+}
>+out:
>+#endif
> close_preserve_errno(fd);
> return ret;
> }
>diff --git a/hw/9pfs/9p-util.h b/hw/9pfs/9p-util.h
>index 91299a24b8af..dc0d2e29aa3b 100644
>--- a/hw/9pfs/9p-util.h
>+++ b/hw/9pfs/9p-util.h
>@@ -13,6 +13,12 @@
> #ifndef QEMU_9P_UTIL_H
> #define QEMU_9P_UTIL_H
>
>+#ifdef O_PATH
>+#define O_PATH_9P_UTIL O_PATH
>+#else
>+#define O_PA
[Qemu-devel] virtio: error trying to map MMIO memory
HI Does anyone hit this issue? It seems that the addr 880037071240 isn't correct. addr 3700711c len 0001 is_write 1 addr 880037071240 len 0010 is_write 0 addr 38599000 len 1000 is_write 0 addr 3700711c len 0001 is_write 1 addr 880037071240 len 0010 is_write 0 qemu-system-x86_64: virtio: error trying to map MMIO memory -- Regards, Zhi Yong Wu
[Qemu-devel] virtio: error trying to map MMIO memory
HI Does anyone hit this issue? It seems that the addr 880037071240 isn't correct. addr 3700711c len 0001 is_write 1 addr 880037071240 len 0010 is_write 0 addr 38599000 len 1000 is_write 0 addr 3700711c len 0001 is_write 1 addr 880037071240 len 0010 is_write 0 qemu-system-x86_64: virtio: error trying to map MMIO memory -- Regards, Zhi Yong Wu
[Qemu-devel] Why *.dsl files exist in qemu project?
HI, Does anyone know why these *.dsl files exist in qemu project? Since these files are used to define some hardware resource and operation methods tables, i thought that they should be in the bios related project, right? $ls -l hw/i386/*.dsl -rw-rw-r-- 1 admin admin 3872 May 26 10:43 hw/i386/acpi-dsdt-cpu-hotplug.dsl -rw-rw-r-- 1 admin admin 1470 May 26 10:43 hw/i386/acpi-dsdt-dbug.dsl -rw-rw-r-- 1 admin admin 11284 May 26 10:43 hw/i386/acpi-dsdt.dsl -rw-rw-r-- 1 admin admin 1673 May 26 10:43 hw/i386/acpi-dsdt-hpet.dsl -rw-rw-r-- 1 admin admin 3682 May 26 10:43 hw/i386/acpi-dsdt-isa.dsl -rw-rw-r-- 1 admin admin 3826 May 26 10:43 hw/i386/acpi-dsdt-pci-crs.dsl -rw-rw-r-- 1 admin admin 16347 May 26 10:43 hw/i386/q35-acpi-dsdt.dsl -rw-rw-r-- 1 admin admin 2948 May 26 10:43 hw/i386/ssdt-mem.dsl -rw-rw-r-- 1 admin admin 10677 May 26 10:43 hw/i386/ssdt-misc.dsl -rw-rw-r-- 1 admin admin 3490 May 26 10:43 hw/i386/ssdt-pcihp.dsl -rw-rw-r-- 1 admin admin 2351 May 26 10:43 hw/i386/ssdt-proc.dsl -- Regards, Zhi Yong Wu
Re: [Qemu-devel] Why *.dsl files exist in qemu project?
On Tue, May 26, 2015 at 7:13 PM, Paolo Bonzini pbonz...@redhat.com wrote: On 26/05/2015 13:06, Zhi Yong Wu wrote: HI, Does anyone know why these *.dsl files exist in qemu project? Since these files are used to define some hardware resource and operation methods tables, i thought that they should be in the bios related project, right? $ls -l hw/i386/*.dsl -rw-rw-r-- 1 admin admin 3872 May 26 10:43 hw/i386/acpi-dsdt-cpu-hotplug.dsl -rw-rw-r-- 1 admin admin 1470 May 26 10:43 hw/i386/acpi-dsdt-dbug.dsl -rw-rw-r-- 1 admin admin 11284 May 26 10:43 hw/i386/acpi-dsdt.dsl -rw-rw-r-- 1 admin admin 1673 May 26 10:43 hw/i386/acpi-dsdt-hpet.dsl -rw-rw-r-- 1 admin admin 3682 May 26 10:43 hw/i386/acpi-dsdt-isa.dsl -rw-rw-r-- 1 admin admin 3826 May 26 10:43 hw/i386/acpi-dsdt-pci-crs.dsl -rw-rw-r-- 1 admin admin 16347 May 26 10:43 hw/i386/q35-acpi-dsdt.dsl -rw-rw-r-- 1 admin admin 2948 May 26 10:43 hw/i386/ssdt-mem.dsl -rw-rw-r-- 1 admin admin 10677 May 26 10:43 hw/i386/ssdt-misc.dsl -rw-rw-r-- 1 admin admin 3490 May 26 10:43 hw/i386/ssdt-pcihp.dsl -rw-rw-r-- 1 admin admin 2351 May 26 10:43 hw/i386/ssdt-proc.dsl These describe the hardware, which changes as QEMU gets new abilities. So QEMU is exporting the ACPI tables to the firmware. The firmware reads them. This eliminates code duplication: for example OVMF, SeaBIOS, CoreBoot and now qboot all can use the same ACPI tables and only implement a very small loader (~100 lines of code) based on fw_cfg. Cool, it is also what i thought, the common stuff exist in qemu for all bios related projects. Thanks. Paolo -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH v2 00/11] cpu: add i386 cpu hot remove support
On Fri, Feb 6, 2015 at 3:54 PM, Zhu Guihua zhugh.f...@cn.fujitsu.com wrote: On Tue, 2015-02-03 at 16:41 +0800, Zhi Yong Wu wrote: HI, Can you push the patchset to a branch on github? It will be convenient for other guys to do some tests. sorry for late reply. I had pushed into https://github.com/zhugh/qemu.git The patchset is on branch cpu-hotplug. Welcome to test, Thanks. HI, Can you let me know why device_add can't support the vCPU with 'host' model? Regards, Zhu On Wed, Jan 14, 2015 at 3:44 PM, Zhu Guihua zhugh.f...@cn.fujitsu.com wrote: This series is based on chen fan's previous i386 cpu hot remove patchset: https://lists.nongnu.org/archive/html/qemu-devel/2013-12/msg04266.html Via implementing ACPI standard methods _EJ0 in ACPI table, after Guest OS remove one vCPU online, the fireware will store removed bitmap to QEMU, then QEMU could know to notify the assigned vCPU of exiting. Meanwhile, intruduce the QOM command 'device_del' to remove vCPU from QEMU itself. The whole work is based on the new hot plug/unplug framework, ,the unplug request callback does the pre-check and send the request, unplug callback does the removal handling. This series depends on tangchen's common hot plug/unplug enhance patchset. [RESEND PATCH v1 0/5] Common unplug and unplug request cb for memory and CPU hot-unplug https://lists.nongnu.org/archive/html/qemu-devel/2015-01/msg00429.html The is the second half of the previous series: [RFC V2 00/10] cpu: add device_add foo-x86_64-cpu and i386 cpu hot remove support https://lists.nongnu.org/archive/html/qemu-devel/2014-08/msg04779.html If you want to test the series, you need to apply the 'device_add foo-x86_64-cpu' patchset first: [PATCH v3 0/7] cpu: add device_add foo-x86_64-cpu support https://lists.nongnu.org/archive/html/qemu-devel/2015-01/msg01552.html --- Changelog since v1: -rebase on the latest version. -delete patch i386/cpu: add instance finalize callback, and put it into patchset [PATCH v3 0/6] cpu: add device_add foo-x86_64-cpu support. Changelog since RFC: -splited the i386 cpu hot remove into single thread. -replaced apic_no with apic_id, so does the related stuff to make it work with arbitrary CPU hotadd. -add the icc_device_unrealize callback to handle apic unrealize. -rework on the new hot plug/unplug platform. --- Chen Fan (2): x86: add x86_cpu_unrealizefn() for cpu apic remove cpu hotplug: implement function cpu_status_write() for vcpu ejection Gu Zheng (5): acpi/cpu: add cpu hot unplug request callback function acpi/piix4: add cpu hot unplug callback support acpi/ich9: add cpu hot unplug support pc: add cpu hot unplug callback support cpus: reclaim allocated vCPU objects Zhu Guihua (4): acpi/piix4: add cpu hot unplug request callback support acpi/ich9: add cpu hot unplug request callback support pc: add cpu hot unplug request callback support acpi/cpu: add cpu hot unplug callback function cpus.c| 44 hw/acpi/cpu_hotplug.c | 88 --- hw/acpi/ich9.c| 17 ++-- hw/acpi/piix4.c | 12 +- hw/core/qdev.c| 2 +- hw/cpu/icc_bus.c | 11 + hw/i386/acpi-dsdt-cpu-hotplug.dsl | 6 ++- hw/i386/kvm/apic.c| 8 hw/i386/pc.c | 62 +-- hw/intc/apic.c| 10 + hw/intc/apic_common.c | 21 ++ include/hw/acpi/cpu_hotplug.h | 8 include/hw/cpu/icc_bus.h | 1 + include/hw/i386/apic_internal.h | 1 + include/hw/qdev-core.h| 1 + include/qom/cpu.h | 9 include/sysemu/kvm.h | 1 + kvm-all.c | 57 - target-i386/cpu.c | 46 19 files changed, 378 insertions(+), 27 deletions(-) -- 1.9.3 -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH v2 0/5] Common unplug and unplug request cb for memory and CPU hot-unplug
HI, If you can push the patchset to a branch on github, it will be convenient for other guys to do some tests. On Wed, Jan 28, 2015 at 3:45 PM, Zhu Guihua zhugh.f...@cn.fujitsu.com wrote: Memory and CPU hot unplug are both asynchronous procedures. When the unplug operation happens, unplug request cb is called first. And when guest OS finished handling unplug, unplug cb will be called to do the real removal of device. They both need pc-machine, piix4 and ich9 unplug and unplug request cb. So this patchset introduces these commom functions as part1, and memory and CPU hot-unplug will come soon as part 2 and 3. This patch-set is based on QEmu 2.2 v2: - Commit messages changes Tang Chen (5): acpi, pc: Add hotunplug request cb for pc machine. acpi, ich9: Add hotunplug request cb for ich9. acpi, pc: Add unplug cb for pc machine. acpi, ich9: Add unplug cb for ich9. acpi, piix4: Add unplug cb for piix4. hw/acpi/ich9.c | 14 ++ hw/acpi/piix4.c| 8 hw/i386/pc.c | 16 hw/isa/lpc_ich9.c | 14 -- include/hw/acpi/ich9.h | 4 5 files changed, 54 insertions(+), 2 deletions(-) -- 1.9.3 -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH v2 00/11] cpu: add i386 cpu hot remove support
HI, Can you push the patchset to a branch on github? It will be convenient for other guys to do some tests. On Wed, Jan 14, 2015 at 3:44 PM, Zhu Guihua zhugh.f...@cn.fujitsu.com wrote: This series is based on chen fan's previous i386 cpu hot remove patchset: https://lists.nongnu.org/archive/html/qemu-devel/2013-12/msg04266.html Via implementing ACPI standard methods _EJ0 in ACPI table, after Guest OS remove one vCPU online, the fireware will store removed bitmap to QEMU, then QEMU could know to notify the assigned vCPU of exiting. Meanwhile, intruduce the QOM command 'device_del' to remove vCPU from QEMU itself. The whole work is based on the new hot plug/unplug framework, ,the unplug request callback does the pre-check and send the request, unplug callback does the removal handling. This series depends on tangchen's common hot plug/unplug enhance patchset. [RESEND PATCH v1 0/5] Common unplug and unplug request cb for memory and CPU hot-unplug https://lists.nongnu.org/archive/html/qemu-devel/2015-01/msg00429.html The is the second half of the previous series: [RFC V2 00/10] cpu: add device_add foo-x86_64-cpu and i386 cpu hot remove support https://lists.nongnu.org/archive/html/qemu-devel/2014-08/msg04779.html If you want to test the series, you need to apply the 'device_add foo-x86_64-cpu' patchset first: [PATCH v3 0/7] cpu: add device_add foo-x86_64-cpu support https://lists.nongnu.org/archive/html/qemu-devel/2015-01/msg01552.html --- Changelog since v1: -rebase on the latest version. -delete patch i386/cpu: add instance finalize callback, and put it into patchset [PATCH v3 0/6] cpu: add device_add foo-x86_64-cpu support. Changelog since RFC: -splited the i386 cpu hot remove into single thread. -replaced apic_no with apic_id, so does the related stuff to make it work with arbitrary CPU hotadd. -add the icc_device_unrealize callback to handle apic unrealize. -rework on the new hot plug/unplug platform. --- Chen Fan (2): x86: add x86_cpu_unrealizefn() for cpu apic remove cpu hotplug: implement function cpu_status_write() for vcpu ejection Gu Zheng (5): acpi/cpu: add cpu hot unplug request callback function acpi/piix4: add cpu hot unplug callback support acpi/ich9: add cpu hot unplug support pc: add cpu hot unplug callback support cpus: reclaim allocated vCPU objects Zhu Guihua (4): acpi/piix4: add cpu hot unplug request callback support acpi/ich9: add cpu hot unplug request callback support pc: add cpu hot unplug request callback support acpi/cpu: add cpu hot unplug callback function cpus.c| 44 hw/acpi/cpu_hotplug.c | 88 --- hw/acpi/ich9.c| 17 ++-- hw/acpi/piix4.c | 12 +- hw/core/qdev.c| 2 +- hw/cpu/icc_bus.c | 11 + hw/i386/acpi-dsdt-cpu-hotplug.dsl | 6 ++- hw/i386/kvm/apic.c| 8 hw/i386/pc.c | 62 +-- hw/intc/apic.c| 10 + hw/intc/apic_common.c | 21 ++ include/hw/acpi/cpu_hotplug.h | 8 include/hw/cpu/icc_bus.h | 1 + include/hw/i386/apic_internal.h | 1 + include/hw/qdev-core.h| 1 + include/qom/cpu.h | 9 include/sysemu/kvm.h | 1 + kvm-all.c | 57 - target-i386/cpu.c | 46 19 files changed, 378 insertions(+), 27 deletions(-) -- 1.9.3 -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [RESEND PATCH v1 00/13] QEmu memory hot unplug support.
HI, Can you push the patchset to a branch on github? It will be convenient for other guys to do some tests. On Thu, Jan 8, 2015 at 9:06 AM, Tang Chen tangc...@cn.fujitsu.com wrote: Memory hot unplug are both asynchronize procedures. When the unplug operation happens, unplug request cb is called first. And when ghest OS finished handling unplug, unplug cb will be called to do the real removal of device. This patch-set is based on QEmu 2.2 This series depends on the following patchset. [PATCH] Common unplug and unplug request cb for memory and CPU hot-unplug. https://www.mail-archive.com/qemu-devel@nongnu.org/msg272745.html Hu Tao (2): acpi, piix4: Add memory hot unplug request support for piix4. pc, acpi bios: Add memory hot unplug interface. Tang Chen (11): acpi, mem-hotplug: Use PC_DIMM_SLOT_PROP in acpi_memory_plug_cb(). acpi, mem-hotplug: Add acpi_memory_get_slot_status_descriptor() to get MemStatus. acpi, mem-hotplug: Add acpi_memory_hotplug_sci() to rise sci for memory hotplug. acpi, mem-hotplug: Add unplug request cb for memory device. acpi, ich9: Add memory hot unplug request support for ich9. pc-dimm: Add memory hot unplug request support for pc-dimm. acpi, mem-hotplug: Add unplug cb for memory device. acpi, piix4: Add memory hot unplug support for piix4. acpi, ich9: Add memory hot unplug support for ich9. pc-dimm: Add memory hot unplug support for pc-dimm. acpi: Add hardware implementation for memory hot unplug. docs/specs/acpi_mem_hotplug.txt | 8 +++- hw/acpi/ich9.c| 20 ++-- hw/acpi/memory_hotplug.c | 97 --- hw/acpi/piix4.c | 18 ++-- hw/core/qdev.c| 2 +- hw/i386/acpi-dsdt-mem-hotplug.dsl | 11 - hw/i386/pc.c | 53 +++-- hw/i386/ssdt-mem.dsl | 5 ++ include/hw/acpi/memory_hotplug.h | 6 +++ include/hw/acpi/pc-hotplug.h | 2 + include/hw/qdev-core.h| 1 + 11 files changed, 192 insertions(+), 31 deletions(-) -- 1.8.4.2 -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH v2] libcacard: fix compile error on glib2-2.12.3-4.el5
c++ -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wold-style-definition -fstack-protector-all -I/usr/include/libpng12 -I/home/zhiyong.wzy/qemu/pixman/pixman -I/home/zhiyong.wzy/qemu/pixman/pixman -I/home/zhiyong.wzy/qemu/tests -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -g -Wl,--warn-common -m64 -g -o fsdev/virtfs-proxy-helper fsdev/virtfs-proxy-helper.o fsdev/virtio-9p-marshal.o libqemuutil.a libqemustub.a-lm -pthread -L/lib64 -lgthread-2.0 -lglib-2.0-lz -lrt -lz -luuid -lutil -lcap cc -I/home/zhiyong.wzy/qemu/tcg -I/home/zhiyong.wzy/qemu/tcg/i386 -I/home/zhiyong.wzy/qemu/linux-headers -I/home/zhiyong.wzy/qemu/linux-headers -I. -I/home/zhiyong.wzy/qemu -I/home/zhiyong.wzy/qemu/include -Ilibcacard -Ilibcacard -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wold-style-definition -fstack-protector-all -I/usr/include/libpng12 -I/home/zhiyong.wzy/qemu/pixman/pixman -I/home/zhiyong.wzy/qemu/pixman/pixman -I/home/zhiyong.wzy/qemu/tests -MMD -MP -MT libcacard/vscclient.o -MF libcacard/vscclient.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -g -c -o libcacard/vscclient.o libcacard/vscclient.c libtool --mode=link --tag=CC c++ -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wold-style-definition -fstack-protector-all -I/usr/include/libpng12 -I/home/zhiyong.wzy/qemu/pixman/pixman -I/home/zhiyong.wzy/qemu/pixman/pixman -I/home/zhiyong.wzy/qemu/tests -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -g -Wl,--warn-common -m64 -g -o vscclient libcacard/vscclient.o libcacard.la-Wc,-fstack-protector-all -lm -pthread -L/lib64 -lgthread-2.0 -lglib-2.0-lz -lrt -lz -luuid -lutil c++ -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wold-style-definition -fstack-protector-all -I/usr/include/libpng12 -I/home/zhiyong.wzy/qemu/pixman/pixman -I/home/zhiyong.wzy/qemu/pixman/pixman -I/home/zhiyong.wzy/qemu/tests -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -g -Wl,--warn-common -m64 -g -o .libs/vscclient libcacard/vscclient.o -Wl,-fstack-protector-all -pthread ./.libs/libcacard.so -lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -lpthread -ldl -L/lib64 -lm -lgthread-2.0 -lglib-2.0 -lrt -lz -luuid -lutil -Wl,--rpath -Wl,/usr/local/lib /usr/bin/ld: -f may not be used without -shared collect2: ld returned 1 exit status make: *** [vscclient] Error 1 On Tue, Sep 30, 2014 at 5:28 PM, Paolo Bonzini pbonz...@redhat.com wrote: Il 30/09/2014 11:12, Zhi Yong Wu ha scritto: diff --git a/Makefile b/Makefile index b33aaac..7cbf7dd 100644 --- a/Makefile +++ b/Makefile @@ -149,6 +149,8 @@ ifneq ($(wildcard config-host.mak),) include $(SRC_PATH)/tests/Makefile endif ifeq ($(CONFIG_SMARTCARD_NSS),y) +CFLAGS += -fPIC +LDFLAGS += $(LDFLAGS_SHARED) include $(SRC_PATH)/libcacard/Makefile endif c++ ... -m64 -g -shared -o qemu-io qemu-io.o ... So you are making all programs shared libraries? (And it would make no sense even if you only made vscclient a shared library). Can you include make V=1 output in the commit message so that we understand what is going on? Paolo -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH v2] libcacard: fix compile error on glib2-2.12.3-4.el5
On Tue, Sep 30, 2014 at 10:06 PM, Paolo Bonzini pbonz...@redhat.com wrote: Il 30/09/2014 15:57, Zhi Yong Wu ha scritto: libtool --mode=link --tag=CC c++ -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wold-style-definition -fstack-protector-all -I/usr/include/libpng12 -I/home/zhiyong.wzy/qemu/pixman/pixman -I/home/zhiyong.wzy/qemu/pixman/pixman -I/home/zhiyong.wzy/qemu/tests -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -g -Wl,--warn-common -m64 -g -o vscclient libcacard/vscclient.o libcacard.la-Wc,-fstack-protector-all -lm -pthread -L/lib64 -lgthread-2.0 -lglib-2.0-lz -lrt -lz -luuid -lutil c++ -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wold-style-definition -fstack-protector-all -I/usr/include/libpng12 -I/home/zhiyong.wzy/qemu/pixman/pixman -I/home/zhiyong.wzy/qemu/pixman/pixman -I/home/zhiyong.wzy/qemu/tests -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -g -Wl,--warn-common -m64 -g -o .libs/vscclient libcacard/vscclient.o -Wl,-fstack-protector-all -pthread ./.libs/libcacard.so -lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -lpthread -ldl -L/lib64 -lm -lgthread-2.0 -lglib-2.0 -lrt -lz -luuid -lutil -Wl,--rpath -Wl,/usr/local/lib /usr/bin/ld: -f may not be used without -shared So the problem seems to be with -Wl,-fstack-protector-all. Where does it come from? QEMU or some pkg-config file? Does it work if you configure with the --disable-stack-protector option? Yes, it can work now, i'm very suprised by how you know it is the root reason? Paolo -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH v2] libcacard: fix compile error on glib2-2.12.3-4.el5
On Tue, Sep 30, 2014 at 11:16 PM, Paolo Bonzini pbonz...@redhat.com wrote: Il 30/09/2014 17:09, Zhi Yong Wu ha scritto: So the problem seems to be with -Wl,-fstack-protector-all. Where does it come from? QEMU or some pkg-config file? Does it work if you configure with the --disable-stack-protector option? Yes, it can work now, i'm very suprised by how you know it is the root reason? Because it is the only -f option that is passed to the linker. heh, thanks. Paolo -- Regards, Zhi Yong Wu
Re: [Qemu-devel] vhost-net issue: does not survive reboot on ppc64
On Sat, Dec 21, 2013 at 11:01 PM, Alexey Kardashevskiy a...@ozlabs.ru wrote: Hi! HI, Alexey I am having a problem with virtio-net + vhost on POWER7 machine - it does not survive reboot of the guest. Can you let me login to your environment for debug? I am interested in trying to fix this issue. Steps to reproduce: 1. boot the guest 2. configure eth0 and do ping - everything works 3. reboot the guest (i.e. type reboot) 4. when it is booted, eth0 can be configured but will not work at all. The test is: ifconfig eth0 172.20.1.2 up ping 172.20.1.23 If to run tcpdump on the host's tap-id3 interface, it shows no trafic coming from the guest. If to compare how it works before and after reboot, I can see the guest doing an ARP request for 172.20.1.23 and receives the response and it does the same after reboot but the answer does not come. If to remove vhost=on, it is all good. If to try Fedora19 (v3.10-something), it all good again - works before and after reboot. And there 2 questions: 1. does anybody have any clue what might go wrong after reboot? 2. Is there any good material to read about what exactly and how vhost accelerates? My understanding is that packets from the guest to the real network are going as: 1. guest's virtio-pci-net does ioport(VIRTIO_PCI_QUEUE_NOTIFY) 2. QEMU's net/virtio-net.c calls qemu_net_queue_deliver() 3. QEMU's net/tap.c calls tap_write_packet() and this is how the host knows that there is a new packet. Thanks! This how I run QEMU: ./qemu-system-ppc64 \ -enable-kvm \ -m 2048 \ -machine pseries \ -initrd 1.cpio \ -kernel vml312_virtio_net_dbg \ -nographic \ -vga none \ -netdev tap,id=id3,ifname=tap-id3,script=ifup.sh,downscript=ifdown.sh,vhost=on \ -device virtio-net-pci,id=id4,netdev=id3,mac=C0:41:49:4b:00:00 That is bridge config: [aik@dyn232 ~]$ brctl show bridge name bridge id STP enabled interfaces brtest 8000.00145e992e88 no pin eth4 The ifup.sh script: ifconfig $1 hw ether ee:01:02:03:04:05 /sbin/ifconfig $1 up /usr/sbin/brctl addif brtest $1 -- Alexey -- Regards, Zhi Yong Wu
Re: [Qemu-devel] RFC: kvm call reschedule
On Tue, Dec 10, 2013 at 11:23 PM, Kevin Wolf kw...@redhat.com wrote: Am 10.12.2013 um 16:11 hat Juan Quintela geschrieben: Anthony can't assist this call, just in the middle of his commute. As it looks like a good idea that he can assit, can we move the call? Options so far are (his local time): - Current time is 7am His suggestions: - 6:00am (15pm CEST) - 9:00am (18pm CEST) We don't have summer time currently, so s/CEST/CET/ That is, the options are 14:00 UTC and 17:00 UTC. I can do any of them. Votes for the people that attend? As I guess he commutes everyday, moving the day will not help :p I prefer 15:00 CET (14:00 UTC). +1, but it will be perfect if it's 13:00 or 14:00 CET Kevin -- Regards, Zhi Yong Wu
Re: [Qemu-devel] RFC: kvm call reschedule
On Thu, Dec 12, 2013 at 8:53 PM, Michael S. Tsirkin m...@redhat.com wrote: On Thu, Dec 12, 2013 at 05:01:55PM +0800, Zhi Yong Wu wrote: On Tue, Dec 10, 2013 at 11:23 PM, Kevin Wolf kw...@redhat.com wrote: Am 10.12.2013 um 16:11 hat Juan Quintela geschrieben: Anthony can't assist this call, just in the middle of his commute. As it looks like a good idea that he can assit, can we move the call? Options so far are (his local time): - Current time is 7am His suggestions: - 6:00am (15pm CEST) - 9:00am (18pm CEST) We don't have summer time currently, so s/CEST/CET/ That is, the options are 14:00 UTC and 17:00 UTC. I can do any of them. Votes for the people that attend? As I guess he commutes everyday, moving the day will not help :p I prefer 15:00 CET (14:00 UTC). +1, but it will be perfect if it's 13:00 or 14:00 CET Won't that be like 4am for Anthony? ah, i suddently realize that he seems to leave austin. If yes, as i said, 15:00 CET is also OK to me. Kevin -- Regards, Zhi Yong Wu -- Regards, Zhi Yong Wu
[Qemu-devel] [PATCH] virtio-net: fix the indent
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
hw/net/virtio-net.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index b75c753..90eca9a 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -1428,7 +1428,7 @@ static NetClientInfo net_virtio_info = {
.size = sizeof(NICState),
.can_receive = virtio_net_can_receive,
.receive = virtio_net_receive,
-.cleanup = virtio_net_cleanup,
+.cleanup = virtio_net_cleanup,
.link_status_changed = virtio_net_set_link_status,
.query_rx_filter = virtio_net_query_rxfilter,
};
--
1.7.6.5
[Qemu-devel] [PATCH 4/4] net, virtio_net: replace the magic value
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
It is more appropriate to use # of queue pairs currently used by
the driver instead of a magic value.
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
drivers/net/virtio_net.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index cdc7c90..e0cb2d1 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1619,8 +1619,8 @@ static int virtnet_probe(struct virtio_device *vdev)
if (err)
goto free_stats;
- netif_set_real_num_tx_queues(dev, 1);
- netif_set_real_num_rx_queues(dev, 1);
+ netif_set_real_num_tx_queues(dev, vi-curr_queue_pairs);
+ netif_set_real_num_rx_queues(dev, vi-curr_queue_pairs);
err = register_netdev(dev);
if (err) {
--
1.7.6.5
Re: [Qemu-devel] [PATCH 4/4] net, virtio_net: replace the magic value
On Mon, Nov 18, 2013 at 5:50 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Mon, Nov 18, 2013 at 04:46:20PM +0800, Zhi Yong Wu wrote:
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
It is more appropriate to use # of queue pairs currently used by
the driver instead of a magic value.
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
I don't mind, but driver should be submitted separately
from qemu patches. As it is only patch 4/4 made it to netdev.
ok, i will sent v2. By the way, can you help take a look at the
following patches? Maybe i can send their v2 together.
[PATCH 1/3] vhost: remove the dead branch
[PATCH 2/3] vhost: adjust vhost_dev_init() to be void
[PATCH 3/3] vhost: fix the wrong log descriptions
---
drivers/net/virtio_net.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index cdc7c90..e0cb2d1 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1619,8 +1619,8 @@ static int virtnet_probe(struct virtio_device *vdev)
if (err)
goto free_stats;
- netif_set_real_num_tx_queues(dev, 1);
- netif_set_real_num_rx_queues(dev, 1);
+ netif_set_real_num_tx_queues(dev, vi-curr_queue_pairs);
+ netif_set_real_num_rx_queues(dev, vi-curr_queue_pairs);
err = register_netdev(dev);
if (err) {
--
1.7.6.5
--
Regards,
Zhi Yong Wu
Re: [Qemu-devel] [PATCH 4/4] net, virtio_net: replace the magic value
On Mon, Nov 18, 2013 at 6:15 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Mon, Nov 18, 2013 at 06:07:45PM +0800, Zhi Yong Wu wrote:
On Mon, Nov 18, 2013 at 5:50 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Mon, Nov 18, 2013 at 04:46:20PM +0800, Zhi Yong Wu wrote:
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
It is more appropriate to use # of queue pairs currently used by
the driver instead of a magic value.
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
I don't mind, but driver should be submitted separately
from qemu patches. As it is only patch 4/4 made it to netdev.
ok, i will sent v2. By the way, can you help take a look at the
following patches?
Will do.
Maybe i can send their v2 together.
Please don't, these seem to be completely unrelated.
OK, i will send it separately.
[PATCH 1/3] vhost: remove the dead branch
[PATCH 2/3] vhost: adjust vhost_dev_init() to be void
[PATCH 3/3] vhost: fix the wrong log descriptions
---
drivers/net/virtio_net.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index cdc7c90..e0cb2d1 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1619,8 +1619,8 @@ static int virtnet_probe(struct virtio_device *vdev)
if (err)
goto free_stats;
- netif_set_real_num_tx_queues(dev, 1);
- netif_set_real_num_rx_queues(dev, 1);
+ netif_set_real_num_tx_queues(dev, vi-curr_queue_pairs);
+ netif_set_real_num_rx_queues(dev, vi-curr_queue_pairs);
err = register_netdev(dev);
if (err) {
--
1.7.6.5
--
Regards,
Zhi Yong Wu
--
Regards,
Zhi Yong Wu
[Qemu-devel] [PATCH] MAINTAINERS: Add the maintainer for hub net client
From: Zhi Yong Wu wu...@linux.vnet.ibm.com Since i did a lot of work to make this feature get merged, and hope to gain some excercises about how to become a good maintainer, i'm applying for this role now and hope to get this chance, thanks. Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 77edacf..ab11f43 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -707,6 +707,14 @@ S: Maintained F: net/ T: git git://github.com/stefanha/qemu.git net +Hub Net Client +M: Zhi Yong Wu zwu.ker...@gmail.com +M: Stefan Hajnoczi stefa...@redhat.com +S: Maintained +F: net/hub.c +F: net/hub.h +T: git git://github.com/wuzhy/qemu.git hub + Network Block Device (NBD) M: Paolo Bonzini pbonz...@redhat.com S: Odd Fixes -- 1.7.11.7
Re: [Qemu-devel] [PATCH] Use qemu-project.org domain name
@@ -1,7 +1,7 @@
(RDMA: Remote Direct Memory Access)
RDMA Live Migration Specification, Version # 1
==
-Wiki: http://wiki.qemu.org/Features/RDMALiveMigration
+Wiki: http://wiki.qemu-project.org/Features/RDMALiveMigration
Github: g...@github.com:hinesmr/qemu.git, 'rdma' branch
Copyright (C) 2013 Michael R. Hines mrhi...@us.ibm.com
diff --git a/pc-bios/README b/pc-bios/README
index e404a22..06f7b33 100644
--- a/pc-bios/README
+++ b/pc-bios/README
@@ -23,7 +23,7 @@
legacy x86 software to communicate with an attached serial console as
if a video card were attached. The master sources reside in a subversion
repository at http://sgabios.googlecode.com/svn/trunk. A git mirror is
- available at git://git.qemu.org/sgabios.git.
+ available at git://git.qemu-project.org/sgabios.git.
- The PXE roms come from the iPXE project. Built with BANNER_TIME 0.
Sources available at http://ipxe.org. Vendor:Device ID - ROM mapping:
diff --git a/qemu.nsi b/qemu.nsi
index 1d57455..0dc1f52 100644
--- a/qemu.nsi
+++ b/qemu.nsi
@@ -20,7 +20,7 @@
; NSIS_WIN32_MAKENSIS
!define PRODUCT QEMU
-!define URL http://www.qemu.org/;
+!define URL http://www.qemu-project.org/;
!define UNINST_EXE $INSTDIR\qemu-uninstall.exe
!define UNINST_KEY
Software\Microsoft\Windows\CurrentVersion\Uninstall\${PRODUCT}
diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index bf5342a..38334de 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -1385,7 +1385,7 @@ sub vcs_exists {
warn($P: No supported VCS found. Add --nogit to options?\n);
warn(Using a git repository produces better results.\n);
warn(Try latest git repository using:\n);
- warn(git clone git://git.qemu.org/qemu.git\n);
+ warn(git clone git://git.qemu-project.org/qemu.git\n);
$printed_novcs = 1;
}
return 0;
diff --git a/scripts/qmp/qemu-ga-client b/scripts/qmp/qemu-ga-client
index b5f7e7c..9908f21 100755
--- a/scripts/qmp/qemu-ga-client
+++ b/scripts/qmp/qemu-ga-client
@@ -33,7 +33,7 @@
# $ qemu-ga-client fsfreeze freeze
# 2 filesystems frozen
#
-# See also: http://wiki.qemu.org/Features/QAPI/GuestAgent
+# See also: http://wiki.qemu-project.org/Features/QAPI/GuestAgent
#
import base64
diff --git a/version.rc b/version.rc
index a50d62f..d42ef62 100644
--- a/version.rc
+++ b/version.rc
@@ -13,7 +13,7 @@ FILESUBTYPE VFT2_UNKNOWN
{
BLOCK 040904E4
{
- VALUE CompanyName, http://www.qemu.org;
+ VALUE CompanyName, http://www.qemu-project.org;
VALUE FileDescription, QEMU machine emulators and tools
VALUE FileVersion, QEMU_VERSION
VALUE LegalCopyright, Copyright various authors. Released under the
GNU General Public License.
--
1.8.3.1
--
Regards,
Zhi Yong Wu
Re: [Qemu-devel] [ANNOUNCE] OSv, an new operating system for the cloud, v0.01
any doc that describes its archtecture or interval? On Tue, Sep 17, 2013 at 3:22 AM, Pekka Enberg penb...@cloudius-systems.com wrote: Hello, We're proud to announce release 0.01 of OSv, a new operating system for running applications on virtual machines. OSv is free software, released under the BSD license, and you can find it in https://github.com/cloudius-systems/osv and http://www.osv.io. To build and run OSv under KVM/QEMU, first grab the latest source code from Github: git clone g...@github.com:cloudius-systems/osv.git Then install prerequisite packages: On Fedora: yum install ant autoconf automake boost-static gcc-c++ genromfs \ libvirt libtool zfs-fuse flex bison On Debian: apt-get install libboost-all-dev genromfs zfs-fuse autoconf Make sure the zfs-fuse daemon is running: On Fedora: sudo systemctl start zfs-fuse.service sudo systemctl enable zfs-fuse.service # to have it start on reboot On Debian the daemon should be started automatically. Fetch git submodules: git submodule update --init Finally, build OSv: make external all You can then start a OSv guest under KVM/QEMU: sudo ./scripts/run.py -nv -m 2G You can SSH into the guest with: ssh admin@192.168.122.89 # password: admin The management web UI is at address: http://192.168.122.89:8080/ Alternatively, you can use prebuilt QEMU QCOW2 images of the release. Instructions how to do that are on our Wiki: https://github.com/cloudius-systems/osv/wiki/Running-OSv-under-KVM-QEMU That's it! Pekka -- 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, Zhi Yong Wu
Re: [Qemu-devel] [ANNOUNCE] OSv, an new operating system for the cloud, v0.01
Thanks for your pointers, Dor. On Wed, Sep 18, 2013 at 8:59 PM, Dor Laor d...@cloudius-systems.com wrote: On Wed, Sep 18, 2013 at 3:43 PM, Zhi Yong Wu zwu.ker...@gmail.com wrote: any doc that describes its archtecture or interval? You can find some of the design principles here [1] and here [2]. We're starting to make the wiki thicker too [3] The rest is documented in c++ for the moment ;) [1] http://www.osv.io/devel-menu/design-submenu [2] http://www.osv.io/users/technology [3] https://github.com/cloudius-systems/osv/wiki/_pages On Tue, Sep 17, 2013 at 3:22 AM, Pekka Enberg penb...@cloudius-systems.com wrote: Hello, We're proud to announce release 0.01 of OSv, a new operating system for running applications on virtual machines. OSv is free software, released under the BSD license, and you can find it in https://github.com/cloudius-systems/osv and http://www.osv.io. To build and run OSv under KVM/QEMU, first grab the latest source code from Github: git clone g...@github.com:cloudius-systems/osv.git Then install prerequisite packages: On Fedora: yum install ant autoconf automake boost-static gcc-c++ genromfs \ libvirt libtool zfs-fuse flex bison On Debian: apt-get install libboost-all-dev genromfs zfs-fuse autoconf Make sure the zfs-fuse daemon is running: On Fedora: sudo systemctl start zfs-fuse.service sudo systemctl enable zfs-fuse.service # to have it start on reboot On Debian the daemon should be started automatically. Fetch git submodules: git submodule update --init Finally, build OSv: make external all You can then start a OSv guest under KVM/QEMU: sudo ./scripts/run.py -nv -m 2G You can SSH into the guest with: ssh admin@192.168.122.89 # password: admin The management web UI is at address: http://192.168.122.89:8080/ Alternatively, you can use prebuilt QEMU QCOW2 images of the release. Instructions how to do that are on our Wiki: https://github.com/cloudius-systems/osv/wiki/Running-OSv-under-KVM-QEMU That's it! Pekka -- 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, Zhi Yong Wu -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH] hmp: Make info block output more readable
+|| info-value-inserted-iops_rd
+|| info-value-inserted-iops_wr)
+{
+monitor_printf(mon, I/O limits: bps=% PRId64
+ bps_rd=% PRId64 bps_wr=% PRId64
+ iops=% PRId64 iops_rd=% PRId64
+ iops_wr=% PRId64 \n,
info-value-inserted-bps,
info-value-inserted-bps_rd,
info-value-inserted-bps_wr,
info-value-inserted-iops,
info-value-inserted-iops_rd,
info-value-inserted-iops_wr);
+}
-if (verbose) {
-monitor_printf(mon, images:\n);
-image_info = info-value-inserted-image;
-while (1) {
-
bdrv_image_info_dump((fprintf_function)monitor_printf,
- mon, image_info);
-if (image_info-has_backing_image) {
-image_info = image_info-backing_image;
-} else {
-break;
-}
+if (verbose) {
+monitor_printf(mon, \nImages:\n);
+image_info = info-value-inserted-image;
+while (1) {
+bdrv_image_info_dump((fprintf_function)monitor_printf,
+ mon, image_info);
+if (image_info-has_backing_image) {
+image_info = image_info-backing_image;
+} else {
+break;
}
}
-} else {
-monitor_printf(mon, [not inserted]);
}
-
-monitor_printf(mon, \n);
}
qapi_free_BlockInfoList(block_list);
--
1.8.1.4
--
Regards,
Zhi Yong Wu
Re: [Qemu-devel] [RFC 1/4] block: fix I/O throttling accounting blind spot
On Thu, Mar 21, 2013 at 10:49 PM, Stefan Hajnoczi stefa...@redhat.com wrote:
I/O throttling relies on bdrv_acct_done() which is called when a request
completes. This leaves a blind spot since we only charge for completed
requests, not submitted requests.
For example, if there is 1 operation remaining in this time slice the
guest could submit 3 operations and they will all be submitted
successfully since they don't actually get accounted for until they
complete.
Originally we probably thought this is okay since the requests will be
accounted when the time slice is extended. In practice it causes
fluctuations since the guest can exceed its I/O limit and it will be
punished for this later on.
Account for I/O upon submission so that I/O limits are enforced
properly.
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
---
block.c | 19 ---
include/block/block_int.h | 2 +-
2 files changed, 9 insertions(+), 12 deletions(-)
diff --git a/block.c b/block.c
index 0a062c9..31fb0b0 100644
--- a/block.c
+++ b/block.c
@@ -141,7 +141,6 @@ void bdrv_io_limits_disable(BlockDriverState *bs)
bs-slice_start = 0;
bs-slice_end = 0;
bs-slice_time = 0;
-memset(bs-io_base, 0, sizeof(bs-io_base));
If we try some concussive operations, enable I/O throttling at first,
then disable it, and then enable it, how about? I guess that
bs-slice_submitted will maybe be not correct.
}
static void bdrv_block_timer(void *opaque)
@@ -1329,8 +1328,8 @@ static void bdrv_move_feature_fields(BlockDriverState
*bs_dest,
bs_dest-slice_time = bs_src-slice_time;
bs_dest-slice_start= bs_src-slice_start;
bs_dest-slice_end = bs_src-slice_end;
+bs_dest-slice_submitted= bs_src-slice_submitted;
bs_dest-io_limits = bs_src-io_limits;
-bs_dest-io_base= bs_src-io_base;
bs_dest-throttled_reqs = bs_src-throttled_reqs;
bs_dest-block_timer= bs_src-block_timer;
bs_dest-io_limits_enabled = bs_src-io_limits_enabled;
@@ -3665,9 +3664,9 @@ static bool bdrv_exceed_bps_limits(BlockDriverState
*bs, int nb_sectors,
slice_time = bs-slice_end - bs-slice_start;
slice_time /= (NANOSECONDS_PER_SECOND);
bytes_limit = bps_limit * slice_time;
-bytes_base = bs-nr_bytes[is_write] - bs-io_base.bytes[is_write];
+bytes_base = bs-slice_submitted.bytes[is_write];
if (bs-io_limits.bps[BLOCK_IO_LIMIT_TOTAL]) {
-bytes_base += bs-nr_bytes[!is_write] - bs-io_base.bytes[!is_write];
+bytes_base += bs-slice_submitted.bytes[!is_write];
}
/* bytes_base: the bytes of data which have been read/written; and
@@ -3683,6 +3682,7 @@ static bool bdrv_exceed_bps_limits(BlockDriverState
*bs, int nb_sectors,
*wait = 0;
}
+bs-slice_submitted.bytes[is_write] += bytes_res;
return false;
}
@@ -3725,9 +3725,9 @@ static bool bdrv_exceed_iops_limits(BlockDriverState
*bs, bool is_write,
slice_time = bs-slice_end - bs-slice_start;
slice_time /= (NANOSECONDS_PER_SECOND);
ios_limit = iops_limit * slice_time;
-ios_base = bs-nr_ops[is_write] - bs-io_base.ios[is_write];
+ios_base = bs-slice_submitted.ios[is_write];
if (bs-io_limits.iops[BLOCK_IO_LIMIT_TOTAL]) {
-ios_base += bs-nr_ops[!is_write] - bs-io_base.ios[!is_write];
+ios_base += bs-slice_submitted.ios[!is_write];
}
if (ios_base + 1 = ios_limit) {
@@ -3735,6 +3735,7 @@ static bool bdrv_exceed_iops_limits(BlockDriverState
*bs, bool is_write,
*wait = 0;
}
+bs-slice_submitted.ios[is_write]++;
return false;
}
@@ -3772,11 +3773,7 @@ static bool bdrv_exceed_io_limits(BlockDriverState
*bs, int nb_sectors,
bs-slice_start = now;
bs-slice_end = now + bs-slice_time;
-bs-io_base.bytes[is_write] = bs-nr_bytes[is_write];
-bs-io_base.bytes[!is_write] = bs-nr_bytes[!is_write];
-
-bs-io_base.ios[is_write]= bs-nr_ops[is_write];
-bs-io_base.ios[!is_write] = bs-nr_ops[!is_write];
+memset(bs-slice_submitted, 0, sizeof(bs-slice_submitted));
}
elapsed_time = now - bs-slice_start;
diff --git a/include/block/block_int.h b/include/block/block_int.h
index ce0aa26..b461764 100644
--- a/include/block/block_int.h
+++ b/include/block/block_int.h
@@ -251,7 +251,7 @@ struct BlockDriverState {
int64_t slice_start;
int64_t slice_end;
BlockIOLimit io_limits;
-BlockIOBaseValue io_base;
+BlockIOBaseValue slice_submitted;
CoQueue throttled_reqs;
QEMUTimer*block_timer;
bool io_limits_enabled;
--
1.8.1.4
--
Regards,
Zhi Yong Wu
Re: [Qemu-devel] [RFC 1/4] block: fix I/O throttling accounting blind spot
On Wed, Mar 27, 2013 at 5:14 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Wed, Mar 27, 2013 at 9:50 AM, Zhi Yong Wu zwu.ker...@gmail.com wrote: On Thu, Mar 21, 2013 at 10:49 PM, Stefan Hajnoczi stefa...@redhat.com wrote: I/O throttling relies on bdrv_acct_done() which is called when a request completes. This leaves a blind spot since we only charge for completed requests, not submitted requests. For example, if there is 1 operation remaining in this time slice the guest could submit 3 operations and they will all be submitted successfully since they don't actually get accounted for until they complete. Originally we probably thought this is okay since the requests will be accounted when the time slice is extended. In practice it causes fluctuations since the guest can exceed its I/O limit and it will be punished for this later on. Account for I/O upon submission so that I/O limits are enforced properly. Signed-off-by: Stefan Hajnoczi stefa...@redhat.com --- block.c | 19 --- include/block/block_int.h | 2 +- 2 files changed, 9 insertions(+), 12 deletions(-) diff --git a/block.c b/block.c index 0a062c9..31fb0b0 100644 --- a/block.c +++ b/block.c @@ -141,7 +141,6 @@ void bdrv_io_limits_disable(BlockDriverState *bs) bs-slice_start = 0; bs-slice_end = 0; bs-slice_time = 0; -memset(bs-io_base, 0, sizeof(bs-io_base)); If we try some concussive operations, enable I/O throttling at first, then disable it, and then enable it, how about? I guess that bs-slice_submitted will maybe be not correct. The memset() was moved... @@ -3772,11 +3773,7 @@ static bool bdrv_exceed_io_limits(BlockDriverState *bs, int nb_sectors, bs-slice_start = now; bs-slice_end = now + bs-slice_time; -bs-io_base.bytes[is_write] = bs-nr_bytes[is_write]; -bs-io_base.bytes[!is_write] = bs-nr_bytes[!is_write]; - -bs-io_base.ios[is_write]= bs-nr_ops[is_write]; -bs-io_base.ios[!is_write] = bs-nr_ops[!is_write]; +memset(bs-slice_submitted, 0, sizeof(bs-slice_submitted)); } elapsed_time = now - bs-slice_start; ...here. Since bs-slice_start = 0 when I/O throttling is disabled we will start a new slice next time bdrv_exceed_io_limits() is called. Therefore bs-slice_submitted is consistent across disable/enable. Yes, i also realized this just when i came home by subway. Stefan -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [RFC 0/4] block: fix I/O throttling oscillations
They look good to me, but i have not done any test on my dev box, thanks for your fix. On Thu, Mar 21, 2013 at 10:49 PM, Stefan Hajnoczi stefa...@redhat.com wrote: Benoît Canet ben...@irqsave.net reported that QEMU I/O throttling can oscillate under continuous I/O. The test case runs 50 threads performing random writes and a -drive iops=150 limit is used. Since QEMU I/O throttling is implemented using 100 millisecond time slices, we'd expect 150 +/- 15 IOPS. Anything outside that range indicates a problem with the I/O throttling algorithm. It turned out that even a single thread performing sequential I/O continuously is throttled outside the 150 +/- 15 IOPS range. The continous stream of I/O slows down as time goes on but resets to 150 IOPS again when interrupted. This can be tested with: $ iostat -d 1 -x /dev/vdb $ dd if=/dev/vdb of=/dev/null bs=4096 iflag=direct This patches addresses these problems as follows: 1. Account for I/O requests when they are submitted instead of completed. This ensures that we do not exceed the budget for this slice. Exceeding the budget leads to fluctuations since we have to make up for this later. 2. Use constant 100 millisecond slice time. Adjusting the slice time at run-time led to oscillations. Since the reason for adjusting slice time is not clear, drop this behavior. I have also included two code clean-up patches. Benoît: Please let me know if this solves the problems you're seeing. Stefan Hajnoczi (4): block: fix I/O throttling accounting blind spot block: keep I/O throttling slice time constant block: drop duplicated slice extension code block: clean up I/O throttling wait_time code block.c | 47 --- blockdev.c| 1 - include/block/block_int.h | 3 +-- 3 files changed, 21 insertions(+), 30 deletions(-) -- 1.8.1.4 -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH] block: fix bdrv_exceed_iops_limits wait computation
On Thu, 2013-03-21 at 10:17 +0100, Stefan Hajnoczi wrote:
On Thu, Mar 21, 2013 at 09:18:27AM +0800, Zhi Yong Wu wrote:
On Wed, 2013-03-20 at 16:12 +0100, Stefan Hajnoczi wrote:
On Wed, Mar 20, 2013 at 03:56:33PM +0100, Benoît Canet wrote:
But I don't understand why bs-slice_time is modified instead of
keeping
it constant at 100 ms:
bs-slice_time = wait_time * BLOCK_IO_SLICE_TIME * 10;
bs-slice_end += bs-slice_time - 3 * BLOCK_IO_SLICE_TIME;
if (wait) {
*wait = wait_time * BLOCK_IO_SLICE_TIME * 10;
}
In bdrv_exceed_bps_limits there is an equivalent to this with a comment.
-
/* When the I/O rate at runtime exceeds the limits,
* bs-slice_end need to be extended in order that the current
statistic
* info can be kept until the timer fire, so it is increased and
tuned
* based on the result of experiment.
*/
bs-slice_time = wait_time * BLOCK_IO_SLICE_TIME * 10;
bs-slice_end += bs-slice_time - 3 * BLOCK_IO_SLICE_TIME;
if (wait) {
*wait = wait_time * BLOCK_IO_SLICE_TIME * 10;
}
--
The comment explains why slice_end needs to be extended, but not why
bs-slice_time should be changed (except that it was tuned as the result
of an experiment).
Zhi Yong: Do you remember a reason for modifying bs-slice_time?
Stefan,
In some case that the bare I/O speed is very fast on physical machine,
when I/O speed is limited to be one lower value, I/O need to wait for
one relative longer time(i.e. wait_time). You know, wait_time should be
smaller than slice_time, if slice_time is constant, wait_time may not be
its expected value, so the throttling function will not work well.
For example, bare I/O speed is 100MB/s, I/O throttling speed is 1MB/s,
slice_time is constant, and set to 50ms(a assumed value) or smaller, If
current I/O can be throttled to 1MB/s, its wait_time is expected to
100ms(a assumed value), and is more bigger than current slice_time, I/O
throttling function will not throttle actual I/O speed well. In the
case, slice_time need to be adjusted to one more suitable value which
depends on wait_time.
When an I/O request spans a slice:
1. It must wait until enough resources are available.
2. We extend the slice so that existing accounting is not lost.
But I don't understand what you say about a fast host. The bare metal
I mean that a fast host is one host with very high metal throughput.
throughput does not affect the throttling calculation. The only values
that matter are bps limit and slice time:
In your example the slice time is 50ms and the current request needs
100ms. We need to extend slice_end to at least 100ms so that we can
account for this request.
Why should slice_time be changed?
It isn't one must choice, if you have one better way, we can maybe do it
based on your way. I thought that if wait_time is big in previous slice
window, slice_time should also be adjusted to be a bit bigger
accordingly for next slice window.
In some other case that the bare I/O speed is very slow and I/O
throttling speed is fast, slice_time also need to be adjusted
dynamically based on wait_time.
If the host is slower than the I/O limit there are two cases:
This is not what i mean; I mean that the bare I/O speed is faster than
I/O limit, but their gap is very small.
1. Requests are below I/O limit. We do not throttle, the host is slow
but that's okay.
2. Requests are above I/O limit. We throttle them but actually the host
will slow them down further to the bare metal speed. This is also fine.
Again, I don't see a nice to change slice_time.
BTW I discovered one thing that Linux blk-throttle does differently from
QEMU I/O throttling: we do not trim completed slices. I think trimming
avoids accumulating values which may lead to overflows if the slice
keeps getting extended due to continuous I/O.
QEMU I/O throttling is not completely same as Linux Block throttle way.
blk-throttle does not modify throtl_slice (their equivalent of
slice_time).
Stefan
--
Regards,
Zhi Yong Wu
Re: [Qemu-devel] [PATCH] block: fix bdrv_exceed_iops_limits wait computation
Reviewed-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
On Wed, 2013-03-20 at 10:12 +0100, Benoît Canet wrote:
This patch fix an I/O throttling behavior triggered by limiting at 150 iops
and running a load of 50 threads doing random pwrites on a raw virtio device.
After a few moments the iops count start to oscillate steadily between 0 and a
value upper than the limit.
As the load keep running the period and the amplitude of the oscillation
increase until io bursts reaching the physical storage max iops count are
done.
These bursts are followed by guest io starvation.
As the period of this oscillation cycle is increasing the cause must be a
computation error leading to increase slowly the wait time.
This patch make the wait time a bit smaller and tests confirm that it solves
the oscillating behavior.
Signed-off-by: Benoit Canet ben...@irqsave.net
---
block.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block.c b/block.c
index 0a062c9..455d8b0 100644
--- a/block.c
+++ b/block.c
@@ -3739,7 +3739,7 @@ static bool bdrv_exceed_iops_limits(BlockDriverState
*bs, bool is_write,
}
/* Calc approx time to dispatch */
-wait_time = (ios_base + 1) / iops_limit;
+wait_time = ios_base / iops_limit;
if (wait_time elapsed_time) {
wait_time = wait_time - elapsed_time;
} else {
--
Regards,
Zhi Yong Wu
Re: [Qemu-devel] [PATCH] block: fix bdrv_exceed_iops_limits wait computation
On Wed, 2013-03-20 at 16:12 +0100, Stefan Hajnoczi wrote:
On Wed, Mar 20, 2013 at 03:56:33PM +0100, Benoît Canet wrote:
But I don't understand why bs-slice_time is modified instead of keeping
it constant at 100 ms:
bs-slice_time = wait_time * BLOCK_IO_SLICE_TIME * 10;
bs-slice_end += bs-slice_time - 3 * BLOCK_IO_SLICE_TIME;
if (wait) {
*wait = wait_time * BLOCK_IO_SLICE_TIME * 10;
}
In bdrv_exceed_bps_limits there is an equivalent to this with a comment.
-
/* When the I/O rate at runtime exceeds the limits,
* bs-slice_end need to be extended in order that the current statistic
* info can be kept until the timer fire, so it is increased and tuned
* based on the result of experiment.
*/
bs-slice_time = wait_time * BLOCK_IO_SLICE_TIME * 10;
bs-slice_end += bs-slice_time - 3 * BLOCK_IO_SLICE_TIME;
if (wait) {
*wait = wait_time * BLOCK_IO_SLICE_TIME * 10;
}
--
The comment explains why slice_end needs to be extended, but not why
bs-slice_time should be changed (except that it was tuned as the result
of an experiment).
Zhi Yong: Do you remember a reason for modifying bs-slice_time?
Stefan,
In some case that the bare I/O speed is very fast on physical machine,
when I/O speed is limited to be one lower value, I/O need to wait for
one relative longer time(i.e. wait_time). You know, wait_time should be
smaller than slice_time, if slice_time is constant, wait_time may not be
its expected value, so the throttling function will not work well.
For example, bare I/O speed is 100MB/s, I/O throttling speed is 1MB/s,
slice_time is constant, and set to 50ms(a assumed value) or smaller, If
current I/O can be throttled to 1MB/s, its wait_time is expected to
100ms(a assumed value), and is more bigger than current slice_time, I/O
throttling function will not throttle actual I/O speed well. In the
case, slice_time need to be adjusted to one more suitable value which
depends on wait_time.
In some other case that the bare I/O speed is very slow and I/O
throttling speed is fast, slice_time also need to be adjusted
dynamically based on wait_time.
If i remember correctly, it's the reason.
Stefan
--
Regards,
Zhi Yong Wu
Re: [Qemu-devel] [Qemu-ppc] [PATCH] ide/macio: Fix macio DMA initialisation.
Why is this patch so hottest? so that both guys would like to apply it?:)
On Mon, Feb 25, 2013 at 4:46 AM, Mark Cave-Ayland
mark.cave-ayl...@ilande.co.uk wrote:
Commit 07a7484e5d713f1eb7c1c37b18a8ab0d56d88875 accidentally introduced a bug
in the initialisation of the second macio DMA device which could cause some
DMA operations to segfault QEMU.
CC: Andreas Färber afaer...@suse.de
Signed-off-by: Mark Cave-Ayland mark.cave-ayl...@ilande.co.uk
---
hw/macio.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/macio.c b/hw/macio.c
index 74bdcd1..0c6a6b8 100644
--- a/hw/macio.c
+++ b/hw/macio.c
@@ -188,7 +188,7 @@ static int macio_newworld_initfn(PCIDevice *d)
sysbus_dev = SYS_BUS_DEVICE(ns-ide[1]);
sysbus_connect_irq(sysbus_dev, 0, ns-irqs[3]);
sysbus_connect_irq(sysbus_dev, 1, ns-irqs[4]);
-macio_ide_register_dma(ns-ide[0], s-dbdma, 0x1a);
+macio_ide_register_dma(ns-ide[1], s-dbdma, 0x1a);
ret = qdev_init(DEVICE(ns-ide[1]));
if (ret 0) {
return ret;
--
1.7.10.4
--
Regards,
Zhi Yong Wu
Re: [Qemu-devel] [RFC V7 00/11] Quorum block filter
On Sat, Jan 19, 2013 at 1:30 AM, Benoît Canet ben...@irqsave.net wrote: This patchset is rebased on top of cutils: unsigned int parsing functions by Eduardo Habkost. This patchset create a block driver implementing a quorum using total qemu disk images. Writes are mirrored on the $total files. For the reading part the $total files are read at the same time and a vote is done to determine if a qiov version is present $threshold or more times. It then return this majority version to the upper layers. When i $threshold versions of the data are returned by the lower layer the quorum is broken and the read return -EIO. The goal of this patchset is to be turned in a QEMU block filter living just above raw-*.c and below qcow2/qed when the required infrastructure will be done. Main use of this feature will be people using NFS appliances which can be subjected to bitflip errors. This patchset can be used to replace blkverify and the out of tree blkmirror. usage: -drive file=quorum:threshold/total:image_1.raw:...:image_total.raw,if=virtio,cache=none I don't know if the following case can be handled correctly. For example, quorum:2/3:image1.raw:image2.raw:image3.raw Let us assume that some data in image2.raw and image3.raw get corrupted, and the two images are now completely identical; while image1.raw doesn't get corrupted. In this case, how will your vote method know if which image gets corrupted and which image doesn't? in this version: parse total and threshold with parse_uint [Eric] return proper qerrors in quorum_open [Eric] Use sha256 for comparing blocks [Eric] Update the rest of the voting function to the new way of doing [Benoît] V6: fix commit message of quorum: Add quorum_open() and quorum_close(). [Eric] return error after a vote in quorum_co_flush [Eric] Fix bitrot caused by headers and structures renaming [Benoît] initialize finished to NULL to prevent crash [Benoît] convert internal quorum code to uint64_t instead of int64_t [Benoît] V5: Eric Blake: revert back separator to : rewrite quorum_getlength Benoît Canet: use memcmp to compare iovec excepted for the blkverify case use strstart to parse argument in open Benoît Canet (11): quorum: Create quorum.c, add QuorumSingleAIOCB and QuorumAIOCB. quorum: Create BDRVQuorumState and BlkDriver and do init. quorum: Add quorum_open() and quorum_close(). quorum: Add quorum_aio_writev and its dependencies. blkverify: Extract qemu_iovec_clone() and qemu_iovec_compare() from blkverify. quorum: Add quorum_aio_readv. quorum: Add quorum mechanism. quorum: Add quorum_getlength(). quorum: Add quorum_invalidate_cache(). quorum: Add quorum_co_is_allocated. quorum: Add quorum_co_flush(). block/Makefile.objs |1 + block/blkverify.c | 108 +-- block/quorum.c| 789 + configure | 22 ++ include/qemu-common.h |2 + util/iov.c| 103 +++ 6 files changed, 919 insertions(+), 106 deletions(-) create mode 100644 block/quorum.c -- 1.7.10.4 -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [RFC V7 00/11] Quorum block filter
On Mon, Jan 21, 2013 at 10:25 PM, Benoît Canet benoit.ca...@irqsave.net wrote: I don't know if the following case can be handled correctly. For example, quorum:2/3:image1.raw:image2.raw:image3.raw Let us assume that some data in image2.raw and image3.raw get corrupted, and the two images are now completely identical; while image1.raw doesn't get corrupted. In this case, how will your vote method know if which image gets corrupted and which image doesn't? It won't the reads will be corrupted on this sector. sorry, i haven't got what it means, can you say standard english?:) e.g, there is one words on image1.raw such as USA is one great country, but due to network bitflip, it is changed to UK is one greate country on image2.raw and image3.raw. the reads will not be corrupted on these sectors on different images, how will quorum block filter determine which images are correct while which aren't? That's why one must set each image on a different filer to avoid identical corruptions. Since each image locates on different filer, you can't also make 100% sure to avoid identical corruptions. Regards, Benoīt -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [RFC V7 00/11] Quorum block filter
On Tue, Jan 22, 2013 at 2:44 AM, Eric Blake ebl...@redhat.com wrote: On 01/21/2013 11:35 AM, Zhi Yong Wu wrote: On Mon, Jan 21, 2013 at 10:25 PM, Benoît Canet benoit.ca...@irqsave.net wrote: I don't know if the following case can be handled correctly. For example, quorum:2/3:image1.raw:image2.raw:image3.raw Let us assume that some data in image2.raw and image3.raw get corrupted, and the two images are now completely identical; while image1.raw doesn't get corrupted. In this case, how will your vote method know if which image gets corrupted and which image doesn't? It won't the reads will be corrupted on this sector. sorry, i haven't got what it means, can you say standard english?:) e.g, there is one words on image1.raw such as USA is one great country, but due to network bitflip, it is changed to UK is one greate country on image2.raw and image3.raw. the reads will not be corrupted on these sectors on different images, how will quorum block filter determine which images are correct while which aren't? That's why one must set each image on a different filer to avoid identical corruptions. Since each image locates on different filer, you can't also make 100% sure to avoid identical corruptions. Corruption is corruption, no matter how it happens. If two of the three images in a quorum are corrupted in the exact same manner, you have lost data. But the reason to use a quorum is that the probability of the majority of the images getting the exact same corruption, especially when the various images in the quorum all come from different storage filers, is so small that you need not worry about it; or else you are worried about it, but then you need something stronger and slower than just a quorum, such as a cryptographic checksum of every sector rather than just a majority rule. Compare this to how ddrescue works - their advice is to burn at least two copies of any important CD or DVD; even if you start to get read failures in one or even both of the images, the probability of getting identical read failures in identical sectors on both disks is so slim that you can still reconstruct the original iso in a staggeringly high percentage of cases. thanks for your great explaination. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [RFC PATCH v4 00/30] ACPI memory hotplug
). If someone can review the seabios patches or has any ideas to debug this, let me know. - hot-operation notification lists need to be added to migration state. series is based on: - qemu master (commit a8a826a3) + patch: https://lists.gnu.org/archive/html/qemu-devel/2012-11/msg02699.html - seabios master (commit a810e4e7) Can also be found at: http://github.com/vliaskov/qemu-kvm/commits/memhp-v4 http://github.com/vliaskov/seabios/commits/memhp-v4 Vasilis Liaskovitis (21): qapi: make visit_type_size fallback to type_int Add SIZE type to qdev properties qemu-option: export parse_option_number Implement dimm device abstraction vl: handle -device dimm acpi_piix4 : Implement memory device hotplug registers acpi_ich9 : Implement memory device hotplug registers piix_pci and pc_piix: refactor piix_pci: Add i440fx dram controller initialization q35: Add i440fx dram controller initialization pc: Add dimm paravirt SRAT info Introduce paravirt interface QEMU_CFG_PCI_WINDOW Implement info memory-total and query-memory-total balloon: update with hotplugged memory Implement dimm-info dimm: add hot-remove capability acpi_piix4: add hot-remove capability acpi_ich9: add hot-remove capability Implement qmp and hmp commands for notification lists Add _OST dimm support Implement _PS3 for dimm docs/specs/acpi_hotplug.txt | 54 ++ docs/specs/fwcfg.txt| 28 +++ hmp-commands.hx |6 + hmp.c | 41 hmp.h |3 + hw/Makefile.objs|2 +- hw/acpi.h |5 + hw/acpi_ich9.c | 115 +++- hw/acpi_ich9.h | 12 +- hw/acpi_piix4.c | 126 - hw/dimm.c | 444 +++ hw/dimm.h | 102 ++ hw/fw_cfg.h |1 + hw/lpc_ich9.c |2 +- hw/pc.c | 28 +++- hw/pc.h |1 + hw/pc_piix.c| 74 ++-- hw/pc_q35.c | 18 ++- hw/piix_pci.c | 249 - hw/q35.c| 27 +++ hw/q35.h|5 + hw/qdev-properties.c| 60 ++ hw/qdev-properties.h|3 + hw/virtio-balloon.c | 13 +- monitor.c | 21 ++ qapi-schema.json| 63 ++ qapi/qapi-visit-core.c | 11 +- qemu-option.c |4 +- qemu-option.h |4 + qmp-commands.hx | 57 ++ sysemu.h|1 + vl.c| 60 ++ 32 files changed, 1432 insertions(+), 208 deletions(-) create mode 100644 docs/specs/acpi_hotplug.txt create mode 100644 docs/specs/fwcfg.txt create mode 100644 hw/dimm.c create mode 100644 hw/dimm.h Vasilis Liaskovitis (9): Add ACPI_EXTRACT_DEVICE* macros Add SSDT memory device support acpi-dsdt: Implement functions for memory hotplug acpi: generate hotplug memory devices q35: Add memory hotplug handler pci: Use paravirt interface for pcimem_start and pcimem64_start acpi: add _EJ0 operation and eject port for memory devices Add _OST dimm method Implement _PS3 method for memory device Makefile |2 +- src/acpi-dsdt-mem-hotplug.dsl | 136 +++ src/acpi-dsdt.dsl |5 +- src/acpi.c| 158 +++-- src/paravirt.c|6 ++ src/paravirt.h|2 + src/pciinit.c |9 +++ src/q35-acpi-dsdt.dsl |6 +- src/ssdt-mem.dsl | 73 +++ tools/acpi_extract.py | 28 +++ 10 files changed, 415 insertions(+), 10 deletions(-) create mode 100644 src/acpi-dsdt-mem-hotplug.dsl create mode 100644 src/ssdt-mem.dsl -- 1.7.9 -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [Bug 1087114] [NEW] assertion QLIST_EMPTY(bs-tracked_requests) failed
=0x30d1d5e7400, offset=0, width=1, data=8)
at /home/ports/pobj/qemu-1.3.0-debug/qemu-1.3.0/memory.c:439
mrio = (MemoryRegionIORange *) 0x30d1d5e7400
mr = (MemoryRegion *) 0x30d0f5f57d0
__func__ = memory_region_iorange_write
#9 0x030b0d5c019a in ioport_writeb_thunk (opaque=0x30d1d5e7400,
addr=49216, data=8) at
/home/ports/pobj/qemu-1.3.0-debug/qemu-1.3.0/ioport.c:212
ioport = (IORange *) 0x30d1d5e7400
#10 0x030b0d5bfb65 in ioport_write (index=0, address=49216, data=8) at
/home/ports/pobj/qemu-1.3.0-debug/qemu-1.3.0/ioport.c:83
func = (IOPortWriteFunc *) 0x30b0d5c0148 ioport_writeb_thunk
default_func = {0x30b0d5bfbbc default_ioport_writeb,
0x30b0d5bfc61 default_ioport_writew, 0x30b0d5bfd0c default_ioport_writel}
#11 0x030b0d5c0704 in cpu_outb (addr=49216, val=8 '\b') at
/home/ports/pobj/qemu-1.3.0-debug/qemu-1.3.0/ioport.c:289
No locals.
#12 0x030b0d6067dd in helper_outb (port=49216, data=8) at
/home/ports/pobj/qemu-1.3.0-debug/qemu-1.3.0/target-i386/misc_helper.c:72
No locals.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1087114/+subscriptions
--
Regards,
Zhi Yong Wu
Re: [Qemu-devel] What is the current state of the various usb implementations?
HI, Since the slides have been there, why would nobody like to export them on http://www.linux-kvm.org/page/KVM_Forum_2012? If so, we can download or review them. On Tue, Dec 11, 2012 at 5:03 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Mon, Dec 10, 2012 at 11:38:21AM -0500, tom289...@safe-mail.net wrote: Hello, I sent this to qemu-discuss a week ago and got no responses, so I'm trying here. Looking at `qemu-kvm -device ?`, there seem to be multiple usb implementations: ich9-usb-uhci2 ich9-usb-uhci3 ich9-usb-uhci1 piix3-usb-uhci piix4-usb-uhci vt82c686b-usb-uhci ich9-usb-ehci1 usb-ehci nec-usb-xhci Are they all fully implemented and stable? If not, what is the state of each? Here is a link to Gerd's USB Status presentation at KVM Forum 2012 in November: http://www.linux-kvm.org/wiki/images/b/be/2012-forum-qemu-usb-status-update.pdf Stefan -- Regards, Zhi Yong Wu
Re: [Qemu-devel] FYI: KVM Forum community team photo
On Thu, Nov 22, 2012 at 6:40 PM, Daniel P. Berrange berra...@redhat.com wrote: At the LinuxCon / KVM Forum last week, a bunch of QEMU/KVM community members were rounded up to pose for a team photo. Thanks to Jeff Cody who was the one with the camera. I've put the photo up here along with, what I hope is a correct, list of names against faces... http://www.linux-kvm.org/static/kvm-forum-2012-barcelona-team-photo.html It will be more appreciated if someone can upload slides. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- Regards, Zhi Yong Wu
Re: [Qemu-devel] KVM call agenda for 2012-11-12
HI, I'm got confused by the date in this topic. On Mon, Nov 12, 2012 at 8:58 PM, Juan Quintela quint...@redhat.com wrote: Hi Please send in any agenda topics you are interested in. Later, Juan. -- 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, Zhi Yong Wu
Re: [Qemu-devel] [hellogcc] Call for Chinese QEMU developers
+1 By the way, forward it to QEMU mail list in order that some qemu guys can see this. 2012/9/19 陳韋任 (Wei-Ren Chen) che...@cs.nctu.edu.tw: Hi all, 借個場地，我們想知道在 QEMU 上的中國/台灣開發者有哪些人。 有興趣露個臉的朋友，請回覆此帖。彼此認識一下。 韋任 -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH v2 00/16] net: Move legacy QEMU VLAN code into net/hub.c
On Mon, Jul 30, 2012 at 11:49 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Tue, Jul 24, 2012 at 4:35 PM, Stefan Hajnoczi stefa...@linux.vnet.ibm.com wrote: [These patches are based on the net tree at git://github.com/stefanha/net] The QEMU net subsystem has the concept of separate network segments, called VLANs. Each VLAN is a broadcast domain so all net clients connected to the same VLAN can communicate with each other. Today this feature is mostly used with the dump backend, which saves packet captures to .pcap files. It can still come in useful in other rare cases. This patch series moves the VLAN code out of net.c and into net/hub.c. The idea is to introduce a software network hub along with hub port net clients. This way we can implement the same semantics of QEMU VLANs using just -netdev peer. Then -netdev peer becomes the single method of connecting net clients. The end result of this series is that the net subsystem core is simplified. Now is a good time to do this because it saves us from modeling QEMU VLANs when we convert the net subsystem to QOM. Please note that this series preserves command-line compatibility with the QEMU VLAN feature. No existing QEMU command-lines should break. I have tested the following configurations: * -net user -net nic,model=virtio * -net user,vlan=1 -net nic,model=virtio,vlan=1 * -net user,vlan=1 -net nic,model=virtio,vlan=1 -net user,vlan=2 -net nic,model=virtio,vlan=2 * -netdev user,id=netdev0 -device virtio-net-pci,netdev=netdev0 * -netdev user,id=netdev0 -device virtio-net-pci,netdev=netdev0 -net user,vlan=2 -net nic,model=virtio,vlan=2 v2: * Change int64_t and unsigned int mess to int which is what VLAN IDs are today [Laszlo] * Remove bogus error_set() - qerror_report() merge artifact [Laszlo] * Use net_hub_id_for_client(nc, NULL) == 0 instead of adding net_hub_port_peer_nc() [Laszlo] * Fix stray print_net_client(..., NetClientState *vc) argument name [Laszlo] * Consistently update vlan - peer argument name [Laszlo] * Drop spurious closesocket(fd), probably merge conflict [Stefan] Stefan Hajnoczi (11): net: Add a hub net client net: Use hubs for the vlan feature net: Look up 'vlan' net clients using hubs hub: Check that hubs are configured correctly net: Drop vlan argument to qemu_new_net_client() net: Remove vlan code from net.c net: Remove VLANState net: Rename non_vlan_clients to net_clients net: Rename VLANClientState to NetClientState net: Rename vc local variables to nc net: Rename qemu_del_vlan_client() to qemu_del_net_client() Zhi Yong Wu (5): net: Convert qdev_prop_vlan to peer with hub net: Make info network output more readable info net: cleanup deliver/deliver_iov func pointers net: determine if packets can be sent before net queue deliver packets hub: add the support for hub own flow control hw/cadence_gem.c|8 +- hw/dp8393x.c|7 +- hw/e1000.c | 10 +- hw/eepro100.c |8 +- hw/etraxfs_eth.c|8 +- hw/exynos4_boards.c |2 +- hw/highbank.c |2 +- hw/integratorcp.c |2 +- hw/kzm.c|2 +- hw/lan9118.c|8 +- hw/lance.c |2 +- hw/mcf5208.c|2 +- hw/mcf_fec.c|7 +- hw/milkymist-minimac2.c |6 +- hw/mips_mipssim.c |2 +- hw/mips_r4k.c |2 +- hw/mipsnet.c|6 +- hw/musicpal.c |6 +- hw/ne2000-isa.c |2 +- hw/ne2000.c |8 +- hw/ne2000.h |4 +- hw/opencores_eth.c |8 +- hw/pcnet-pci.c |4 +- hw/pcnet.c |6 +- hw/pcnet.h |6 +- hw/qdev-properties.c| 54 +++-- hw/qdev.c |2 - hw/qdev.h |7 +- hw/rtl8139.c| 10 +- hw/smc91c111.c |6 +- hw/spapr_llan.c |4 +- hw/stellaris_enet.c |6 +- hw/usb/dev-network.c|8 +- hw/vexpress.c |2 +- hw/vhost_net.c | 24 +- hw/vhost_net.h |2 +- hw/virtio-net.c | 12 +- hw/xen_nic.c|7 +- hw/xgmac.c |6 +- hw/xilinx_axienet.c |6 +- hw/xilinx_ethlite.c |6 +- hw/xtensa_lx60.c|2 +- net.c | 616 ++- net.h | 86 +++ net/Makefile.objs |2 +- net/dump.c | 27 ++- net/dump.h |2 +- net/hub.c | 339 ++ net/hub.h | 29 +++ net/queue.c | 38 ++- net/queue.h | 25 +- net/slirp.c | 34 ++- net/slirp.h |2 +- net/socket.c| 60 ++--- net/socket.h|2 +- net
Re: [Qemu-devel] [RFC 0/9] vhost-scsi: Add support for host virtualized target
On Wed, Jul 25, 2012 at 6:33 AM, Nicholas A. Bellinger n...@linux-iscsi.org wrote: From: Nicholas Bellinger n...@linux-iscsi.org Hi Anthony + QEMU storage folks, The following is a reviewable RFC series of vhost-scsi against yesterday's QEMU.git/master @ commit 401a66357d. The series is available directly from: git://git.kernel.org/pub/scm/virt/kvm/nab/qemu-kvm.git vhost-scsi-merge Is this git tree cloned from qemu-kvm.git/master or qemu.git/master? But from above info, it seems to be from latter. I got confused. It contains the squashed + re-ordered patches from Stefan - Zhi's QEMU original work into a updated series against recent QEMU code. As mentioned recently on qemu-devel here: http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg03280.html the 'vhost-scsi-merge' branch is currently failing with vhost/virtio errors using the latest HEAD. Stefan + myself are currently working through the 1.1.0 regressions, and will be posting incremental patches against this working tree as individual progress is made.. Please have a look. --nab P.S: Also, for folks who are interested in trying out a working virtio-scsi - tcm_vhost setup, check out using branch 'vhost-scsi' with the last pre-regression commit from upstream QEMU that appears to be performing very well. This along with target-pending.git/for-next-merge for KVM host + a virtio-scsi SCSI LLD bugfix for KVM guest that's headed into 3.6-rc1 here should be enough to get up and running: virtio-scsi: Add vdrv-scan for post VIRTIO_CONFIG_S_DRIVER_OK LUN scanning http://git.kernel.org/?p=linux/kernel/git/jejb/scsi.git;a=commitdiff;h=59057fbc37178f10a196ab7ec170b80273f75a47;hp=0b1017aab197271a78169fde3d7e487bb721997c Thanks! Nicholas Bellinger (1): virtio-scsi: Set max_target=0 during vhost-scsi operation Stefan Hajnoczi (8): notifier: add validity check and notify function virtio-pci: support host notifiers in TCG mode virtio-pci: check that event notification worked vhost: Pass device path to vhost_dev_init() virtio-scsi: Add wwpn and tgpt properties virtio-scsi: Open and initialize /dev/vhost-scsi virtio-scsi: Start/stop vhost vhost-scsi: add -vhost-scsi host device configure| 10 +++ event_notifier.c | 21 ++ event_notifier.h |4 + hw/Makefile.objs |1 + hw/qdev-properties.c | 32 + hw/qdev.h|3 + hw/vhost-scsi.c | 173 ++ hw/vhost-scsi.h | 50 ++ hw/vhost.c |5 +- hw/vhost.h |3 +- hw/vhost_net.c |2 +- hw/virtio-pci.c | 28 +++- hw/virtio-scsi.c | 59 +- hw/virtio-scsi.h |1 + hw/virtio.c |7 ++ qemu-common.h|1 + qemu-config.c| 16 + qemu-options.hx |4 + vl.c | 18 + 19 files changed, 430 insertions(+), 8 deletions(-) create mode 100644 hw/vhost-scsi.c create mode 100644 hw/vhost-scsi.h -- 1.7.2.5 -- You received this message because you are subscribed to the Google Groups Linux-iSCSI.org Target Development group. To post to this group, send email to linux-iscsi-target-...@googlegroups.com. To unsubscribe from this group, send email to linux-iscsi-target-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/linux-iscsi-target-dev?hl=en. -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH v6 00/17] hub-based networking patchset
On Thu, Jul 19, 2012 at 11:41 PM, Paolo Bonzini pbonz...@redhat.com wrote: Il 19/07/2012 17:40, Stefan Hajnoczi ha scritto: On Sun, Jun 24, 2012 at 4:11 PM, Zhi Yong Wu zwu.ker...@gmail.com wrote: pull? I have been basing work off this series. I'm sending a rebased and retested version which applies to current qemu.git/master. We need to coordinate between this series and Laszlo's QemuOpts conversion. How to coordinate? Look at which patchset gets merged at first, then the latter will depend on it? Paolo -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH v6 00/17] hub-based networking patchset
qapi/opts-visitor.h | 31 qapi/opts-visitor.c | 427 +++ qapi/Makefile.objs |2 +- 3 files changed, 459 insertions(+), 1 deletions(-) create mode 100644 qapi/opts-visitor.h create mode 100644 qapi/opts-visitor.c From the above log of laszlo's patchset, there seems to be no too much conflict with my patchset. On Thu, Jul 19, 2012 at 11:49 PM, Paolo Bonzini pbonz...@redhat.com wrote: Il 19/07/2012 17:48, Zhi Yong Wu ha scritto: I have been basing work off this series. I'm sending a rebased and retested version which applies to current qemu.git/master. We need to coordinate between this series and Laszlo's QemuOpts conversion. How to coordinate? Look at which patchset gets merged at first, then the latter will depend on it? Laszlo's patchset is ready to merge AFAIK. Paolo -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH v6 00/17] hub-based networking patchset
net.h | 16 +-- net/dump.h |5 +- net/slirp.h|4 +- net/socket.h |5 +- net/tap.h | 10 +- net/vde.h |5 +- net.c | 494 +++- net/dump.c | 24 ++- net/slirp.c| 96 +++-- net/socket.c | 124 --- net/tap-aix.c |2 +- net/tap-bsd.c |2 +- net/tap-haiku.c|2 +- net/tap-linux.c|9 +- net/tap-solaris.c |2 +- net/tap-win32.c| 14 +- net/tap.c | 152 ++-- net/vde.c | 20 + I guess that it should be not so difficult to coodinate between the two patchsets. You can see that only some lines of code in most above files are changed. On Fri, Jul 20, 2012 at 12:08 AM, Paolo Bonzini pbonz...@redhat.com wrote: Il 19/07/2012 17:57, Zhi Yong Wu ha scritto: qapi/opts-visitor.h | 31 qapi/opts-visitor.c | 427 +++ qapi/Makefile.objs |2 +- 3 files changed, 459 insertions(+), 1 deletions(-) create mode 100644 qapi/opts-visitor.h create mode 100644 qapi/opts-visitor.c From the above log of laszlo's patchset, there seems to be no too much conflict with my patchset. The log is this: error.h|2 +- net.h | 16 +-- net/dump.h |5 +- net/slirp.h|4 +- net/socket.h |5 +- net/tap.h | 10 +- net/vde.h |5 +- qapi/opts-visitor.h| 31 +++ qapi/qapi-visit-core.h |3 + qemu-option-internal.h | 53 + error.c|3 +- hw/cadence_gem.c |2 +- hw/dp8393x.c |2 +- hw/e1000.c |2 +- hw/eepro100.c |2 +- hw/etraxfs_eth.c |2 +- hw/lan9118.c |2 +- hw/lance.c |2 +- hw/mcf_fec.c |2 +- hw/milkymist-minimac2.c|2 +- hw/mipsnet.c |2 +- hw/musicpal.c |2 +- hw/ne2000-isa.c|2 +- hw/ne2000.c|2 +- hw/opencores_eth.c |2 +- hw/pcnet-pci.c |2 +- hw/rtl8139.c |2 +- hw/smc91c111.c |2 +- hw/spapr_llan.c|2 +- hw/stellaris_enet.c|2 +- hw/usb/dev-network.c |2 +- hw/vhost_net.c |2 +- hw/virtio-net.c| 10 +- hw/xen_nic.c |2 +- hw/xgmac.c |2 +- hw/xilinx_axienet.c|2 +- hw/xilinx_ethlite.c|2 +- net.c | 494 +++- net/dump.c | 24 ++- net/slirp.c| 96 +++-- net/socket.c | 124 --- net/tap-aix.c |2 +- net/tap-bsd.c |2 +- net/tap-haiku.c|2 +- net/tap-linux.c|9 +- net/tap-solaris.c |2 +- net/tap-win32.c| 14 +- net/tap.c | 152 ++-- net/vde.c | 20 +- qapi/opts-visitor.c| 427 ++ qapi/qapi-visit-core.c | 17 +- qemu-option.c | 24 +-- tests/test-qmp-commands.c | 42 tests/test-qmp-input-visitor.c | 24 ++- docs/qapi-code-gen.txt |2 + qapi-schema.json | 288 +++- qapi/Makefile.objs |2 +- scripts/qapi-visit.py | 150 - scripts/qapi.py|6 + 59 files changed, 1350 insertions(+), 770 deletions(-) create mode 100644 qapi/opts-visitor.h create mode 100644 qemu-option-internal.h create mode 100644 qapi/opts-visitor.c and the net.h and net/* parts are going to conflict. Paolo -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH] hw/virtio-scsi: Set max_target=0 during vhost-scsi operation
HI, nab, On Fri, Jul 13, 2012 at 6:08 AM, Nicholas A. Bellinger n...@linux-iscsi.org wrote: Hi Zhi, On Thu, 2012-07-12 at 14:59 +0800, Zhi Yong Wu wrote: thanks, it is applied to my vhost_scsi git tree git://github.com/wuzhy/qemu.git vhost-scsi Thanks for picking up this patch in your vhost-scsi tree. As mentioned off-list, I'd like to rebase to a more recent qemu.git to include megasas 8708EM2 HBA emulation from Dr. Hannes so we can experiment with a few more types of target setups. ;) I have rebased my vhost-scsi tree to latest qemu.git. I'll likely do this on my local branch for now, but if you have the extra cycles please feel free to update vhost-scsi to the latest qemu.git HEAD so we can have both vhost-scsi + megasas HBA emulation in the same working tree. I have push rebased vhost-scsi tree to my public git. Depending upon how long we'll need to hold vhost-scsi patches out-of-tree (hopefully it's less than infinity ;) a qemu/vhost-scsi Heh, i also hope so, but have not anthority to push it to kernel.org. working tree on kernel.org might also be helpful. Thanks! --nab -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH] hw/virtio-scsi: Set max_target=0 during vhost-scsi operation
thanks, it is applied to my vhost_scsi git tree
git://github.com/mdroth/qemu.git vhost-scsi
On Thu, Jul 12, 2012 at 4:55 AM, Nicholas A. Bellinger
n...@linux-iscsi.org wrote:
From: Nicholas Bellinger n...@linux-iscsi.org
This QEMU patch sets VirtIOSCSIConfig-max_target=0 for vhost-scsi operation
to restrict virtio-scsi LLD guest scanning to max_id=0 (a single target ID
instance) when connected to individual tcm_vhost endpoints as requested by
Paolo.
This ensures that virtio-scsi LLD only attempts to scan target IDs up to
VIRTIO_SCSI_MAX_TARGET when connected via virtio-scsi-raw.
It's currently cut against Zhi's qemu vhost-scsi tree here:
https://github.com/wuzhy/qemu/tree/vhost-scsi
Cc: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
Cc: Zhi Yong Wu wu...@linux.vnet.ibm.com
Cc: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Nicholas Bellinger n...@linux-iscsi.org
---
hw/virtio-scsi.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/hw/virtio-scsi.c b/hw/virtio-scsi.c
index e38cdd0..71276b6 100644
--- a/hw/virtio-scsi.c
+++ b/hw/virtio-scsi.c
@@ -523,7 +523,11 @@ static void virtio_scsi_get_config(VirtIODevice *vdev,
stl_raw(scsiconf-sense_size, s-sense_size);
stl_raw(scsiconf-cdb_size, s-cdb_size);
stl_raw(scsiconf-max_channel, VIRTIO_SCSI_MAX_CHANNEL);
-stl_raw(scsiconf-max_target, VIRTIO_SCSI_MAX_TARGET);
+if (s-vhost_scsi) {
+stl_raw(scsiconf-max_target, 0);
+} else {
+stl_raw(scsiconf-max_target, VIRTIO_SCSI_MAX_TARGET);
+}
stl_raw(scsiconf-max_lun, VIRTIO_SCSI_MAX_LUN);
}
--
1.7.2.5
--
You received this message because you are subscribed to the Google Groups
Linux-iSCSI.org Target Development group.
To post to this group, send email to linux-iscsi-target-...@googlegroups.com.
To unsubscribe from this group, send email to
linux-iscsi-target-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/linux-iscsi-target-dev?hl=en.
--
Regards,
Zhi Yong Wu
Re: [Qemu-devel] [PATCH] hw/virtio-scsi: Set max_target=0 during vhost-scsi operation
thanks, it is applied to my vhost_scsi git tree
git://github.com/wuzhy/qemu.git vhost-scsi
On Thu, Jul 12, 2012 at 4:55 AM, Nicholas A. Bellinger
n...@linux-iscsi.org wrote:
From: Nicholas Bellinger n...@linux-iscsi.org
This QEMU patch sets VirtIOSCSIConfig-max_target=0 for vhost-scsi operation
to restrict virtio-scsi LLD guest scanning to max_id=0 (a single target ID
instance) when connected to individual tcm_vhost endpoints as requested by
Paolo.
This ensures that virtio-scsi LLD only attempts to scan target IDs up to
VIRTIO_SCSI_MAX_TARGET when connected via virtio-scsi-raw.
It's currently cut against Zhi's qemu vhost-scsi tree here:
https://github.com/wuzhy/qemu/tree/vhost-scsi
Cc: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
Cc: Zhi Yong Wu wu...@linux.vnet.ibm.com
Cc: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Nicholas Bellinger n...@linux-iscsi.org
---
hw/virtio-scsi.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/hw/virtio-scsi.c b/hw/virtio-scsi.c
index e38cdd0..71276b6 100644
--- a/hw/virtio-scsi.c
+++ b/hw/virtio-scsi.c
@@ -523,7 +523,11 @@ static void virtio_scsi_get_config(VirtIODevice *vdev,
stl_raw(scsiconf-sense_size, s-sense_size);
stl_raw(scsiconf-cdb_size, s-cdb_size);
stl_raw(scsiconf-max_channel, VIRTIO_SCSI_MAX_CHANNEL);
-stl_raw(scsiconf-max_target, VIRTIO_SCSI_MAX_TARGET);
+if (s-vhost_scsi) {
+stl_raw(scsiconf-max_target, 0);
+} else {
+stl_raw(scsiconf-max_target, VIRTIO_SCSI_MAX_TARGET);
+}
stl_raw(scsiconf-max_lun, VIRTIO_SCSI_MAX_LUN);
}
--
1.7.2.5
--
You received this message because you are subscribed to the Google Groups
Linux-iSCSI.org Target Development group.
To post to this group, send email to linux-iscsi-target-...@googlegroups.com.
To unsubscribe from this group, send email to
linux-iscsi-target-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/linux-iscsi-target-dev?hl=en.
--
Regards,
Zhi Yong Wu
Re: [Qemu-devel] [PATCH] hw/virtio-scsi: Set max_target=0 during vhost-scsi operation
HI,
Do we need to maintain one QEMU branch to collect all useful latest
patches for tcm_vhost support? You know, those patches will not get
merged into qemu.git/master.
On Thu, Jul 12, 2012 at 4:55 AM, Nicholas A. Bellinger
n...@linux-iscsi.org wrote:
From: Nicholas Bellinger n...@linux-iscsi.org
This QEMU patch sets VirtIOSCSIConfig-max_target=0 for vhost-scsi operation
to restrict virtio-scsi LLD guest scanning to max_id=0 (a single target ID
instance) when connected to individual tcm_vhost endpoints as requested by
Paolo.
This ensures that virtio-scsi LLD only attempts to scan target IDs up to
VIRTIO_SCSI_MAX_TARGET when connected via virtio-scsi-raw.
It's currently cut against Zhi's qemu vhost-scsi tree here:
https://github.com/wuzhy/qemu/tree/vhost-scsi
Cc: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
Cc: Zhi Yong Wu wu...@linux.vnet.ibm.com
Cc: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Nicholas Bellinger n...@linux-iscsi.org
---
hw/virtio-scsi.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/hw/virtio-scsi.c b/hw/virtio-scsi.c
index e38cdd0..71276b6 100644
--- a/hw/virtio-scsi.c
+++ b/hw/virtio-scsi.c
@@ -523,7 +523,11 @@ static void virtio_scsi_get_config(VirtIODevice *vdev,
stl_raw(scsiconf-sense_size, s-sense_size);
stl_raw(scsiconf-cdb_size, s-cdb_size);
stl_raw(scsiconf-max_channel, VIRTIO_SCSI_MAX_CHANNEL);
-stl_raw(scsiconf-max_target, VIRTIO_SCSI_MAX_TARGET);
+if (s-vhost_scsi) {
+stl_raw(scsiconf-max_target, 0);
+} else {
+stl_raw(scsiconf-max_target, VIRTIO_SCSI_MAX_TARGET);
+}
stl_raw(scsiconf-max_lun, VIRTIO_SCSI_MAX_LUN);
}
--
1.7.2.5
--
You received this message because you are subscribed to the Google Groups
Linux-iSCSI.org Target Development group.
To post to this group, send email to linux-iscsi-target-...@googlegroups.com.
To unsubscribe from this group, send email to
linux-iscsi-target-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/linux-iscsi-target-dev?hl=en.
--
Regards,
Zhi Yong Wu
Re: [Qemu-devel] [RFC 0/7] qcow2: implement lazy refcounts optimization
On Fri, Jun 22, 2012 at 11:08 PM, Stefan Hajnoczi stefa...@linux.vnet.ibm.com wrote: This series aims to improve qcow2 performance with cache=writethrough and cache=directsync. In particular it reduces the impact of metadata updates for What does cache=directsync mean? what is the difference between them? allocating writes. Allocating writes are expensive because they involve updating L2 tables and refcount blocks. In addition they can also cause L2 table allocation and refcount block allocation but these remain unaffected by this optimization. The key insight is that refcounts are not required to access data in the image. Can you elaborate this? why? This means that we can postpone refcount updates without violating the data integrity guarantee that cache=writethrough and cache=directsync give. The trade-off for postponing refcount updates is that the image may not be completely consistent in case of power failure or crash. If the image is dirty then it must be repaired before performing further modifications, in other words we need an fsck-like scan on startup. I don't have performance results to share yet but I wanted to get the code out there. The bigger picture is that this optimization should help make qcow2 a good choice even for cache=writethrough and cache=directsync where QED has traditionally had an advantage due to less metadata - this allows us to converge image format development in QEMU around the qcow2v3 format. Why do we design one new image format? e.g. use btree to manage metadata and disk data layout? Since btree has a lot of advantages than bitmap or tables. Stefan Hajnoczi (7): docs: add dirty bit to qcow2 specification qcow2: introduce dirty bit docs: add lazy refcounts bit to qcow2 specification qemu-iotests: ignore qemu-img create lazy_refcounts output qcow2: implement lazy refcounts qemu-io: add abort command to simulate program crash qemu-iotests: add 039 qcow2 lazy refcounts test block/qcow2-cluster.c | 5 +- block/qcow2.c | 111 +++--- block/qcow2.h | 11 + block_int.h | 26 +- docs/specs/qcow2.txt | 12 - qemu-io.c | 12 + tests/qemu-iotests/039 | 99 + tests/qemu-iotests/039.out | 34 + tests/qemu-iotests/common.rc | 3 +- tests/qemu-iotests/group | 1 + 10 files changed, 292 insertions(+), 22 deletions(-) create mode 100755 tests/qemu-iotests/039 create mode 100644 tests/qemu-iotests/039.out -- 1.7.10 -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH v6 00/17] hub-based networking patchset
pull? On Thu, Jun 21, 2012 at 9:14 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Wed, Jun 20, 2012 at 10:42 AM, zwu.ker...@gmail.com wrote: From: Zhi Yong Wu wu...@linux.vnet.ibm.com All comments have been addressed and stefan has completed one more reviewing. For this patchset, my git repo: g...@github.com:wuzhy/qemu.git for-anthony Changelog from v5: 1.) cleanup VLANState in other targets files [anthony] v5: 1.) roll back qdev_prop_vlan [stefanha] v4: 1.) refactor hub own flow control [paolo] 2.) refactor the output for monitor command info network [jan kiszka] v3: 1.) add the support for hub own flow control [paolo] 2.) make the monitor output more reasonable hub info [jan kiszka] v2: 1.) cleanup some obsolete vlan info 2.) cleanup deliver/deliver_iov func pointers [paolo] 3.) support more flexible flow control [paolo] Stefan Hajnoczi (12): net: Add a hub net client net: Use hubs for the vlan feature net: Look up 'vlan' net clients using hubs hub: Check that hubs are configured correctly net: Drop vlan argument to qemu_new_net_client() net: Remove vlan qdev property net: Remove vlan code from net.c net: Remove VLANState net: Rename non_vlan_clients to net_clients net: Rename VLANClientState to NetClientState net: Rename vc local variables to nc net: Rename qemu_del_vlan_client() to qemu_del_net_client() Zhi Yong Wu (5): net: Make info network output more readable info net: cleanup deliver/deliver_iov func pointers net: determine if packets can be sent before net queue deliver packets hub: add the support for hub own flow control net: roll back qdev_prop_vlan hw/cadence_gem.c | 8 +- hw/dp8393x.c | 7 +- hw/e1000.c | 10 +- hw/eepro100.c | 8 +- hw/etraxfs_eth.c | 8 +- hw/exynos4_boards.c | 2 +- hw/highbank.c | 2 +- hw/integratorcp.c | 2 +- hw/lan9118.c | 8 +- hw/lance.c | 2 +- hw/mcf5208.c | 2 +- hw/mcf_fec.c | 7 +- hw/milkymist-minimac2.c | 6 +- hw/mips_mipssim.c | 2 +- hw/mips_r4k.c | 2 +- hw/mipsnet.c | 6 +- hw/musicpal.c | 6 +- hw/ne2000-isa.c | 2 +- hw/ne2000.c | 8 +- hw/ne2000.h | 4 +- hw/opencores_eth.c | 8 +- hw/pcnet-pci.c | 4 +- hw/pcnet.c | 6 +- hw/pcnet.h | 6 +- hw/qdev-properties.c | 53 +++-- hw/qdev.c | 2 - hw/qdev.h | 7 +- hw/rtl8139.c | 10 +- hw/smc91c111.c | 6 +- hw/spapr_llan.c | 4 +- hw/stellaris_enet.c | 6 +- hw/usb/dev-network.c | 8 +- hw/vexpress.c | 2 +- hw/vhost_net.c | 24 +- hw/vhost_net.h | 2 +- hw/virtio-net.c | 12 +- hw/xen_nic.c | 7 +- hw/xgmac.c | 6 +- hw/xilinx_axienet.c | 6 +- hw/xilinx_ethlite.c | 6 +- hw/xtensa_lx60.c | 2 +- net.c | 593 ++- net.h | 87 net/Makefile.objs | 2 +- net/dump.c | 27 ++- net/dump.h | 2 +- net/hub.c | 335 ++ net/hub.h | 29 +++ net/queue.c | 37 ++-- net/queue.h | 25 +-- net/slirp.c | 32 +-- net/slirp.h | 2 +- net/socket.c | 66 +++--- net/socket.h | 2 +- net/tap-win32.c | 26 +- net/tap.c | 44 ++-- net/tap.h | 20 +- net/vde.c | 16 +- net/vde.h | 2 +- qemu-common.h | 3 +- slirp/if.c | 5 - slirp/libslirp.h | 1 - 62 files changed, 868 insertions(+), 777 deletions(-) create mode 100644 net/hub.c create mode 100644 net/hub.h It successfully builds all targets now. Other than that the code hasn't changed since the time I last reviewed. Stefan -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH v2 0/3] Some socket fix patches
pull? On Wed, Jun 20, 2012 at 5:46 PM, zwu.ker...@gmail.com wrote: From: Zhi Yong Wu wu...@linux.vnet.ibm.com The patchset is on top of hub-based networking patchset. For this patchset, my git repo: g...@github.com:wuzhy/qemu.git for-anthony Zhi Yong Wu (3): net: fix the coding style net: add the support for -netdev socket, listen net: complete NetSocketState lifecycle handling net/socket.c | 82 +++-- 1 files changed, 50 insertions(+), 32 deletions(-) -- 1.7.6 -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH] net: roll back qdev_prop_vlan
Good catch, thanks, please next version.
On Mon, Jun 18, 2012 at 6:22 PM, Stefan Hajnoczi
stefa...@linux.vnet.ibm.com wrote:
On Sun, Jun 17, 2012 at 12:30:32AM +0800, zwu.ker...@gmail.com wrote:
+static int print_vlan(DeviceState *dev, Property *prop, char *dest, size_t
len)
+{
+ NetClientState **ptr = qdev_get_prop_ptr(dev, prop);
+
+ if (*ptr) {
+ unsigned int id;
+ if (!net_hub_id_for_client(*ptr, id)) {
+ return snprintf(dest, len, %d, id);
Unsigned int should be %u. Source code scanners or the compiler could
warn about this so it's worth changing.
+ }
+ }
+
+ return snprintf(dest, len, null);
+}
+
+static void get_vlan(Object *obj, Visitor *v, void *opaque,
+ const char *name, Error **errp)
+{
+ DeviceState *dev = DEVICE(obj);
+ Property *prop = opaque;
+ NetClientState **ptr = qdev_get_prop_ptr(dev, prop);
+ int64_t id = -1;
+
+ if (*ptr) {
+ unsigned int hub_id;
+ net_hub_id_for_client(*ptr, hub_id);
It's unclear what happens if net_hub_id_for_client() fails but it looks
like hub_id may be uninitialized.
Stefan
--
Regards,
Zhi Yong Wu
[Qemu-devel] The latest qemu.git/master build break
HI, When i want to rebase my hub-based network patchset to latest qemu.git/master, i found the build break. lt LINK libcacard.la ar: libcacard/cac.o: No such file or directory make[1]: *** [libcacard.la] Error 1 make: *** [subdir-libcacard] Error 2 -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH 3/3] net: complete NetSocketS?tate lifecycle handling
please ignore this. thanks.
On Tue, Jun 19, 2012 at 1:13 AM, zwu.ker...@gmail.com wrote:
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
The NetSocketState struct contains two file descriptors: an active
connection and a listen socket for new connections. It's important that
we clean up after ourselves so these file descriptors are initialized to
-1 when unused. This allows makes it possible to call cleanup functions
only when the file descriptors are valid (not -1).
The specific issue solved by this patch is that we avoid calling
close(-1), close(0), and qemu_set_fd_handler(-1, net_socket_accept,
NULL, s). All of these are either problematic or unclean (e.g. reported
as warnings by Valgrind).
Also stay consistent by bringing the link down when the active
connection is closed.
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
net/socket.c | 24 +++-
1 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/net/socket.c b/net/socket.c
index 408d00e..9b15479 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -82,13 +82,16 @@ static void net_socket_send(void *opaque)
/* end of connection */
eoc:
qemu_set_fd_handler(s-fd, NULL, NULL, NULL);
- qemu_set_fd_handler(s-listen_fd, net_socket_accept, NULL, s);
+ if (s-listen_fd != -1) {
+ qemu_set_fd_handler(s-listen_fd, net_socket_accept, NULL, s);
+ }
closesocket(s-fd);
s-fd = -1;
s-state = 0;
s-index = 0;
s-packet_len = 0;
+ s-nc.link_down = true;
memset(s-buf, 0, sizeof(s-buf));
memset(s-nc.info_str, 0, sizeof(s-nc.info_str));
@@ -239,8 +242,16 @@ fail:
static void net_socket_cleanup(NetClientState *nc)
{
NetSocketState *s = DO_UPCAST(NetSocketState, nc, nc);
- qemu_set_fd_handler(s-fd, NULL, NULL, NULL);
- close(s-fd);
+ if (s-fd != -1) {
+ qemu_set_fd_handler(s-fd, NULL, NULL, NULL);
+ close(s-fd);
+ s-fd = -1;
+ }
+ if (s-listen_fd != -1) {
+ qemu_set_fd_handler(s-listen_fd, NULL, NULL, NULL);
+ closesocket(s-listen_fd);
+ s-listen_fd = -1;
+ }
}
static NetClientInfo net_dgram_socket_info = {
@@ -302,6 +313,7 @@ static NetSocketState
*net_socket_fd_init_dgram(NetClientState *peer,
s = DO_UPCAST(NetSocketState, nc, nc);
s-fd = fd;
+ s-listen_fd = -1;
qemu_set_fd_handler(s-fd, net_socket_send_dgram, NULL, s);
@@ -345,6 +357,7 @@ static NetSocketState
*net_socket_fd_init_stream(NetClientState *peer,
s = DO_UPCAST(NetSocketState, nc, nc);
s-fd = fd;
+ s-listen_fd = -1;
if (is_connected) {
net_socket_connect(s);
@@ -411,7 +424,7 @@ static int net_socket_listen_init(NetClientState *peer,
const char *name,
const char *host_str)
{
- VLANClientState *nc;
+ NetClientState *nc;
NetSocketState *s;
struct sockaddr_in saddr;
int fd, val, ret;
@@ -443,8 +456,9 @@ static int net_socket_listen_init(NetClientState *peer,
return -1;
}
- nc = qemu_new_net_client(net_socket_info, vlan, NULL, model, name);
+ nc = qemu_new_net_client(net_socket_info, peer, model, name);
s = DO_UPCAST(NetSocketState, nc, nc);
+ s-fd = -1;
s-listen_fd = fd;
s-nc.link_down = true;
--
1.7.6
--
Regards,
Zhi Yong Wu
Re: [Qemu-devel] The latest qemu.git/master build break
On Mon, Jun 18, 2012 at 11:37 PM, Dunrong Huang riegama...@gmail.com wrote: 2012/6/18 Zhi Yong Wu zwu.ker...@gmail.com: HI, When i want to rebase my hub-based network patchset to latest qemu.git/master, i found the build break. lt LINK libcacard.la ar: libcacard/cac.o: No such file or directory make[1]: *** [libcacard.la] Error 1 make: *** [subdir-libcacard] Error 2 I also get this error, my solution is to delete the temporary file by: rm -rf libcacard/libcacard rm -rf libcacard/trace I think there should be a better way to solve it. You can disable smartcard config to workaround this issue. -- Regards, Zhi Yong Wu -- Regards, Dunrong Huang blog: http://mathslinux.org twitter: https://twitter.com/mathslinux google+: https://plus.google.com/118129852578326338750 -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH] net: complete NetSocketState lifecycle handling
On Tue, Jun 12, 2012 at 10:04 PM, Stefan Hajnoczi
stefa...@linux.vnet.ibm.com wrote:
The NetSocketState struct contains two file descriptors: an active
connection and a listen socket for new connections. It's important that
we clean up after ourselves so these file descriptors are initialized to
-1 when unused. This allows makes it possible to call cleanup functions
only when the file descriptors are valid (not -1).
The specific issue solved by this patch is that we avoid calling
close(-1), close(0), and qemu_set_fd_handler(-1, net_socket_accept,
NULL, s). All of these are either problematic or unclean (e.g. reported
as warnings by Valgrind).
Also stay consistent by bringing the link down when the active
connection is closed.
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
This patch adds additional fixes on top of Zhi Yong's first 2 patches. With
this patch in place I'm happy with this series.
net/socket.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/net/socket.c b/net/socket.c
index f67de47..403221c 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -82,13 +82,16 @@ static void net_socket_send(void *opaque)
/* end of connection */
eoc:
qemu_set_fd_handler(s-fd, NULL, NULL, NULL);
- qemu_set_fd_handler(s-listen_fd, net_socket_accept, NULL, s);
+ if (s-listen_fd != -1) {
+ qemu_set_fd_handler(s-listen_fd, net_socket_accept, NULL, s);
+ }
closesocket(s-fd);
s-fd = -1;
s-state = 0;
s-index = 0;
s-packet_len = 0;
+ s-nc.link_down = true;
memset(s-buf, 0, sizeof(s-buf));
memset(s-nc.info_str, 0, sizeof(s-nc.info_str));
@@ -239,8 +242,16 @@ fail:
static void net_socket_cleanup(VLANClientState *nc)
{
NetSocketState *s = DO_UPCAST(NetSocketState, nc, nc);
- qemu_set_fd_handler(s-fd, NULL, NULL, NULL);
- close(s-fd);
+ if (s-fd != -1) {
+ qemu_set_fd_handler(s-fd, NULL, NULL, NULL);
+ close(s-fd);
+ s-fd = -1;
+ }
+ if (s-listen_fd != -1) {
+ qemu_set_fd_handler(s-listen_fd, NULL, NULL, NULL);
+ closesocket(s-listen_fd);
+ s-listen_fd = -1;
+ }
}
static NetClientInfo net_dgram_socket_info = {
@@ -302,6 +313,7 @@ static NetSocketState *net_socket_fd_init_dgram(VLANState
*vlan,
s = DO_UPCAST(NetSocketState, nc, nc);
s-fd = fd;
+ s-listen_fd = -1;
qemu_set_fd_handler(s-fd, net_socket_send_dgram, NULL, s);
@@ -345,6 +357,7 @@ static NetSocketState
*net_socket_fd_init_stream(VLANState *vlan,
s = DO_UPCAST(NetSocketState, nc, nc);
s-fd = fd;
+ s-listen_fd = -1;
if (is_connected) {
net_socket_connect(s);
@@ -445,6 +458,7 @@ static int net_socket_listen_init(VLANState *vlan,
nc = qemu_new_net_client(net_socket_info, vlan, NULL, model, name);
s = DO_UPCAST(NetSocketState, nc, nc);
+ s-fd = -1;
s-listen_fd = fd;
s-nc.link_down = true;
--
1.7.10
Reviewed-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
--
Regards,
Zhi Yong Wu
Re: [Qemu-devel] [PATCH v4 06/16] net: Remove vlan qdev property
On Mon, Jun 11, 2012 at 2:28 PM, Paolo Bonzini pbonz...@redhat.com wrote: Il 09/06/2012 05:04, Zhi Yong Wu ha scritto: This commit looks suspicious because it removes a user-visible qdev property but we're trying to preserve backward compatibility. This command-line will break: x86_64-softmmu/qemu-system-x86_64 -net user,vlan=1 -device virtio-net-pci,vlan=1 Instead of dropping the qdev_prop_vlan completely the hw/qdev-properties.c code needs to call net/hub.h external functions to implement equivalent functionality: 1. Setting the vlan=id property looks up the hub port and assigns the NICConf-peer field. 2. Getting the vlan property looks up the hub id (i.e. vlan id) given the peer. If the peer is not a hub port the result is -1. When I wrote this patch I missed the big picture and forgot about backwards compatibility :(. To be honest, i am concerned if anyone uses this syntax. Since the feature will finally be discarded, i suggest that we don't support this now. If someone complains this later, we can fix it. If nobody complains, that is what we hope. I think you're missing the big picture of this series, which is exactly _not_ to discard the VLAN feature, but just to rewrite it in a better way. Yeah, i know that this series are rewriting VLAN feature in one better way. What i mean was that luiz and other some guys think that the -net syntax should be completely removed. That said, I agree that this is a somewhat fringe usage; most people will use -net nic,model=virtio,vlan=1 rather than -device. We may get Yes. by with dropping it. I have no strong opinion either way. Paolo -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH v4 06/16] net: Remove vlan qdev property
On Mon, Jun 11, 2012 at 4:57 PM, Stefan Hajnoczi stefa...@linux.vnet.ibm.com wrote: On Mon, Jun 11, 2012 at 08:28:57AM +0200, Paolo Bonzini wrote: Il 09/06/2012 05:04, Zhi Yong Wu ha scritto: This commit looks suspicious because it removes a user-visible qdev property but we're trying to preserve backward compatibility. This command-line will break: x86_64-softmmu/qemu-system-x86_64 -net user,vlan=1 -device virtio-net-pci,vlan=1 Instead of dropping the qdev_prop_vlan completely the hw/qdev-properties.c code needs to call net/hub.h external functions to implement equivalent functionality: 1. Setting the vlan=id property looks up the hub port and assigns the NICConf-peer field. 2. Getting the vlan property looks up the hub id (i.e. vlan id) given the peer. If the peer is not a hub port the result is -1. When I wrote this patch I missed the big picture and forgot about backwards compatibility :(. To be honest, i am concerned if anyone uses this syntax. Since the feature will finally be discarded, i suggest that we don't support this now. If someone complains this later, we can fix it. If nobody complains, that is what we hope. I think you're missing the big picture of this series, which is exactly _not_ to discard the VLAN feature, but just to rewrite it in a better way. That said, I agree that this is a somewhat fringe usage; most people will use -net nic,model=virtio,vlan=1 rather than -device. We may get by with dropping it. I have no strong opinion either way. Either we keep backwards compatibility or we don't. Taking a middle path where we preserve only some of the VLAN syntax is confusing and inconsistent. in terms of technology, i fully agree with you, but in terms of usefulness and our business, it will waste our effort, time and is meaningless if nobody or no customers use this syntax. As i said, if someone complain this later, we can fix it. Like Paolo said, the point here is not to drop VLAN support. We're simply moving this feature into a regular net client (the hub) so that the special case VLAN code in net.c can be removed. Stefan -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH v4 06/16] net: Remove vlan qdev property
On Mon, Jun 11, 2012 at 10:42 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Mon, Jun 11, 2012 at 3:24 PM, Zhi Yong Wu zwu.ker...@gmail.com wrote: On Mon, Jun 11, 2012 at 4:57 PM, Stefan Hajnoczi stefa...@linux.vnet.ibm.com wrote: On Mon, Jun 11, 2012 at 08:28:57AM +0200, Paolo Bonzini wrote: Il 09/06/2012 05:04, Zhi Yong Wu ha scritto: This commit looks suspicious because it removes a user-visible qdev property but we're trying to preserve backward compatibility. This command-line will break: x86_64-softmmu/qemu-system-x86_64 -net user,vlan=1 -device virtio-net-pci,vlan=1 Instead of dropping the qdev_prop_vlan completely the hw/qdev-properties.c code needs to call net/hub.h external functions to implement equivalent functionality: 1. Setting the vlan=id property looks up the hub port and assigns the NICConf-peer field. 2. Getting the vlan property looks up the hub id (i.e. vlan id) given the peer. If the peer is not a hub port the result is -1. When I wrote this patch I missed the big picture and forgot about backwards compatibility :(. To be honest, i am concerned if anyone uses this syntax. Since the feature will finally be discarded, i suggest that we don't support this now. If someone complains this later, we can fix it. If nobody complains, that is what we hope. I think you're missing the big picture of this series, which is exactly _not_ to discard the VLAN feature, but just to rewrite it in a better way. That said, I agree that this is a somewhat fringe usage; most people will use -net nic,model=virtio,vlan=1 rather than -device. We may get by with dropping it. I have no strong opinion either way. Either we keep backwards compatibility or we don't. Taking a middle path where we preserve only some of the VLAN syntax is confusing and inconsistent. in terms of technology, i fully agree with you, but in terms of usefulness and our business, it will waste our effort, time and is meaningless if nobody or no customers use this syntax. As i said, if someone complain this later, we can fix it. When users upgrade QEMU versions and find their setup is now broken QEMU's reputation will be damaged. You can't build critical systems on top of software which keeps changing and breaking. Fixing it after a user hits the problem is not okay, users won't trust us if we do that. OK, i will try to work on this. We need to be disciplined when it comes to backwards compatibility. Either we support the VLAN feature or we drop it. We already had this discussion in another thread, here's what Anthony had to say: Dropping features is only something that should be approached lightly and certainly not something that should be done just because you don't like a particular bit of code. http://permalink.gmane.org/gmane.comp.emulators.qemu/153600 Stefan -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH v4 06/16] net: Remove vlan qdev property
On Tue, Jun 12, 2012 at 4:05 AM, Luiz Capitulino lcapitul...@redhat.com wrote: On Mon, 11 Jun 2012 22:15:55 +0800 Zhi Yong Wu zwu.ker...@gmail.com wrote: On Mon, Jun 11, 2012 at 2:28 PM, Paolo Bonzini pbonz...@redhat.com wrote: Il 09/06/2012 05:04, Zhi Yong Wu ha scritto: This commit looks suspicious because it removes a user-visible qdev property but we're trying to preserve backward compatibility. This command-line will break: x86_64-softmmu/qemu-system-x86_64 -net user,vlan=1 -device virtio-net-pci,vlan=1 Instead of dropping the qdev_prop_vlan completely the hw/qdev-properties.c code needs to call net/hub.h external functions to implement equivalent functionality: 1. Setting the vlan=id property looks up the hub port and assigns the NICConf-peer field. 2. Getting the vlan property looks up the hub id (i.e. vlan id) given the peer. If the peer is not a hub port the result is -1. When I wrote this patch I missed the big picture and forgot about backwards compatibility :(. To be honest, i am concerned if anyone uses this syntax. Since the feature will finally be discarded, i suggest that we don't support this now. If someone complains this later, we can fix it. If nobody complains, that is what we hope. I think you're missing the big picture of this series, which is exactly _not_ to discard the VLAN feature, but just to rewrite it in a better way. Yeah, i know that this series are rewriting VLAN feature in one better way. What i mean was that luiz and other some guys think that the -net syntax should be completely removed. One of the motivations for having the hub feature is to preserve the vlan functionality, in that case we shouldn't break cmd-line backwards compatibility. OK, thanks. -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH v5 2/2] net: add the support for -netdev socket, listen
On Fri, Jun 8, 2012 at 6:31 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Thu, Jun 7, 2012 at 3:54 PM, zwu.ker...@gmail.com wrote: @@ -86,7 +82,16 @@ static void net_socket_send(void *opaque) /* end of connection */ eoc: qemu_set_fd_handler(s-fd, NULL, NULL, NULL); + qemu_set_fd_handler(s-listen_fd, net_socket_accept, NULL, s); What happens when this is not a listen socket? I suggest setting listen_fd to -1 during creation and not calling qemu_set_fd_handler() listen_fd isn't -1 here, and is one valid value when this function is executed. when listen_fd is -1 here. If listen_fd is 0 then we'll register net_socket_accept when standard input becomes ready! closesocket(s-fd); + + s-fd = 0; -1 should be used since 0 is a valid file descriptor (standard input). OK. done, but In fact, some other places default fd to zero. Stefan -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH v5 2/2] net: add the support for -netdev socket, listen
On Fri, Jun 8, 2012 at 10:20 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Fri, Jun 8, 2012 at 3:15 PM, Zhi Yong Wu zwu.ker...@gmail.com wrote: On Fri, Jun 8, 2012 at 6:31 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Thu, Jun 7, 2012 at 3:54 PM, zwu.ker...@gmail.com wrote: @@ -86,7 +82,16 @@ static void net_socket_send(void *opaque) /* end of connection */ eoc: qemu_set_fd_handler(s-fd, NULL, NULL, NULL); + qemu_set_fd_handler(s-listen_fd, net_socket_accept, NULL, s); What happens when this is not a listen socket? I suggest setting listen_fd to -1 during creation and not calling qemu_set_fd_handler() listen_fd isn't -1 here, and is one valid value when this function is executed. when listen_fd is -1 here. If listen_fd is 0 then we'll register net_socket_accept when standard input becomes ready! closesocket(s-fd); + + s-fd = 0; -1 should be used since 0 is a valid file descriptor (standard input). OK. done, but In fact, some other places default fd to zero. Where? Maybe those places need to be fixed too. The danger with fd=0 In qemu_new_net_client(), you can see vc = g_malloc0(info-size);. If it will create one socket net client, it will default fd to zero. is that we call functions like read()/write()/close() on standard input by mistake. Stefan -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH v5 2/2] net: add the support for -netdev socket, listen
On Fri, Jun 8, 2012 at 10:20 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Fri, Jun 8, 2012 at 3:15 PM, Zhi Yong Wu zwu.ker...@gmail.com wrote: On Fri, Jun 8, 2012 at 6:31 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Thu, Jun 7, 2012 at 3:54 PM, zwu.ker...@gmail.com wrote: @@ -86,7 +82,16 @@ static void net_socket_send(void *opaque) /* end of connection */ eoc: qemu_set_fd_handler(s-fd, NULL, NULL, NULL); + qemu_set_fd_handler(s-listen_fd, net_socket_accept, NULL, s); What happens when this is not a listen socket? I suggest setting listen_fd to -1 during creation and not calling qemu_set_fd_handler() listen_fd isn't -1 here, and is one valid value when this function is executed. when listen_fd is -1 here. If listen_fd is 0 then we'll register net_socket_accept when standard input becomes ready! closesocket(s-fd); + + s-fd = 0; -1 should be used since 0 is a valid file descriptor (standard input). OK. done, but In fact, some other places default fd to zero. Where? Maybe those places need to be fixed too. The danger with fd=0 is that we call functions like read()/write()/close() on standard input by mistake. When net_socket_accept() is registered, fd/listen_fd has been not zero in our codes. So that case you said will not happen for our codes. Stefan -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH v4 06/16] net: Remove vlan qdev property
On Fri, Jun 8, 2012 at 9:23 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Mon, Jun 4, 2012 at 6:29 AM, zwu.ker...@gmail.com wrote: From: Stefan Hajnoczi stefa...@linux.vnet.ibm.com The vlan feature is implemented using hubs and no longer uses special-purpose VLANState structs that are accessible as qdev properties. Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com --- hw/qdev-properties.c | 72 -- hw/qdev.c | 2 - hw/qdev.h | 4 --- net.h | 3 -- 4 files changed, 0 insertions(+), 81 deletions(-) This commit looks suspicious because it removes a user-visible qdev property but we're trying to preserve backward compatibility. This command-line will break: x86_64-softmmu/qemu-system-x86_64 -net user,vlan=1 -device virtio-net-pci,vlan=1 Should this type of syntax be supported? i know this at the first time Instead of dropping the qdev_prop_vlan completely the hw/qdev-properties.c code needs to call net/hub.h external functions to implement equivalent functionality: 1. Setting the vlan=id property looks up the hub port and assigns the NICConf-peer field. 2. Getting the vlan property looks up the hub id (i.e. vlan id) given the peer. If the peer is not a hub port the result is -1. When I wrote this patch I missed the big picture and forgot about backwards compatibility :(. Do you feel comfortable rewriting this commit? Do you mean that you would like to rewrite this by yourself? Stefan -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH v5 2/2] net: add the support for -netdev socket, listen
On Fri, Jun 8, 2012 at 6:31 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Thu, Jun 7, 2012 at 3:54 PM, zwu.ker...@gmail.com wrote: @@ -86,7 +82,16 @@ static void net_socket_send(void *opaque) /* end of connection */ eoc: qemu_set_fd_handler(s-fd, NULL, NULL, NULL); + qemu_set_fd_handler(s-listen_fd, net_socket_accept, NULL, s); What happens when this is not a listen socket? I suggest setting listen_fd to -1 during creation and not calling qemu_set_fd_handler() when listen_fd is -1 here. If listen_fd is 0 then we'll register net_socket_accept when standard input becomes ready! closesocket(s-fd); + + s-fd = 0; -1 should be used since 0 is a valid file descriptor (standard input). I think that s-fd = 0 doesn't cause every issue. When it is zero, this fd hasn't been registered with every handler. You can see that qemu_set_fd_handler(s-fd, NULL, NULL, NULL); before s-fd = 0. Stefan -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH v5 2/2] net: add the support for -netdev socket, listen
On Fri, Jun 8, 2012 at 11:59 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Fri, Jun 8, 2012 at 3:54 PM, Zhi Yong Wu zwu.ker...@gmail.com wrote: On Fri, Jun 8, 2012 at 6:31 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Thu, Jun 7, 2012 at 3:54 PM, zwu.ker...@gmail.com wrote: @@ -86,7 +82,16 @@ static void net_socket_send(void *opaque) /* end of connection */ eoc: qemu_set_fd_handler(s-fd, NULL, NULL, NULL); + qemu_set_fd_handler(s-listen_fd, net_socket_accept, NULL, s); What happens when this is not a listen socket? I suggest setting listen_fd to -1 during creation and not calling qemu_set_fd_handler() when listen_fd is -1 here. If listen_fd is 0 then we'll register net_socket_accept when standard input becomes ready! closesocket(s-fd); + + s-fd = 0; -1 should be used since 0 is a valid file descriptor (standard input). I think that s-fd = 0 doesn't cause every issue. When it is zero, this fd hasn't been registered with every handler. You can see that qemu_set_fd_handler(s-fd, NULL, NULL, NULL); before s-fd = 0. If s-fd = 0 because we are still listening and net_socket_cleanup() OK, done. any other issue? is called we will close() standard input. Stefan -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH v4 06/16] net: Remove vlan qdev property
On Sat, Jun 9, 2012 at 12:09 AM, Stefan Hajnoczi stefa...@gmail.com wrote: On Fri, Jun 8, 2012 at 3:48 PM, Zhi Yong Wu zwu.ker...@gmail.com wrote: On Fri, Jun 8, 2012 at 9:23 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Mon, Jun 4, 2012 at 6:29 AM, zwu.ker...@gmail.com wrote: From: Stefan Hajnoczi stefa...@linux.vnet.ibm.com The vlan feature is implemented using hubs and no longer uses special-purpose VLANState structs that are accessible as qdev properties. Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com --- hw/qdev-properties.c | 72 -- hw/qdev.c | 2 - hw/qdev.h | 4 --- net.h | 3 -- 4 files changed, 0 insertions(+), 81 deletions(-) This commit looks suspicious because it removes a user-visible qdev property but we're trying to preserve backward compatibility. This command-line will break: x86_64-softmmu/qemu-system-x86_64 -net user,vlan=1 -device virtio-net-pci,vlan=1 Should this type of syntax be supported? i know this at the first time Instead of dropping the qdev_prop_vlan completely the hw/qdev-properties.c code needs to call net/hub.h external functions to implement equivalent functionality: 1. Setting the vlan=id property looks up the hub port and assigns the NICConf-peer field. 2. Getting the vlan property looks up the hub id (i.e. vlan id) given the peer. If the peer is not a hub port the result is -1. When I wrote this patch I missed the big picture and forgot about backwards compatibility :(. Do you feel comfortable rewriting this commit? Do you mean that you would like to rewrite this by yourself? No, I meant do you agree with the changes that I suggested? I wanted to make sure that you understand the problem that I'm describing and how it could be solved. To be honest, i am concerned if anyone uses this syntax. Since the feature will finally be discarded, i suggest that we don't support this now. If someone complains this later, we can fix it. If nobody complains, that is what we hope. Stefan -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH v4] net: add the support for -netdev socket, listen
On Thu, Jun 7, 2012 at 6:08 PM, Stefan Hajnoczi stefa...@linux.vnet.ibm.com wrote: On Wed, Jun 06, 2012 at 09:26:23PM +0800, zwu.ker...@gmail.com wrote: From: Zhi Yong Wu wu...@linux.vnet.ibm.com The -net socket,listen option does not work with the newer -netdev syntax: http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg01508.html This patch makes it work now. For the case where one vlan has multiple listenning sockets, the patch will also provide the support. Supported syntax: 1.) -net socket,listen=127.0.0.1:1234,vlan=0 2.) -net socket,listen=127.0.0.1:1234,vlan=0 -net socket,listen=127.0.0.1:1235,vlan=0 3.) -netdev socket,listen=127.0.0.1:1234,id=socket0 Suggested-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com --- net.c | 24 +++ net.h | 3 + net/socket.c | 123 ++--- 3 files changed, 117 insertions(+), 33 deletions(-) Please include changelogs in new versions of patches. It looks like you have implemented 1 connection at a time semantics. This is good, I think it maps best to the netdev peer model. Allowing multiple clients to connect to a single listen socket at the same time doesn't fit into the netdev peer model. I think the patch can be simplified a lot though. There's no need to modify net.c or add consumed booleans. Instead, drop the NetSocketListenState struct and add a listen_fd field to NetSocketState. When a -netdev socket,listen= instance is created there will be a NetSocketState with fd=-1 and a valid listen_fd. The Have you considered the case where there're mulitple -net socket,listen= instance in one vlan? net_socket_accept() handler waits for listen_fd to become readable and then accepts the connection. When this state transition happens, we no longer monitor listen_fd for incoming connections...until the client disconnects again. This approach doesn't need to change net.c or VLANClientState. It also makes memory allocation simpler because we only have 1 struct: NetSocketState. Stefan -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH v4] net: add the support for -netdev socket, listen
On Thu, Jun 7, 2012 at 10:16 PM, Paolo Bonzini pbonz...@redhat.com wrote: Il 07/06/2012 14:49, Zhi Yong Wu ha scritto: Instead, drop the NetSocketListenState struct and add a listen_fd field to NetSocketState. When a -netdev socket,listen= instance is created there will be a NetSocketState with fd=-1 and a valid listen_fd. The Have you considered the case where there're mulitple -net socket,listen= instance in one vlan? Why should that matter? They will have different NetSocketState and different listen_fds. Each socket will discard incoming packets until the other side connects. You are correct, thanks, please see next version. Paolo -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [Bug 1003054] Re: Socket not closed when a connection ends
Please check my patch: [PATCH v4] net: add the support for -netdev socket, listen It fix this issue. On Tue, May 29, 2012 at 7:04 PM, Vincent Autefage 1003...@bugs.launchpad.net wrote: This implies serious duplication problem in case of reboot : A [192.168.0.1] -- B [192.168.0.2] A# ping 192.168.0.1 PING 192.168.0.1 56(84) bytes of data 64 bytes from 192.168.0.1: icmp_req=1 ttl=64 time=3.82 ms 64 bytes from 192.168.0.1: icmp_req=2 ttl=64 time=0.344 ms 64 bytes from 192.168.0.1: icmp_req=3 ttl=64 time=0.325 ms B# reboot A# ping 192.168.0.1 PING 192.168.0.1 56(84) bytes of data 64 bytes from 192.168.0.1: icmp_req=1 ttl=64 time=3.82 ms 64 bytes from 192.168.0.1: icmp_req=1 ttl=64 time=3.82 ms (DUP!) 64 bytes from 192.168.0.1: icmp_req=2 ttl=64 time=0.344 ms 64 bytes from 192.168.0.1: icmp_req=2 ttl=64 time=0.344 ms (DUP!) 64 bytes from 192.168.0.1: icmp_req=3 ttl=64 time=0.325 ms 64 bytes from 192.168.0.1: icmp_req=3 ttl=64 time=0.325 ms (DUP!) Vince -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1003054 Title: Socket not closed when a connection ends Status in QEMU: New Bug description: Hi, I've noticed in the QEMU monitor that when a TCP connection between to QEMU virtual machines is closed in one side, the other side is not closed. Consequence is that the network behavior is completely messed up in case of a reconnection. For instance, we consider that we have 2 virtual machines : $ qemu -name A -net nic vlan=0 -net socket,vlan=0,listen=127.0.0.1:7000 $ qemu -name B -net nic vlan=0 -net socket,vlan=0,connect=127.0.0.1:7000 If the socket of B is closed (error or machine down), the socket in A is not closed : B % host_net_remove 0 socket.0 A % info network e1000.0: ... socket.0: ... (The removed connection) B % host_net_add socket vlan=0,connect=127.0.0.1:7000 A % info network e1000.0: ... socket.0: ... (The removed connection) socket.1: ... (The new connection) By not perform any close on sockets of A, the new communication between A and B is corrupted (duplicated packets, invalid transmission, etc.). In the case of the close was performed by A, B should detect a problem on the socket and retry a new connection, unfortunately, this is not the case. Those two problems corrupt the dynamicity of a QEMU topology which could be strongly problematic for the development of network tools based on QEMU. Thanks a lot. Vince To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1003054/+subscriptions -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH block-next 0/3] qemu-img check/qcow2: Allow fixing refcounts
On Wed, Jun 6, 2012 at 6:32 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Fri, Jun 1, 2012 at 9:26 AM, Zhi Yong Wu zwu.ker...@gmail.com wrote: On Fri, Jun 1, 2012 at 4:06 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Fri, Jun 1, 2012 at 6:22 AM, Zhi Yong Wu zwu.ker...@gmail.com wrote: On Thu, May 31, 2012 at 5:26 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Wed, May 30, 2012 at 9:31 AM, Zhi Yong Wu zwu.ker...@gmail.com wrote: On Sat, May 12, 2012 at 12:48 AM, Kevin Wolf kw...@redhat.com wrote: A prerequisite for a QED mode in qcow2, which doesn't update the refcount Recently some new concepts such as QED mode in qcow2 are seen frequencely, can anyone explain what it means? thanks. qcow2 has more metadata than qed. More metadata means more write operations when allocating new clusters. In order to overcome this performance issue qcow2 has a metadata cache. But when QEMU is launched with -drive ...,cache=writethrough (the default) the metadata cache *must* be in writethrough mode Why must i be? If the option with -drive ..,cache=writethrough is specified. it means that host page cache is on while guest disk cache is off. Since the metadata cache exists in host page cache, not guest, i think that it is in writeback mode. Since the emulated disk write cache is off, we must ensure that guest writes are on disk before completing them. Therefore we cannot cache metadata updates in host RAM - it would be lost on power failure but But host page cache is *on* in this mode, which means that metadata should be cached in host RAM. how do you explain this? cache=writethrough means that the file is opened with O_SYNC. Every single write reaches the physical disk - that's why it's called a writethrough cache. Read requests, however, can be satisfied from the host page cache. In other words, cache=writethrough ensures that all data reaches the disk but may give performance benefits to read-heavy workloads (especially when guest RAM is much smaller than host RAM, so the host page cache would have a high hit rate). Ah, i see now, cache=writethrough mean that host page cache is applied to read request, not write. thanks. we promised the guest its writes reached the disk! instead of writeback mode. In other words, every metadata update needs to be written to the image file before we complete the guest's What will mean one guest's wirte request is completed? For example, virtio-blk fills in the success status code and raises an interrupt. This notifies the guest that the write is done. Great, thanks. write request. This means the metadata cache only hides the metadata performance issue when -drive ...,cache=direct|writeback are used because there we can keep metadata changes buffered in memory until the guest flushes the emulated disk write cache. QED mode is a solution for -drive ...,cache=writethrough|directsync. It simply doesn't update refcount metadata in the qcow2 image file l1/l2 info need to be updated to qcow2 image file? Yes, this is necessary to ensure written data is accessible in the future. Without the L1/L2 tables we cannot find the data we wrote. Stefan -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH v2] net: add the support for -netdev socket, listen
On Sun, Feb 26, 2012 at 10:48 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Sat, Feb 18, 2012 at 9:19 AM, zwu.ker...@gmail.com wrote: From: Zhi Yong Wu wu...@linux.vnet.ibm.com The -net socket,listen option does not work with the newer -netdev syntax: http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg01508.html This patch makes it work now. Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com --- net.c | 26 + net.h | 2 + net/socket.c | 72 +- 3 files changed, 84 insertions(+), 16 deletions(-) I wanted to understand the problem better so I tried out -net socket,listen=. Here is its behavior: 1. A client can connect to QEMU, this creates a new socket VLANClientState on the VLAN. 2. If another client connects to QEMU, another VLANClientState is created. That means many socket clients can be added to the same VLAN. 3. When a simple TCP client like netcat connects and then disconnects, the VLANClientState remains forever. There seems to be no cleanup. This patch does not handle the -net socket,listen= case where multiple clients connect. Also, the -netdev socket,listen= semantics cannot match -net socket-listen= semantics because there is only one peer at any time. Some options: 1. Do not accept new connections while a client is connected. Once the client disconnects we can accept a new connection. This maintains How will socket server know that the client disconnected? the 1-1 peer behavior. 2. Integrate with vlan-hub so that multiple clients can connect even with -netdev. Connections will create new NetClientStates and auto-attach to the hub. This mimics -net socket,listen= but requires a hub to be used. 3. Forbid -netdev socket,listen=, only allow -net socket,listen=. I think #1 would be okay, although it no longer allows multiple connections, but I don't have a strong opinion either way. Stefan -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PULL 1.2 00/16] hub-based networking patches
On Mon, Jun 4, 2012 at 12:51 PM, Anthony Liguori aligu...@us.ibm.com wrote: On 06/04/2012 10:46 AM, zwu.ker...@gmail.com wrote: From: Zhi Yong Wuwu...@linux.vnet.ibm.com All comments from other guys were addressed. v3 had review comments from Paolo that you acknowledged. I don't see a v4 on the list. You cannot do a pull request of unposted patches. I only post v4 for some of them, not all. OK. let me send all. Stefan, can I assume you Reviewed-by this whole series? I don't see any Stefan is on his UK holiday. But i guess that he should review them. explicit Reviewed-bys in v3. Regards, Anthony Liguori The following changes since commit a854972f8cdec0148087789d62777d8f7176933d: Update version to open the 1.2 development branch (Fri Jun 1 16:56:16 2012 +0800) are available in the git repository at: g...@github.com:wuzhy/qemu.git for-anthony Stefan Hajnoczi (12): net: Add a hub net client net: Use hubs for the vlan feature net: Look up 'vlan' net clients using hubs hub: Check that hubs are configured correctly net: Drop vlan argument to qemu_new_net_client() net: Remove vlan qdev property net: Remove vlan code from net.c net: Remove VLANState net: Rename non_vlan_clients to net_clients net: Rename VLANClientState to NetClientState net: Rename vc local variables to nc net: Rename qemu_del_vlan_client() to qemu_del_net_client() Zhi Yong Wu (4): net: Make info network output more readable info net: cleanup deliver/deliver_iov func pointers net: determine if packets can be sent before net queue deliver packets hub: add the support for hub own flow control Makefile.objs | 2 +- hw/cadence_gem.c | 8 +- hw/dp8393x.c | 6 +- hw/e1000.c | 10 +- hw/eepro100.c | 8 +- hw/etraxfs_eth.c | 8 +- hw/lan9118.c | 8 +- hw/lance.c | 2 +- hw/mcf_fec.c | 6 +- hw/milkymist-minimac2.c | 6 +- hw/mipsnet.c | 6 +- hw/musicpal.c | 6 +- hw/ne2000-isa.c | 2 +- hw/ne2000.c | 8 +- hw/ne2000.h | 4 +- hw/opencores_eth.c | 8 +- hw/pcnet-pci.c | 4 +- hw/pcnet.c | 6 +- hw/pcnet.h | 6 +- hw/qdev-properties.c | 78 +-- hw/qdev.c | 2 - hw/qdev.h | 8 +- hw/rtl8139.c | 10 +- hw/smc91c111.c | 6 +- hw/spapr_llan.c | 4 +- hw/stellaris_enet.c | 6 +- hw/usb/dev-network.c | 8 +- hw/vhost_net.c | 24 +- hw/vhost_net.h | 2 +- hw/virtio-net.c | 12 +- hw/xen_nic.c | 7 +- hw/xgmac.c | 6 +- hw/xilinx_axienet.c | 6 +- hw/xilinx_ethlite.c | 6 +- net.c | 605 ++- net.h | 86 net/dump.c | 28 ++- net/dump.h | 2 +- net/hub.c | 310 net/hub.h | 28 +++ net/queue.c | 37 ++-- net/queue.h | 25 +-- net/slirp.c | 32 +-- net/slirp.h | 2 +- net/socket.c | 66 +++--- net/socket.h | 2 +- net/tap-win32.c | 27 +- net/tap.c | 45 ++-- net/tap.h | 21 +- net/vde.c | 17 +- net/vde.h | 3 +- qemu-common.h | 3 +- slirp/if.c | 5 - slirp/libslirp.h | 1 - 54 files changed, 818 insertions(+), 826 deletions(-) create mode 100644 net/hub.c create mode 100644 net/hub.h -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH block-next 0/3] qemu-img check/qcow2: Allow fixing refcounts
On Fri, Jun 1, 2012 at 4:06 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Fri, Jun 1, 2012 at 6:22 AM, Zhi Yong Wu zwu.ker...@gmail.com wrote: On Thu, May 31, 2012 at 5:26 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Wed, May 30, 2012 at 9:31 AM, Zhi Yong Wu zwu.ker...@gmail.com wrote: On Sat, May 12, 2012 at 12:48 AM, Kevin Wolf kw...@redhat.com wrote: A prerequisite for a QED mode in qcow2, which doesn't update the refcount Recently some new concepts such as QED mode in qcow2 are seen frequencely, can anyone explain what it means? thanks. qcow2 has more metadata than qed. More metadata means more write operations when allocating new clusters. In order to overcome this performance issue qcow2 has a metadata cache. But when QEMU is launched with -drive ...,cache=writethrough (the default) the metadata cache *must* be in writethrough mode Why must i be? If the option with -drive ..,cache=writethrough is specified. it means that host page cache is on while guest disk cache is off. Since the metadata cache exists in host page cache, not guest, i think that it is in writeback mode. Since the emulated disk write cache is off, we must ensure that guest writes are on disk before completing them. Therefore we cannot cache metadata updates in host RAM - it would be lost on power failure but But host page cache is *on* in this mode, which means that metadata should be cached in host RAM. how do you explain this? we promised the guest its writes reached the disk! instead of writeback mode. In other words, every metadata update needs to be written to the image file before we complete the guest's What will mean one guest's wirte request is completed? For example, virtio-blk fills in the success status code and raises an interrupt. This notifies the guest that the write is done. Great, thanks. write request. This means the metadata cache only hides the metadata performance issue when -drive ...,cache=direct|writeback are used because there we can keep metadata changes buffered in memory until the guest flushes the emulated disk write cache. QED mode is a solution for -drive ...,cache=writethrough|directsync. It simply doesn't update refcount metadata in the qcow2 image file l1/l2 info need to be updated to qcow2 image file? immediately in exchange for a refcount fixup step that is introduced Can you say this with more details? Why is this step need only when image file is opened? After image file is opened, and some guest's write requests are completed, maybe the refcount fixup step need to be done once. If we don't update refcounts on disk then they become outdated and no longer reflect the true allocation information. It's not safe to rely on outdated refcount information since we could allocate the same cluster multiple times - this means data corruption. By running a consistency check when opening a dirty image file we guarantee that we have accurate refcount information again. ah, i got it now. As an optimization we will commit refcount information to disk when closing the image file and mark it clean. This means a clean QEMU shutdown does not require a consistency check on startup - but in the worst case (power failure or crash) we will have a dirty image file. Yeah, a consistency check on startup is good, i think. thanks. Stefan -- Regards, Zhi Yong Wu
Re: [Qemu-devel] frame reordering in qemu_net_queue_send() ?
On Thu, May 31, 2012 at 5:34 PM, Luigi Rizzo ri...@iet.unipi.it wrote:
On Thu, May 31, 2012 at 11:18 AM, Stefan Hajnoczi stefa...@gmail.com
wrote:
On Wed, May 30, 2012 at 8:59 AM, Luigi Rizzo ri...@iet.unipi.it wrote:
Hi,
while investigating rx performance for emulated network devices
(i am looking at the userspace version, relying on net=tap
or similar approaches) i noticed the code
in net/queue.c :: qemu_net_queue_send()
which look strange to me (same goes for the iov version).
The whole function is below, just for reference.
My impression is that the call to qemu_net_queue_flush()
is misplaced, and it should be before qemu_net_queue_deliver()
otherwise the current packet is pushed out before anything
was already in the queue.
Yeah, this case actually exists, but tcp/ip protocol stack in guest
will make sure this ordering will finally be correct.
By the way, e.g. even if some packets are sent successfully in order,
after internet trasmission, we can not also make sure that these
packets will be received by their destination in its original order.
The tcp/ip protocol stack in destination host will make sure that they
will be sorted by their seq number in these packets.
Does it make sense ?
cheers
luigi
ssize_t qemu_net_queue_send(NetQueue *queue,
VLANClientState *sender,
unsigned flags,
const uint8_t *data,
size_t size,
NetPacketSent *sent_cb)
{
ssize_t ret;
if (queue-delivering) {
return qemu_net_queue_append(queue, sender, flags, data,
size, NULL);
}
ret = qemu_net_queue_deliver(queue, sender, flags, data, size);
if (ret == 0) {
qemu_net_queue_append(queue, sender, flags, data, size,
sent_cb);
return 0;
}
qemu_net_queue_flush(queue);
This of the case where delivering a packet causes additional
(re-entrant) qemu_net_queue_send() calls to this queue. We'll be in
-delivering state and queue those packets. After we've finished
delivering the initial packet we flush the queue.
This is a weird case but this is how I read the intention of the code.
i was under the impression that qemu_net_queue_deliver() may also return 0
if the other side
(frontend network device) has no room for the packet. This would cause the
queue to
contain data on entry in the next call, even without reentrancy. Consider
this:
t0. qemu_net_queue_send(pkt-A)
qemu_net_queue_deliver() returns 0, pkt-A is queued and we return
t1. qemu_net_queue_send(pkt-B)
qemu_net_queue_deliver() returns successfully, pkt-B is sent to the
frontend
then we call qemu_net_queue_flush() and this sends pkt-B to the
frontend,
in the wrong order
cheers
luigi
--
-+---
Prof. Luigi RIZZO, ri...@iet.unipi.it . Dip. di Ing. dell'Informazione
http://www.iet.unipi.it/~luigi/ . Universita` di Pisa
TEL +39-050-2211611 . via Diotisalvi 2
Mobile +39-338-6809875 . 56122 PISA (Italy)
-+---
--
Regards,
Zhi Yong Wu
Re: [Qemu-devel] frame reordering in qemu_net_queue_send() ?
On Thu, May 31, 2012 at 5:18 PM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Wed, May 30, 2012 at 8:59 AM, Luigi Rizzo ri...@iet.unipi.it wrote:
Hi,
while investigating rx performance for emulated network devices
(i am looking at the userspace version, relying on net=tap
or similar approaches) i noticed the code
in net/queue.c :: qemu_net_queue_send()
which look strange to me (same goes for the iov version).
The whole function is below, just for reference.
My impression is that the call to qemu_net_queue_flush()
is misplaced, and it should be before qemu_net_queue_deliver()
otherwise the current packet is pushed out before anything
was already in the queue.
Does it make sense ?
cheers
luigi
ssize_t qemu_net_queue_send(NetQueue *queue,
VLANClientState *sender,
unsigned flags,
const uint8_t *data,
size_t size,
NetPacketSent *sent_cb)
{
ssize_t ret;
if (queue-delivering) {
return qemu_net_queue_append(queue, sender, flags, data, size,
NULL);
}
ret = qemu_net_queue_deliver(queue, sender, flags, data, size);
if (ret == 0) {
qemu_net_queue_append(queue, sender, flags, data, size, sent_cb);
return 0;
}
qemu_net_queue_flush(queue);
This of the case where delivering a packet causes additional
(re-entrant) qemu_net_queue_send() calls to this queue. We'll be in
If qemu_net_queue_send() are re-entranced, what issue or badness will
it introduce?
I haven't found what issue will take place when queue_flush() is moved
before queue_deliver().
-delivering state and queue those packets. After we've finished
delivering the initial packet we flush the queue.
This is a weird case but this is how I read the intention of the code.
Jan: maybe slirp can do this re-entrant qemu_net_queue_send()?
Stefan
--
Regards,
Zhi Yong Wu
Re: [Qemu-devel] frame reordering in qemu_net_queue_send() ?
On Thu, May 31, 2012 at 9:19 PM, Paolo Bonzini pbonz...@redhat.com wrote: Il 31/05/2012 15:07, Zhi Yong Wu ha scritto: Yeah, this case actually exists, but tcp/ip protocol stack in guest will make sure this ordering will finally be correct. Nevertheless it's not good, and the latest Windows Logo tests will fail Yeah, it surely need to be improved. if you reorder frames. I don't know the details for Windows logo tests. but i think that one good protocol stack implementation should tolerate this case. Paolo -- Regards, Zhi Yong Wu
Re: [Qemu-devel] frame reordering in qemu_net_queue_send() ?
On Thu, May 31, 2012 at 9:48 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2012-05-31 15:45, Zhi Yong Wu wrote:
On Thu, May 31, 2012 at 5:18 PM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Wed, May 30, 2012 at 8:59 AM, Luigi Rizzo ri...@iet.unipi.it wrote:
Hi,
while investigating rx performance for emulated network devices
(i am looking at the userspace version, relying on net=tap
or similar approaches) i noticed the code
in net/queue.c :: qemu_net_queue_send()
which look strange to me (same goes for the iov version).
The whole function is below, just for reference.
My impression is that the call to qemu_net_queue_flush()
is misplaced, and it should be before qemu_net_queue_deliver()
otherwise the current packet is pushed out before anything
was already in the queue.
Does it make sense ?
cheers
luigi
ssize_t qemu_net_queue_send(NetQueue *queue,
VLANClientState *sender,
unsigned flags,
const uint8_t *data,
size_t size,
NetPacketSent *sent_cb)
{
ssize_t ret;
if (queue-delivering) {
return qemu_net_queue_append(queue, sender, flags, data, size,
NULL);
}
ret = qemu_net_queue_deliver(queue, sender, flags, data, size);
if (ret == 0) {
qemu_net_queue_append(queue, sender, flags, data, size,
sent_cb);
return 0;
}
qemu_net_queue_flush(queue);
This of the case where delivering a packet causes additional
(re-entrant) qemu_net_queue_send() calls to this queue. We'll be in
If qemu_net_queue_send() are re-entranced, what issue or badness will
it introduce?
I haven't found what issue will take place when queue_flush() is moved
before queue_deliver().
Delayed packets that are hold back during delivering==1. Having a flush
Sorry, i don't get what it mean? You know, english is not my first
language.:) You mean that delayed packets may be reenqueued?
before and after may be fine - if we really need it before.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
Regards,
Zhi Yong Wu
Re: [Qemu-devel] frame reordering in qemu_net_queue_send() ?
On Thu, May 31, 2012 at 10:16 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2012-05-31 16:10, Zhi Yong Wu wrote:
On Thu, May 31, 2012 at 9:48 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2012-05-31 15:45, Zhi Yong Wu wrote:
On Thu, May 31, 2012 at 5:18 PM, Stefan Hajnoczi stefa...@gmail.com
wrote:
On Wed, May 30, 2012 at 8:59 AM, Luigi Rizzo ri...@iet.unipi.it wrote:
Hi,
while investigating rx performance for emulated network devices
(i am looking at the userspace version, relying on net=tap
or similar approaches) i noticed the code
in net/queue.c :: qemu_net_queue_send()
which look strange to me (same goes for the iov version).
The whole function is below, just for reference.
My impression is that the call to qemu_net_queue_flush()
is misplaced, and it should be before qemu_net_queue_deliver()
otherwise the current packet is pushed out before anything
was already in the queue.
Does it make sense ?
cheers
luigi
ssize_t qemu_net_queue_send(NetQueue *queue,
VLANClientState *sender,
unsigned flags,
const uint8_t *data,
size_t size,
NetPacketSent *sent_cb)
{
ssize_t ret;
if (queue-delivering) {
return qemu_net_queue_append(queue, sender, flags, data,
size, NULL);
}
ret = qemu_net_queue_deliver(queue, sender, flags, data, size);
if (ret == 0) {
qemu_net_queue_append(queue, sender, flags, data, size,
sent_cb);
return 0;
}
qemu_net_queue_flush(queue);
This of the case where delivering a packet causes additional
(re-entrant) qemu_net_queue_send() calls to this queue. We'll be in
If qemu_net_queue_send() are re-entranced, what issue or badness will
it introduce?
I haven't found what issue will take place when queue_flush() is moved
before queue_deliver().
Delayed packets that are hold back during delivering==1. Having a flush
Sorry, i don't get what it mean? You know, english is not my first
language.:) You mean that delayed packets may be reenqueued?
before and after may be fine - if we really need it before.
I might have been to brief as well: The purpose of the flush after
delivery is the case when we re-entered qemu_net_queue_send while
delivering. If queue-delivering is 1 on entry, we don't deliver but
queue the packet. Once the returned from qemu_net_queue_deliver to the
root qemu_net_queue_send, the queue of hold back packets has to be
flushed to avoid delays.
Yeah, current solution has been this.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
Regards,
Zhi Yong Wu
Re: [Qemu-devel] [PATCH block-next 0/3] qemu-img check/qcow2: Allow fixing refcounts
On Thu, May 31, 2012 at 5:26 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Wed, May 30, 2012 at 9:31 AM, Zhi Yong Wu zwu.ker...@gmail.com wrote: On Sat, May 12, 2012 at 12:48 AM, Kevin Wolf kw...@redhat.com wrote: A prerequisite for a QED mode in qcow2, which doesn't update the refcount Recently some new concepts such as QED mode in qcow2 are seen frequencely, can anyone explain what it means? thanks. qcow2 has more metadata than qed. More metadata means more write operations when allocating new clusters. In order to overcome this performance issue qcow2 has a metadata cache. But when QEMU is launched with -drive ...,cache=writethrough (the default) the metadata cache *must* be in writethrough mode Why must i be? If the option with -drive ..,cache=writethrough is specified. it means that host page cache is on while guest disk cache is off. Since the metadata cache exists in host page cache, not guest, i think that it is in writeback mode. instead of writeback mode. In other words, every metadata update needs to be written to the image file before we complete the guest's What will mean one guest's wirte request is completed? write request. This means the metadata cache only hides the metadata performance issue when -drive ...,cache=direct|writeback are used because there we can keep metadata changes buffered in memory until the guest flushes the emulated disk write cache. QED mode is a solution for -drive ...,cache=writethrough|directsync. It simply doesn't update refcount metadata in the qcow2 image file immediately in exchange for a refcount fixup step that is introduced Can you say this with more details? Why is this step need only when image file is opened? After image file is opened, and some guest's write requests are completed, maybe the refcount fixup step need to be done once. when opening the image file. It's like doing an fsck operation on a file system when mounting it. Stefan -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH block-next 0/3] qemu-img check/qcow2: Allow fixing refcounts
On Sat, May 12, 2012 at 12:48 AM, Kevin Wolf kw...@redhat.com wrote: A prerequisite for a QED mode in qcow2, which doesn't update the refcount Recently some new concepts such as QED mode in qcow2 are seen frequencely, can anyone explain what it means? thanks. table except on clean shutdown, is that refcounts can be repaired when the image is opened the next time after a crash. This series adds a qemu-img check option that doesn't only check, but also tries to fix the errors that it found. Kevin Wolf (3): qemu-img check -r for repairing images qemu-img check: Print fixed clusters and recheck qcow2: Support for fixing refcount inconsistencies block.c | 4 ++-- block.h | 9 - block/qcow2-refcount.c | 27 +-- block/qcow2.c | 5 +++-- block/qcow2.h | 3 ++- block/qed-check.c | 2 ++ block/qed.c | 5 +++-- block/vdi.c | 7 ++- block_int.h | 3 ++- qemu-img-cmds.hx | 4 ++-- qemu-img.c | 35 --- qemu-img.texi | 7 ++- 12 files changed, 93 insertions(+), 18 deletions(-) -- 1.7.6.5 -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH v2] net: add the support for -netdev socket, listen
On Sun, Feb 26, 2012 at 10:48 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Sat, Feb 18, 2012 at 9:19 AM, zwu.ker...@gmail.com wrote: From: Zhi Yong Wu wu...@linux.vnet.ibm.com The -net socket,listen option does not work with the newer -netdev syntax: http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg01508.html This patch makes it work now. Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com --- net.c | 26 + net.h | 2 + net/socket.c | 72 +- 3 files changed, 84 insertions(+), 16 deletions(-) I wanted to understand the problem better so I tried out -net socket,listen=. Here is its behavior: 1. A client can connect to QEMU, this creates a new socket VLANClientState on the VLAN. 2. If another client connects to QEMU, another VLANClientState is created. That means many socket clients can be added to the same VLAN. 3. When a simple TCP client like netcat connects and then disconnects, the VLANClientState remains forever. There seems to be no cleanup. This patch does not handle the -net socket,listen= case where multiple clients connect. Also, the -netdev socket,listen= semantics cannot match -net socket-listen= semantics because there is only one peer at any time. Some options: 1. Do not accept new connections while a client is connected. Once the client disconnects we can accept a new connection. This maintains the 1-1 peer behavior. 2. Integrate with vlan-hub so that multiple clients can connect even with -netdev. Connections will create new NetClientStates and auto-attach to the hub. This mimics -net socket,listen= but requires a hub to be used. 3. Forbid -netdev socket,listen=, only allow -net socket,listen=. I think #1 would be okay, although it no longer allows multiple connections, but I don't have a strong opinion either way. Now i prefer to support #2. Do you think of it? Should the usage -netdev socket,listen also been supported or forbidden? As you said, -netdev only has one peer, so their usage will be a bit different. Stefan -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH v2] net: add the support for -netdev socket, listen
On Mon, May 28, 2012 at 6:51 PM, Stefan Hajnoczi stefa...@linux.vnet.ibm.com wrote: On Mon, May 28, 2012 at 03:49:11PM +0800, Zhi Yong Wu wrote: On Sun, Feb 26, 2012 at 10:48 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Sat, Feb 18, 2012 at 9:19 AM, zwu.ker...@gmail.com wrote: From: Zhi Yong Wu wu...@linux.vnet.ibm.com The -net socket,listen option does not work with the newer -netdev syntax: http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg01508.html This patch makes it work now. Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com --- net.c | 26 + net.h | 2 + net/socket.c | 72 +- 3 files changed, 84 insertions(+), 16 deletions(-) I wanted to understand the problem better so I tried out -net socket,listen=. Here is its behavior: 1. A client can connect to QEMU, this creates a new socket VLANClientState on the VLAN. 2. If another client connects to QEMU, another VLANClientState is created. That means many socket clients can be added to the same VLAN. 3. When a simple TCP client like netcat connects and then disconnects, the VLANClientState remains forever. There seems to be no cleanup. This patch does not handle the -net socket,listen= case where multiple clients connect. Also, the -netdev socket,listen= semantics cannot match -net socket-listen= semantics because there is only one peer at any time. Some options: 1. Do not accept new connections while a client is connected. Once the client disconnects we can accept a new connection. This maintains the 1-1 peer behavior. 2. Integrate with vlan-hub so that multiple clients can connect even with -netdev. Connections will create new NetClientStates and auto-attach to the hub. This mimics -net socket,listen= but requires a hub to be used. 3. Forbid -netdev socket,listen=, only allow -net socket,listen=. I think #1 would be okay, although it no longer allows multiple connections, but I don't have a strong opinion either way. Now i prefer to support #2. Do you think of it? Should the usage -netdev socket,listen also been supported or forbidden? As you said, -netdev only has one peer, so their usage will be a bit different. I'm not sure how useful the multiple connections behavior is. Since -netdev socket,listen= has not worked in the past we have the freedom to decide how it should work (without breaking existing users' setups). Several folks have pointed out that vde or other external programs are better for virtual hubs/switches. I would implement #1 because it adds useful behavior but doesn't complicate QEMU much. But if you feel adding #2 would be worthwhile and not a big effort to code, then go ahead. My intuition is that #1 will be easier to get merged and can be extended to support #2 in the future, if necessary. OK. i will try. Stefan -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH v4 16/16] hub: add the support for hub own flow control
On Fri, May 25, 2012 at 8:13 PM, Stefan Hajnoczi
stefa...@linux.vnet.ibm.com wrote:
On Fri, May 25, 2012 at 06:52:14PM +0800, zwu.ker...@gmail.com wrote:
@@ -59,16 +60,16 @@ static ssize_t net_hub_receive_iov(NetHub *hub,
NetHubPort *source_port,
const struct iovec *iov, int iovcnt)
{
NetHubPort *port;
- ssize_t ret = 0;
+ ssize_t len = iov_size(iov, iovcnt);
QLIST_FOREACH(port, hub-ports, next) {
if (port == source_port) {
continue;
}
- ret = qemu_sendv_packet(port-nc, iov, iovcnt);
+ qemu_sendv_packet(port-nc, iov, iovcnt);
}
- return ret;
+ return len;
}
I think this is okay because at this point we've given it our best shot:
we already checked that port peers can receive. If they error out now
there's not much we can do. The packet is dropped for that particular
peer but at least we tried to deliver it when they claimed to be ready.
Yeah, i think that he is lack of enough understanding on net subsystem
code. He can't see that his thought brought a lot of issues.
Stefan
--
Regards,
Zhi Yong Wu
Re: [Qemu-devel] [PATCH v3 16/16] hub: add the support for hub own flow control
On Fri, May 25, 2012 at 3:04 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 24/05/2012 19:59, zwu.ker...@gmail.com ha scritto:
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
net/hub.c | 35 ---
net/hub.h | 2 ++
net/queue.c | 5 +
3 files changed, 39 insertions(+), 3 deletions(-)
diff --git a/net/hub.c b/net/hub.c
index 8a583ab..d27c52a 100644
--- a/net/hub.c
+++ b/net/hub.c
@@ -28,6 +28,7 @@ typedef struct NetHubPort {
QLIST_ENTRY(NetHubPort) next;
NetHub *hub;
unsigned int id;
+ uint64_t nr_packets;
} NetHubPort;
struct NetHub {
@@ -39,19 +40,37 @@ struct NetHub {
static QLIST_HEAD(, NetHub) hubs = QLIST_HEAD_INITIALIZER(hubs);
+static void net_hub_receive_completed(NetClientState *nc, ssize_t len)
+{
+ NetHubPort *port = DO_UPCAST(NetHubPort, nc, nc);
+ port-nr_packets--;
+ if (!port-nr_packets) {
+ qemu_net_queue_flush(nc-peer-send_queue);
+ }
+}
+
+void net_hub_port_packet_stats(NetClientState *nc)
+{
+ NetHubPort *port = DO_UPCAST(NetHubPort, nc, nc);
+
+ port-nr_packets++;
+}
Isn't this being called also for non-hubport clients?
Thanks.
static ssize_t net_hub_receive(NetHub *hub, NetHubPort *source_port,
const uint8_t *buf, size_t len)
{
NetHubPort *port;
+ ssize_t ret = 0;
QLIST_FOREACH(port, hub-ports, next) {
if (port == source_port) {
continue;
}
- qemu_send_packet(port-nc, buf, len);
+ ret = qemu_send_packet_async(port-nc, buf, len,
+ net_hub_receive_completed);
Just increment nr_packets here:
ret = qemu_send_packet_async
if (ret == 0) {
port-nr_packets++;
}
}
- return len;
+ return ret;
You can return len here. In fact returning ret is wrong because the
value comes from a random port (the last one).
If the return value from the last port doesn't equal to len, you let
this function return len, it will be also wrong.
}
static ssize_t net_hub_receive_iov(NetHub *hub, NetHubPort *source_port,
@@ -65,7 +84,8 @@ static ssize_t net_hub_receive_iov(NetHub *hub, NetHubPort
*source_port,
continue;
}
- ret = qemu_sendv_packet(port-nc, iov, iovcnt);
+ ret = qemu_sendv_packet_async(port-nc, iov, iovcnt,
+ net_hub_receive_completed);
Same here (increment nr_packets)
}
return ret;
Same here (return len).
No, it has no such variable called as len, I think that here should
return ret, not len.
Do you think that it is necessary to calc len by iov and viocnt?
}
@@ -84,6 +104,13 @@ static NetHub *net_hub_new(unsigned int id)
return hub;
}
+static int net_hub_port_can_receive(NetClientState *nc)
+{
+ NetHubPort *port = DO_UPCAST(NetHubPort, nc, nc);
+
+ return port-nr_packets ? 0 : 1;
+}
This is return port-nr_packets == 0;.
thanks.
But I think you need to implement this on the hub rather than on the
port, and return true only if port-nr_packets == 0 for all ports.
Can you explain why to need based on hub, not port?
Probably you can move nr_packets to the hub itself rather than the port?
I think that the counter brings a lot of issues.
1.) The packet delivery is bidirectional. one direction is blocked
doesn't mean another direction also is blocked.
2.) If the packets comes from guest to outside, when hubport's
can_receive fails, the following packets will all be enqueued to
hubport queue, How will these packets in hubport queue are trigered to
send again? Maybe this will lead to introduce one timer for each
hubport queue.
static ssize_t net_hub_port_receive(NetClientState *nc,
const uint8_t *buf, size_t len)
{
@@ -110,6 +137,7 @@ static void net_hub_port_cleanup(NetClientState *nc)
static NetClientInfo net_hub_port_info = {
.type = NET_CLIENT_TYPE_HUB,
.size = sizeof(NetHubPort),
+ .can_receive = net_hub_port_can_receive,
.receive = net_hub_port_receive,
.receive_iov = net_hub_port_receive_iov,
.cleanup = net_hub_port_cleanup,
@@ -128,6 +156,7 @@ static NetHubPort *net_hub_port_new(NetHub *hub)
port = DO_UPCAST(NetHubPort, nc, nc);
port-id = id;
port-hub = hub;
+ port-nr_packets = 0;
QLIST_INSERT_HEAD(hub-ports, port, next);
Everything below this has to go away (sender is not necessarily a hub
port!).
diff --git a/net/hub.h b/net/hub.h
index d04f1b1..542e657 100644
--- a/net/hub.h
+++ b/net/hub.h
@@ -23,4 +23,6 @@ void net_hub_info(Monitor *mon);
int net_hub_id_for_client(NetClientState *nc, unsigned int *id);
void net_hub_check_clients(void);
+void net_hub_port_packet_stats(NetClientState *nc);
+
#endif /* NET_HUB_H */
diff --git a/net/queue.c b/net/queue.c
index 7484d2a..ebf18aa
Re: [Qemu-devel] [PATCH v3 16/16] hub: add the support for hub own flow control
On Fri, May 25, 2012 at 3:04 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 24/05/2012 19:59, zwu.ker...@gmail.com ha scritto:
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
net/hub.c | 35 ---
net/hub.h | 2 ++
net/queue.c | 5 +
3 files changed, 39 insertions(+), 3 deletions(-)
diff --git a/net/hub.c b/net/hub.c
index 8a583ab..d27c52a 100644
--- a/net/hub.c
+++ b/net/hub.c
@@ -28,6 +28,7 @@ typedef struct NetHubPort {
QLIST_ENTRY(NetHubPort) next;
NetHub *hub;
unsigned int id;
+ uint64_t nr_packets;
} NetHubPort;
struct NetHub {
@@ -39,19 +40,37 @@ struct NetHub {
static QLIST_HEAD(, NetHub) hubs = QLIST_HEAD_INITIALIZER(hubs);
+static void net_hub_receive_completed(NetClientState *nc, ssize_t len)
+{
+ NetHubPort *port = DO_UPCAST(NetHubPort, nc, nc);
+ port-nr_packets--;
+ if (!port-nr_packets) {
+ qemu_net_queue_flush(nc-peer-send_queue);
+ }
+}
+
+void net_hub_port_packet_stats(NetClientState *nc)
+{
+ NetHubPort *port = DO_UPCAST(NetHubPort, nc, nc);
+
+ port-nr_packets++;
+}
Isn't this being called also for non-hubport clients?
static ssize_t net_hub_receive(NetHub *hub, NetHubPort *source_port,
const uint8_t *buf, size_t len)
{
NetHubPort *port;
+ ssize_t ret = 0;
QLIST_FOREACH(port, hub-ports, next) {
if (port == source_port) {
continue;
}
- qemu_send_packet(port-nc, buf, len);
+ ret = qemu_send_packet_async(port-nc, buf, len,
+ net_hub_receive_completed);
Just increment nr_packets here:
ret = qemu_send_packet_async
if (ret == 0) {
port-nr_packets++;
}
This is wrong, if you check the code, sent_cb is only called when the
send queue is not empty. That is, sent_cb is used for those enqueued
packets. For those packets which aren't enqueued, The counter will be
not decreased. And when qemu_send_packet_async/qemu_sendv_packet_async
return, flush function has been executed. But you increase the
coutner, when the next following packets come, they will be enqueued
without condition. And no timer triger the hubport queue to fire
again.
}
- return len;
+ return ret;
You can return len here. In fact returning ret is wrong because the
value comes from a random port (the last one).
}
static ssize_t net_hub_receive_iov(NetHub *hub, NetHubPort *source_port,
@@ -65,7 +84,8 @@ static ssize_t net_hub_receive_iov(NetHub *hub, NetHubPort
*source_port,
continue;
}
- ret = qemu_sendv_packet(port-nc, iov, iovcnt);
+ ret = qemu_sendv_packet_async(port-nc, iov, iovcnt,
+ net_hub_receive_completed);
Same here (increment nr_packets)
}
return ret;
Same here (return len).
}
@@ -84,6 +104,13 @@ static NetHub *net_hub_new(unsigned int id)
return hub;
}
+static int net_hub_port_can_receive(NetClientState *nc)
+{
+ NetHubPort *port = DO_UPCAST(NetHubPort, nc, nc);
+
+ return port-nr_packets ? 0 : 1;
+}
This is return port-nr_packets == 0;.
But I think you need to implement this on the hub rather than on the
port, and return true only if port-nr_packets == 0 for all ports.
Probably you can move nr_packets to the hub itself rather than the port?
static ssize_t net_hub_port_receive(NetClientState *nc,
const uint8_t *buf, size_t len)
{
@@ -110,6 +137,7 @@ static void net_hub_port_cleanup(NetClientState *nc)
static NetClientInfo net_hub_port_info = {
.type = NET_CLIENT_TYPE_HUB,
.size = sizeof(NetHubPort),
+ .can_receive = net_hub_port_can_receive,
.receive = net_hub_port_receive,
.receive_iov = net_hub_port_receive_iov,
.cleanup = net_hub_port_cleanup,
@@ -128,6 +156,7 @@ static NetHubPort *net_hub_port_new(NetHub *hub)
port = DO_UPCAST(NetHubPort, nc, nc);
port-id = id;
port-hub = hub;
+ port-nr_packets = 0;
QLIST_INSERT_HEAD(hub-ports, port, next);
Everything below this has to go away (sender is not necessarily a hub
port!).
diff --git a/net/hub.h b/net/hub.h
index d04f1b1..542e657 100644
--- a/net/hub.h
+++ b/net/hub.h
@@ -23,4 +23,6 @@ void net_hub_info(Monitor *mon);
int net_hub_id_for_client(NetClientState *nc, unsigned int *id);
void net_hub_check_clients(void);
+void net_hub_port_packet_stats(NetClientState *nc);
+
#endif /* NET_HUB_H */
diff --git a/net/queue.c b/net/queue.c
index 7484d2a..ebf18aa 100644
--- a/net/queue.c
+++ b/net/queue.c
@@ -22,6 +22,7 @@
*/
#include net/queue.h
+#include net/hub.h
#include qemu-queue.h
#include net.h
@@ -101,6 +102,8 @@ static ssize_t qemu_net_queue_append(NetQueue *queue,
QTAILQ_INSERT_TAIL(queue-packets, packet, entry
Re: [Qemu-devel] [PATCH v3 16/16] hub: add the support for hub own flow control
On Fri, May 25, 2012 at 3:04 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 24/05/2012 19:59, zwu.ker...@gmail.com ha scritto:
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
net/hub.c | 35 ---
net/hub.h | 2 ++
net/queue.c | 5 +
3 files changed, 39 insertions(+), 3 deletions(-)
diff --git a/net/hub.c b/net/hub.c
index 8a583ab..d27c52a 100644
--- a/net/hub.c
+++ b/net/hub.c
@@ -28,6 +28,7 @@ typedef struct NetHubPort {
QLIST_ENTRY(NetHubPort) next;
NetHub *hub;
unsigned int id;
+ uint64_t nr_packets;
} NetHubPort;
struct NetHub {
@@ -39,19 +40,37 @@ struct NetHub {
static QLIST_HEAD(, NetHub) hubs = QLIST_HEAD_INITIALIZER(hubs);
+static void net_hub_receive_completed(NetClientState *nc, ssize_t len)
+{
+ NetHubPort *port = DO_UPCAST(NetHubPort, nc, nc);
+ port-nr_packets--;
+ if (!port-nr_packets) {
+ qemu_net_queue_flush(nc-peer-send_queue);
+ }
+}
+
+void net_hub_port_packet_stats(NetClientState *nc)
+{
+ NetHubPort *port = DO_UPCAST(NetHubPort, nc, nc);
+
+ port-nr_packets++;
+}
Isn't this being called also for non-hubport clients?
static ssize_t net_hub_receive(NetHub *hub, NetHubPort *source_port,
const uint8_t *buf, size_t len)
{
NetHubPort *port;
+ ssize_t ret = 0;
QLIST_FOREACH(port, hub-ports, next) {
if (port == source_port) {
continue;
}
- qemu_send_packet(port-nc, buf, len);
+ ret = qemu_send_packet_async(port-nc, buf, len,
+ net_hub_receive_completed);
Just increment nr_packets here:
ret = qemu_send_packet_async
if (ret == 0) {
port-nr_packets++;
}
}
- return len;
+ return ret;
You can return len here. In fact returning ret is wrong because the
value comes from a random port (the last one).
}
static ssize_t net_hub_receive_iov(NetHub *hub, NetHubPort *source_port,
@@ -65,7 +84,8 @@ static ssize_t net_hub_receive_iov(NetHub *hub, NetHubPort
*source_port,
continue;
}
- ret = qemu_sendv_packet(port-nc, iov, iovcnt);
+ ret = qemu_sendv_packet_async(port-nc, iov, iovcnt,
+ net_hub_receive_completed);
Same here (increment nr_packets)
}
return ret;
Same here (return len).
}
@@ -84,6 +104,13 @@ static NetHub *net_hub_new(unsigned int id)
return hub;
}
+static int net_hub_port_can_receive(NetClientState *nc)
+{
+ NetHubPort *port = DO_UPCAST(NetHubPort, nc, nc);
+
+ return port-nr_packets ? 0 : 1;
+}
This is return port-nr_packets == 0;.
But I think you need to implement this on the hub rather than on the
port, and return true only if port-nr_packets == 0 for all ports.
I don't think so.
e.g. guest --- hubport1 - hubport2 -- network backend.
hubport1-nr_packets == 0 mean if guest can send packet through
hubport1 to outside.
while hubport2-nr_packets == 0 mean if network backend can send
packet through hubport1 to guest.
Their direction is different. So i don't understand why to need
port-nr_packets == 0 for all ports?
Probably you can move nr_packets to the hub itself rather than the port?
static ssize_t net_hub_port_receive(NetClientState *nc,
const uint8_t *buf, size_t len)
{
@@ -110,6 +137,7 @@ static void net_hub_port_cleanup(NetClientState *nc)
static NetClientInfo net_hub_port_info = {
.type = NET_CLIENT_TYPE_HUB,
.size = sizeof(NetHubPort),
+ .can_receive = net_hub_port_can_receive,
.receive = net_hub_port_receive,
.receive_iov = net_hub_port_receive_iov,
.cleanup = net_hub_port_cleanup,
@@ -128,6 +156,7 @@ static NetHubPort *net_hub_port_new(NetHub *hub)
port = DO_UPCAST(NetHubPort, nc, nc);
port-id = id;
port-hub = hub;
+ port-nr_packets = 0;
QLIST_INSERT_HEAD(hub-ports, port, next);
Everything below this has to go away (sender is not necessarily a hub
port!).
diff --git a/net/hub.h b/net/hub.h
index d04f1b1..542e657 100644
--- a/net/hub.h
+++ b/net/hub.h
@@ -23,4 +23,6 @@ void net_hub_info(Monitor *mon);
int net_hub_id_for_client(NetClientState *nc, unsigned int *id);
void net_hub_check_clients(void);
+void net_hub_port_packet_stats(NetClientState *nc);
+
#endif /* NET_HUB_H */
diff --git a/net/queue.c b/net/queue.c
index 7484d2a..ebf18aa 100644
--- a/net/queue.c
+++ b/net/queue.c
@@ -22,6 +22,7 @@
*/
#include net/queue.h
+#include net/hub.h
#include qemu-queue.h
#include net.h
@@ -101,6 +102,8 @@ static ssize_t qemu_net_queue_append(NetQueue *queue,
QTAILQ_INSERT_TAIL(queue-packets, packet, entry);
+ net_hub_port_packet_stats(sender);
+
return size;
}
@@ -134,6 +137,8 @@ static ssize_t qemu_net_queue_append_iov(NetQueue
Re: [Qemu-devel] [PATCH v3 16/16] hub: add the support for hub own flow control
On Fri, May 25, 2012 at 6:08 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 25/05/2012 09:48, Zhi Yong Wu ha scritto:
static ssize_t net_hub_receive(NetHub *hub, NetHubPort *source_port,
const uint8_t *buf, size_t len)
{
NetHubPort *port;
+ ssize_t ret = 0;
QLIST_FOREACH(port, hub-ports, next) {
if (port == source_port) {
continue;
}
- qemu_send_packet(port-nc, buf, len);
+ ret = qemu_send_packet_async(port-nc, buf, len,
+ net_hub_receive_completed);
Just increment nr_packets here:
ret = qemu_send_packet_async
if (ret == 0) {
port-nr_packets++;
}
This is wrong, if you check the code, sent_cb is only called when the
send queue is not empty. That is, sent_cb is used for those enqueued
packets. For those packets which aren't enqueued, The counter will be
not decreased.
It will also not be incremented, because I'm checking for ret == 0.
}
- return len;
+ return ret;
You can return len here. In fact returning ret is wrong because the
value comes from a random port (the last one).
If the return value from the last port doesn't equal to len, you let
this function return len, it will be also wrong.
But that's the whole point of implementing flow control. We return len
because we _did_ process the packet; it is now in the port's queues.
However, can_receive will not admit new packets until all ports have
processed the previous one, so that all ports advance to new packets at
the same time.
}
static ssize_t net_hub_receive_iov(NetHub *hub, NetHubPort *source_port,
@@ -65,7 +84,8 @@ static ssize_t net_hub_receive_iov(NetHub *hub,
NetHubPort *source_port,
continue;
}
- ret = qemu_sendv_packet(port-nc, iov, iovcnt);
+ ret = qemu_sendv_packet_async(port-nc, iov, iovcnt,
+ net_hub_receive_completed);
Same here (increment nr_packets)
}
return ret;
Same here (return len).
No, it has no such variable called as len, I think that here should
return ret, not len.
Do you think that it is necessary to calc len by iov and viocnt?
Yes, for the same reason as above. Returning ret for a random port
(the last one) does not make sense! But you could just punt: do not
implement net_hub_receive_iov at all...
But I think you need to implement this on the hub rather than on the
port, and return true only if port-nr_packets == 0 for all ports.
Can you explain why to need based on hub, not port?
Because the purpose of the counter is to do flow control _on the hub_.
The ports can do their flow control just as well, but the hub has to
reconcile the decisions of the ports.
Taking your example from another message:
e.g. guest --- hubport1 - hubport2 -- network backend.
hubport1-nr_packets == 0 mean if guest can send packet through
hubport1 to outside.
while hubport2-nr_packets == 0 mean if network backend can send
packet through hubport1 to guest.
Their direction is different.
So i don't understand why to need
port-nr_packets == 0 for all ports?
For simplicity. Yes, this means hubs will be half-duplex. In practice
I don't think you need to care.
If you want to make it full-duplex, you can keep the per-port counter
and in can_receive check if all ports except this one has a zero
nr_packets count. In other words, your can_receive method is backwards:
a port can receive a packet if all of its sibling ports are ready to
receive it.
Don't think of it in terms of directions. It is not correct, because
it is a star topology. Think of it in terms of where the packets enter
the hub, and where they are forwarded to.
Probably you can move nr_packets to the hub itself rather than the port?
I think that the counter brings a lot of issues.
I said already that it's not *necessary*. You're free to find another
solution. Removing TODO comments and leaving the problem however is not
a solution.
I like the words. I sent out v4 for this patch. In new version, i
define one new rule for hub port .can_receive().
anyway, thanks a lot for your comments. Have nice weekend!!
Paolo
--
Regards,
Zhi Yong Wu
Re: [Qemu-devel] [PATCH v4 16/16] hub: add the support for hub own flow control
On Fri, May 25, 2012 at 7:05 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 25/05/2012 12:52, zwu.ker...@gmail.com ha scritto:
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Only when all other hub port's *peer* .can_receive() all return 1, the
source hub port .can_receive() return 1.
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
net/hub.c | 27 ---
1 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/net/hub.c b/net/hub.c
index 357ca87..478cce1 100644
--- a/net/hub.c
+++ b/net/hub.c
@@ -15,6 +15,7 @@
#include monitor.h
#include net.h
#include hub.h
+#include iov.h
/*
* A hub broadcasts incoming packets to all its ports except the source
port.
@@ -59,16 +60,16 @@ static ssize_t net_hub_receive_iov(NetHub *hub,
NetHubPort *source_port,
const struct iovec *iov, int iovcnt)
{
NetHubPort *port;
- ssize_t ret = 0;
+ ssize_t len = iov_size(iov, iovcnt);
QLIST_FOREACH(port, hub-ports, next) {
if (port == source_port) {
continue;
}
- ret = qemu_sendv_packet(port-nc, iov, iovcnt);
+ qemu_sendv_packet(port-nc, iov, iovcnt);
I think you still need to apply flow control, otherwise you're cheating.
But perhaps this is acceptable, I'll leave it to more expert people.
Great. thanks. any comments for other patches?
Paolo
--
Regards,
Zhi Yong Wu
Re: [Qemu-devel] [PATCH v3 13/16] net: Make the monitor output more reasonable hub info
On Fri, May 25, 2012 at 4:34 AM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2012-05-24 14:59, zwu.ker...@gmail.com wrote:
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
net.c | 7 ++-
net/hub.c | 2 +-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/net.c b/net.c
index 61dc28d..79ac51f 100644
--- a/net.c
+++ b/net.c
@@ -887,6 +887,12 @@ static const struct {
},
},
#endif /* CONFIG_NET_BRIDGE */
+ [NET_CLIENT_TYPE_HUB] = {
+ .type = hubport,
+ .desc = {
+ { /* end of list */ }
+ },
+ },
};
int net_client_init(Monitor *mon, QemuOpts *opts, int is_netdev)
@@ -1079,7 +1085,6 @@ void do_info_network(Monitor *mon)
NetClientState *nc, *peer;
net_client_type type;
- monitor_printf(mon, Devices not on any VLAN:\n);
QTAILQ_FOREACH(nc, net_clients, next) {
peer = nc-peer;
type = nc-info-type;
diff --git a/net/hub.c b/net/hub.c
index 0cc385e..8a583ab 100644
--- a/net/hub.c
+++ b/net/hub.c
@@ -193,7 +193,7 @@ void net_hub_info(Monitor *mon)
QLIST_FOREACH(hub, hubs, next) {
monitor_printf(mon, hub %u\n, hub-id);
QLIST_FOREACH(port, hub-ports, next) {
- monitor_printf(mon, port %u peer %s\n, port-id,
+ monitor_printf(mon, \\ %s\n,
port-nc.peer ? port-nc.peer-name : none);
}
}
I still do not agree with this formatting (peer - hubport + hub -
abbreviated peers instead of just hub - peers). But the series has a
higher value than this, and we can fix on top - unless there is a need
for another round anyway.
Can the following formatting let you be happy?
(qemu) info network
hub 1
\ dump.0: type=dump,dump to qemu-vlan1.pcap (len=65536)
\ user.1: type=user,net=10.0.2.0,restrict=off
\ virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:58
hub 0
\ user.0: type=user,net=10.0.2.0,restrict=off
\ e1000.0: type=nic,model=e1000,macaddr=52:54:00:12:34:57
virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
\ ur: type=tap,ifname=tap0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown
(qemu)
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
Regards,
Zhi Yong Wu
Re: [Qemu-devel] [PATCH v3 13/16] net: Make the monitor output more reasonable hub info
On Fri, May 25, 2012 at 9:49 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2012-05-25 09:00, Zhi Yong Wu wrote:
On Fri, May 25, 2012 at 4:34 AM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2012-05-24 14:59, zwu.ker...@gmail.com wrote:
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
net.c | 7 ++-
net/hub.c | 2 +-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/net.c b/net.c
index 61dc28d..79ac51f 100644
--- a/net.c
+++ b/net.c
@@ -887,6 +887,12 @@ static const struct {
},
},
#endif /* CONFIG_NET_BRIDGE */
+ [NET_CLIENT_TYPE_HUB] = {
+ .type = hubport,
+ .desc = {
+ { /* end of list */ }
+ },
+ },
};
int net_client_init(Monitor *mon, QemuOpts *opts, int is_netdev)
@@ -1079,7 +1085,6 @@ void do_info_network(Monitor *mon)
NetClientState *nc, *peer;
net_client_type type;
- monitor_printf(mon, Devices not on any VLAN:\n);
QTAILQ_FOREACH(nc, net_clients, next) {
peer = nc-peer;
type = nc-info-type;
diff --git a/net/hub.c b/net/hub.c
index 0cc385e..8a583ab 100644
--- a/net/hub.c
+++ b/net/hub.c
@@ -193,7 +193,7 @@ void net_hub_info(Monitor *mon)
QLIST_FOREACH(hub, hubs, next) {
monitor_printf(mon, hub %u\n, hub-id);
QLIST_FOREACH(port, hub-ports, next) {
- monitor_printf(mon, port %u peer %s\n, port-id,
+ monitor_printf(mon, \\ %s\n,
port-nc.peer ? port-nc.peer-name :
none);
}
}
I still do not agree with this formatting (peer - hubport + hub -
abbreviated peers instead of just hub - peers). But the series has a
higher value than this, and we can fix on top - unless there is a need
for another round anyway.
Can the following formatting let you be happy?
(qemu) info network
hub 1
\ dump.0: type=dump,dump to qemu-vlan1.pcap (len=65536)
\ user.1: type=user,net=10.0.2.0,restrict=off
\ virtio-net-pci.0:
type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:58
hub 0
\ user.0: type=user,net=10.0.2.0,restrict=off
\ e1000.0: type=nic,model=e1000,macaddr=52:54:00:12:34:57
virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
\ ur: type=tap,ifname=tap0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown
Yes, this is what I was propose. You can just save the peer indentions
in the hub case.
OK. sent out v4 for this patch.
Thanks!
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
Regards,
Zhi Yong Wu
Re: [Qemu-devel] [PATCH v4 13/16] net: Make info network output more readable info
On Fri, May 25, 2012 at 10:17 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2012-05-25 11:02, zwu.ker...@gmail.com wrote:
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Reviewed-by: Jan Kiszka jan.kis...@siemens.com
Please don't put reviewed-by tags here before the reviewer had a chance
to look at the code.
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
net.c | 18 ++
net.h | 12
net/hub.c | 23 +--
net/hub.h | 1 +
4 files changed, 48 insertions(+), 6 deletions(-)
diff --git a/net.c b/net.c
index 61dc28d..ae0deec 100644
--- a/net.c
+++ b/net.c
@@ -887,6 +887,12 @@ static const struct {
},
},
#endif /* CONFIG_NET_BRIDGE */
+ [NET_CLIENT_TYPE_HUB] = {
+ .type = hubport,
+ .desc = {
+ { /* end of list */ }
+ },
+ },
This should be obsolete now.
};
int net_client_init(Monitor *mon, QemuOpts *opts, int is_netdev)
@@ -1068,7 +1074,7 @@ int do_netdev_del(Monitor *mon, const QDict *qdict,
QObject **ret_data)
return 0;
}
-static void print_net_client(Monitor *mon, NetClientState *vc)
+void print_net_client(Monitor *mon, NetClientState *vc)
{
monitor_printf(mon, %s: type=%s,%s\n, vc-name,
net_client_types[vc-info-type].type, vc-info_str);
@@ -1079,12 +1085,17 @@ void do_info_network(Monitor *mon)
NetClientState *nc, *peer;
net_client_type type;
- monitor_printf(mon, Devices not on any VLAN:\n);
+ net_hub_info(mon);
+
QTAILQ_FOREACH(nc, net_clients, next) {
peer = nc-peer;
type = nc-info-type;
+
+ if (net_hub_port_peer_nc(nc)) {
+ continue;
+ }
+
if (!peer || type == NET_CLIENT_TYPE_NIC) {
- monitor_printf(mon, );
print_net_client(mon, nc);
} /* else it's a netdev connected to a NIC, printed with the NIC */
if (peer type == NET_CLIENT_TYPE_NIC) {
@@ -1092,7 +1103,6 @@ void do_info_network(Monitor *mon)
print_net_client(mon, peer);
}
}
- net_hub_info(mon);
Why introduce a different hub output format at all? Do it in the final
right from the start.
}
void qmp_set_link(const char *name, bool up, Error **errp)
diff --git a/net.h b/net.h
index 250669a..08306a4 100644
--- a/net.h
+++ b/net.h
@@ -112,6 +112,18 @@ void qemu_check_nic_model(NICInfo *nd, const char
*model);
int qemu_find_nic_model(NICInfo *nd, const char * const *models,
const char *default_model);
+ssize_t qemu_deliver_packet(NetClientState *sender,
+ unsigned flags,
+ const uint8_t *data,
+ size_t size,
+ void *opaque);
+ssize_t qemu_deliver_packet_iov(NetClientState *sender,
+ unsigned flags,
+ const struct iovec *iov,
+ int iovcnt,
+ void *opaque);
+
I bet those two prototypes are required by some other patch (or are even
redundant).
I have noticed this, and split out them to other patch.
+void print_net_client(Monitor *mon, NetClientState *vc);
void do_info_network(Monitor *mon);
/* NIC info */
diff --git a/net/hub.c b/net/hub.c
index 122de69..8c77d03 100644
--- a/net/hub.c
+++ b/net/hub.c
@@ -184,6 +184,25 @@ NetClientState *net_hub_find_client_by_name(unsigned
int hub_id,
}
/**
+ * Determine if one nc peers with one hub port
+ */
+bool net_hub_port_peer_nc(NetClientState *nc)
+{
+ NetHub *hub;
+ NetHubPort *port;
+
+ QLIST_FOREACH(hub, hubs, next) {
+ QLIST_FOREACH(port, hub-ports, next) {
+ if (nc == port-nc.peer) {
+ return true;
+ }
+ }
+ }
+
+ return false;
+}
+
+/**
* Print hub configuration
*/
void net_hub_info(Monitor *mon)
@@ -194,8 +213,8 @@ void net_hub_info(Monitor *mon)
QLIST_FOREACH(hub, hubs, next) {
monitor_printf(mon, hub %u\n, hub-id);
QLIST_FOREACH(port, hub-ports, next) {
- monitor_printf(mon, port %u peer %s\n, port-id,
- port-nc.peer ? port-nc.peer-name : none);
+ monitor_printf(mon, \\ );
This will have the following layout:
(qemu) info network
hub 1
\ dump.0: type=dump,dump to qemu-vlan1.pcap (len=65536)
\ user.1: type=user,net=10.0.2.0,restrict=off
\ virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:58
hub 0
\ user.0: type=user,net=10.0.2.0,restrict=off
\ e1000.0: type=nic,model=e1000,macaddr=52:54:00:12:34:57
virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
\ ur: type=tap,ifname=tap0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown
^^^
Two space too much of indention (you remove them above for the existing
It is three
Re: [Qemu-devel] [PATCH v4 13/16] net: Make info network output more readable info
On Fri, May 25, 2012 at 10:40 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2012-05-25 11:25, Zhi Yong Wu wrote:
diff --git a/net/hub.c b/net/hub.c
index 122de69..8c77d03 100644
--- a/net/hub.c
+++ b/net/hub.c
@@ -184,6 +184,25 @@ NetClientState *net_hub_find_client_by_name(unsigned
int hub_id,
}
/**
+ * Determine if one nc peers with one hub port
+ */
+bool net_hub_port_peer_nc(NetClientState *nc)
+{
+ NetHub *hub;
+ NetHubPort *port;
+
+ QLIST_FOREACH(hub, hubs, next) {
+ QLIST_FOREACH(port, hub-ports, next) {
+ if (nc == port-nc.peer) {
+ return true;
+ }
+ }
+ }
+
+ return false;
+}
+
+/**
* Print hub configuration
*/
void net_hub_info(Monitor *mon)
@@ -194,8 +213,8 @@ void net_hub_info(Monitor *mon)
QLIST_FOREACH(hub, hubs, next) {
monitor_printf(mon, hub %u\n, hub-id);
QLIST_FOREACH(port, hub-ports, next) {
- monitor_printf(mon, port %u peer %s\n, port-id,
- port-nc.peer ? port-nc.peer-name :
none);
+ monitor_printf(mon, \\ );
This will have the following layout:
(qemu) info network
hub 1
\ dump.0: type=dump,dump to qemu-vlan1.pcap (len=65536)
\ user.1: type=user,net=10.0.2.0,restrict=off
\ virtio-net-pci.0:
type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:58
hub 0
\ user.0: type=user,net=10.0.2.0,restrict=off
\ e1000.0: type=nic,model=e1000,macaddr=52:54:00:12:34:57
virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
\ ur:
type=tap,ifname=tap0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown
^^^
Two space too much of indention (you remove them above for the existing
It is three space, not two.
peer \ peer outputs).
Do you mean that it should be like monitor_printf(mon, \\ ); but
this indention will not match with those peers in hub case.
This line is for printing peers attached to a hub, isn't it? So it
Yeah, but it is three spaces, not one. You can check the code in
do_info_network. For non-hub peers, it is also three spaces.
should be exactly one space, like for the non-hub peers. You should see
it better than I when running the code.
That is the result i got when i was running the code.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
Regards,
Zhi Yong Wu
Re: [Qemu-devel] [PATCH v4 13/16] net: Make info network output more readable info
On Fri, May 25, 2012 at 10:50 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2012-05-25 11:44, Zhi Yong Wu wrote:
On Fri, May 25, 2012 at 10:40 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2012-05-25 11:25, Zhi Yong Wu wrote:
diff --git a/net/hub.c b/net/hub.c
index 122de69..8c77d03 100644
--- a/net/hub.c
+++ b/net/hub.c
@@ -184,6 +184,25 @@ NetClientState
*net_hub_find_client_by_name(unsigned int hub_id,
}
/**
+ * Determine if one nc peers with one hub port
+ */
+bool net_hub_port_peer_nc(NetClientState *nc)
+{
+ NetHub *hub;
+ NetHubPort *port;
+
+ QLIST_FOREACH(hub, hubs, next) {
+ QLIST_FOREACH(port, hub-ports, next) {
+ if (nc == port-nc.peer) {
+ return true;
+ }
+ }
+ }
+
+ return false;
+}
+
+/**
* Print hub configuration
*/
void net_hub_info(Monitor *mon)
@@ -194,8 +213,8 @@ void net_hub_info(Monitor *mon)
QLIST_FOREACH(hub, hubs, next) {
monitor_printf(mon, hub %u\n, hub-id);
QLIST_FOREACH(port, hub-ports, next) {
- monitor_printf(mon, port %u peer %s\n, port-id,
- port-nc.peer ? port-nc.peer-name :
none);
+ monitor_printf(mon, \\ );
This will have the following layout:
(qemu) info network
hub 1
\ dump.0: type=dump,dump to qemu-vlan1.pcap (len=65536)
\ user.1: type=user,net=10.0.2.0,restrict=off
\ virtio-net-pci.0:
type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:58
hub 0
\ user.0: type=user,net=10.0.2.0,restrict=off
\ e1000.0: type=nic,model=e1000,macaddr=52:54:00:12:34:57
virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
\ ur:
type=tap,ifname=tap0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown
^^^
Two space too much of indention (you remove them above for the existing
It is three space, not two.
peer \ peer outputs).
Do you mean that it should be like monitor_printf(mon, \\ ); but
this indention will not match with those peers in hub case.
This line is for printing peers attached to a hub, isn't it? So it
Yeah, but it is three spaces, not one. You can check the code in
do_info_network. For non-hub peers, it is also three spaces.
Then non-hub needs adjustment to a single space as well. Just remove the
two spaces I added to indent the categories (VLAN vs. non-VLAN listing)
OK, done
for _both_ peer lines.
(I love nit-picking discussions :) )
No matter. :)
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
Regards,
Zhi Yong Wu
Re: [Qemu-devel] [PATCH] version: update version info
On Thu, May 24, 2012 at 4:53 PM, Stefan Hajnoczi stefa...@linux.vnet.ibm.com wrote: On Thu, May 24, 2012 at 10:54:46AM +0800, zwu.ker...@gmail.com wrote: From: Zhi Yong Wu wu...@linux.vnet.ibm.com Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com --- VERSION | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Try: $ git log -p ./VERSION Anthony manages this file, what he does is: x.y.50 - development branch x.y.90 - Next version -rc0 release x.y.91 - Next version -rc1 release ... When he tags QEMU 1.1 he will change the version to 1.1.0. It's too early to do this now since we still need more -rc releases before 1.1.0 stable is released. The only person who needs to update this file in Anthony since he creates the release. thanks. please ignore this patch.:) Stefan -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH v2 15/15] net: invoke qemu_can_send_packet only before net queue sending function
On Thu, May 24, 2012 at 6:07 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 24/05/2012 06:05, Zhi Yong Wu ha scritto:
On Thu, May 24, 2012 at 12:00 AM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 23/05/2012 17:14, zwu.ker...@gmail.com ha scritto:
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
net/queue.c | 4 ++--
net/slirp.c | 7 ---
net/tap.c | 2 +-
slirp/if.c | 5 -
slirp/libslirp.h | 1 -
5 files changed, 3 insertions(+), 16 deletions(-)
diff --git a/net/queue.c b/net/queue.c
index 0afd783..d2e57de 100644
--- a/net/queue.c
+++ b/net/queue.c
@@ -176,7 +176,7 @@ ssize_t qemu_net_queue_send(NetQueue *queue,
{
ssize_t ret;
- if (queue-delivering) {
+ if (queue-delivering || !qemu_can_send_packet(sender)) {
return qemu_net_queue_append(queue, sender, flags, data, size,
NULL);
}
@@ -200,7 +200,7 @@ ssize_t qemu_net_queue_send_iov(NetQueue *queue,
{
ssize_t ret;
- if (queue-delivering) {
+ if (queue-delivering || !qemu_can_send_packet(sender)) {
return qemu_net_queue_append_iov(queue, sender, flags, iov,
iovcnt, NULL);
}
diff --git a/net/slirp.c b/net/slirp.c
index a6ede2b..248f7ff 100644
--- a/net/slirp.c
+++ b/net/slirp.c
@@ -96,13 +96,6 @@ static void slirp_smb_cleanup(SlirpState *s);
static inline void slirp_smb_cleanup(SlirpState *s) { }
#endif
-int slirp_can_output(void *opaque)
-{
- SlirpState *s = opaque;
-
- return qemu_can_send_packet(s-nc);
-}
-
void slirp_output(void *opaque, const uint8_t *pkt, int pkt_len)
{
SlirpState *s = opaque;
diff --git a/net/tap.c b/net/tap.c
index 65f45b8..7b1992b 100644
--- a/net/tap.c
+++ b/net/tap.c
@@ -210,7 +210,7 @@ static void tap_send(void *opaque)
if (size == 0) {
tap_read_poll(s, 0);
}
- } while (size 0 qemu_can_send_packet(s-nc));
+ } while (size 0);
Can you explain this? Also, have you benchmarked the change to see what
Its code execution flow is like below:
tap_send -- qemu_send_packet_async
-qemu_send_packet_async_with_flags -qemu_net_queue_send
So it will finally invoke qemu_can_send_packet to determine if it can
send packets. this code change delay this determination.
But you will copy packets uselessly. The code before the patch simply
left them on the tap file descriptor. This is better because it
involves the kernel in flow control. You are introducing bufferbloat.
You are correct, but can_send_packet will be invoked twice for one
packet delivery.
Also, can you explain why you didn't implement this?
Hub can now do its own flow control if it provides its can_recieve.
But you didn't add can_receive.
Why need we add some counts to track in-flight packets?
To implement can_receive.
Let me try.
Paolo
--
Regards,
Zhi Yong Wu
Re: [Qemu-devel] [PATCH v2 13/15] net: Remove obsolete vlan info
On Thu, May 24, 2012 at 8:09 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2012-05-23 23:42, Zhi Yong Wu wrote:
On Wed, May 23, 2012 at 11:41 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2012-05-23 12:14, zwu.ker...@gmail.com wrote:
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
net.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/net.c b/net.c
index 61dc28d..8c8e703 100644
--- a/net.c
+++ b/net.c
@@ -1079,7 +1079,6 @@ void do_info_network(Monitor *mon)
NetClientState *nc, *peer;
net_client_type type;
- monitor_printf(mon, Devices not on any VLAN:\n);
QTAILQ_FOREACH(nc, net_clients, next) {
peer = nc-peer;
type = nc-info-type;
This looks suspicious - or the patch description is improvable. This is
really just about removing that headline? And what about the indention
of the lines printed afterward?
As you have known, vlan concept is replaced with hub. So i think that
it is more reasonable to remove this in monitor.
That is true. But the output formatting is still improvable.
Please see below.
It also leads me to the question how hub-based networks will be
visualized on info network, specifically when there are multiple hubs.
Can you provide some more complex example of an info network output?
(qemu) info network
virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
\ hub0port0: type=(null),
virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57
\ hub1port0: type=(null),
hub 1
port 1 peer user.1
port 0 peer virtio-net-pci.1
hub 0
port 1 peer user.0
port 0 peer virtio-net-pci.0
What about a layout like this:
hub.0
\ virtio-net-pci.0: ...
\ virtio-net-pci.1: ...
\ user.0: ...
hub.1
\ e1000.0: ...
e1000.1: ...
\ user.1: ...
It is completely wrong. In one hub, one NIC emulated driver such as
virtio-net peers with one hub port; while its network backend such as
user peers with another hub port in the same hub. This is hub work
logic. Of course, you can add one dump network backend to this hub via
one hub port.
ie. printing the hubs first, listing all the peers of their ports
underneath them. Also, things like type=(null) should be avoided.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
Regards,
Zhi Yong Wu
