Re: [Qemu-devel] [sheepdog] [PATCH v4 03/10] sheepdog: check return values of qemu_co_recv/send correctly
At Tue, 30 Jul 2013 15:48:02 +0200,
Stefan Hajnoczi wrote:
On Fri, Jul 26, 2013 at 03:10:45PM +0900, MORITA Kazutaka wrote:
If qemu_co_recv/send doesn't return the specified length, it means
that an error happened.
Tested-and-reviewed-by: Liu Yuan namei.u...@gmail.com
Signed-off-by: MORITA Kazutaka morita.kazut...@lab.ntt.co.jp
---
block/sheepdog.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/block/sheepdog.c b/block/sheepdog.c
index 6a41ad9..c6e9b89 100644
--- a/block/sheepdog.c
+++ b/block/sheepdog.c
@@ -489,13 +489,13 @@ static coroutine_fn int send_co_req(int sockfd,
SheepdogReq *hdr, void *data,
int ret;
ret = qemu_co_send(sockfd, hdr, sizeof(*hdr));
-if (ret sizeof(*hdr)) {
+if (ret != sizeof(*hdr)) {
error_report(failed to send a req, %s, strerror(errno));
Does this rely on qemu_co_send_recv() getting ret=-1 errno=EPIPE from
iov_send_recv()? I want to check that I understand what happens when
the socket is closed by the other side.
Yes, when the socket is closed by the peer, qemu_co_send_recv()
returns a short write (if some bytes are already sent) or -1 (if no
data is sent). The current sheepdog driver doesn't work correctly for
the latter case because it compares -1 and an unsigned value.
This doesn't happen for the current qemu-io and qemu-img because they
terminate with SIGPIPE when the connection is closed by the peer.
Thanks,
Kazutaka
Re: [Qemu-devel] [sheepdog] [PATCH v4 06/10] coroutine: add co_aio_sleep_ns() to allow sleep in block drivers
At Tue, 30 Jul 2013 15:58:58 +0200,
Stefan Hajnoczi wrote:
On Fri, Jul 26, 2013 at 03:10:48PM +0900, MORITA Kazutaka wrote:
This helper function behaves similarly to co_sleep_ns(), but the
sleeping coroutine will be resumed when using qemu_aio_wait().
Signed-off-by: MORITA Kazutaka morita.kazut...@lab.ntt.co.jp
---
include/block/coroutine.h | 8
qemu-coroutine-sleep.c| 47
+++
2 files changed, 55 insertions(+)
diff --git a/include/block/coroutine.h b/include/block/coroutine.h
index 377805a..23ea6e9 100644
--- a/include/block/coroutine.h
+++ b/include/block/coroutine.h
@@ -210,6 +210,14 @@ void qemu_co_rwlock_unlock(CoRwlock *lock);
void coroutine_fn co_sleep_ns(QEMUClock *clock, int64_t ns);
/**
+ * Yield the coroutine for a given duration
+ *
+ * Behaves similarly to co_sleep_ns(), but the sleeping coroutine will be
+ * resumed when using qemu_aio_wait().
+ */
+void coroutine_fn co_aio_sleep_ns(int64_t ns);
+
+/**
* Yield until a file descriptor becomes readable
*
* Note that this function clobbers the handlers for the file descriptor.
diff --git a/qemu-coroutine-sleep.c b/qemu-coroutine-sleep.c
index 169ce5c..3955347 100644
--- a/qemu-coroutine-sleep.c
+++ b/qemu-coroutine-sleep.c
@@ -13,6 +13,7 @@
#include block/coroutine.h
#include qemu/timer.h
+#include qemu/thread.h
typedef struct CoSleepCB {
QEMUTimer *ts;
@@ -37,3 +38,49 @@ void coroutine_fn co_sleep_ns(QEMUClock *clock, int64_t
ns)
qemu_del_timer(sleep_cb.ts);
qemu_free_timer(sleep_cb.ts);
}
+
+typedef struct CoAioSleepCB {
+QEMUBH *bh;
+int64_t ns;
+Coroutine *co;
+} CoAioSleepCB;
+
+static void co_aio_sleep_cb(void *opaque)
+{
+CoAioSleepCB *aio_sleep_cb = opaque;
+
+qemu_coroutine_enter(aio_sleep_cb-co, NULL);
+}
+
+static void *sleep_thread(void *opaque)
+{
+CoAioSleepCB *aio_sleep_cb = opaque;
+struct timespec req = {
+.tv_sec = aio_sleep_cb-ns / 10,
+.tv_nsec = aio_sleep_cb-ns % 10,
+};
+struct timespec rem;
+
+while (nanosleep(req, rem) 0 errno == EINTR) {
This breaks the Windows build and makes qemu_aio_wait() spin instead of
blocking (wastes CPU).
I think Alex Bligh and Ping Fan's QEMUTimer in AioContext work is needed
here. I have CCed them. Their patches would allow you to use
co_sleep_ns() in qemu_aio_wait().
Okay, I'll update this patch based on the AioContext timer. I'm also
happy to help Alex and Pingfan to finish the implementation.
Thanks,
Kazutaka
[Qemu-devel] [Bug 994378] Re: Nested-virt)L1 (kvm on kvm)guest panic with parameter “-cpu host” in qemu command line.
after echo 1 /sys/modules/kvm/parameters/ignore_msrs in host, the guest (with my own kernel config) boot up fine. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/994378 Title: Nested-virt)L1 (kvm on kvm)guest panic with parameter “-cpu host” in qemu command line. Status in QEMU: New Bug description: Environment: Host OS (ia32/ia32e/IA64):ia32e Guest OS (ia32/ia32e/IA64):ia32e Guest OS Type (Linux/Windows):Linux kvm.git Commit:19853301ef3289bda2d5264c1093e74efddaeab9 qemu-kvm Commit:69abebf20280152da8fa7c418a819ae51e862231 Host Kernel Version:3.4.0-rc3 Hardware:WSM-EP, Romley-EP Bug detailed description: -- (KVM on KVM) L1 guest panic when starting the L1 guest with “-cpu host” parameter in qemu command line. Note: 1. when creating guest with “-cpu qemu64,+vmx”, L1 guest and L2 guest can boot up. 2. This should be a qemu-kvm bug. using '-cpu host' parameter, the following is the result. Kvm+ qemu-kvm =result 19853301 + 69abebf2 = bad 19853301 + 44755ea3 = good 3. when booting up the guest with the good commit of 19853301 + 44755ea3, you can see some error info, but nested virt works fine. (L1 and L2 guest can boot up.) “error: feature i64 not available in set error: bad option value [extfeature_edx = i64 xd syscall]” some logs [root@vt-snb9 x86_64-softmmu]# ./qemu-system-x86_64 -m 2048 -net nic,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup -hda /root/nested-kvm.qcow -cpu host error: feature i64 not available in set error: bad option value [extfeature_edx = i64 xd syscall] error: feature i64 not available in set error: bad option value [extfeature_edx = i64 xd syscall] error: feature i64 not available in set error: bad option value [extfeature_edx = i64 syscall xd] error: feature i64 not available in set error: bad option value [extfeature_edx = i64 syscall xd] VNC server running on `::1:5900' Reproduce steps: 1.start up a host with kvm (commit: 19853301) 2.rmmod kvm_intel 3.modprobe kvm_intel nested=1 4.qemu-system-x86_64 -m 2048 -hda L1-kvm.img -cpu host Current result: L1 guest panic. Expected result: L1 guest and L2 guest boot up correctly. Basic root-causing log: -- To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/994378/+subscriptions
Re: [Qemu-devel] default slot used for vga device on q35 machines
Hi, qemu-kvm -M q35 -nodefaults -nodefconfig -qmp unix:/tmp/qemu,server -vnc :15 -vga std -usb Then ran query-pci in the qmp monitor and found that the vga device is put at slot 1 instead of slot 2. My questions: 1) Is this difference intentional, or a bug? The vga simply goes into the first free slot. That happens to be #2 with i440fx and #1 with q35. 2) If it's intentional, will the device always be at slot 1 (and trigger an error if something else is also placed at slot 1), or is it just picking the first unused slot? (that would *not* be good, because we must be able to predict what device is in which slot and prevent them from changing from run to run). The vga is the very first (pci) device being created (when selecting via -vga), so it gets the slots mentioned above no matter what, even though simply picking the first unused slot. 3) Does the qxl multihead support really require that the device be at slot 2 (as stated in the above bugzilla commend)? Or is that just a misunderstanding/overstatement? It's not required at all. The problem is that on older qemu versions (pre-memory-api basically) it was impossible to create functional vga devices via -device due to an initialization order issue. Which implies you have to use -vga instead, which in turn implies the vga ends up in slot #2. On i440fx, but q35 didn't exist yet back then ;) cheers, Gerd
Re: [Qemu-devel] [PATCH v3 04/19] block: update bs-total_sectors on writes
On 29.07.2013 16:18, Paolo Bonzini wrote:
Il 29/07/2013 16:10, Kevin Wolf ha scritto:
Am 29.07.2013 um 15:47 hat Paolo Bonzini geschrieben:
Il 29/07/2013 15:13, Kevin Wolf ha scritto:
Am 25.07.2013 um 16:23 hat Paolo Bonzini geschrieben:
If a BlockDriverState is growable, after every write we need to
check if bs-total_sectors might have changed.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
block.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/block.c b/block.c
index 6cd39fa..ebac2fa 100644
--- a/block.c
+++ b/block.c
@@ -2651,6 +2651,9 @@ static int coroutine_fn
bdrv_co_do_writev(BlockDriverState *bs,
if (bs-wr_highest_sector sector_num + nb_sectors - 1) {
bs-wr_highest_sector = sector_num + nb_sectors - 1;
}
+if (bs-growable ret = 0) {
+bs-total_sectors = MAX(bs-total_sectors, sector_num + nb_sectors);
+}
Can we change bdrv_getlength() to use bs-total_sectors even for
growable images after this patch?
Probably, but not in 1.6. :)
Probably was my conclusion as well. The answer to this question is the
answer to whether this patch makes sense, I think. So I can give you a
Probably-reviewed-by if that's of any use. ;-)
FWIW, I've got the feeling that the whole series might be better suited
for block-next. Is there anything urgent in it?
No, I don't think so.
can you give an update what are to current plans/schedule to merge this series?
I have
a few patches in the queue that in their current version depend on this series
being merged.
Peter
[Qemu-devel] [PATCH for-1.6 1/2] don't create pvpanic device by default.
The problem with pvpanic being an internal device is that VMs running
operating systems without a driver for this device will have problems
when qemu will be upgraded (from qemu without this pvpanic).
The outcome may be, for example: in Windows(let's say XP) the Device
manager will open a new device wizard and the device will appear as
an unrecognized device. On a cluster with hundreds of such VMs, If
that cluster has a health monitoring service it may show all the VMs
in a not healthy state.
Reported-by: Marcel Apfelbaum marce...@redhat.com
Signed-off-by: Hu Tao hu...@cn.fujitsu.com
---
hw/i386/pc_piix.c | 8
hw/i386/pc_q35.c | 6 --
2 files changed, 14 deletions(-)
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index ab25458..3ccf96c 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -56,7 +56,6 @@ static const int ide_iobase[MAX_IDE_BUS] = { 0x1f0, 0x170 };
static const int ide_iobase2[MAX_IDE_BUS] = { 0x3f6, 0x376 };
static const int ide_irq[MAX_IDE_BUS] = { 14, 15 };
-static bool has_pvpanic = true;
static bool has_pci_info = true;
/* PC hardware initialisation */
@@ -228,10 +227,6 @@ static void pc_init1(MemoryRegion *system_memory,
if (pci_enabled) {
pc_pci_device_init(pci_bus);
}
-
-if (has_pvpanic) {
-pvpanic_init(isa_bus);
-}
}
static void pc_init_pci(QEMUMachineInitArgs *args)
@@ -257,7 +252,6 @@ static void pc_init_pci_1_5(QEMUMachineInitArgs *args)
static void pc_init_pci_1_4(QEMUMachineInitArgs *args)
{
-has_pvpanic = false;
x86_cpu_compat_set_features(n270, FEAT_1_ECX, 0, CPUID_EXT_MOVBE);
pc_init_pci_1_5(args);
}
@@ -290,7 +284,6 @@ static void pc_init_pci_no_kvmclock(QEMUMachineInitArgs
*args)
const char *kernel_cmdline = args-kernel_cmdline;
const char *initrd_filename = args-initrd_filename;
const char *boot_device = args-boot_device;
-has_pvpanic = false;
has_pci_info = false;
disable_kvm_pv_eoi();
enable_compat_apic_id_mode();
@@ -309,7 +302,6 @@ static void pc_init_isa(QEMUMachineInitArgs *args)
const char *kernel_cmdline = args-kernel_cmdline;
const char *initrd_filename = args-initrd_filename;
const char *boot_device = args-boot_device;
-has_pvpanic = false;
has_pci_info = false;
if (cpu_model == NULL)
cpu_model = 486;
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 2f35d12..c816c2f 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -46,7 +46,6 @@
/* ICH9 AHCI has 6 ports */
#define MAX_SATA_PORTS 6
-static bool has_pvpanic = true;
static bool has_pci_info = true;
/* PC hardware initialisation */
@@ -211,10 +210,6 @@ static void pc_q35_init(QEMUMachineInitArgs *args)
if (pci_enabled) {
pc_pci_device_init(host_bus);
}
-
-if (has_pvpanic) {
-pvpanic_init(isa_bus);
-}
}
static void pc_q35_init_1_5(QEMUMachineInitArgs *args)
@@ -225,7 +220,6 @@ static void pc_q35_init_1_5(QEMUMachineInitArgs *args)
static void pc_q35_init_1_4(QEMUMachineInitArgs *args)
{
-has_pvpanic = false;
x86_cpu_compat_set_features(n270, FEAT_1_ECX, 0, CPUID_EXT_MOVBE);
pc_q35_init_1_5(args);
}
--
1.8.1.4
[Qemu-devel] [PATCH for-1.6 2/2] pvpanic: make pvpanic known to user
Thus user can create pvpanic by -device.
Signed-off-by: Hu Tao hu...@cn.fujitsu.com
---
hw/misc/pvpanic.c| 23 ---
include/hw/i386/pc.h | 3 ---
2 files changed, 8 insertions(+), 18 deletions(-)
diff --git a/hw/misc/pvpanic.c b/hw/misc/pvpanic.c
index 7bb49a5..6e4c53e 100644
--- a/hw/misc/pvpanic.c
+++ b/hw/misc/pvpanic.c
@@ -93,14 +93,6 @@ static void pvpanic_isa_initfn(Object *obj)
memory_region_init_io(s-io, OBJECT(s), pvpanic_ops, s, pvpanic, 1);
}
-static void pvpanic_isa_realizefn(DeviceState *dev, Error **errp)
-{
-ISADevice *d = ISA_DEVICE(dev);
-PVPanicState *s = ISA_PVPANIC_DEVICE(dev);
-
-isa_register_ioport(d, s-io, s-ioport);
-}
-
static void pvpanic_fw_cfg(ISADevice *dev, FWCfgState *fw_cfg)
{
PVPanicState *s = ISA_PVPANIC_DEVICE(dev);
@@ -111,15 +103,16 @@ static void pvpanic_fw_cfg(ISADevice *dev, FWCfgState
*fw_cfg)
sizeof(*pvpanic_port));
}
-void pvpanic_init(ISABus *bus)
+static void pvpanic_isa_realizefn(DeviceState *dev, Error **errp)
{
-ISADevice *dev;
+ISADevice *d = ISA_DEVICE(dev);
+PVPanicState *s = ISA_PVPANIC_DEVICE(dev);
FWCfgState *fw_cfg = fw_cfg_find();
-if (!fw_cfg) {
-return;
+
+isa_register_ioport(d, s-io, s-ioport);
+if (fw_cfg) {
+pvpanic_fw_cfg(d, fw_cfg);
}
-dev = isa_create_simple (bus, TYPE_ISA_PVPANIC_DEVICE);
-pvpanic_fw_cfg(dev, fw_cfg);
}
static Property pvpanic_isa_properties[] = {
@@ -132,8 +125,8 @@ static void pvpanic_isa_class_init(ObjectClass *klass, void
*data)
DeviceClass *dc = DEVICE_CLASS(klass);
dc-realize = pvpanic_isa_realizefn;
-dc-no_user = 1;
dc-props = pvpanic_isa_properties;
+dc-bus_type = TYPE_ISA_BUS;
}
static TypeInfo pvpanic_isa_info = {
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 3a0c4e3..e54751c 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -202,9 +202,6 @@ static inline bool isa_ne2000_init(ISABus *bus, int base,
int irq, NICInfo *nd)
/* pc_sysfw.c */
void pc_system_firmware_init(MemoryRegion *rom_memory);
-/* pvpanic.c */
-void pvpanic_init(ISABus *bus);
-
/* e820 types */
#define E820_RAM1
#define E820_RESERVED 2
--
1.8.1.4
Re: [Qemu-devel] default slot used for vga device on q35 machines
Gerd Hoffmann kra...@redhat.com writes: Hi, qemu-kvm -M q35 -nodefaults -nodefconfig -qmp unix:/tmp/qemu,server -vnc :15 -vga std -usb Then ran query-pci in the qmp monitor and found that the vga device is put at slot 1 instead of slot 2. My questions: 1) Is this difference intentional, or a bug? The vga simply goes into the first free slot. That happens to be #2 with i440fx and #1 with q35. The slot used by -vga depends on the machine type, and can be expected to remain stable. We've kept it stable even for the machine type family i440FX. Nevertheless, if you require the graphics adapter to go into a specific slot, I very much recommend to control its placement with -device. [...]
Re: [Qemu-devel] [PATCH v3 1/7] vvfat: use bdrv_new() to allocate BlockDriverState
Reviewed-by: Wenchao Xia xiaw...@linux.vnet.ibm.com we need bdrv_new() to properly initialize BDS, don't allocate memory manually. Signed-off-by: Fam Zheng f...@redhat.com --- block/vvfat.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/block/vvfat.c b/block/vvfat.c index cd3b8ed..a827d91 100644 --- a/block/vvfat.c +++ b/block/vvfat.c @@ -2943,7 +2943,7 @@ static int enable_write_target(BDRVVVFATState *s) unlink(s-qcow_filename); #endif -s-bs-backing_hd = calloc(sizeof(BlockDriverState), 1); +s-bs-backing_hd = bdrv_new(); s-bs-backing_hd-drv = vvfat_write_target; s-bs-backing_hd-opaque = g_malloc(sizeof(void*)); *(void**)s-bs-backing_hd-opaque = s; -- Best Regards Wenchao Xia
Re: [Qemu-devel] [PATCH 1/2] raw: add license header
On 31.07.2013 10:01, Markus Armbruster wrote: Paolo Bonzini pbonz...@redhat.com writes: Most of the block layer is under the BSD license, thus it is reasonable to license block/raw.c the same way. CCed people should ACK by replying with a Signed-off-by line. Cc: Christoph Hellwig h...@lst.de Cc: Kevin Wolf kw...@redhat.com Cc: Anthony Liguori aligu...@us.ibm.com Cc: Markus Armbruster arm...@redhat.com Cc: Stefan Hajnoczi stefa...@redhat.com Cc: Luiz Capitulino lcapitul...@redhat.com Cc: Jeff Cody jc...@redhat.com Cc: Peter Lieven p...@kamp.de Signed-off-by: Paolo Bonzini pbonz...@redhat.com In general, I very much prefer to protect my work with a strong copyleft license like the GPLv2+. However, my contributions to raw.c are trivial, so I choose to go with the flow in this case. Signed-off-by: Markus Armbruster arm...@redhat.com same applies for me. Signed-off-by: Peter Lieven p...@kamp.de
Re: [Qemu-devel] net/tap.c: Possibly a way to stall tap input
On Thu, Aug 01, 2013 at 07:24:13PM +0200, Jan Kiszka wrote: On 2013-08-01 19:15, Jan Kiszka wrote: Hi all, I'm tracking down a nasty stall of tap input over a custom 1.3.x QEMU version. Under certain load, our tap backend stops reading from the char device, and that even if we reset the guest. The frontend device (pcnet32) is able to receive (can_receive would return 0), but the ^^^ Yes, the pcnet lacks qemu_flush_queued_packets, like certain other NIC models already have. We added that to pcnet_init and pcnet_start (patch will follow), but that didn't make a difference, likely due to what I described below. Yes, you need to add qemu_flush_queued_packets() where the guest enables RX or marks RX descriptors free (usually by writing to a hardware register to update the RX ring index). Please also confirm that you are using -netdev tap -device pcnet32 instead of the legacy -net syntax. The reason I'm asking is because I remember the same issue with net/hub.c, which gets in the way if you use legacy syntax (see 199ee608). Hope this helps, Stefan
[Qemu-devel] [PATCH] qemu-option: Guard against qemu_opts_set_defaults() misuse
Commit 6d4cd40 fixed qemu_opts_set_defaults() for an existing corner
case, but broke it for another one that can't be reached in current
code.
Quote from its commit message:
I believe [opts_parse()] attempts to do the following:
If options don't yet exist, create new options
Else, if defaults, modify the existing options
Else, if list-merge_lists, modify the existing options
Else, fail
The only caller that passes true for defaults is
qemu_opts_set_defaults().
The commit message then claims:
A straightforward call of qemu_opts_create() does exactly that.
Wrong. When !list-merge_lists, and the option string doesn't contain
id=, and options without ID exist, then we don't actually modify the
existing options, we create new ones.
Not reachable, because we never pass lists with !list-merge_lists to
qemu_opts_set_defaults().
Guard against possible (if unlikely) future misuse with assert().
Reported-by: Peter Maydell peter.mayd...@linaro.org
Signed-off-by: Markus Armbruster arm...@redhat.com
---
util/qemu-option.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/util/qemu-option.c b/util/qemu-option.c
index 7a1552a..4ebdc4c 100644
--- a/util/qemu-option.c
+++ b/util/qemu-option.c
@@ -928,6 +928,15 @@ static QemuOpts *opts_parse(QemuOptsList *list, const char
*params,
get_opt_value(value, sizeof(value), p+4);
id = value;
}
+
+/*
+ * This code doesn't work for defaults !list-merge_lists: when
+ * params has no id=, and list has an element with !opts-id, it
+ * appends a new element instead of returning the existing opts.
+ * However, we got no use for this case. Guard against possible
+ * (if unlikely) future misuse:
+ */
+assert(!defaults || list-merge_lists);
opts = qemu_opts_create(list, id, !defaults, local_err);
if (opts == NULL) {
if (error_is_set(local_err)) {
--
1.7.11.7
Re: [Qemu-devel] [PATCH v3 2/7] iscsi: use bdrv_new() instead of stack structure
于 2013-7-31 18:13, Fam Zheng 写道:
BlockDriverState structure needs bdrv_new() to initialize refcnt, don't
allocate a local structure variable and memset to 0, becasue with coming
refcnt implementation, bdrv_unref will crash if bs-refcnt not
initialized to 1.
Signed-off-by: Fam Zheng f...@redhat.com
---
block/iscsi.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/block/iscsi.c b/block/iscsi.c
index 5f28c6a..db8a699 100644
--- a/block/iscsi.c
+++ b/block/iscsi.c
@@ -1247,11 +1247,11 @@ static int iscsi_create(const char *filename,
QEMUOptionParameter *options)
{
int ret = 0;
int64_t total_size = 0;
-BlockDriverState bs;
+BlockDriverState *bs;
IscsiLun *iscsilun = NULL;
QDict *bs_options;
-memset(bs, 0, sizeof(BlockDriverState));
+bs = bdrv_new();
/* Read out options */
while (options options-name) {
@@ -1261,12 +1261,12 @@ static int iscsi_create(const char *filename,
QEMUOptionParameter *options)
options++;
}
-bs.opaque = g_malloc0(sizeof(struct IscsiLun));
-iscsilun = bs.opaque;
+bs-opaque = g_malloc0(sizeof(struct IscsiLun));
+iscsilun = bs-opaque;
bs_options = qdict_new();
qdict_put(bs_options, filename, qstring_from_str(filename));
-ret = iscsi_open(bs, bs_options, 0);
+ret = iscsi_open(bs, bs_options, 0);
QDECREF(bs_options);
if (ret != 0) {
@@ -1280,7 +1280,7 @@ static int iscsi_create(const char *filename,
QEMUOptionParameter *options)
ret = -ENODEV;
goto out;
}
-if (bs.total_sectors total_size) {
+if (bs-total_sectors total_size) {
ret = -ENOSPC;
goto out;
}
@@ -1290,7 +1290,7 @@ out:
if (iscsilun-iscsi != NULL) {
iscsi_destroy_context(iscsilun-iscsi);
}
-g_free(bs.opaque);
bs,opaque seems leaked. bdrv_delete() will not free it unless bs-drv
!= NULL.
+bdrv_delete(bs);
return ret;
}
--
Best Regards
Wenchao Xia
Re: [Qemu-devel] [PATCH v3 3/7] block: implement reference count for BlockDriverState
Reviewed-by: Wenchao Xia xiaw...@linux.vnet.ibm.com Introduce bdrv_ref/bdrv_unref to manage the lifecycle of BlockDriverState. They are unused for now but will used to replace bdrv_delete() later. Signed-off-by: Fam Zheng f...@redhat.com --- block.c | 21 + include/block/block.h | 2 ++ include/block/block_int.h | 1 + 3 files changed, 24 insertions(+) -- Best Regards Wenchao Xia
Re: [Qemu-devel] net/tap.c: Possibly a way to stall tap input
On 2013-08-02 09:33, Stefan Hajnoczi wrote: On Thu, Aug 01, 2013 at 07:24:13PM +0200, Jan Kiszka wrote: On 2013-08-01 19:15, Jan Kiszka wrote: Hi all, I'm tracking down a nasty stall of tap input over a custom 1.3.x QEMU version. Under certain load, our tap backend stops reading from the char device, and that even if we reset the guest. The frontend device (pcnet32) is able to receive (can_receive would return 0), but the ^^^ Yes, the pcnet lacks qemu_flush_queued_packets, like certain other NIC models already have. We added that to pcnet_init and pcnet_start (patch will follow), but that didn't make a difference, likely due to what I described below. Yes, you need to add qemu_flush_queued_packets() where the guest enables RX or marks RX descriptors free (usually by writing to a hardware register to update the RX ring index). For the pcnet, this is different as can_receive checks for stop and suspend states. Please also confirm that you are using -netdev tap -device pcnet32 instead of the legacy -net syntax. The reason I'm asking is because I remember the same issue with net/hub.c, which gets in the way if you use legacy syntax (see 199ee608). We are using legacy syntax. But my analysis of the issue in tap.c appears to be independent of other networking components. Possibly, other setup paper over it, but the conceptual issue remains. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH v3 4/7] block: make bdrv_delete() static
Reviewed-by: Wenchao Xia xiaw...@linux.vnet.ibm.com -- Best Regards Wenchao Xia
[Qemu-devel] [PATCH EMBARGOED 5/7] vmdk: check cluster size in vmdk_open
VMDK specification doesn't give upper limit of cluster size (header.grainSize). But we need to avoid unbounded memory allocation. Check the value when opening and refuse too big value (512MB cluster size). Signed-off-by: Fam Zheng f...@redhat.com --- block/vmdk.c | 1 + tests/qemu-iotests/059 | 2 +- tests/qemu-iotests/059.out | 6 ++ 3 files changed, 8 insertions(+), 1 deletion(-) diff --git a/block/vmdk.c b/block/vmdk.c index dbedff7..1d6bc39 100644 --- a/block/vmdk.c +++ b/block/vmdk.c @@ -41,6 +41,7 @@ #define VMDK4_GD_AT_END 0xULL #define VMDK_GTE_ZEROED 0x1 +#define VMDK_GRANULARITY_MAX 0x10 /* limit of cluster_sectors */ /* VMDK internal error codes */ #define VMDK_OK 0 diff --git a/tests/qemu-iotests/059 b/tests/qemu-iotests/059 index 18807d3..f14c41b 100755 --- a/tests/qemu-iotests/059 +++ b/tests/qemu-iotests/059 @@ -43,7 +43,7 @@ _supported_fmt vmdk _supported_proto generic _supported_os Linux -granularity_offset=16 +granularity_offset=20 echo === Testing invalid granularity === echo diff --git a/tests/qemu-iotests/059.out b/tests/qemu-iotests/059.out index 4ca7f29..380ca3d 100644 --- a/tests/qemu-iotests/059.out +++ b/tests/qemu-iotests/059.out @@ -1,2 +1,8 @@ QA output created by 059 +=== Testing invalid granularity === + +Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=67108864 +invalid granularity, image may be corrupt +qemu-io: can't open device TEST_DIR/t.vmdk +no file open, try 'help open' *** done -- 1.8.3.4
[Qemu-devel] [PATCH EMBARGOED 2/7] vmdk: use unsigned values for on disk header fields
The size and offset fields are all non-negative values, use uint64_t for
them to avoid getting negative in memory value by int overflow.
Signed-off-by: Fam Zheng f...@redhat.com
---
block/vmdk.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/block/vmdk.c b/block/vmdk.c
index 8ff43b9..3c6fa47 100644
--- a/block/vmdk.c
+++ b/block/vmdk.c
@@ -67,14 +67,14 @@ typedef struct {
typedef struct {
uint32_t version;
uint32_t flags;
-int64_t capacity;
-int64_t granularity;
-int64_t desc_offset;
-int64_t desc_size;
-int32_t num_gtes_per_gte;
-int64_t rgd_offset;
-int64_t gd_offset;
-int64_t grain_offset;
+uint64_t capacity;
+uint64_t granularity;
+uint64_t desc_offset;
+uint64_t desc_size;
+uint32_t num_gtes_per_gte;
+uint64_t rgd_offset;
+uint64_t gd_offset;
+uint64_t grain_offset;
char filler[1];
char check_bytes[4];
uint16_t compressAlgorithm;
--
1.8.3.4
[Qemu-devel] [PATCH EMBARGOED 1/7] vmdk: Make VMDK3Header QEMU_PACKED
Although the fields are all uint32_t, it's best to make it consistent
that all on disk structures are QEMU_PACKED.
Signed-off-by: Fam Zheng f...@redhat.com
---
block/vmdk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/vmdk.c b/block/vmdk.c
index 3756333..8ff43b9 100644
--- a/block/vmdk.c
+++ b/block/vmdk.c
@@ -62,7 +62,7 @@ typedef struct {
uint32_t cylinders;
uint32_t heads;
uint32_t sectors_per_track;
-} VMDK3Header;
+} QEMU_PACKED VMDK3Header;
typedef struct {
uint32_t version;
--
1.8.3.4
Re: [Qemu-devel] [PATCH v3 5/7] migration: omit drive ref as we have bdrv_ref now
There should be a section of code in device hot unplug, checking
DriverInfo's ref, fail or do nothing when ref != 1. But I haven't found
that code, so not sure whether this patch will change the behavior in
device hot unplug.
block-migration.c does not actually use DriveInfo anywhere. Hence it's
safe to drive ref code, we really only care about referencing BDS.
Signed-off-by: Fam Zheng f...@redhat.com
---
block-migration.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/block-migration.c b/block-migration.c
index f803f20..daf9ec1 100644
--- a/block-migration.c
+++ b/block-migration.c
@@ -336,8 +336,8 @@ static void init_blk_migration_it(void *opaque,
BlockDriverState *bs)
bmds-completed_sectors = 0;
bmds-shared_base = block_mig_state.shared_base;
alloc_aio_bitmap(bmds);
-drive_get_ref(drive_get_by_blockdev(bs));
bdrv_set_in_use(bs, 1);
+bdrv_ref(bs);
block_mig_state.total_sector_sum += sectors;
@@ -575,7 +575,7 @@ static void blk_mig_cleanup(void)
while ((bmds = QSIMPLEQ_FIRST(block_mig_state.bmds_list)) != NULL) {
QSIMPLEQ_REMOVE_HEAD(block_mig_state.bmds_list, entry);
bdrv_set_in_use(bmds-bs, 0);
-drive_put_ref(drive_get_by_blockdev(bmds-bs));
+bdrv_unref(bmds-bs);
g_free(bmds-aio_bitmap);
g_free(bmds);
}
--
Best Regards
Wenchao Xia
Re: [Qemu-devel] [sheepdog] [PATCH v4 06/10] coroutine: add co_aio_sleep_ns() to allow sleep in block drivers
On Fri, Aug 2, 2013 at 2:20 PM, MORITA Kazutaka
morita.kazut...@lab.ntt.co.jp wrote:
At Tue, 30 Jul 2013 15:58:58 +0200,
Stefan Hajnoczi wrote:
On Fri, Jul 26, 2013 at 03:10:48PM +0900, MORITA Kazutaka wrote:
This helper function behaves similarly to co_sleep_ns(), but the
sleeping coroutine will be resumed when using qemu_aio_wait().
Signed-off-by: MORITA Kazutaka morita.kazut...@lab.ntt.co.jp
---
include/block/coroutine.h | 8
qemu-coroutine-sleep.c| 47
+++
2 files changed, 55 insertions(+)
diff --git a/include/block/coroutine.h b/include/block/coroutine.h
index 377805a..23ea6e9 100644
--- a/include/block/coroutine.h
+++ b/include/block/coroutine.h
@@ -210,6 +210,14 @@ void qemu_co_rwlock_unlock(CoRwlock *lock);
void coroutine_fn co_sleep_ns(QEMUClock *clock, int64_t ns);
/**
+ * Yield the coroutine for a given duration
+ *
+ * Behaves similarly to co_sleep_ns(), but the sleeping coroutine will be
+ * resumed when using qemu_aio_wait().
+ */
+void coroutine_fn co_aio_sleep_ns(int64_t ns);
+
+/**
* Yield until a file descriptor becomes readable
*
* Note that this function clobbers the handlers for the file descriptor.
diff --git a/qemu-coroutine-sleep.c b/qemu-coroutine-sleep.c
index 169ce5c..3955347 100644
--- a/qemu-coroutine-sleep.c
+++ b/qemu-coroutine-sleep.c
@@ -13,6 +13,7 @@
#include block/coroutine.h
#include qemu/timer.h
+#include qemu/thread.h
typedef struct CoSleepCB {
QEMUTimer *ts;
@@ -37,3 +38,49 @@ void coroutine_fn co_sleep_ns(QEMUClock *clock, int64_t
ns)
qemu_del_timer(sleep_cb.ts);
qemu_free_timer(sleep_cb.ts);
}
+
+typedef struct CoAioSleepCB {
+QEMUBH *bh;
+int64_t ns;
+Coroutine *co;
+} CoAioSleepCB;
+
+static void co_aio_sleep_cb(void *opaque)
+{
+CoAioSleepCB *aio_sleep_cb = opaque;
+
+qemu_coroutine_enter(aio_sleep_cb-co, NULL);
+}
+
+static void *sleep_thread(void *opaque)
+{
+CoAioSleepCB *aio_sleep_cb = opaque;
+struct timespec req = {
+.tv_sec = aio_sleep_cb-ns / 10,
+.tv_nsec = aio_sleep_cb-ns % 10,
+};
+struct timespec rem;
+
+while (nanosleep(req, rem) 0 errno == EINTR) {
This breaks the Windows build and makes qemu_aio_wait() spin instead of
blocking (wastes CPU).
I think Alex Bligh and Ping Fan's QEMUTimer in AioContext work is needed
here. I have CCed them. Their patches would allow you to use
co_sleep_ns() in qemu_aio_wait().
Okay, I'll update this patch based on the AioContext timer. I'm also
happy to help Alex and Pingfan to finish the implementation.
Alex, do you make a further step than V4? If you have, could you share
it with us?So we can rebase our patches onto yours.
Thanks,
Pingfan
[Qemu-devel] [PATCH EMBARGOED 3/7] qemu-iotests: add empty test case for vmdk
Will add vmdk specific tests later here.
Signed-off-by: Fam Zheng f...@redhat.com
---
tests/qemu-iotests/059 | 51 ++
tests/qemu-iotests/059.out | 2 ++
tests/qemu-iotests/group | 1 +
3 files changed, 54 insertions(+)
create mode 100755 tests/qemu-iotests/059
create mode 100644 tests/qemu-iotests/059.out
diff --git a/tests/qemu-iotests/059 b/tests/qemu-iotests/059
new file mode 100755
index 000..996d85c
--- /dev/null
+++ b/tests/qemu-iotests/059
@@ -0,0 +1,51 @@
+#!/bin/bash
+#
+# Test case for vmdk
+#
+# Copyright (C) 2011 Red Hat, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see http://www.gnu.org/licenses/.
+#
+
+# creator
+owner=f...@redhat.com
+
+seq=`basename $0`
+echo QA output created by $seq
+
+here=`pwd`
+tmp=/tmp/$$
+status=1 # failure is the default!
+
+_cleanup()
+{
+ _cleanup_test_img
+}
+trap _cleanup; exit \$status 0 1 2 3 15
+
+# get standard environment, filters and checks
+. ./common.rc
+. ./common.filter
+
+# This tests qcow2-specific low-level functionality
+_supported_fmt vmdk
+_supported_proto generic
+_supported_os Linux
+
+granularity_offset=16
+
+# success, all done
+echo *** done
+rm -f $seq.full
+status=0
diff --git a/tests/qemu-iotests/059.out b/tests/qemu-iotests/059.out
new file mode 100644
index 000..4ca7f29
--- /dev/null
+++ b/tests/qemu-iotests/059.out
@@ -0,0 +1,2 @@
+QA output created by 059
+*** done
diff --git a/tests/qemu-iotests/group b/tests/qemu-iotests/group
index 1a1a30a..732dff8 100644
--- a/tests/qemu-iotests/group
+++ b/tests/qemu-iotests/group
@@ -65,3 +65,4 @@
056 rw auto backing
057 rw auto
058 rw auto
+059 rw auto
--
1.8.3.4
Re: [Qemu-devel] [PATCH v3 6/7] xen_disk: simplify blk_disconnect with refcnt
Better to split it into two patches:
1 bugfix: always call bdrv_detach_dev().
2 use refcnt to manage lifecycle.
We call bdrv_attach_dev when initializing whether or not bs is created
locally, so call bdrv_detach_dev and let the refcnt handle the
lifecycle.
Signed-off-by: Fam Zheng f...@redhat.com
---
hw/block/xen_disk.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index 99537e8..39757d9 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -812,6 +812,9 @@ static int blk_connect(struct XenDevice *xendev)
/* setup via qemu cmdline - already setup for us */
xen_be_printf(blkdev-xendev, 2, get configured bdrv (cmdline
setup)\n);
blkdev-bs = blkdev-dinfo-bdrv;
+/* blkdev-bs is not create by us, we get a reference
+ * so we can bdrv_unref() unconditionally */
+bdrv_ref(blkdev-bs);
}
bdrv_attach_dev_nofail(blkdev-bs, blkdev);
blkdev-file_size = bdrv_getlength(blkdev-bs);
@@ -910,12 +913,8 @@ static void blk_disconnect(struct XenDevice *xendev)
struct XenBlkDev *blkdev = container_of(xendev, struct XenBlkDev,
xendev);
if (blkdev-bs) {
-if (!blkdev-dinfo) {
-/* close/delete only if we created it ourself */
-bdrv_close(blkdev-bs);
-bdrv_detach_dev(blkdev-bs, blkdev);
-bdrv_unref(blkdev-bs);
-}
+bdrv_detach_dev(blkdev-bs, blkdev);
+bdrv_unref(blkdev-bs);
blkdev-bs = NULL;
}
xen_be_unbind_evtchn(blkdev-xendev);
--
Best Regards
Wenchao Xia
Re: [Qemu-devel] [PATCH for-1.6 1/2] don't create pvpanic device by default.
On 08/02/2013 09:04 AM, Hu Tao wrote: The problem with pvpanic being an internal device is that VMs running operating systems without a driver for this device will have problems when qemu will be upgraded (from qemu without this pvpanic). The outcome may be, for example: in Windows(let's say XP) the Device manager will open a new device wizard and the device will appear as an unrecognized device. On a cluster with hundreds of such VMs, If that cluster has a health monitoring service it may show all the VMs in a not healthy state. Reported-by: Marcel Apfelbaum marce...@redhat.com Signed-off-by: Hu Tao hu...@cn.fujitsu.com NACK, this is premature. It is fundamentally a firmware problem. We have time to apply an even smaller patch that doesn't set has_pvpanic to true, and delay the whole feature to 1.7, if we do not fix the firmware in the next two weeks. Paolo
Re: [Qemu-devel] [PATCH v3 7/7] nbd: use BlockDriverState refcnt
Reviewed-by: Wenchao Xia xiaw...@linux.vnet.ibm.com Previously, nbd calls drive_get_ref() on the drive of bs. A BDS doesn't always have associated dinfo, which nbd doesn't care either. We already have BDS ref count, so use it to make it safe for a BDS w/o blockdev. Signed-off-by: Fam Zheng f...@redhat.com -- Best Regards Wenchao Xia
Re: [Qemu-devel] pvpanic device should not be automatically included as an internal device
On 08/02/2013 12:42 AM, Eric Blake wrote: On 08/01/2013 04:23 PM, Paolo Bonzini wrote: Automatic devices with no command line argument have proven to be a nightmare for libvirt as well. Although the just-released libvirt 1.1.1 now supports the on_crash element for controlling the command line parameters of qemu related to how qemu will behave when the pvpanic device is triggered, I would also welcome having the ability to control whether the guest even has a pvpanic device exposed, just as we can control whether a guest has a memballoon device exposed. This is quite different from memballoon. pvpanic is a single I/O port, it doesn't use up a PCI slot (thus causing conflicts with other devices at the same address). Perhaps this issue is simply fixed by making the _STA method return 0x0B instead of 0x0F (i.e. turning off the show in user interface bit). That may fix the issue of a windows guest showing the yellow ! mark, but what if, down the road, someone writes an actual windows driver that is aware of that port and how to make a windows BSOD write a panic notification to the port? How does a user go about installing such a driver if the device is not exposed in the user interface list of devices? The user can still manually install a driver even for a device that is not exposed. Having to manually specify the pvpanic device would be yet another knob that nobody uses. Panic notification is a useful feature that should be supported with no particular intervention from the user. Paolo
[Qemu-devel] [PATCH EMBARGOED 4/7] vmdk: check granularity field in opening
Granularity is used to calculate the cluster size and allocate r/w
buffer. Check the value from image before using it, so we don't abort()
for unbounded memory allocation.
Signed-off-by: Fam Zheng f...@redhat.com
---
block/vmdk.c | 13 +
tests/qemu-iotests/059 | 6 ++
2 files changed, 19 insertions(+)
diff --git a/block/vmdk.c b/block/vmdk.c
index 3c6fa47..dbedff7 100644
--- a/block/vmdk.c
+++ b/block/vmdk.c
@@ -475,6 +475,13 @@ static int vmdk_open_vmdk3(BlockDriverState *bs,
if (ret 0) {
return ret;
}
+
+if (le32_to_cpu(header.granularity) 0x20) {
+/* 1GB for one cluster is unrealistic */
+error_report(invalid granularity, image may be corrupt);
+return -EINVAL;
+}
+
extent = vmdk_add_extent(bs,
bs-file, false,
le32_to_cpu(header.disk_sectors),
@@ -561,6 +568,12 @@ static int vmdk_open_vmdk4(BlockDriverState *bs,
header = footer.header;
}
+if (le32_to_cpu(header.granularity) 0x20) {
+/* 1GB for one cluster is unrealistic */
+error_report(invalid granularity, image may be corrupt);
+return -EINVAL;
+}
+
if (le32_to_cpu(header.version) = 3) {
char buf[64];
snprintf(buf, sizeof(buf), VMDK version %d,
diff --git a/tests/qemu-iotests/059 b/tests/qemu-iotests/059
index 996d85c..18807d3 100755
--- a/tests/qemu-iotests/059
+++ b/tests/qemu-iotests/059
@@ -45,6 +45,12 @@ _supported_os Linux
granularity_offset=16
+echo === Testing invalid granularity ===
+echo
+_make_test_img 64M
+poke_file $TEST_IMG $granularity_offset \xff\xff\xff\xff\xff\xff\xff\xff
+$QEMU_IO -c read 0 512 $TEST_IMG 21 | _filter_qemu_io | _filter_testdir
+
# success, all done
echo *** done
rm -f $seq.full
--
1.8.3.4
[Qemu-devel] [PATCH V5 0/6] Refine and export backing file loop check
From: Xu Wang cngesa...@gmail.com If there is loop exists in the backing file chain, many problems could be caused by it, such as no response and segment fault during system boot. Hence stopping backing file loop appear is very necessary. These patches refine and export loop checking function from collect_image_ info_list() to block.c and build a independent function named bdrv_ backing_file_loop_check(). Backing file loop checking is added before image created, before change backing file and before system boot. Updates from V4: 1. Add backing file loop check in bdrv_new_open(). 2. Adjust open file logic of collect_image_info_list() (bdrv_new_open() is called only once when opening the whole chain). 3. Remove redundant brackets in lnk file check logic. 4. Add error output in bdrv_img_create(). 5. Remove MAX_PATH_LEN to use PATH_MAX instead. Updates from V3: 1. Comments fix for function bdrv_backing_file_loop_check(). 2. Add ret check for fseek()/fread() in get_lnk_target_file(). 3. Add limit of shortcuts filename length reading during comparing. 4. Add error_report() in driv_init(). 5. Remove redundant loop check in qcow2/qed_change_backing_file(). Updates from V2: 1. Removed parameter @chain from bdrv_backing_file_loop_check() 2. Comments and format fix, all patches were checked by checkpatch.pl 3. Fixed *bs leak. 4. Improved logic of .lnk file recognization. 5. Add filename lenth limit check in while() 6. Changed get_win_inode() to get_inode() and move all inode get method into it to make logic more simpler. 7. Added value of @fmt as suggested. 8. Added backing file loop check in qcow2.c/qed.c Xu Wang (6): block/qemu-img: Refine and export infinite loop checking in collect_image_info_list() qemu-img: Add infinite loop checking in bdrv_new_open() block: Add WIN32 platform support for backing_file_loop_check() block: Check infinite loop in bdrv_img_create() block: Add backing file loop check in change_backing_file() block: Add infinite loop check in drive_init() block.c | 253 +- blockdev.c| 7 ++ include/block/block.h | 4 + qemu-img.c| 51 +- 4 files changed, 284 insertions(+), 31 deletions(-) -- 1.8.1.4
[Qemu-devel] [PATCH V5 3/6] block: Add WIN32 platform support for backing_file_loop_check()
From: Xu Wang cngesa...@gmail.com
Method of get_inode is different between Linux and WIN32 plateform.
This patch added inode caculate method on Windows plateform so that
backing file check could work on Windows plateform.
Signed-off-by: Xu Wang cngesa...@gmail.com
---
block.c | 156
1 file changed, 148 insertions(+), 8 deletions(-)
diff --git a/block.c b/block.c
index aea653d..1e64665 100644
--- a/block.c
+++ b/block.c
@@ -4433,6 +4433,147 @@ bdrv_acct_done(BlockDriverState *bs, BlockAcctCookie
*cookie)
bs-total_time_ns[cookie-type] += get_clock() - cookie-start_time_ns;
}
+#ifdef _WIN32
+static int get_lnk_target_file(const char *lnk_file, char *filepath)
+{
+unsigned int flag, offset;
+unsigned int sflag;
+char uch;
+int i = 0;
+
+FILE *fd = fopen(lnk_file, rb);
+if (!fd) {
+error_report(Open file %s failed., lnk_file);
+return -1;
+}
+
+/* Check if the file is shortcuts by reading first 4 bytes if it's 0x4c */
+if (fread(flag, 4, 1, fd) != 1) {
+error_report(Read 0x4c field of %s failed., lnk_file);
+goto err;
+}
+
+if (flag != 0x4c) {
+error_report(%s is not a lnk file., lnk_file);
+goto err;
+}
+
+/* Parse flags on offset 0x14 */
+if (fseek(fd, 0x14, SEEK_SET)) {
+error_report(Seek flags of %s failed., lnk_file);
+goto err;
+}
+
+if (fread(flag, 4, 1, fd) != 1) {
+error_report(Read flags of %s failed., lnk_file);
+goto err;
+}
+
+/* seek to the length of item ID list */
+if (fseek(fd, 0x4c, SEEK_SET)) {
+error_report(Seek %s length of item ID list failed., lnk_file);
+goto err;
+}
+
+/* Parse Shell item ID list */
+if (flag 0x01) {
+/* Get the length of SHITEMID */
+if (fread(sflag, 2, 1, fd) != 1) {
+error_report(Read %s length of SHITEMID failed., lnk_file);
+goto err;
+}
+
+/* Skip SHITEMID */
+if (fseek(fd, sflag, SEEK_CUR)) {
+error_report(Skip SHITEMID of %s failed., lnk_file);
+goto err;
+}
+}
+
+offset = ftell(fd);
+if (offset == -1) {
+error_report(ftell() of %s failed., lnk_file);
+goto err;
+}
+/* Read offset of local path */
+if (fseek(fd, offset + 0x10, SEEK_SET)) {
+error_report(Seek offset of %s failed., lnk_file);
+goto err;
+}
+if (fread(flag, 4, 1, fd) != 1) {
+error_report(Read offset of %s failed., lnk_file);
+goto err;
+}
+/* Seek to the start of target file path */
+if (fseek(fd, flag + offset, SEEK_SET)) {
+error_report(Seek target file path of %s failed., lnk_file);
+goto err;
+}
+
+do {
+if (fread(uch, 1, 1, fd) != 1) {
+error_report(Read target path of %s failed., lnk_file);
+goto err;
+}
+filepath[i++] = uch;
+} while ((i = PATH_MAX) (uch != '\0'));
+
+fclose(fd);
+return 0;
+
+err:
+fclose(fd);
+return -1;
+}
+#endif
+
+static long get_inode(const char *filename)
+{
+#ifdef _WIN32
+char pbuf[PATH_MAX + 1], *p;
+long inode;
+struct stat sbuf;
+char path[PATH_MAX + 1];
+int len;
+
+/* If filename contains .lnk, it's a shortcuts. Target file
+ * need to be parsed.
+ */
+len = strlen(filename);
+if (len 4 !strcmp(filename + len - 4, .lnk)) {
+if (get_lnk_target_file(filename, path)) {
+error_report(Parse .lnk file %s failed., filename);
+return -1;
+}
+} else {
+memcpy(path, filename, sizeof(filename));
+}
+
+if (stat(path, sbuf) == -1) {
+error_report(get file %s stat error., path);
+return -1;
+}
+if (GetFullPathName(path, PATH_MAX + 1, pbuf, p) != 0) {
+inode = 11003;
+for (p = pbuf; *p != '\0'; p++) {
+inode = inode * 31 + *(unsigned char *)p;
+}
+return (inode * 911) 0x7FFF;
+}
+
+return -1;
+#else
+struct stat sbuf;
+
+if (stat(filename, sbuf) == -1) {
+error_report(get file %s stat error., filename);
+return -1;
+}
+
+return sbuf.st_ino;
+#endif
+}
+
static gboolean str_equal_func(gconstpointer a, gconstpointer b)
{
return strcmp(a, b) == 0;
@@ -4456,7 +4597,6 @@ bool bdrv_backing_file_loop_check(const char *filename,
const char *fmt,
GHashTable *inodes;
BlockDriverState *bs;
BlockDriver *drv;
-struct stat sbuf;
long inode = 0;
int ret;
char fbuf[1024];
@@ -4468,11 +4608,11 @@ bool bdrv_backing_file_loop_check(const char *filename,
const char *fmt,
if (access(filename, F_OK)) {
inode = -1;
} else {
-if (stat(filename, sbuf) == -1) {
-error_report(Get file %s stat failed., filename);
+inode =
[Qemu-devel] [PATCH V5 6/6] block: Add infinite loop check in drive_init()
From: Xu Wang cngesa...@gmail.com
Backing file should be checked if there is a loop in it during image
boot. Becase if there is loop qemu would no response for a long time
and segment fault occured. So this patch would check backing file
chain if there is loop in it before open image.
Signed-off-by: Xu Wang cngesa...@gmail.com
---
blockdev.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/blockdev.c b/blockdev.c
index b3a57e0..590193f 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -695,6 +695,13 @@ DriveInfo *drive_init(QemuOpts *all_opts,
BlockInterfaceType block_default_type)
error_report(warning: disabling copy_on_read on readonly drive);
}
+/* Add backing file loop check */
+if (bdrv_backing_file_loop_check(file, drv ? drv-format_name : NULL,
+ NULL, NULL)) {
+error_report(drive_init: backing file loop check failed!);
+goto err;
+}
+
ret = bdrv_open(dinfo-bdrv, file, bs_opts, bdrv_flags, drv);
bs_opts = NULL;
--
1.8.1.4
[Qemu-devel] [PATCH V5 2/6] qemu-img: Add infinite loop checking in bdrv_new_open()
From: Xu Wang cngesa...@gmail.com
Every image should be checked if there is infinite loop in backing
file chain before open it. So infinite loop check was added into
bdrv_new_open(). If @filename is opened with no flags
BDRV_O_NO_BACKING, the infinite loop check should be called.
Signed-off-by: Xu Wang cngesa...@gmail.com
---
qemu-img.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/qemu-img.c b/qemu-img.c
index 4f01b0a..1a63bbf 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -278,6 +278,13 @@ static BlockDriverState *bdrv_new_open(const char
*filename,
drv = NULL;
}
+/* check backing file loop if the whole chain need to be opened */
+if (!(flags BDRV_O_NO_BACKING)
+bdrv_backing_file_loop_check(filename, fmt, NULL, NULL)) {
+error_report(bdrv_new_open: Open %s failed., filename);
+goto fail;
+}
+
ret = bdrv_open(bs, filename, NULL, flags, drv);
if (ret 0) {
error_report(Could not open '%s': %s, filename, strerror(-ret));
--
1.8.1.4
[Qemu-devel] [PATCH V5 4/6] block: Check infinite loop in bdrv_img_create()
From: Xu Wang cngesa...@gmail.com
Backing file loop should be checked before qemu-img create command
execution. If loop was found, qemu-img create should be stopped and
an error was printed.
Signed-off-by: Xu Wang cngesa...@gmail.com
---
block.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/block.c b/block.c
index 1e64665..8bb63c2 100644
--- a/block.c
+++ b/block.c
@@ -4731,15 +4731,15 @@ void bdrv_img_create(const char *filename, const char
*fmt,
}
backing_file = get_option_parameter(param, BLOCK_OPT_BACKING_FILE);
+backing_fmt = get_option_parameter(param, BLOCK_OPT_BACKING_FMT);
if (backing_file backing_file-value.s) {
-if (!strcmp(filename, backing_file-value.s)) {
-error_setg(errp, Error: Trying to create an image with the
- same filename as the backing file);
+if (bdrv_backing_file_loop_check(filename, fmt,
+ backing_file-value.s,
+ backing_fmt-value.s)) {
+error_report(bdrv_img_create: loop exists, image create failed.);
goto out;
}
}
-
-backing_fmt = get_option_parameter(param, BLOCK_OPT_BACKING_FMT);
if (backing_fmt backing_fmt-value.s) {
backing_drv = bdrv_find_format(backing_fmt-value.s);
if (!backing_drv) {
--
1.8.1.4
[Qemu-devel] [PATCH V5 1/6] block/qemu-img: Refine and export infinite loop checking in collect_image_info_list()
From: Xu Wang cngesa...@gmail.com
If there is a loop exists in the backing file chain, many problems
could be caused by it, such as no response and segment fault during
system boot. Hence stopping backing file loop appear is very necessary.
This patch refine and export loop checking function from collect_image_
info_list() to block.c and build a independent function named bdrv_
backing_file_loop_check().
Signed-off-by: Xu Wang cngesa...@gmail.com
---
block.c | 96 +++
include/block/block.h | 4 +++
qemu-img.c| 44 ++-
3 files changed, 118 insertions(+), 26 deletions(-)
diff --git a/block.c b/block.c
index 183fec8..aea653d 100644
--- a/block.c
+++ b/block.c
@@ -4433,6 +4433,102 @@ bdrv_acct_done(BlockDriverState *bs, BlockAcctCookie
*cookie)
bs-total_time_ns[cookie-type] += get_clock() - cookie-start_time_ns;
}
+static gboolean str_equal_func(gconstpointer a, gconstpointer b)
+{
+return strcmp(a, b) == 0;
+}
+
+/**
+ * Check backing file chain if there is a loop in it.
+ *
+ * @filename: topmost image filename, absolute or relative path is OK.
+ * @fmt: topmost image format (may be NULL to autodetect)
+ * @backing_file: if this value is set, @filename inode (-1 if it doesn't
+ *exist) will insert into hash table directly. Loop check
+ *starts from it. Absolute or relative path is OK for it.
+ * @backing_format: format of backing file
+ *
+ * Returns: true for backing file loop or error happened, false for no loop.
+ */
+bool bdrv_backing_file_loop_check(const char *filename, const char *fmt,
+ const char *backing_file,
+ const char *backing_format) {
+GHashTable *inodes;
+BlockDriverState *bs;
+BlockDriver *drv;
+struct stat sbuf;
+long inode = 0;
+int ret;
+char fbuf[1024];
+
+inodes = g_hash_table_new_full(g_str_hash, str_equal_func, NULL, NULL);
+
+if (backing_file) {
+/* Check if file exists. */
+if (access(filename, F_OK)) {
+inode = -1;
+} else {
+if (stat(filename, sbuf) == -1) {
+error_report(Get file %s stat failed., filename);
+goto err;
+}
+inode = (long)sbuf.st_ino;
+}
+
+filename = backing_file;
+fmt = backing_format;
+g_hash_table_insert(inodes, (gpointer)inode, NULL);
+}
+
+while (filename (filename[0] != '\0')) {
+if (stat(filename, sbuf) == -1) {
+error_report(Get file %s stat failed., filename);
+goto err;
+}
+inode = (long)sbuf.st_ino;
+
+if (g_hash_table_lookup_extended(inodes, inode, NULL, NULL)) {
+error_report(Backing file '%s' creates an infinite loop.,
+ filename);
+goto err;
+}
+g_hash_table_insert(inodes, (gpointer)inode, NULL);
+
+bs = bdrv_new(image);
+
+if (fmt) {
+drv = bdrv_find_format(fmt);
+if (!drv) {
+error_report(Unknown file format '%s', fmt);
+bdrv_delete(bs);
+goto err;
+}
+} else {
+drv = NULL;
+}
+
+ret = bdrv_open(bs, filename, NULL,
+BDRV_O_CACHE_WB | BDRV_O_NO_BACKING, drv);
+if (ret 0) {
+error_report(Could not open '%s': %s, filename, strerror(-ret));
+bdrv_delete(bs);
+goto err;
+}
+
+bdrv_get_backing_filename(bs, fbuf, sizeof(fbuf));
+filename = fbuf;
+fmt = NULL;
+
+bdrv_delete(bs);
+}
+g_hash_table_destroy(inodes);
+return false;
+
+err:
+g_hash_table_destroy(inodes);
+return true;
+}
+
void bdrv_img_create(const char *filename, const char *fmt,
const char *base_filename, const char *base_fmt,
char *options, uint64_t img_size, int flags,
diff --git a/include/block/block.h b/include/block/block.h
index dd8eca1..3dc29bb 100644
--- a/include/block/block.h
+++ b/include/block/block.h
@@ -333,6 +333,10 @@ int bdrv_save_vmstate(BlockDriverState *bs, const uint8_t
*buf,
int bdrv_load_vmstate(BlockDriverState *bs, uint8_t *buf,
int64_t pos, int size);
+bool bdrv_backing_file_loop_check(const char *filename, const char *fmt,
+ const char *backing_file,
+ const char *backing_format);
+
void bdrv_img_create(const char *filename, const char *fmt,
const char *base_filename, const char *base_fmt,
char *options, uint64_t img_size, int flags,
diff --git a/qemu-img.c b/qemu-img.c
index f8c97d3..4f01b0a 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -1620,11 +1620,6 @@ static void dump_human_image_info_list(ImageInfoList
*list)
[Qemu-devel] [PATCH V5 5/6] block: Add backing file loop check in change_backing_file()
From: Xu Wang cngesa...@gmail.com
Backing file loop should be checked before calling change_backing_
file(). If loop appeared, this calling should be stopped and an
error was printed.
Signed-off-by: Xu Wang cngesa...@gmail.com
---
block.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/block.c b/block.c
index 8bb63c2..a14488f 100644
--- a/block.c
+++ b/block.c
@@ -1963,6 +1963,13 @@ int bdrv_change_backing_file(BlockDriverState *bs,
return -EINVAL;
}
+/* Check if loop exists in backing files chain after changed */
+if (bdrv_backing_file_loop_check(bs-filename,
+ bs-drv ? bs-drv-format_name : NULL,
+ backing_file, backing_fmt)) {
+return -EIO;
+}
+
if (drv-bdrv_change_backing_file != NULL) {
ret = drv-bdrv_change_backing_file(bs, backing_file, backing_fmt);
} else {
--
1.8.1.4
[Qemu-devel] [PATCH v2] target-mips: fix 34Kf configuration for DSP ASE
34Kf core does support DSP ASE. CP0_Config3 configuration for 34Kf and description are wrong. Please refer to MIPS32(R) 34Kf(TM) Processor Core Datasheet Signed-off-by: Yongbok Kim yongbok@imgtec.com --- changes from v1: make status.MX writeable target-mips/translate_init.c |7 +++ 1 files changed, 3 insertions(+), 4 deletions(-) diff --git a/target-mips/translate_init.c b/target-mips/translate_init.c index 7cf238f..c45b1b2 100644 --- a/target-mips/translate_init.c +++ b/target-mips/translate_init.c @@ -274,14 +274,13 @@ static const mips_def_t mips_defs[] = (0 CP0C1_DS) | (3 CP0C1_DL) | (1 CP0C1_DA) | (1 CP0C1_CA), .CP0_Config2 = MIPS_CONFIG2, -.CP0_Config3 = MIPS_CONFIG3 | (1 CP0C3_VInt) | (1 CP0C3_MT), +.CP0_Config3 = MIPS_CONFIG3 | (1 CP0C3_VInt) | (1 CP0C3_MT) | + (1 CP0C3_DSPP), .CP0_LLAddr_rw_bitmask = 0, .CP0_LLAddr_shift = 0, .SYNCI_Step = 32, .CCRes = 2, -/* No DSP implemented. */ -.CP0_Status_rw_bitmask = 0x3678FF1F, -/* No DSP implemented. */ +.CP0_Status_rw_bitmask = 0x3778FF1F, .CP0_TCStatus_rw_bitmask = (0 CP0TCSt_TCU3) | (0 CP0TCSt_TCU2) | (1 CP0TCSt_TCU1) | (1 CP0TCSt_TCU0) | (0 CP0TCSt_TMX) | (1 CP0TCSt_DT) | -- 1.7.4
Re: [Qemu-devel] pvpanic device should not be automatically included as an internal device
On Fri, Aug 02, 2013 at 10:31:11AM +0200, Paolo Bonzini wrote: On 08/02/2013 12:42 AM, Eric Blake wrote: On 08/01/2013 04:23 PM, Paolo Bonzini wrote: Automatic devices with no command line argument have proven to be a nightmare for libvirt as well. Although the just-released libvirt 1.1.1 now supports the on_crash element for controlling the command line parameters of qemu related to how qemu will behave when the pvpanic device is triggered, I would also welcome having the ability to control whether the guest even has a pvpanic device exposed, just as we can control whether a guest has a memballoon device exposed. This is quite different from memballoon. pvpanic is a single I/O port, it doesn't use up a PCI slot (thus causing conflicts with other devices at the same address). Perhaps this issue is simply fixed by making the _STA method return 0x0B instead of 0x0F (i.e. turning off the show in user interface bit). That may fix the issue of a windows guest showing the yellow ! mark, but what if, down the road, someone writes an actual windows driver that is aware of that port and how to make a windows BSOD write a panic notification to the port? How does a user go about installing such a driver if the device is not exposed in the user interface list of devices? The user can still manually install a driver even for a device that is not exposed. Having to manually specify the pvpanic device would be yet another knob that nobody uses. Panic notification is a useful feature that should be supported with no particular intervention from the user. Yep, that was the big motivation behind doing it as an I/O port that we could have enabled by default, as opposed to a virtio serial device or some other paravirt device that required explicit configuration. 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 :|
Re: [Qemu-devel] [RFC v2 3/5] timer: make qemu_clock_enable sync between disable and timer's cb
On Aug 02 2013, liu ping fan wrote: On Thu, Aug 1, 2013 at 10:28 PM, Paolo Bonzini pbonz...@redhat.com wrote: So actually there is another problem with this patch (both the condvar and the event approach are equally buggy). If a timer on clock X disables clock X, qemu_clock_enable will deadlock. Checking the code for callers of qemu_clock_enable() it seems like there shouldn't be any deadlocks. So it should work if qemu_clock_enable Do you mean the caller of qemu_clock_enable(foo,false) can NOT be timer cb? Yes. As for this deadlock issue, making qemu_clock_enable(foo,false) ASYNC, and forcing the caller to sync explicitly ? Right now the callers of qemu_clock_enable(foo, false) are safe. So the problem can be fixed just by adequate documentation. But we should document the expectations since they are different from the current code. Paolo
[Qemu-devel] [Bug 1207686] [NEW] qemu-1.4.0 and onwards, linux kernel 3.2.x, heavy I/O leads to kernel_hung_tasks_timout_secs message and unresponsive qemu-process
Public bug reported: Hi, after some testing I tried to narrow down a problem, which was initially reported by some users. Seen on different distros - debian 7.1, ubuntu 12.04 LTS, IPFire-2.3 as reported by now. All using some flavour of linux-3.2.x kernel. Tried e.g. under Ubuntu an upgrade to Linux 3.8.0-27-generic x86_64 which solves the problem. Problem could be triggert with some workload ala: spew -v --raw -P -t -i 3 -b 4k -p random -B 4k 1G /tmp/doof.dat and in parallel do some apt-get install/remove/whatever. That results in a somewhat stuck qemu-session with the bad kernel_hung_task... messages. A typical command-line is as follows: /usr/local/qemu-1.6.0/bin/qemu-system-x86_64 -usbdevice tablet -enable- kvm -daemonize -pidfile /var/run/qemu-server/760.pid -monitor unix:/var/run/qemu-server/760.mon,server,nowait -vnc unix:/var/run/qemu- server/760.vnc,password -qmp unix:/var/run/qemu- server/760.qmp,server,nowait -nodefaults -serial none -parallel none -device virtio-net-pci,mac=00:F1:70:00:2F:80,netdev=vlan0d0 -netdev type=tap,id=vlan0d0,ifname=tap760i0d0,script=/etc/fcms/add_if.sh,downscript=/etc/fcms/downscript.sh -name 1155823384-4 -m 512 -vga cirrus -k de -smp sockets=1,cores=1 -device virtio-blk-pci,drive=virtio0 -drive format=raw,file=rbd:1155823384/vm-760-disk-1.rbd:rbd_cache=false,cache=writeback,if=none,id=virtio0,media=disk,index=0,aio=native -drive format=raw,file=rbd:1155823384/vm-760-swap-1.rbd:rbd_cache=false,cache=writeback,if=virtio,media=disk,index=1,aio=native -drive if=ide,media=cdrom,id=ide1-cd0,readonly=on -drive if=ide,media=cdrom,id=ide1-cd1,readonly=on -boot order=dc no system_reset, sendkey ctrl-alt-delete or q in monitoring- session is accepted, need to hard-kill the process. Please give any advice on what to do for tracing/debugging, because the number of tickets here are raising, and noone knows, what users are doing inside their VM. Kind regards, Oliver Francke. ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1207686 Title: qemu-1.4.0 and onwards, linux kernel 3.2.x, heavy I/O leads to kernel_hung_tasks_timout_secs message and unresponsive qemu-process Status in QEMU: New Bug description: Hi, after some testing I tried to narrow down a problem, which was initially reported by some users. Seen on different distros - debian 7.1, ubuntu 12.04 LTS, IPFire-2.3 as reported by now. All using some flavour of linux-3.2.x kernel. Tried e.g. under Ubuntu an upgrade to Linux 3.8.0-27-generic x86_64 which solves the problem. Problem could be triggert with some workload ala: spew -v --raw -P -t -i 3 -b 4k -p random -B 4k 1G /tmp/doof.dat and in parallel do some apt-get install/remove/whatever. That results in a somewhat stuck qemu-session with the bad kernel_hung_task... messages. A typical command-line is as follows: /usr/local/qemu-1.6.0/bin/qemu-system-x86_64 -usbdevice tablet -enable-kvm -daemonize -pidfile /var/run/qemu-server/760.pid -monitor unix:/var/run/qemu-server/760.mon,server,nowait -vnc unix:/var/run /qemu-server/760.vnc,password -qmp unix:/var/run/qemu- server/760.qmp,server,nowait -nodefaults -serial none -parallel none -device virtio-net-pci,mac=00:F1:70:00:2F:80,netdev=vlan0d0 -netdev type=tap,id=vlan0d0,ifname=tap760i0d0,script=/etc/fcms/add_if.sh,downscript=/etc/fcms/downscript.sh -name 1155823384-4 -m 512 -vga cirrus -k de -smp sockets=1,cores=1 -device virtio-blk-pci,drive=virtio0 -drive format=raw,file=rbd:1155823384/vm-760-disk-1.rbd:rbd_cache=false,cache=writeback,if=none,id=virtio0,media=disk,index=0,aio=native -drive format=raw,file=rbd:1155823384/vm-760-swap-1.rbd:rbd_cache=false,cache=writeback,if=virtio,media=disk,index=1,aio=native -drive if=ide,media=cdrom,id=ide1-cd0,readonly=on -drive if=ide,media=cdrom,id=ide1-cd1,readonly=on -boot order=dc no system_reset, sendkey ctrl-alt-delete or q in monitoring- session is accepted, need to hard-kill the process. Please give any advice on what to do for tracing/debugging, because the number of tickets here are raising, and noone knows, what users are doing inside their VM. Kind regards, Oliver Francke. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1207686/+subscriptions
Re: [Qemu-devel] net/tap.c: Possibly a way to stall tap input
On Thu, Aug 01, 2013 at 07:15:54PM +0200, Jan Kiszka wrote:
I was digging into the involved code and found something fishy:
net/tap.c:
static void tap_send(void *opaque)
{
...
size = qemu_send_packet_async(s-nc, buf, size,
tap_send_completed);
if (size == 0) {
tap_read_poll(s, false);
}
So, if tap_send is registered for the mainloop polling (ie. can_receive
returned true before starting to poll) but qemu_send_packet_async
returns 0 now as qemu_can_send_packet/can_receive happens to report
false in the meantime, we will disable read polling. If also write
polling is off, the fd will be completely removed from the iohandler
list. But even if write polling remains on, I wonder what should bring
read polling back?
This behavior seems fine to me. Once the peer (pcnet) is able to
receive again it must flush the queue, this will re-enable
tap_read_poll().
Can you explain a bit more why this would be a problem?
Stefan
Re: [Qemu-devel] [PATCH for-1.6 2/2] pvpanic: make pvpanic known to user
Am 02.08.2013 09:04, schrieb Hu Tao:
Thus user can create pvpanic by -device.
Signed-off-by: Hu Tao hu...@cn.fujitsu.com
---
hw/misc/pvpanic.c| 23 ---
include/hw/i386/pc.h | 3 ---
2 files changed, 8 insertions(+), 18 deletions(-)
diff --git a/hw/misc/pvpanic.c b/hw/misc/pvpanic.c
index 7bb49a5..6e4c53e 100644
--- a/hw/misc/pvpanic.c
+++ b/hw/misc/pvpanic.c
@@ -93,14 +93,6 @@ static void pvpanic_isa_initfn(Object *obj)
memory_region_init_io(s-io, OBJECT(s), pvpanic_ops, s, pvpanic, 1);
}
-static void pvpanic_isa_realizefn(DeviceState *dev, Error **errp)
-{
-ISADevice *d = ISA_DEVICE(dev);
-PVPanicState *s = ISA_PVPANIC_DEVICE(dev);
-
-isa_register_ioport(d, s-io, s-ioport);
-}
-
static void pvpanic_fw_cfg(ISADevice *dev, FWCfgState *fw_cfg)
{
PVPanicState *s = ISA_PVPANIC_DEVICE(dev);
@@ -111,15 +103,16 @@ static void pvpanic_fw_cfg(ISADevice *dev, FWCfgState
*fw_cfg)
sizeof(*pvpanic_port));
}
-void pvpanic_init(ISABus *bus)
+static void pvpanic_isa_realizefn(DeviceState *dev, Error **errp)
{
-ISADevice *dev;
+ISADevice *d = ISA_DEVICE(dev);
+PVPanicState *s = ISA_PVPANIC_DEVICE(dev);
FWCfgState *fw_cfg = fw_cfg_find();
-if (!fw_cfg) {
-return;
+
+isa_register_ioport(d, s-io, s-ioport);
+if (fw_cfg) {
+pvpanic_fw_cfg(d, fw_cfg);
}
-dev = isa_create_simple (bus, TYPE_ISA_PVPANIC_DEVICE);
-pvpanic_fw_cfg(dev, fw_cfg);
}
Doing this in-place above might've been a bit easier to read. ;)
The only thing fw_cfg does at realize time is registering its I/O ports,
the /machine/fw_cfg path is set up in fw_cfg_init() helper function
before, so there are no potential realize ordering problems here.
static Property pvpanic_isa_properties[] = {
@@ -132,8 +125,8 @@ static void pvpanic_isa_class_init(ObjectClass *klass,
void *data)
DeviceClass *dc = DEVICE_CLASS(klass);
dc-realize = pvpanic_isa_realizefn;
-dc-no_user = 1;
dc-props = pvpanic_isa_properties;
+dc-bus_type = TYPE_ISA_BUS;
This is already done in hw/isa/isa-bus.c:isa_device_class_init(), please
drop if we go with this.
Regards,
Andreas
}
static TypeInfo pvpanic_isa_info = {
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 3a0c4e3..e54751c 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -202,9 +202,6 @@ static inline bool isa_ne2000_init(ISABus *bus, int base,
int irq, NICInfo *nd)
/* pc_sysfw.c */
void pc_system_firmware_init(MemoryRegion *rom_memory);
-/* pvpanic.c */
-void pvpanic_init(ISABus *bus);
-
/* e820 types */
#define E820_RAM1
#define E820_RESERVED 2
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH for 1.6] tci: Fix broken build (compiler warning caused by redefined macro BIT)
Applied. Thanks. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH] seccomp: add additional asynchronous I/O syscalls
Applied. Thanks. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH v2 for-1.6] chardev: fix CHR_EVENT_OPENED events for mux chardevs
Applied. Thanks. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH for-1.6 v3 0/7] pc: limit 64 bit hole to 2G by default
Applied. Thanks. Regards, Anthony Liguori
Re: [Qemu-devel] net/tap.c: Possibly a way to stall tap input
On 2013-08-02 13:46, Stefan Hajnoczi wrote:
On Thu, Aug 01, 2013 at 07:15:54PM +0200, Jan Kiszka wrote:
I was digging into the involved code and found something fishy:
net/tap.c:
static void tap_send(void *opaque)
{
...
size = qemu_send_packet_async(s-nc, buf, size,
tap_send_completed);
if (size == 0) {
tap_read_poll(s, false);
}
So, if tap_send is registered for the mainloop polling (ie. can_receive
returned true before starting to poll) but qemu_send_packet_async
returns 0 now as qemu_can_send_packet/can_receive happens to report
false in the meantime, we will disable read polling. If also write
polling is off, the fd will be completely removed from the iohandler
list. But even if write polling remains on, I wonder what should bring
read polling back?
This behavior seems fine to me. Once the peer (pcnet) is able to
receive again it must flush the queue, this will re-enable
tap_read_poll().
Can you explain a bit more why this would be a problem?
The problem is that I don't see at all what will call tap_read_poll(s,
1), neither in theory nor in reality.
As long as the real test case is out of reach, I tried to emulate the
faulty behaviour by letting tap_can_send always return 1. Result:
reception stalls during boot as even qemu_flush_queued_packets cannot
get it running again once tap_read_poll(s, 0) was called.
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH] seccomp: add arch_prctl() to the syscall whitelist
Applied. Thanks. Regards, Anthony Liguori
Re: [Qemu-devel] [RFC] [PATCHv4 10/13] aio / timers: Convert mainloop to use timeout
Paolo,
(apologies for taking a little time to reply to this one)
--On 1 August 2013 16:14:11 +0200 Paolo Bonzini pbonz...@redhat.com wrote:
@@ -449,6 +460,7 @@ int main_loop_wait(int nonblocking)
{
int ret;
uint32_t timeout = UINT32_MAX;
+int64_t timeout_ns;
if (nonblocking) {
timeout = 0;
@@ -462,7 +474,21 @@ int main_loop_wait(int nonblocking)
slirp_pollfds_fill(gpollfds);
# endif
qemu_iohandler_fill(gpollfds);
-ret = os_host_main_loop_wait(timeout);
+
+if (timeout == UINT32_MAX) {
+timeout_ns = -1;
+} else {
+timeout_ns = (uint64_t)timeout * (int64_t)(SCALE_MS);
+}
+
+timeout_ns = qemu_soonest_timeout(timeout_ns,
+
qemu_clock_deadline_ns(rt_clock)); +timeout_ns =
qemu_soonest_timeout(timeout_ns,
+
qemu_clock_deadline_ns(vm_clock));
This must not be included if use_icount.
Really? qemu_run_all_timers was running all 3 timers irrespective of
use_icount, and doing a qemu_notify if anything expired, so I'm merely
mimicking the existing behaviour here.
Maybe I'm misreading the code. If it is a replacement of
qemu_next_alarm_deadline, then it is indeed omitting vm_clock.
Well, qemu_next_alarm_deadline calculated the time at which the
next alarm signal would be sent. What I'm calculating is the
wait timeout for poll(), either in the mainloop or in AioContext.
In the mainloop, what this appears to do is to ignore the vm_clock
(whether or not it is enabled) in calculating the timeout if
use_icount is set. However qemu_run_timers is running the timers
attached to the vm_clock whether or not use_icount is set.
If use_icount is set, should be assuming vm_timers have an infinite
timeout for the purpose of calculating timeouts? What the the timer
has already expired (i.e. qemu_run_timers would run it immediately)?
In AioContext, there were previously no timers, so I'm not sure
whether or not this should be doing the same thing.
I'm not quite sure what use_icount does. Does vm_clock get disabled
if it is set? (in which case it won't matter).
It doesn't count nanoseconds anymore.
it being the vm_timer clock source I presume.
The clock is updated by the
VCPU thread. When the VCPU thread notices that the clock is past the
earliest timers, it does a qemu_notify_event(). That exits the g_poll
and qemu_run_all_timers then can process the callbacks.
So the first problem is that this will not cause the other threads
to have aio_notify called, which they should do.
The second question is whether this approach is consistent with using
a timeout for poll at all. I think the answer to that is yes
PROVIDED THAT the VCPU thread is never the one doing the poll,
or we'll go in with an infinite timeout.
I am presuming use_icount never changes at runtime? If not, I
think the way to address this is to add a 'lineartime' member
to QEMUClock, and set that false on the vm_timer QEMUClock if
use_icount is true. I can then ignore it when looping through
clocksources bases on that rather than special casing vm_clock.
Yep - per the above that's really intrusive (I think I touched well over
a hundred files). The problem is that lots of things refer to vm_clock
to set a timer (when it's a clock so should use a timer list) and
also to vm_clock to read the timer (which is a clock function).
Yes, that's fine. You can still keep the shorter invocation,
but instead of using clock-timerlist it would use
qemu_aio_context-clocks[clock-type].
Note that the aio context contains a QEMUTimerList and not
a clock. So it would have 3 QEMUTimerLists, and not 3 QEMUClocks.
I might see if there is a neat way to encapsulate these
(QEMUTimerListGroup or similar?) but yes I get the idea.
Do you want this in a v5 or are we polishing the ball a bit
much here?
Related to this, a better name for the full functions taking
a timerlist could be simply timer_new_ns etc. And I would remove
the allocation step for these functions. It is shameful how little
we use qemu_free_timer, and removing allocation would fix the
problem completely for users of the QEMUTimerList-based functions.
It's already a convention to use qemu_* only for functions that use some
global state, for example qemu_notify_event() vs. aio_notify().
Agree
And because all timerlists have an AioContext,
Well old callers, particularly those not using an AioContext, would
not have an AioContext would they?
It would be qemu_aio_context.
If this were the case, then the timeout for the mainloop would be
the same as the timeout for the qemu_aio_context. Is that an improvement?
What about a (putative) thread that wants a timer but has no AioContext?
I was trying hard to avoid anything having to iterate over all
timerlists, and leave the timerlist to be per-thread where possible.
This may well fail for the clock warp stuff. I probably need to
exactly the same as on qemu_clock_enable() here if use_icount is
true. WDYT?
Yes. This:
Re: [Qemu-devel] [PATCH for-1.6 0/2] Fix clang warnings in linux-user signal code
Applied. Thanks. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH 1/3] rdma: don't use negative index to array
On 08/01/2013 11:56 PM, Isaku Yamahata wrote:
Cc: Michael R. Hines mrhi...@us.ibm.com
Signed-off-by: Isaku Yamahata yamah...@private.email.ne.jp
---
migration-rdma.c | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/migration-rdma.c b/migration-rdma.c
index 4828738..edbae9f 100644
--- a/migration-rdma.c
+++ b/migration-rdma.c
@@ -1931,10 +1931,21 @@ static int qemu_rdma_write_flush(QEMUFile *f,
RDMAContext *rdma)
static inline int qemu_rdma_buffer_mergable(RDMAContext *rdma,
uint64_t offset, uint64_t len)
{
-RDMALocalBlock *block =
-(rdma-local_ram_blocks.block[rdma-current_index]);
-uint8_t *host_addr = block-local_host_addr + (offset - block-offset);
-uint8_t *chunk_end = ram_chunk_end(block, rdma-current_chunk);
+RDMALocalBlock *block;
+uint8_t *host_addr;
+uint8_t *chunk_end;
+
+if (rdma-current_index 0) {
+return 0;
+}
+
+if (rdma-current_chunk 0) {
+return 0;
+}
+
+block = (rdma-local_ram_blocks.block[rdma-current_index]);
+host_addr = block-local_host_addr + (offset - block-offset);
+chunk_end = ram_chunk_end(block, rdma-current_chunk);
if (rdma-current_length == 0) {
return 0;
@@ -1947,10 +1958,6 @@ static inline int qemu_rdma_buffer_mergable(RDMAContext
*rdma,
return 0;
}
-if (rdma-current_index 0) {
-return 0;
-}
-
if (offset block-offset) {
return 0;
}
@@ -1959,10 +1966,6 @@ static inline int qemu_rdma_buffer_mergable(RDMAContext
*rdma,
return 0;
}
-if (rdma-current_chunk 0) {
-return 0;
-}
-
if ((host_addr + len) chunk_end) {
return 0;
}
Reviewed-by: Michael R. Hines mrhi...@us.ibm.com
[Qemu-devel] [Bug 1207623] [NEW] 64bit RHEL6.4 guest crashes and reboots continuously
Public bug reported: Environment: Host OS (ia32/ia32e/IA64):ia32e Guest OS (ia32/ia32e/IA64):ia32e Guest OS Type (Linux/Windows):Linux kvm.git next Commit:9576c4cd6b6fa5716400e63618757b76cff6a813 qemu-kvm uq/master Commit:0779caeb1a17f4d3ed14e2925b36ba09b084fb7b Host Kernel Version:3.11.0-rc1 Hardware: SandyBridge-EP Bug detailed description: -- RHEL6.4 guest alwasy crashes and reboots. 32bit RHEL6.4 and 64bit RHEL6.3 guest can work fine. kvm next + qemu-kvm uq/master = result 9576c4cd + 0779caeb = bad 9576c4cd + c3cb8e77 = good seems the following commit is the culprit commit. commit 0779caeb1a17f4d3ed14e2925b36ba09b084fb7b Author: Arthur Chunqi Li yzt...@gmail.com Date: Sun Jul 7 23:13:37 2013 +0800 Initialize IA32_FEATURE_CONTROL MSR in reset and migration The recent KVM patch adds IA32_FEATURE_CONTROL support. QEMU needs to clear this MSR when reset vCPU and keep the value of it when migration. This patch add this feature. Reproduce steps: 1. qemu-system-x86_64 -enable-kvm -m 1024 -smp 2 -net none /root/rhel6u4.qcow Current result: guest reboot continuously Expected result: guest boot up fine Basic root-causing log: -- (guest serial port log is attached.) ** Affects: qemu-kvm Importance: Undecided Status: New ** Project changed: qemu = qemu-kvm -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1207623 Title: 64bit RHEL6.4 guest crashes and reboots continuously Status in qemu-kvm: New Bug description: Environment: Host OS (ia32/ia32e/IA64):ia32e Guest OS (ia32/ia32e/IA64):ia32e Guest OS Type (Linux/Windows):Linux kvm.git next Commit:9576c4cd6b6fa5716400e63618757b76cff6a813 qemu-kvm uq/master Commit:0779caeb1a17f4d3ed14e2925b36ba09b084fb7b Host Kernel Version:3.11.0-rc1 Hardware: SandyBridge-EP Bug detailed description: -- RHEL6.4 guest alwasy crashes and reboots. 32bit RHEL6.4 and 64bit RHEL6.3 guest can work fine. kvm next + qemu-kvm uq/master = result 9576c4cd + 0779caeb = bad 9576c4cd + c3cb8e77 = good seems the following commit is the culprit commit. commit 0779caeb1a17f4d3ed14e2925b36ba09b084fb7b Author: Arthur Chunqi Li yzt...@gmail.com Date: Sun Jul 7 23:13:37 2013 +0800 Initialize IA32_FEATURE_CONTROL MSR in reset and migration The recent KVM patch adds IA32_FEATURE_CONTROL support. QEMU needs to clear this MSR when reset vCPU and keep the value of it when migration. This patch add this feature. Reproduce steps: 1. qemu-system-x86_64 -enable-kvm -m 1024 -smp 2 -net none /root/rhel6u4.qcow Current result: guest reboot continuously Expected result: guest boot up fine Basic root-causing log: -- (guest serial port log is attached.) To manage notifications about this bug go to: https://bugs.launchpad.net/qemu-kvm/+bug/1207623/+subscriptions
Re: [Qemu-devel] [v2][PATCH 1/1] cpus: use cpu_is_stopped efficiently
Am 02.08.2013 03:43, schrieb Tiejun Chen: It makes more sense and simple later. Signed-off-by: Tiejun Chen tiejun.c...@windriver.com --- v1 - v2: To optimize performance slightly, we can reorder the two conditions to avoid the non-inline function call if cpu-stopped. Patch doesn't apply to qemu.git: next_cpu and cpu_thread_is_idle() use CPUState since a few weeks and do_vm_stop() changed from void to int. Please remember to rebase before sending patches. Thanks, applied to qom-cpu-next (with modified commit message): https://github.com/afaerber/qemu-cpu/commits/qom-cpu-next Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH] qemu-option: Guard against qemu_opts_set_defaults() misuse
On 08/02/2013 01:34 AM, Markus Armbruster wrote: Commit 6d4cd40 fixed qemu_opts_set_defaults() for an existing corner case, but broke it for another one that can't be reached in current code. Not reachable, because we never pass lists with !list-merge_lists to qemu_opts_set_defaults(). Guard against possible (if unlikely) future misuse with assert(). Reported-by: Peter Maydell peter.mayd...@linaro.org Signed-off-by: Markus Armbruster arm...@redhat.com --- util/qemu-option.c | 9 + 1 file changed, 9 insertions(+) + * This code doesn't work for defaults !list-merge_lists: when + * params has no id=, and list has an element with !opts-id, it + * appends a new element instead of returning the existing opts. + * However, we got no use for this case. Guard against possible s/got/have/ Reviewed-by: Eric Blake ebl...@redhat.com -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH 3/3] rdma: use RDMA_WRID_READY
On 08/01/2013 11:56 PM, Isaku Yamahata wrote:
Cc: Michael R. Hines mrhi...@us.ibm.com
Signed-off-by: Isaku Yamahata yamah...@private.email.ne.jp
---
migration-rdma.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/migration-rdma.c b/migration-rdma.c
index 67069d2..871f9cd 100644
--- a/migration-rdma.c
+++ b/migration-rdma.c
@@ -2221,7 +2221,7 @@ static int qemu_rdma_connect(RDMAContext *rdma, Error
**errp)
rdma_ack_cm_event(cm_event);
-ret = qemu_rdma_post_recv_control(rdma, 0);
+ret = qemu_rdma_post_recv_control(rdma, RDMA_WRID_READY);
if (ret) {
ERROR(errp, posting second control recv!\n);
goto err_rdma_source_connect;
@@ -2726,7 +2726,7 @@ static int qemu_rdma_accept(RDMAContext *rdma)
rdma_ack_cm_event(cm_event);
-ret = qemu_rdma_post_recv_control(rdma, 0);
+ret = qemu_rdma_post_recv_control(rdma, RDMA_WRID_READY);
if (ret) {
fprintf(stderr, rdma migration: error posting second control
recv!\n);
goto err_rdma_dest_wait;
Good catch too.
Reviewed-by: Michael R. Hines mrhi...@us.ibm.com
Re: [Qemu-devel] [PATCH 2/3] rdma: qemu_rdma_post_send_control uses wrongly RDMA_WRID_MAX
On 08/01/2013 11:56 PM, Isaku Yamahata wrote:
RDMA_WRID_CONTROL should be used. And remove related work around.
Cc: Michael R. Hines mrhi...@us.ibm.com
Signed-off-by: Isaku Yamahata yamah...@private.email.ne.jp
---
migration-rdma.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/migration-rdma.c b/migration-rdma.c
index edbae9f..67069d2 100644
--- a/migration-rdma.c
+++ b/migration-rdma.c
@@ -322,7 +322,7 @@ typedef struct RDMAContext {
char *host;
int port;
-RDMAWorkRequestData wr_data[RDMA_WRID_MAX + 1];
+RDMAWorkRequestData wr_data[RDMA_WRID_MAX];
/*
* This is used by *_exchange_send() to figure out whether or not
@@ -1397,7 +1397,7 @@ static int qemu_rdma_post_send_control(RDMAContext *rdma,
uint8_t *buf,
RDMAControlHeader *head)
{
int ret = 0;
-RDMAWorkRequestData *wr = rdma-wr_data[RDMA_WRID_MAX];
+RDMAWorkRequestData *wr = rdma-wr_data[RDMA_WRID_CONTROL];
struct ibv_send_wr *bad_wr;
struct ibv_sge sge = {
.addr = (uint64_t)(wr-control),
@@ -2052,7 +2052,7 @@ static void qemu_rdma_cleanup(RDMAContext *rdma)
g_free(rdma-block);
rdma-block = NULL;
-for (idx = 0; idx = RDMA_WRID_MAX; idx++) {
+for (idx = 0; idx RDMA_WRID_MAX; idx++) {
if (rdma-wr_data[idx].control_mr) {
rdma-total_registrations--;
ibv_dereg_mr(rdma-wr_data[idx].control_mr);
@@ -2134,7 +2134,7 @@ static int qemu_rdma_source_init(RDMAContext *rdma, Error
**errp, bool pin_all)
goto err_rdma_source_init;
}
-for (idx = 0; idx = RDMA_WRID_MAX; idx++) {
+for (idx = 0; idx RDMA_WRID_MAX; idx++) {
ret = qemu_rdma_reg_control(rdma, idx);
if (ret) {
ERROR(temp, rdma migration: error registering %d control!\n,
@@ -2243,7 +2243,7 @@ static int qemu_rdma_dest_init(RDMAContext *rdma, Error
**errp)
struct rdma_cm_id *listen_id;
char ip[40] = unknown;
-for (idx = 0; idx = RDMA_WRID_MAX; idx++) {
+for (idx = 0; idx RDMA_WRID_MAX; idx++) {
rdma-wr_data[idx].control_len = 0;
rdma-wr_data[idx].control_curr = NULL;
}
@@ -2696,7 +2696,7 @@ static int qemu_rdma_accept(RDMAContext *rdma)
goto err_rdma_dest_wait;
}
-for (idx = 0; idx = RDMA_WRID_MAX; idx++) {
+for (idx = 0; idx RDMA_WRID_MAX; idx++) {
ret = qemu_rdma_reg_control(rdma, idx);
if (ret) {
fprintf(stderr, rdma: error registering %d control!\n, idx);
Good eyes .. I totally missed that =)
Reviewed-by: Michael R. Hines mrhi...@us.ibm.com
Re: [Qemu-devel] [PATCH 0/3] rdma fixes and clean ups
On 08/01/2013 11:56 PM, Isaku Yamahata wrote: Small fixes/clean up to rdma. found through code review. Isaku Yamahata (3): rdma: don't use negative index to array rdma: qemu_rdma_post_send_control uses wrongly RDMA_WRID_MAX rdma: use RDMA_WRID_READY migration-rdma.c | 43 +++ 1 file changed, 23 insertions(+), 20 deletions(-) Would you like me to apply this series to my tree and re-send our bugfixes together to the maintainer for 1.6? - Michael
Re: [Qemu-devel] [Qemu-trivial] [PATCH] vmdk: fix comment for vmdk_co_write_zeroes
01.08.2013 14:12, Fam Zheng wrote: The comment was truncated. Add the missing parts, especially explain why we need zero_dry_run. Thanks, applied to the trivial patches queue. /mjt
Re: [Qemu-devel] [Qemu-trivial] [PATCH v3] block/iscsi.c: Fix printf format error.
Thanks, applied to the trivial patches queue. /mjt
[Qemu-devel] [PULL 4/4] vmdk: fix comment for vmdk_co_write_zeroes
From: Fam Zheng f...@redhat.com
The comment was truncated. Add the missing parts, especially explain why
we need zero_dry_run.
Signed-off-by: Fam Zheng f...@redhat.com
Signed-off-by: Michael Tokarev m...@tls.msk.ru
---
block/vmdk.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/block/vmdk.c b/block/vmdk.c
index 3756333..e6c50b1 100644
--- a/block/vmdk.c
+++ b/block/vmdk.c
@@ -1200,8 +1200,10 @@ static coroutine_fn int vmdk_co_read(BlockDriverState
*bs, int64_t sector_num,
/**
* vmdk_write:
* @zeroed: buf is ignored (data is zero), use zeroed_grain GTE feature
- * if possible, otherwise return -ENOTSUP.
- * @zero_dry_run: used for zeroed == true only, don't update L2 table, just
+ *if possible, otherwise return -ENOTSUP.
+ * @zero_dry_run: used for zeroed == true only, don't update L2 table, just try
+ *with each cluster. By dry run we can find if the zero write
+ *is possible without modifying image data.
*
* Returns: error code with 0 for success.
*/
@@ -1328,6 +1330,8 @@ static int coroutine_fn
vmdk_co_write_zeroes(BlockDriverState *bs,
int ret;
BDRVVmdkState *s = bs-opaque;
qemu_co_mutex_lock(s-lock);
+/* write zeroes could fail if sectors not aligned to cluster, test it with
+ * dry_run == true before really updating image */
ret = vmdk_write(bs, sector_num, NULL, nb_sectors, true, true);
if (!ret) {
ret = vmdk_write(bs, sector_num, NULL, nb_sectors, true, false);
--
1.7.10.4
[Qemu-devel] [PULL 0/4] trivial patches for 2013-08-02
The following changes since commit 2ddc463725d0fa24e0910fba77fef2777fa94a74: Merge remote-tracking branch 'afaerber/tags/qom-cpu-for-anthony' into staging (2013-08-01 17:09:35 -0500) are available in the git repository at: git://git.corpit.ru/qemu.git trivial-patches for you to fetch changes up to 8e50724313895a87057cc243ad805f2eb21feb9f: vmdk: fix comment for vmdk_co_write_zeroes (2013-08-02 18:07:04 +0400) Fam Zheng (1): vmdk: fix comment for vmdk_co_write_zeroes Michael S. Tsirkin (1): memory.c: drop kvm.h dependency Michael Tokarev (1): qemu-ga: build it even if !system Richard W.M. Jones (1): block/iscsi.c: Fix printf format error. block/iscsi.c |4 +++- block/vmdk.c |8 ++-- configure | 11 --- memory.c |1 - 4 files changed, 17 insertions(+), 7 deletions(-)
[Qemu-devel] [PULL 2/4] block/iscsi.c: Fix printf format error.
From: Richard W.M. Jones rjo...@redhat.com
The error on armv7hl was:
block/iscsi.c: In function ‘is_request_lun_aligned’:
block/iscsi.c:251:26: error: format ‘%ld’ expects argument of type ‘long int’,
but argument 3 has type ‘int64_t’ [-Werror=format=]
iscsilun-block_size, sector_num, nb_sectors);
^
This also splits the long line to comply with qemu coding guidelines.
Signed-off-by: Richard W.M. Jones rjo...@redhat.com
Reviewed-by: Stefan Weil s...@weilnetz.de
Reviewed-by: Stefan Hajnoczi stefa...@redhat.com
Signed-off-by: Michael Tokarev m...@tls.msk.ru
---
block/iscsi.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/block/iscsi.c b/block/iscsi.c
index 5f28c6a..e7c1c2b 100644
--- a/block/iscsi.c
+++ b/block/iscsi.c
@@ -247,7 +247,9 @@ static bool is_request_lun_aligned(int64_t sector_num, int
nb_sectors,
{
if ((sector_num * BDRV_SECTOR_SIZE) % iscsilun-block_size ||
(nb_sectors * BDRV_SECTOR_SIZE) % iscsilun-block_size) {
-error_report(iSCSI misaligned request: iscsilun-block_size %u,
sector_num %ld, nb_sectors %d,
+error_report(iSCSI misaligned request:
+ iscsilun-block_size %u, sector_num % PRIi64
+ , nb_sectors %d,
iscsilun-block_size, sector_num, nb_sectors);
return 0;
}
--
1.7.10.4
[Qemu-devel] [PULL 1/4] qemu-ga: build it even if !system
Move qemu-ga build check out of if softmmu.. into its own section. We want to build qemu-ga for _guest_ even if system build isn't done. It is controlled separately using --enable-guest-agent. Additionally, give error message if guest agent is requested but not supported. Signed-off-by: Michael Tokarev m...@tls.msk.ru --- configure | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/configure b/configure index f0761ea..293f167 100755 --- a/configure +++ b/configure @@ -231,7 +231,7 @@ libusb= usb_redir= glx= zlib=yes -guest_agent=yes +guest_agent= want_tools=yes libiscsi= coroutine= @@ -3444,10 +3444,15 @@ if test $softmmu = yes ; then virtfs=no fi fi +fi +if [ $guest_agent != no ]; then if [ $linux = yes -o $bsd = yes -o $solaris = yes ] ; then -if [ $guest_agent = yes ]; then tools=qemu-ga\$(EXESUF) $tools -fi + guest_agent=yes + elif [ $guest_agent != yes ]; then + guest_agent=no + else + error_exit Guest agent is not supported on this platform fi fi -- 1.7.10.4
[Qemu-devel] [PULL 3/4] memory.c: drop kvm.h dependency
From: Michael S. Tsirkin m...@redhat.com memory.c does not use any kvm specific interfaces, don't include kvm.h Signed-off-by: Michael S. Tsirkin m...@redhat.com Acked-by: Paolo Bonzini pbonz...@redhat.com Signed-off-by: Michael Tokarev m...@tls.msk.ru --- memory.c |1 - 1 file changed, 1 deletion(-) diff --git a/memory.c b/memory.c index ac6f3c6..886f838 100644 --- a/memory.c +++ b/memory.c @@ -18,7 +18,6 @@ #include exec/ioport.h #include qemu/bitops.h #include qom/object.h -#include sysemu/kvm.h #include trace.h #include assert.h -- 1.7.10.4
[Qemu-devel] [PATCH v6] e1000: add interrupt mitigation support
This patch partially implements the e1000 interrupt mitigation mechanisms.
Using a single QEMUTimer, it emulates the ITR register (which is the newer
mitigation register, recommended by Intel) and approximately emulates
RADV and TADV registers. TIDV and RDTR register functionalities are not
emulated (RDTR is only used to validate RADV, according to the e1000 specs).
RADV, TADV, TIDV and RDTR registers make up the older e1000 mitigation
mechanism and would need a timer each to be completely emulated. However,
a single timer has been used in order to reach a good compromise between
emulation accuracy and simplicity/efficiency.
The implemented mechanism can be enabled/disabled specifying the command
line e1000-specific boolean parameter mitigation, e.g.
qemu-system-x86_64 -device e1000,mitigation=on,... ...
For more information, see the Software developer's manual at
http://download.intel.com/design/network/manuals/8254x_GBe_SDM.pdf.
Interrupt mitigation boosts performance when the guest suffers from
an high interrupt rate (i.e. receiving short UDP packets at high packet
rate). For some numerical results see the following link
http://info.iet.unipi.it/~luigi/papers/20130520-rizzo-vm.pdf
Signed-off-by: Vincenzo Maffione v.maffi...@gmail.com
---
Added pc-*-1.7 machines (default machine moved to pc-i440fx-1.7).
hw/i386/pc_piix.c| 18 ++-
hw/i386/pc_q35.c | 16 ++-
hw/net/e1000.c | 131 +--
include/hw/i386/pc.h | 8
4 files changed, 167 insertions(+), 6 deletions(-)
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index ab25458..f5183d4 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -336,8 +336,8 @@ static void pc_xen_hvm_init(QEMUMachineInitArgs *args)
}
#endif
-static QEMUMachine pc_i440fx_machine_v1_6 = {
-.name = pc-i440fx-1.6,
+static QEMUMachine pc_i440fx_machine_v1_7 = {
+.name = pc-i440fx-1.7,
.alias = pc,
.desc = Standard PC (i440FX + PIIX, 1996),
.init = pc_init_pci,
@@ -347,6 +347,19 @@ static QEMUMachine pc_i440fx_machine_v1_6 = {
DEFAULT_MACHINE_OPTIONS,
};
+static QEMUMachine pc_i440fx_machine_v1_6 = {
+.name = pc-i440fx-1.6,
+.desc = Standard PC (i440FX + PIIX, 1996),
+.init = pc_init_pci,
+.hot_add_cpu = pc_hot_add_cpu,
+.max_cpus = 255,
+.compat_props = (GlobalProperty[]) {
+PC_COMPAT_1_6,
+{ /* end of list */ }
+},
+DEFAULT_MACHINE_OPTIONS,
+};
+
static QEMUMachine pc_i440fx_machine_v1_5 = {
.name = pc-i440fx-1.5,
.desc = Standard PC (i440FX + PIIX, 1996),
@@ -769,6 +782,7 @@ static QEMUMachine xenfv_machine = {
static void pc_machine_init(void)
{
+qemu_register_machine(pc_i440fx_machine_v1_7);
qemu_register_machine(pc_i440fx_machine_v1_6);
qemu_register_machine(pc_i440fx_machine_v1_5);
qemu_register_machine(pc_i440fx_machine_v1_4);
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 2f35d12..09b0a54 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -230,13 +230,26 @@ static void pc_q35_init_1_4(QEMUMachineInitArgs *args)
pc_q35_init_1_5(args);
}
+static QEMUMachine pc_q35_machine_v1_7 = {
+.name = pc-q35-1.7,
+.alias = q35,
+.desc = Standard PC (Q35 + ICH9, 2009),
+.init = pc_q35_init,
+.hot_add_cpu = pc_hot_add_cpu,
+.max_cpus = 255,
+DEFAULT_MACHINE_OPTIONS,
+};
+
static QEMUMachine pc_q35_machine_v1_6 = {
.name = pc-q35-1.6,
-.alias = q35,
.desc = Standard PC (Q35 + ICH9, 2009),
.init = pc_q35_init,
.hot_add_cpu = pc_hot_add_cpu,
.max_cpus = 255,
+.compat_props = (GlobalProperty[]) {
+PC_COMPAT_1_6,
+{ /* end of list */ }
+},
DEFAULT_MACHINE_OPTIONS,
};
@@ -267,6 +280,7 @@ static QEMUMachine pc_q35_machine_v1_4 = {
static void pc_q35_machine_init(void)
{
+qemu_register_machine(pc_q35_machine_v1_7);
qemu_register_machine(pc_q35_machine_v1_6);
qemu_register_machine(pc_q35_machine_v1_5);
qemu_register_machine(pc_q35_machine_v1_4);
diff --git a/hw/net/e1000.c b/hw/net/e1000.c
index fdb1f89..32014c2 100644
--- a/hw/net/e1000.c
+++ b/hw/net/e1000.c
@@ -135,9 +135,16 @@ typedef struct E1000State_st {
QEMUTimer *autoneg_timer;
+QEMUTimer *mit_timer; /* Mitigation timer. */
+bool mit_timer_on; /* Mitigation timer is running. */
+bool mit_irq_level;/* Tracks interrupt pin level. */
+uint32_t mit_ide; /* Tracks E1000_TXD_CMD_IDE bit. */
+
/* Compatibility flags for migration to/from qemu 1.3.0 and older */
#define E1000_FLAG_AUTONEG_BIT 0
+#define E1000_FLAG_MIT_BIT 1
#define E1000_FLAG_AUTONEG (1 E1000_FLAG_AUTONEG_BIT)
+#define E1000_FLAG_MIT (1 E1000_FLAG_MIT_BIT)
uint32_t compat_flags;
} E1000State;
@@ -158,7 +165,8 @@ enum {
defreg(TORH), defreg(TORL), defreg(TOTH), defreg(TOTL),
defreg(TPR), defreg(TPT),defreg(TXDCTL), defreg(WUFC),
defreg(RA),
Re: [Qemu-devel] [Qemu-trivial] [PATCH] memory.c: drop kvm.h dependency
01.08.2013 12:39, Paolo Bonzini wrote: memory.c does not use any kvm specific interfaces, don't include kvm.h Thanks, applied to the trivial patches queue. /mjt
[Qemu-devel] [PATCH 2/2] Add ARM registers definitions in Monitor commands
Signed-off-by: Fabien Chouteau chout...@adacore.com
---
monitor.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/monitor.c b/monitor.c
index 5dc0aa9..78e93af 100644
--- a/monitor.c
+++ b/monitor.c
@@ -3167,6 +3167,23 @@ static const MonitorDef monitor_defs[] = {
{ cleanwin, offsetof(CPUSPARCState, cleanwin) },
{ fprs, offsetof(CPUSPARCState, fprs) },
#endif
+#elif defined(TARGET_ARM)
+{ r0, offsetof(CPUARMState, regs[0]) },
+{ r1, offsetof(CPUARMState, regs[1]) },
+{ r2, offsetof(CPUARMState, regs[2]) },
+{ r3, offsetof(CPUARMState, regs[3]) },
+{ r4, offsetof(CPUARMState, regs[4]) },
+{ r5, offsetof(CPUARMState, regs[5]) },
+{ r6, offsetof(CPUARMState, regs[6]) },
+{ r7, offsetof(CPUARMState, regs[7]) },
+{ r8, offsetof(CPUARMState, regs[8]) },
+{ r9, offsetof(CPUARMState, regs[9]) },
+{ r10,offsetof(CPUARMState, regs[10]) },
+{ r11,offsetof(CPUARMState, regs[11]) },
+{ r12,offsetof(CPUARMState, regs[12]) },
+{ r13|sp, offsetof(CPUARMState, regs[13]) },
+{ r14|lr, offsetof(CPUARMState, regs[14]) },
+{ r15|pc, offsetof(CPUARMState, regs[15]) },
#endif
{ NULL },
};
--
1.7.9.5
Re: [Qemu-devel] KVM call agenda for 2013-08-06
On Tue, Jul 23, 2013 at 06:31:45PM +0200, Juan Quintela wrote: Hi Please, send any topic that you are interested in covering. * libvirt requirements for: * Checking which CPU features are exposed/required by each CPU model + machine-type * Checking which CPU features are available on a given host (considering QEMU + kernel + host CPU capabilities) I hope Jiri and Daniel can join the call. -- Eduardo
Re: [Qemu-devel] [PATCH v2 0/2] Fix qdev 32-bit compilation
Applied. Thanks. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH v2 15/17] raw-posix: detect XFS unwritten extents
On Tue, Jul 16, 2013 at 06:29:26PM +0200, Paolo Bonzini wrote: Signed-off-by: Paolo Bonzini pbonz...@redhat.com This isn't really XFS specific, at least ext4 and ocfs2 can report the same.
Re: [Qemu-devel] [Bug 1207686] [NEW] qemu-1.4.0 and onwards, linux kernel 3.2.x, heavy I/O leads to kernel_hung_tasks_timout_secs message and unresponsive qemu-process
On Fri, Aug 02, 2013 at 09:58:29AM -, Oliver Francke wrote: after some testing I tried to narrow down a problem, which was initially reported by some users. Seen on different distros - debian 7.1, ubuntu 12.04 LTS, IPFire-2.3 as reported by now. All using some flavour of linux-3.2.x kernel. Tried e.g. under Ubuntu an upgrade to Linux 3.8.0-27-generic x86_64 which solves the problem. Is that a guest kernel upgrade? Problem could be triggert with some workload ala: spew -v --raw -P -t -i 3 -b 4k -p random -B 4k 1G /tmp/doof.dat and in parallel do some apt-get install/remove/whatever. That results in a somewhat stuck qemu-session with the bad kernel_hung_task... messages. A typical command-line is as follows: /usr/local/qemu-1.6.0/bin/qemu-system-x86_64 -usbdevice tablet -enable- kvm -daemonize -pidfile /var/run/qemu-server/760.pid -monitor unix:/var/run/qemu-server/760.mon,server,nowait -vnc unix:/var/run/qemu- server/760.vnc,password -qmp unix:/var/run/qemu- server/760.qmp,server,nowait -nodefaults -serial none -parallel none -device virtio-net-pci,mac=00:F1:70:00:2F:80,netdev=vlan0d0 -netdev type=tap,id=vlan0d0,ifname=tap760i0d0,script=/etc/fcms/add_if.sh,downscript=/etc/fcms/downscript.sh -name 1155823384-4 -m 512 -vga cirrus -k de -smp sockets=1,cores=1 -device virtio-blk-pci,drive=virtio0 -drive format=raw,file=rbd:1155823384/vm-760-disk-1.rbd:rbd_cache=false,cache=writeback,if=none,id=virtio0,media=disk,index=0,aio=native -drive format=raw,file=rbd:1155823384/vm-760-swap-1.rbd:rbd_cache=false,cache=writeback,if=virtio,media=disk,index=1,aio=native -drive if=ide,media=cdrom,id=ide1-cd0,readonly=on -drive if=ide,media=cdrom,id=ide1-cd1,readonly=on -boot order=dc no system_reset, sendkey ctrl-alt-delete or q in monitoring- session is accepted, need to hard-kill the process. Yesterday I saw a possibly related report on IRC. It was a Windows guest running under OpenStack with images on Ceph. They reported that the QEMU process would lock up - ping would not work and their management tools showed 0 CPU activity for the guest. However, they were able to kick the guest by taking a VNC screenshot (I think). Then it would come back to life. If you have a Linux guest that is reporting kernel_hung_task, then it could be a similar scenario. Please confirm that the hung task message is from inside the guest. If you are able to reproduce this and have an alternative non-Ceph storage pool, please try that since Ceph is common to both these bug reports. Stefan
Re: [Qemu-devel] Error handling in cpu_x86_create
On 2013-07-30 14:21, Igor Mammedov wrote:
On Tue, 30 Jul 2013 13:00:40 +0200
Jan Kiszka jan.kis...@siemens.com wrote:
Hi Igor,
just noticed by chance that error handling in cpu_x86_create is likely
broken after your changes. Any error after cpu = ...object_new() will
not properly release the CPU object again nor report NULL to the caller.
That means errors should slip through, no? And cpu_x86_init looks similar.
Failure of object_new() in cpu_x86_create() is not checked since it should
never fail.
As for following error handling caller of cpu_x86_create(..., errp) should
use errp to check for errors and release failed cpu.
cpu_x86_init() that calls it has:
===
out:
if (error) {
fprintf(stderr, %s\n, error_get_pretty(error));
error_free(error);
if (cpu != NULL) {
object_unref(OBJECT(cpu));
===
similar code-path exists in pc_new_cpu()
Not truly:
cpu = cpu_x86_create(cpu_model, icc_bridge, errp);
if (!cpu) {
return cpu;
}
object_property_set_int(OBJECT(cpu), apic_id, apic-id, local_err);
object_property_set_bool(OBJECT(cpu), true, realized, local_err);
if (local_err) {
if (cpu != NULL) {
object_unref(OBJECT(cpu));
cpu = NULL;
}
That's what made me think the error is supposed to be derived from cpu
== NULL, rather than from errp. So the actual uncleanness is here: errp
should be checked instead of cpu, right?
Jan
end goal is to replace cpu_x86_create() with just object_new(FOO_CPU),
but that needs to x86 CPU subclasses and properties in place so
we could remove/isolate legacy stuff to legacy hook.
Did you hit any particular problem with current code?
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux
[Qemu-devel] [RFC V3 1/2] throttle: Add a new throttling API implementing continuus leaky bucket.
Implement the continuous leaky bucket algorithm devised on IRC as a separate
module.
Signed-off-by: Benoit Canet ben...@irqsave.net
---
include/qemu/throttle.h | 111
util/Makefile.objs |1 +
util/throttle.c | 436 +++
3 files changed, 548 insertions(+)
create mode 100644 include/qemu/throttle.h
create mode 100644 util/throttle.c
diff --git a/include/qemu/throttle.h b/include/qemu/throttle.h
new file mode 100644
index 000..328c782
--- /dev/null
+++ b/include/qemu/throttle.h
@@ -0,0 +1,111 @@
+/*
+ * QEMU throttling infrastructure
+ *
+ * Copyright (C) Nodalink, SARL. 2013
+ *
+ * Author:
+ * Benoît Canet benoit.ca...@irqsave.net
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 or
+ * (at your option) version 3 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see http://www.gnu.org/licenses/.
+ */
+
+#ifndef THROTTLING_H
+#define THROTTLING_H
+
+#include stdint.h
+#include qemu-common.h
+#include qemu/timer.h
+
+#define NANOSECONDS_PER_SECOND 10.0
+
+#define BUCKETS_COUNT 6
+
+typedef enum {
+THROTTLE_BPS_TOTAL = 0,
+THROTTLE_BPS_READ = 1,
+THROTTLE_BPS_WRITE = 2,
+THROTTLE_OPS_TOTAL = 3,
+THROTTLE_OPS_READ = 4,
+THROTTLE_OPS_WRITE = 5,
+} BucketType;
+
+typedef struct LeakyBucket {
+int64_t ups; /* units per second */
+int64_t max; /* leaky bucket max in units */
+double bucket;/* bucket in units */
+int64_t previous_leak; /* timestamp of the last leak done */
+} LeakyBucket;
+
+/* The following structure is used to configure a ThrottleState
+ * It contains a bit of state: the bucket field of the LeakyBucket structure.
+ * However it allows to keep the code clean and the bucket field is reset to
+ * zero at the right time.
+ */
+typedef struct ThrottleConfig {
+LeakyBucket buckets[6];/* leaky buckets */
+int64_t unit_size; /* size of an unit in bytes */
+int64_t op_size; /* size of an operation in units */
+} ThrottleConfig;
+
+typedef struct ThrottleState {
+ThrottleConfig cfg;
+bool timer_is_throttling_write; /* is the timer throttling a write */
+QEMUTimer *timer;/* timer used to do the throttling */
+QEMUClock *clock;/* the clock used */
+} ThrottleState;
+
+/* following 3 function exposed for tests */
+bool throttle_do_start(ThrottleState *ts,
+ bool is_write,
+ int64_t size,
+ int64_t now,
+ int64_t *next_timer);
+
+bool throttle_do_end(ThrottleState *ts,
+ bool is_write,
+ int64_t now,
+ int64_t *next_timer);
+
+bool throttle_do_timer(ThrottleState *ts,
+ bool is_write,
+ int64_t now,
+ int64_t *next_timer);
+
+/* user API functions */
+void throttle_init(ThrottleState *ts,
+ QEMUClock *clock,
+ void (timer)(void *),
+ void *timer_opaque);
+
+void throttle_destroy(ThrottleState *ts);
+
+bool throttle_start(ThrottleState *ts, bool is_write, int64_t size);
+
+void throttle_end(ThrottleState *ts, bool is_write);
+
+void throttle_timer(ThrottleState *ts, int64_t now, bool *must_wait);
+
+void throttle_config(ThrottleState *ts, ThrottleConfig *cfg);
+
+void throttle_get_config(ThrottleState *ts, ThrottleConfig *cfg);
+
+bool throttle_enabled(ThrottleConfig *cfg);
+
+bool throttle_conflicting(ThrottleConfig *cfg);
+
+bool throttle_is_valid(ThrottleConfig *cfg);
+
+bool throttle_have_timer(ThrottleState *ts);
+
+#endif
diff --git a/util/Makefile.objs b/util/Makefile.objs
index dc72ab0..2bb13a2 100644
--- a/util/Makefile.objs
+++ b/util/Makefile.objs
@@ -11,3 +11,4 @@ util-obj-y += iov.o aes.o qemu-config.o qemu-sockets.o uri.o
notify.o
util-obj-y += qemu-option.o qemu-progress.o
util-obj-y += hexdump.o
util-obj-y += crc32c.o
+util-obj-y += throttle.o
diff --git a/util/throttle.c b/util/throttle.c
new file mode 100644
index 000..4afc407
--- /dev/null
+++ b/util/throttle.c
@@ -0,0 +1,436 @@
+/*
+ * QEMU throttling infrastructure
+ *
+ * Copyright (C) Nodalink, SARL. 2013
+ *
+ * Author:
+ * Benoît Canet benoit.ca...@irqsave.net
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version
[Qemu-devel] [RFC V3 2/2] block: Enable the new throttling code in the block layer.
Signed-off-by: Benoit Canet ben...@irqsave.net
---
block.c | 316 +++--
block/qapi.c | 21 ++-
blockdev.c| 115 +
include/block/block.h |1 -
include/block/block_int.h | 33 +
5 files changed, 150 insertions(+), 336 deletions(-)
diff --git a/block.c b/block.c
index 5a2240f..efa64fa 100644
--- a/block.c
+++ b/block.c
@@ -86,13 +86,6 @@ static void coroutine_fn bdrv_co_do_rw(void *opaque);
static int coroutine_fn bdrv_co_do_write_zeroes(BlockDriverState *bs,
int64_t sector_num, int nb_sectors);
-static bool bdrv_exceed_bps_limits(BlockDriverState *bs, int nb_sectors,
-bool is_write, double elapsed_time, uint64_t *wait);
-static bool bdrv_exceed_iops_limits(BlockDriverState *bs, bool is_write,
-double elapsed_time, uint64_t *wait);
-static bool bdrv_exceed_io_limits(BlockDriverState *bs, int nb_sectors,
-bool is_write, int64_t *wait);
-
static QTAILQ_HEAD(, BlockDriverState) bdrv_states =
QTAILQ_HEAD_INITIALIZER(bdrv_states);
@@ -123,55 +116,68 @@ int is_windows_drive(const char *filename)
#endif
/* throttling disk I/O limits */
-void bdrv_io_limits_disable(BlockDriverState *bs)
+void bdrv_set_io_limits(BlockDriverState *bs,
+ThrottleConfig *cfg)
{
-bs-io_limits_enabled = false;
+throttle_config(bs-throttle_state, cfg);
+}
-while (qemu_co_enter_next(bs-throttled_reqs)) {
-}
+static bool bdrv_drain_throttled(BlockDriverState *bs)
+{
+bool drained = false;
+int i;
-if (bs-block_timer) {
-qemu_del_timer(bs-block_timer);
-qemu_free_timer(bs-block_timer);
-bs-block_timer = NULL;
+for (i = 0; i 2; i++) {
+while (qemu_co_enter_next(bs-throttled_reqs[i]) {
+drained = true;
+}
}
-bs-slice_start = 0;
-bs-slice_end = 0;
+return drained;
}
-static void bdrv_block_timer(void *opaque)
+void bdrv_io_limits_disable(BlockDriverState *bs)
{
-BlockDriverState *bs = opaque;
+bs-io_limits_enabled = false;
+
+bdrv_drain_throttled(bs);
-qemu_co_enter_next(bs-throttled_reqs);
+throttle_destroy(bs-throttle_state);
}
-void bdrv_io_limits_enable(BlockDriverState *bs)
+static void bdrv_throttle_timer_cb(void *opaque)
{
-qemu_co_queue_init(bs-throttled_reqs);
-bs-block_timer = qemu_new_timer_ns(vm_clock, bdrv_block_timer, bs);
-bs-io_limits_enabled = true;
+BlockDriverState *bs = opaque;
+int now = qemu_get_clock_ns(vm_clock);
+bool must_wait[2]; /* does throttled reads or writes must wait */
+int i;
+
+throttle_timer(bs-throttle_state, now, must_wait);
+
+/* execute not throttled requests */
+for (i = 0; i 2; i++) {
+if (must_wait[i]) {
+continue;
+}
+qemu_co_enter_next(bs-throttled_reqs[i]);
+}
}
-bool bdrv_io_limits_enabled(BlockDriverState *bs)
+/* should be called before bdrv_set_io_limits if a limit is set */
+void bdrv_io_limits_enable(BlockDriverState *bs)
{
-BlockIOLimit *io_limits = bs-io_limits;
-return io_limits-bps[BLOCK_IO_LIMIT_READ]
- || io_limits-bps[BLOCK_IO_LIMIT_WRITE]
- || io_limits-bps[BLOCK_IO_LIMIT_TOTAL]
- || io_limits-iops[BLOCK_IO_LIMIT_READ]
- || io_limits-iops[BLOCK_IO_LIMIT_WRITE]
- || io_limits-iops[BLOCK_IO_LIMIT_TOTAL];
+throttle_init(bs-throttle_state, vm_clock, bdrv_throttle_timer_cb, bs);
+qemu_co_queue_init(bs-throttled_reqs[0]);
+qemu_co_queue_init(bs-throttled_reqs[1]);
+bs-io_limits_enabled = true;
}
static void bdrv_io_limits_intercept(BlockDriverState *bs,
- bool is_write, int nb_sectors)
+ bool is_write,
+ int nb_sectors)
{
-int64_t wait_time = -1;
-
-if (!qemu_co_queue_empty(bs-throttled_reqs)) {
-qemu_co_queue_wait(bs-throttled_reqs);
+if (!qemu_co_queue_empty(bs-throttled_reqs[is_write])) {
+qemu_co_queue_wait(bs-throttled_reqs[is_write]);
}
/* In fact, we hope to keep each request's timing, in FIFO mode. The next
@@ -181,13 +187,11 @@ static void bdrv_io_limits_intercept(BlockDriverState *bs,
* be still in throttled_reqs queue.
*/
-while (bdrv_exceed_io_limits(bs, nb_sectors, is_write, wait_time)) {
-qemu_mod_timer(bs-block_timer,
- wait_time + qemu_get_clock_ns(vm_clock));
-qemu_co_queue_wait_insert_head(bs-throttled_reqs);
+while (throttle_start(bs-throttle_state, is_write, nb_sectors)) {
+qemu_co_queue_wait_insert_head(bs-throttled_reqs[is_write]);
}
-qemu_co_queue_next(bs-throttled_reqs);
+qemu_co_queue_next(bs-throttled_reqs[is_write]);
}
/* check if the path starts with protocol: */
@@ -1106,11 +1110,6 @@ int bdrv_open(BlockDriverState *bs, const char
*filename, QDict
Re: [Qemu-devel] [PULL 1/4] qemu-ga: build it even if !system
Am 02.08.2013 16:20, schrieb Michael Tokarev: Move qemu-ga build check out of if softmmu.. into its own section. We want to build qemu-ga for _guest_ even if system build isn't done. It is controlled separately using --enable-guest-agent. Additionally, give error message if guest agent is requested but not supported. Signed-off-by: Michael Tokarev m...@tls.msk.ru --- configure | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/configure b/configure index f0761ea..293f167 100755 --- a/configure +++ b/configure @@ -231,7 +231,7 @@ libusb= usb_redir= glx= zlib=yes -guest_agent=yes +guest_agent= want_tools=yes libiscsi= coroutine= @@ -3444,10 +3444,15 @@ if test $softmmu = yes ; then virtfs=no fi fi +fi +if [ $guest_agent != no ]; then if [ $linux = yes -o $bsd = yes -o $solaris = yes ] ; then -if [ $guest_agent = yes ]; then tools=qemu-ga\$(EXESUF) $tools -fi + guest_agent=yes + elif [ $guest_agent != yes ]; then + guest_agent=no + else + error_exit Guest agent is not supported on this platform fi fi You are mixing 2- and 4-char indentation here... Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH 4/4] xics: Support for in-kernel XICS interrupt controller
On 08/01/2013 11:29 AM, Andreas Färber wrote:
Am 01.08.2013 02:14, schrieb Alexey Kardashevskiy:
On 08/01/2013 05:52 AM, Andreas Färber wrote:
Am 17.07.2013 08:37, schrieb Alexey Kardashevskiy:
+
+icp-ss = g_malloc0(icp-nr_servers*sizeof(ICPState));
+for (i = 0; i icp-nr_servers; i++) {
+char buffer[32];
+object_initialize(icp-ss[i], TYPE_ICP_KVM);
+snprintf(buffer, sizeof(buffer), icp[%d], i);
+object_property_add_child(OBJECT(icp), buffer,
OBJECT(icp-ss[i]), NULL);
+qdev_init_nofail(DEVICE(icp-ss[i]));
object_property_set_bool()
? Anthony did XICS refactoring recently and that has qdev_init_nofail().
Nobody is perfect. ;)
The point is, this is an object, and in realize you shouldn't abort but
set errp and leave error printing and handling to your caller. The QOM
API as opposed to qdev works with an Error object that you can
error_propagate() to your caller.
(Also using qdev_* for something that is new-style QOM is ugly IMO.)
Where does icp-nr_servers come from?
Via properties in try_create_xics() (hw/ppc/spapr.c).
Sounds tricky... Peter introduced static array properties for a similar
purpose, I believe. Don't know if that would help here.
Peter who? For what purpose? Could you please point to it? Cannot find it
anywhere.
Is there no way to split this into
instance_init and realize?
Why would we want to split?
Because realize is too late to create new devices: With our targetted
late, recursive realization model it will not be possible to see and
modify such objects from management interface - only before realize.
Oh. I lost you here. I need to create XICS with some child ICP devices (now
they are devices). The number of child devices comes from spapr.c via
properties. Now you are saying it is too late to create devices (even so
lame ones) in realize(). So I have to put the creation in instance_init().
Could you please point now I can create device-and-pass-propetries in one
shot? Thanks!
--
Alexey
Re: [Qemu-devel] [PATCH] target-ppc: Add POWER7+ CPU model
Am 02.08.2013 04:59, schrieb Alexey Kardashevskiy:
This patch adds CPU PVR definition for POWER7+.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
target-ppc/cpu-models.c | 2 ++
target-ppc/cpu-models.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/target-ppc/cpu-models.c b/target-ppc/cpu-models.c
index 9578ed8..c97c183 100644
--- a/target-ppc/cpu-models.c
+++ b/target-ppc/cpu-models.c
@@ -1143,6 +1143,8 @@
POWER7 v2.1)
POWERPC_DEF(POWER7_v2.3, CPU_POWERPC_POWER7_v23, POWER7,
POWER7 v2.3)
+POWERPC_DEF(POWER7P, CPU_POWERPC_POWER7P,POWER7,
+POWER7P)
Subject says POWER7+ rather than POWER7P. Since this is a string there's
nothing wrong with +. How should it show up in SLOF?
See also below.
POWERPC_DEF(POWER8_v1.0, CPU_POWERPC_POWER8_v10, POWER8,
POWER8 v1.0)
POWERPC_DEF(970, CPU_POWERPC_970,970,
diff --git a/target-ppc/cpu-models.h b/target-ppc/cpu-models.h
index 01e488f..c3c78d1 100644
--- a/target-ppc/cpu-models.h
+++ b/target-ppc/cpu-models.h
@@ -556,6 +556,7 @@ enum {
CPU_POWERPC_POWER7_v20 = 0x003F0200,
CPU_POWERPC_POWER7_v21 = 0x003F0201,
CPU_POWERPC_POWER7_v23 = 0x003F0203,
+CPU_POWERPC_POWER7P= 0x004A0201,
Shouldn't this be ..._POWER7P_v21 to align with the surrounding models?
Ditto for the model name then, POWER7+ being an alias to the latest
version only.
The first field becomes part of the type name, so we should properly
name it from the start.
Andreas
CPU_POWERPC_POWER8_v10 = 0x004B0100,
CPU_POWERPC_970= 0x00390202,
CPU_POWERPC_970FX_v10 = 0x00391100,
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[Qemu-devel] [Bug 1207825] [NEW] change ide1-cd0 /path/to/file.iso doesn't work in qemu-kvm
Public bug reported: I'm using qemu-kvm from git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm , version qemu-kvm-1.2.0-703-g4d9367b, and when I try putting an ISO image to virtual CD drive via change ide1-cd0 /path/to/file.iso, Windows XP guest says I/O error reading CD. At the same time, using ordinary QEMU version 1.0 works correctly with same guest and iso file. ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1207825 Title: change ide1-cd0 /path/to/file.iso doesn't work in qemu-kvm Status in QEMU: New Bug description: I'm using qemu-kvm from git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm , version qemu-kvm-1.2.0-703-g4d9367b, and when I try putting an ISO image to virtual CD drive via change ide1-cd0 /path/to/file.iso, Windows XP guest says I/O error reading CD. At the same time, using ordinary QEMU version 1.0 works correctly with same guest and iso file. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1207825/+subscriptions
Re: [Qemu-devel] [PATCH for-1.6] pc: disable pci-info for 1.6
On 08/01/2013 02:42 AM, Michael S. Tsirkin wrote:
-static void pc_init_pci_1_5(QEMUMachineInitArgs *args)
+static void pc_init_pci_1_6(QEMUMachineInitArgs *args)
{
has_pci_info = false;
pc_init_pci(args);
}
+static void pc_init_pci_1_5(QEMUMachineInitArgs *args)
+{
+pc_init_pci(args);
+}
Surely the numbers aren't right here. Aren't you now enabling
pci_info for 1.5, when it was disabled previously?
r~
[Qemu-devel] [PATCH] target-arm: Implement 'int' loglevel
The 'int' loglevel for recording interrupts and exceptions
requires support in the target-specific code. Implement
it for ARM. This improves debug logging in some situations
that were otherwise pretty opaque, such as when we fault
trying to execute at an exception vector address, which
would otherwise cause an infinite loop of taking exceptions
without any indication in the debug log of what was going on.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
An infinite loop of exceptions now comes out in the trace like this:
Taking exception 3 [Prefetch Abort]
...with IFSR 0xd IFAR 0x201043c
Taking exception 3 [Prefetch Abort]
...with IFSR 0xd IFAR 0xc
Taking exception 3 [Prefetch Abort]
...with IFSR 0xd IFAR 0xc
Taking exception 3 [Prefetch Abort]
...with IFSR 0xd IFAR 0xc
target-arm/helper.c | 42 ++
1 file changed, 42 insertions(+)
diff --git a/target-arm/helper.c b/target-arm/helper.c
index 3c57558..c221e76 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -2228,6 +2228,37 @@ static void do_v7m_exception_exit(CPUARMState *env)
pointer. */
}
+/* Exception names for debug logging; note that not all of these
+ * precisely correspond to architectural exceptions.
+ */
+static const char *excnames[] = {
+[EXCP_UDEF] = Undefined Instruction,
+[EXCP_SWI] = SVC,
+[EXCP_PREFETCH_ABORT] = Prefetch Abort,
+[EXCP_DATA_ABORT] = Data Abort,
+[EXCP_IRQ] = IRQ,
+[EXCP_FIQ] = FIQ,
+[EXCP_BKPT] = Breakpoint,
+[EXCP_EXCEPTION_EXIT] = QEMU v7M exception exit,
+[EXCP_KERNEL_TRAP] = QEMU intercept of kernel commpage,
+[EXCP_STREX] = QEMU intercept of STREX,
+};
+
+static inline void arm_log_exception(int idx)
+{
+if (qemu_loglevel_mask(CPU_LOG_INT)) {
+const char *exc = NULL;
+
+if (idx = 0 idx ARRAY_SIZE(excnames)) {
+exc = excnames[idx];
+}
+if (!exc) {
+exc = unknown;
+}
+qemu_log_mask(CPU_LOG_INT, Taking exception %d [%s]\n, idx, exc);
+}
+}
+
void arm_v7m_cpu_do_interrupt(CPUState *cs)
{
ARMCPU *cpu = ARM_CPU(cs);
@@ -2236,6 +2267,8 @@ void arm_v7m_cpu_do_interrupt(CPUState *cs)
uint32_t lr;
uint32_t addr;
+arm_log_exception(env-exception_index);
+
lr = 0xfff1;
if (env-v7m.current_sp)
lr |= 4;
@@ -2265,6 +2298,7 @@ void arm_v7m_cpu_do_interrupt(CPUState *cs)
if (nr == 0xab) {
env-regs[15] += 2;
env-regs[0] = do_arm_semihosting(env);
+qemu_log_mask(CPU_LOG_INT, ...handled as semihosting call\n);
return;
}
}
@@ -2318,6 +2352,8 @@ void arm_cpu_do_interrupt(CPUState *cs)
assert(!IS_M(env));
+arm_log_exception(env-exception_index);
+
/* TODO: Vectored interrupt controller. */
switch (env-exception_index) {
case EXCP_UDEF:
@@ -2345,6 +2381,7 @@ void arm_cpu_do_interrupt(CPUState *cs)
|| (mask == 0xab env-thumb))
(env-uncached_cpsr CPSR_M) != ARM_CPU_MODE_USR) {
env-regs[0] = do_arm_semihosting(env);
+qemu_log_mask(CPU_LOG_INT, ...handled as semihosting call\n);
return;
}
}
@@ -2362,18 +2399,23 @@ void arm_cpu_do_interrupt(CPUState *cs)
(env-uncached_cpsr CPSR_M) != ARM_CPU_MODE_USR) {
env-regs[15] += 2;
env-regs[0] = do_arm_semihosting(env);
+qemu_log_mask(CPU_LOG_INT, ...handled as semihosting call\n);
return;
}
}
env-cp15.c5_insn = 2;
/* Fall through to prefetch abort. */
case EXCP_PREFETCH_ABORT:
+qemu_log_mask(CPU_LOG_INT, ...with IFSR 0x%x IFAR 0x%x\n,
+ env-cp15.c5_insn, env-cp15.c6_insn);
new_mode = ARM_CPU_MODE_ABT;
addr = 0x0c;
mask = CPSR_A | CPSR_I;
offset = 4;
break;
case EXCP_DATA_ABORT:
+qemu_log_mask(CPU_LOG_INT, ...with DFSR 0x%x DFAR 0x%x\n,
+ env-cp15.c5_data, env-cp15.c6_data);
new_mode = ARM_CPU_MODE_ABT;
addr = 0x10;
mask = CPSR_A | CPSR_I;
--
1.7.9.5
[Qemu-devel] [PATCH for-1.6] target-i386: Fix X86CPU error handling
Error **errp argument is not for emitting warnings, it means an error
has occurred and the caller should not make any assumptions about the
state of other return values (unless otherwise documented).
Therefore cpu_x86_create() must unref the new X86CPU itself, and
pc_new_cpu() must check for an Error rather than NULL return value.
While at it, clean up a superfluous NULL check.
Reported-by: Jan Kiszka jan.kis...@siemens.com
Cc: qemu-sta...@nongnu.org
Cc: Igor Mammedov imamm...@redhat.com
Signed-off-by: Andreas Färber afaer...@suse.de
---
hw/i386/pc.c | 13 ++---
target-i386/cpu.c | 6 +-
2 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index a2b9d88..6a0b042 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -912,20 +912,19 @@ static X86CPU *pc_new_cpu(const char *cpu_model, int64_t
apic_id,
X86CPU *cpu;
Error *local_err = NULL;
-cpu = cpu_x86_create(cpu_model, icc_bridge, errp);
-if (!cpu) {
-return cpu;
+cpu = cpu_x86_create(cpu_model, icc_bridge, local_err);
+if (local_err != NULL) {
+error_propagate(errp, local_err);
+return NULL;
}
object_property_set_int(OBJECT(cpu), apic_id, apic-id, local_err);
object_property_set_bool(OBJECT(cpu), true, realized, local_err);
if (local_err) {
-if (cpu != NULL) {
-object_unref(OBJECT(cpu));
-cpu = NULL;
-}
error_propagate(errp, local_err);
+object_unref(OBJECT(cpu));
+cpu = NULL;
}
return cpu;
}
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 71ab915..2efbeca 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -1824,7 +1824,11 @@ X86CPU *cpu_x86_create(const char *cpu_model,
DeviceState *icc_bridge,
}
out:
-error_propagate(errp, error);
+if (error != NULL) {
+error_propagate(errp, error);
+object_unref(OBJECT(cpu));
+cpu = NULL;
+}
g_strfreev(model_pieces);
return cpu;
}
--
1.8.1.4
Re: [Qemu-devel] default slot used for vga device on q35 machines
Laine Stump la...@redhat.com writes: On 08/02/2013 03:23 AM, Markus Armbruster wrote: Gerd Hoffmann kra...@redhat.com writes: Hi, qemu-kvm -M q35 -nodefaults -nodefconfig -qmp unix:/tmp/qemu,server -vnc :15 -vga std -usb Then ran query-pci in the qmp monitor and found that the vga device is put at slot 1 instead of slot 2. My questions: 1) Is this difference intentional, or a bug? The vga simply goes into the first free slot. That happens to be #2 with i440fx and #1 with q35. The slot used by -vga depends on the machine type, and can be expected to remain stable. We've kept it stable even for the machine type family i440FX. Nevertheless, if you require the graphics adapter to go into a specific slot, I very much recommend to control its placement with -device. Right. We prefer explicitly specifying the pci address for everything, but apparently in the case of multihead qxl devices, this isn't an option (is this correct, or has there been a misunderstanding?) If you find a case where -vga is still *required*, report it as a bug. Elsewhere in thread, Gerd wrote it's not required for qxl multihead. Suggest to work with Gerd to resolve remaining issues / misunderstandings.
Re: [Qemu-devel] [PATCH 7/7] pc: limit 64 bit hole to 2G by default
Am 29.07.2013 16:47, schrieb Igor Mammedov:
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index b0b98a8..a2b9d88 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
[...]
@@ -1003,15 +1004,27 @@ typedef struct PcRomPciInfo {
static void pc_fw_cfg_guest_info(PcGuestInfo *guest_info)
{
PcRomPciInfo *info;
+Object *pci_info;
+bool ambiguous = false;
+
if (!guest_info-has_pci_info || !guest_info-fw_cfg) {
return;
}
+pci_info = object_resolve_path_type(, TYPE_PCI_HOST_BRIDGE,
ambiguous);
+g_assert(!ambiguous);
+if (!pci_info) {
+return;
+}
info = g_malloc(sizeof *info);
-info-w32_min = cpu_to_le64(guest_info-pci_info.w32.begin);
-info-w32_max = cpu_to_le64(guest_info-pci_info.w32.end);
-info-w64_min = cpu_to_le64(guest_info-pci_info.w64.begin);
-info-w64_max = cpu_to_le64(guest_info-pci_info.w64.end);
+info-w32_min = cpu_to_le64(object_property_get_int(pci_info,
+PCI_HOST_PROP_PCI_HOLE_START, NULL));
+info-w32_max = cpu_to_le64(object_property_get_int(pci_info,
+PCI_HOST_PROP_PCI_HOLE_END, NULL));
+info-w64_min = cpu_to_le64(object_property_get_int(pci_info,
+PCI_HOST_PROP_PCI_HOLE64_START, NULL));
+info-w64_max = cpu_to_le64(object_property_get_int(pci_info,
+PCI_HOST_PROP_PCI_HOLE64_END, NULL));
/* Pass PCI hole info to guest via a side channel.
* Required so guest PCI enumeration does the right thing. */
fw_cfg_add_file(guest_info-fw_cfg, etc/pci-info, info, sizeof *info);
I wonder, if we're passing PcRomInfo out to SeaBIOS via fw_cfg,
shouldn't it be QEMU_PACKED just in case?
Not strictly related to this patch, obviously.
Regards,
Andreas
/* pci-info ROM file. Little endian format */
typedef struct PcRomPciInfo {
uint64_t w32_min;
uint64_t w32_max;
uint64_t w64_min;
uint64_t w64_max;
} PcRomPciInfo;
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[Qemu-devel] [Bug 1204697] Re: guest disk accesses lead to ATA errors + host vcpu0 unhandled wrmsr/rdmsr
Having tried now with virtio as well: works So: virtio, ide = OK sata = broken -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1204697 Title: guest disk accesses lead to ATA errors + host vcpu0 unhandled wrmsr/rdmsr Status in QEMU: New Status in “qemu” package in Debian: Confirmed Bug description: Hi. This is from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717724. Using Debian sid with 1.5.0-5 my Linux VMs (also Debian sid) are broken. When they boot I get gazillions of ATA errors inside the guest, as well as: [ 242.479951] kvm [7790]: vcpu0 unhandled rdmsr: 0x345 [ 242.483683] kvm [7790]: vcpu0 unhandled wrmsr: 0x680 data 0 [ 242.483687] kvm [7790]: vcpu0 unhandled wrmsr: 0x6c0 data 0 [ 242.483689] kvm [7790]: vcpu0 unhandled wrmsr: 0x681 data 0 [ 242.483691] kvm [7790]: vcpu0 unhandled wrmsr: 0x6c1 data 0 [ 242.483693] kvm [7790]: vcpu0 unhandled wrmsr: 0x682 data 0 [ 242.483696] kvm [7790]: vcpu0 unhandled wrmsr: 0x6c2 data 0 [ 242.483698] kvm [7790]: vcpu0 unhandled wrmsr: 0x683 data 0 [ 242.483700] kvm [7790]: vcpu0 unhandled wrmsr: 0x6c3 data 0 [ 242.483702] kvm [7790]: vcpu0 unhandled wrmsr: 0x684 data 0 [ 242.483704] kvm [7790]: vcpu0 unhandled wrmsr: 0x6c4 data 0 [ 242.988307] kvm [7790]: vcpu0 unhandled rdmsr: 0xe8 [ 242.988312] kvm [7790]: vcpu0 unhandled rdmsr: 0xe7 [ 242.988314] kvm [7790]: vcpu0 unhandled rdmsr: 0xce [ 242.988316] kvm [7790]: vcpu0 unhandled rdmsr: 0xce [ 242.988318] kvm [7790]: vcpu0 unhandled rdmsr: 0x1ad [ 242.988320] kvm [7790]: vcpu0 unhandled rdmsr: 0xce [ 242.988322] kvm [7790]: vcpu0 unhandled rdmsr: 0xe8 [ 242.988324] kvm [7790]: vcpu0 unhandled rdmsr: 0xe7 [ 242.988598] kvm [7790]: vcpu0 unhandled rdmsr: 0xce in the host. Please have a look at the Debian bug, for screenshots and more info. The problem didn't occur in 1.5.0-4 and there were basically no changes inside the VM (i.e. no kernel upgrade or so). Thanks, Chris. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1204697/+subscriptions
Re: [Qemu-devel] default slot used for vga device on q35 machines
On 08/02/2013 03:23 AM, Markus Armbruster wrote: Gerd Hoffmann kra...@redhat.com writes: Hi, qemu-kvm -M q35 -nodefaults -nodefconfig -qmp unix:/tmp/qemu,server -vnc :15 -vga std -usb Then ran query-pci in the qmp monitor and found that the vga device is put at slot 1 instead of slot 2. My questions: 1) Is this difference intentional, or a bug? The vga simply goes into the first free slot. That happens to be #2 with i440fx and #1 with q35. The slot used by -vga depends on the machine type, and can be expected to remain stable. We've kept it stable even for the machine type family i440FX. Nevertheless, if you require the graphics adapter to go into a specific slot, I very much recommend to control its placement with -device. Right. We prefer explicitly specifying the pci address for everything, but apparently in the case of multihead qxl devices, this isn't an option (is this correct, or has there been a misunderstanding?)
Re: [Qemu-devel] [PATCH 3/7] arch_init: add ram_madvise_free()
On 06/16/2013 12:04 PM, Anthony Liguori wrote:
Lei Li li...@linux.vnet.ibm.com writes:
Signed-off-by: Lei Li li...@linux.vnet.ibm.com
---
arch_init.c | 13 +
include/migration/migration.h |3 +++
2 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index 872020e..fc66bd2 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -524,6 +524,19 @@ uint64_t ram_bytes_total(void)
return total;
}
+void ram_madvise_free(ram_addr_t size)
+{
+void *ram;
+RAMBlock *block = NULL;
+
+ram = memory_region_get_ram_ptr(block-mr);
+
+/* XXX. Here just simplely madvise(.., MADV_DONTNEED) the whole ram
+ * pages, need more work to keep MADV_DONTNEED ram pages that
+ * already sent. */
+qemu_madvise(ram, size, MADV_DONTNEED);
+}
+
I don't think this is right at all. There's no guarantee we have a
single linear mapping of all ram.
I think you need something a bit more clever than this.
static void migration_end(void)
{
if (migration_bitmap) {
diff --git a/include/migration/migration.h b/include/migration/migration.h
index 8866c3c..9cc5285 100644
--- a/include/migration/migration.h
+++ b/include/migration/migration.h
@@ -21,6 +21,7 @@
#include qapi/error.h
#include migration/vmstate.h
#include qapi-types.h
+#include exec/memory.h
enum {
MIG_STATE_ERROR,
@@ -100,6 +101,8 @@ uint64_t ram_bytes_remaining(void);
uint64_t ram_bytes_transferred(void);
uint64_t ram_bytes_total(void);
+void ram_madvise_free(ram_addr_t size);
+
If you introduce new interfaces, please include documentation in the
header.
Regards,
Anthony Liguori
extern SaveVMHandlers savevm_ram_handlers;
uint64_t dup_mig_bytes_transferred(void);
--
1.7.7.6
We have a new function in master.. ram_handle_compressed() (was
exported for RDMA).
Perhaps this could be used.
- Michael
Re: [Qemu-devel] [PATCH 04/12] arch_init: introduce ram_page_save()
On 07/25/2013 04:18 PM, Lei Li wrote:
Signed-off-by: Lei Li li...@linux.vnet.ibm.com
---
arch_init.c | 58 ++
1 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index a8b91ee..a418071 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -699,6 +699,64 @@ static uint64_t ram_save_pending(QEMUFile *f, void
*opaque, uint64_t max_size)
return remaining_size;
}
+/* This is the last block from where we have sent data for local migration */
+static RAMBlock *last_block_local;
+static ram_addr_t last_offset_local;
+
+static int ram_page_save(QEMUFile *f)
+{
+RAMBlock *block = last_block_local;
+ram_addr_t offset = last_offset_local;
+MemoryRegion *mr = block-mr;
+int bytes_sent = 0;
+
+if (!block) {
+block = QTAILQ_FIRST(ram_list.blocks);
+}
+
+do {
+mr = block-mr;
+uint8_t *p;
+int cont = (block == last_block_local) ? RAM_SAVE_FLAG_CONTINUE : 0;
+
+p = memory_region_get_ram_ptr(mr) + offset;
+
+if (is_zero_page(p)) {
+qemu_put_be64(f, offset | cont | RAM_SAVE_FLAG_COMPRESS);
+if (!cont) {
+qemu_put_byte(f, strlen(block-idstr));
+qemu_put_buffer(f, (uint8_t *)block-idstr,
+strlen(block-idstr));
+}
+qemu_put_byte(f, *p);
+bytes_sent = 1;
+} else {
+qemu_put_be64(f, offset | cont | RAM_SAVE_FLAG_PAGE);
+if (!cont) {
+qemu_put_byte(f, strlen(block-idstr));
+qemu_put_buffer(f, (uint8_t *)block-idstr,
+strlen(block-idstr));
+}
+qemu_put_buffer(f, p, TARGET_PAGE_SIZE);
+bytes_sent = TARGET_PAGE_SIZE;
+}
+
+offset += TARGET_PAGE_SIZE;
+if (offset = block-length) {
+offset = 0;
+block = QTAILQ_NEXT(block, next);
+if (!block) {
+block = QTAILQ_FIRST(ram_list.blocks);
+}
+}
+} while (block != last_block_local || offset != last_offset_local);
+
+last_block_local = block;
+last_offset_local = offset;
+
+return bytes_sent;
+}
+
static int load_xbzrle(QEMUFile *f, ram_addr_t addr, void *host)
{
int ret, rc = 0;
Seems like there's a lot of duplicate code.
We have new hooks to override the way memory is saved in arch_init.c
See the QEMUFileOps. save_page() / before_ram_iterate() /
after_ram_iterate()
You might need to introduce a new load_page() pointer in QEMUFileOps.
Then all this code can be private to migration-local.c
- Michael
Re: [Qemu-devel] net/tap.c: Possibly a way to stall tap input
On 2013-08-02 14:45, Jan Kiszka wrote:
On 2013-08-02 13:46, Stefan Hajnoczi wrote:
On Thu, Aug 01, 2013 at 07:15:54PM +0200, Jan Kiszka wrote:
I was digging into the involved code and found something fishy:
net/tap.c:
static void tap_send(void *opaque)
{
...
size = qemu_send_packet_async(s-nc, buf, size,
tap_send_completed);
if (size == 0) {
tap_read_poll(s, false);
}
So, if tap_send is registered for the mainloop polling (ie. can_receive
returned true before starting to poll) but qemu_send_packet_async
returns 0 now as qemu_can_send_packet/can_receive happens to report
false in the meantime, we will disable read polling. If also write
polling is off, the fd will be completely removed from the iohandler
list. But even if write polling remains on, I wonder what should bring
read polling back?
This behavior seems fine to me. Once the peer (pcnet) is able to
receive again it must flush the queue, this will re-enable
tap_read_poll().
Can you explain a bit more why this would be a problem?
The problem is that I don't see at all what will call tap_read_poll(s,
1), neither in theory nor in reality.
As long as the real test case is out of reach, I tried to emulate the
faulty behaviour by letting tap_can_send always return 1. Result:
reception stalls during boot as even qemu_flush_queued_packets cannot
get it running again once tap_read_poll(s, 0) was called.
OK, false alarm. The issue was most likely fixed by commit 199ee608
(net: fix qemu_flush_queued_packets() in presence of a hub) which is
present in 1.5.x but not 1.3.x. We initially tried to test on 1.5 but
had to role back to 1.3 due to other issues - and missed this fix.
My understanding of the networking maze was confused by the unfortunate
naming of the incoming net client queues (send_queue) - will propose a
renaming.
This still requires a confirmation on the target, but I'm quite
optimistic now.
Jan
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH 05/12] arch_init: introduce ram_save_local()
On 07/25/2013 04:18 PM, Lei Li wrote:
Signed-off-by: Lei Li li...@linux.vnet.ibm.com
---
arch_init.c | 32
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index a418071..7eeb52f 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -757,6 +757,38 @@ static int ram_page_save(QEMUFile *f)
return bytes_sent;
}
+static int ram_save_local(QEMUFile *f, void *opaque)
+{
+uint64_t bytes_sent = 0;
+uint64_t total_ram_bytes = ram_bytes_total();
+
+qemu_mutex_lock_ramlist();
+
+while (total_ram_bytes) {
+ void *ram;
+ MemoryRegion *mr;
+
+ bytes_sent = ram_page_save(f);
+ /* No more ram pages. */
+ if (bytes_sent == 0) {
+ return bytes_sent;
+ }
+
+ mr = last_block_local-mr;
+ ram = memory_region_get_ram_ptr(mr) + last_offset_local;
+
+ /* DONTNEED the ram page that has already copied. */
+ qemu_madvise(ram, bytes_sent, QEMU_MADV_DONTNEED);
+ total_ram_bytes -= bytes_sent;
+}
+
+qemu_mutex_unlock_ramlist();
+
+qemu_put_be64(f, RAM_SAVE_FLAG_EOS);
+
+return bytes_sent;
+}
+
static int load_xbzrle(QEMUFile *f, ram_addr_t addr, void *host)
{
int ret, rc = 0;
You need to create a new private structure QEMUFileLocal.
Then override f-save_page and point this to your own function.
See migration-rdma.c for an example.
- Michael
Re: [Qemu-devel] [PATCH 06/12] arch_init: add save_local_setup to savevm_ram_handlers
On 07/25/2013 04:18 PM, Lei Li wrote:
Signed-off-by: Lei Li li...@linux.vnet.ibm.com
---
arch_init.c |1 +
include/migration/vmstate.h |2 ++
2 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index 7eeb52f..5c25005 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -973,6 +973,7 @@ SaveVMHandlers savevm_ram_handlers = {
.save_live_iterate = ram_save_iterate,
.save_live_complete = ram_save_complete,
.save_live_pending = ram_save_pending,
+.save_local_setup = ram_save_local,
.load_state = ram_load,
.cancel = ram_migration_cancel,
};
diff --git a/include/migration/vmstate.h b/include/migration/vmstate.h
index acf847b..c534254 100644
--- a/include/migration/vmstate.h
+++ b/include/migration/vmstate.h
@@ -53,6 +53,8 @@ typedef struct SaveVMHandlers {
int (*save_live_setup)(QEMUFile *f, void *opaque);
uint64_t (*save_live_pending)(QEMUFile *f, void *opaque, uint64_t
max_size);
+int (*save_local_setup)(QEMUFile *f, void *opaque);
+
LoadStateHandler *load_state;
} SaveVMHandlers;
save_page() should be good enough for you - it has more parameters too
see last email
- Michael
Re: [Qemu-devel] net/tap.c: Possibly a way to stall tap input
On 2013-08-02 14:45, Jan Kiszka wrote:
On 2013-08-02 13:46, Stefan Hajnoczi wrote:
On Thu, Aug 01, 2013 at 07:15:54PM +0200, Jan Kiszka wrote:
I was digging into the involved code and found something fishy:
net/tap.c:
static void tap_send(void *opaque)
{
...
size = qemu_send_packet_async(s-nc, buf, size,
tap_send_completed);
if (size == 0) {
tap_read_poll(s, false);
}
So, if tap_send is registered for the mainloop polling (ie. can_receive
returned true before starting to poll) but qemu_send_packet_async
returns 0 now as qemu_can_send_packet/can_receive happens to report
false in the meantime, we will disable read polling. If also write
polling is off, the fd will be completely removed from the iohandler
list. But even if write polling remains on, I wonder what should bring
read polling back?
This behavior seems fine to me. Once the peer (pcnet) is able to
receive again it must flush the queue, this will re-enable
tap_read_poll().
Can you explain a bit more why this would be a problem?
The problem is that I don't see at all what will call tap_read_poll(s,
1), neither in theory nor in reality.
As long as the real test case is out of reach, I tried to emulate the
faulty behaviour by letting tap_can_send always return 1. Result:
reception stalls during boot as even qemu_flush_queued_packets cannot
get it running again once tap_read_poll(s, 0) was called.
OK, this is the bug: When a NIC becomes ready to send or receive again,
the issued qemu_flush_queued_packets will only flush queued packets that
are supposed to leave the NIC, none that may have been queued at the
output of the corresponding backend. For the case of hub-based setups,
we need to propagate this flush via the hub to all attached peers. This
flush will trigger the send callback of tap, and that will re-enable
receive polling.
So this is actually a generic bug that should theoretically affect any
user space NIC, with or without a hub in the middle. I'll cook up a fix,
play with it on Monday and share the outcome.
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH 09/12] migration-local: implementation of outgoing part
On 07/25/2013 04:18 PM, Lei Li wrote:
Signed-off-by: Lei Li li...@linux.vnet.ibm.com
---
Makefile.objs |1 +
include/migration/migration.h | 15
migration-local.c | 158 +
migration-unix.c | 13
qapi-schema.json | 14
qmp-commands.hx | 22 ++
6 files changed, 223 insertions(+), 0 deletions(-)
create mode 100644 migration-local.c
diff --git a/Makefile.objs b/Makefile.objs
index 5b288ba..2a3d9a5 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -53,6 +53,7 @@ common-obj-$(CONFIG_LINUX) += fsdev/
common-obj-y += migration.o migration-tcp.o
common-obj-y += qemu-char.o #aio.o
common-obj-y += block-migration.o
+common-obj-y += migration-local.o
common-obj-y += page_cache.o xbzrle.o
common-obj-$(CONFIG_POSIX) += migration-exec.o migration-unix.o migration-fd.o
diff --git a/include/migration/migration.h b/include/migration/migration.h
index a821c80..a690e18 100644
--- a/include/migration/migration.h
+++ b/include/migration/migration.h
@@ -58,6 +58,17 @@ struct MigrationState
int64_t xbzrle_cache_size;
};
+
+typedef struct LocalMigState LocalMigState;
+
+struct LocalMigState
+{
+int fd;
+int state;
+QEMUFile *file;
+QemuThread thread;
+};
+
void process_incoming_migration(QEMUFile *f);
void qemu_start_incoming_migration(const char *uri, Error **errp);
@@ -80,6 +91,8 @@ void unix_start_incoming_migration(const char *path, Error
**errp);
void unix_start_outgoing_migration(MigrationState *s, const char *path, Error
**errp);
+void unix_start_local_outgoing_migration(LocalMigState *s, const char *path,
Error **errp);
+
void fd_start_incoming_migration(const char *path, Error **errp);
void fd_start_outgoing_migration(MigrationState *s, const char *fdname, Error
**errp);
@@ -88,6 +101,8 @@ void migrate_fd_error(MigrationState *s);
void migrate_fd_connect(MigrationState *s);
+void local_migration_fd_connect(LocalMigState *s);
+
int migrate_fd_close(MigrationState *s);
void add_migration_state_change_notifier(Notifier *notify);
diff --git a/migration-local.c b/migration-local.c
new file mode 100644
index 000..5bd1ed0
--- /dev/null
+++ b/migration-local.c
@@ -0,0 +1,158 @@
+/*
+ * QEMU localhost migration
+ *
+ * Copyright IBM, Corp. 2013
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2. See
+ * the COPYING file in the top-level directory.
+ *
+ * Contributions are licensed under the terms of the GNU GPL, version 2
+ * or (at your option) any later version.
+ */
+
+#include qemu-common.h
+#include migration/migration.h
+#include monitor/monitor.h
+#include migration/qemu-file.h
+#include sysemu/sysemu.h
+#include block/block.h
+#include qemu/sockets.h
+#include migration/block.h
+#include qemu/thread.h
+#include qmp-commands.h
+#include exec/memory.h
+#include trace.h
+#include qemu/osdep.h
+
+//#define DEBUG_MIGRATION_LOCAL
+
+#ifdef DEBUG_MIGRATION_LOCAL
+#define DPRINTF(fmt, ...) \
+do { printf(migration-local: fmt, ## __VA_ARGS__); } while (0)
+#else
+#define DPRINTF(fmt, ...) \
+do { } while (0)
+#endif
+
+
+/
+ * Outgoing part
+ */
+
+static LocalMigState *local_migration_init(void)
+{
+LocalMigState *s = g_malloc0(sizeof(*s));
+
+s-state = MIG_STATE_SETUP;
+trace_migrate_set_state(MIG_STATE_SETUP);
+s-fd = -1;
+
+return s;
+}
+
+static void local_migration_error(LocalMigState *s)
+{
+assert(s-file == NULL);
+
+s-state = MIG_STATE_ERROR;
+trace_migrate_set_state(MIG_STATE_ERROR);
+}
+
+static void local_outgoing_completed(LocalMigState *s)
+{
+s-state = MIG_STATE_COMPLETED;
+trace_migrate_set_state(MIG_STATE_COMPLETED);
+}
+
+static void *migration_local_thread(void *opaque)
+{
+LocalMigState *s = opaque;
+int ret;
+
+DPRINTF(Beginning savevm\n);
+
+while (s-state == MIG_STATE_ACTIVE) {
+qemu_mutex_lock_iothread();
+ret = qemu_savevm_local(s-file);
+qemu_mutex_unlock_iothread();
+
+/* No need to send device states if ram pages fails to to sent. */
+if (ret 0) {
+local_migration_error(s);
+break;
+}
+
+qemu_save_device_state(s-file);
+qemu_fclose(s-file);
+}
+
+ret = qemu_file_get_error(s-file);
+if (ret 0) {
+local_migration_error(s);
+} else {
+local_outgoing_completed(s);
+}
+
+qemu_mutex_lock_iothread();
+
+if (s-state == MIG_STATE_COMPLETED) {
+runstate_set(RUN_STATE_POSTMIGRATE);
+}
+
+qemu_mutex_unlock_iothread();
+
+return NULL;
+}
+
+void local_migration_fd_connect(LocalMigState *s)
+{
+s-state = MIG_STATE_ACTIVE;
+trace_migrate_set_state(MIG_STATE_ACTIVE);
+
+qemu_thread_create(s-thread, migration_local_thread, s,
+ QEMU_THREAD_JOINABLE);
+}
+
+void
[Qemu-devel] [PATCH] net: Rename send_queue to incoming_queue
From: Jan Kiszka jan.kis...@siemens.com
Each networking client has a queue for packets that could not yet be
delivered to that client. Calling this queue send_queue is highly
confusing as it has nothing to to with packets send from this client but
to it. Avoid this confusing by renaming it to incoming_queue.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
include/net/net.h |2 +-
net/hub.c |2 +-
net/net.c | 14 +++---
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/include/net/net.h b/include/net/net.h
index 30e4b04..11e1468 100644
--- a/include/net/net.h
+++ b/include/net/net.h
@@ -69,7 +69,7 @@ struct NetClientState {
int link_down;
QTAILQ_ENTRY(NetClientState) next;
NetClientState *peer;
-NetQueue *send_queue;
+NetQueue *incoming_queue;
char *model;
char *name;
char info_str[256];
diff --git a/net/hub.c b/net/hub.c
index df32074..33a99c9 100644
--- a/net/hub.c
+++ b/net/hub.c
@@ -347,7 +347,7 @@ bool net_hub_flush(NetClientState *nc)
QLIST_FOREACH(port, source_port-hub-ports, next) {
if (port != source_port) {
-ret += qemu_net_queue_flush(port-nc.send_queue);
+ret += qemu_net_queue_flush(port-nc.incoming_queue);
}
}
return ret ? true : false;
diff --git a/net/net.c b/net/net.c
index c0d61bf..5890e56 100644
--- a/net/net.c
+++ b/net/net.c
@@ -206,7 +206,7 @@ static void qemu_net_client_setup(NetClientState *nc,
}
QTAILQ_INSERT_TAIL(net_clients, nc, next);
-nc-send_queue = qemu_new_net_queue(nc);
+nc-incoming_queue = qemu_new_net_queue(nc);
nc-destructor = destructor;
}
@@ -288,8 +288,8 @@ static void qemu_cleanup_net_client(NetClientState *nc)
static void qemu_free_net_client(NetClientState *nc)
{
-if (nc-send_queue) {
-qemu_del_net_queue(nc-send_queue);
+if (nc-incoming_queue) {
+qemu_del_net_queue(nc-incoming_queue);
}
if (nc-peer) {
nc-peer-peer = NULL;
@@ -430,7 +430,7 @@ void qemu_purge_queued_packets(NetClientState *nc)
return;
}
-qemu_net_queue_purge(nc-peer-send_queue, nc);
+qemu_net_queue_purge(nc-peer-incoming_queue, nc);
}
void qemu_flush_queued_packets(NetClientState *nc)
@@ -443,7 +443,7 @@ void qemu_flush_queued_packets(NetClientState *nc)
}
return;
}
-if (qemu_net_queue_flush(nc-send_queue)) {
+if (qemu_net_queue_flush(nc-incoming_queue)) {
/* We emptied the queue successfully, signal to the IO thread to repoll
* the file descriptor (for tap, for example).
*/
@@ -467,7 +467,7 @@ static ssize_t
qemu_send_packet_async_with_flags(NetClientState *sender,
return size;
}
-queue = sender-peer-send_queue;
+queue = sender-peer-incoming_queue;
return qemu_net_queue_send(queue, sender, flags, buf, size, sent_cb);
}
@@ -542,7 +542,7 @@ ssize_t qemu_sendv_packet_async(NetClientState *sender,
return iov_size(iov, iovcnt);
}
-queue = sender-peer-send_queue;
+queue = sender-peer-incoming_queue;
return qemu_net_queue_send_iov(queue, sender,
QEMU_NET_PACKET_FLAG_NONE,
--
1.7.3.4
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH 11/12] migration-local: add option to commandline for incoming-local
On 07/25/2013 04:18 PM, Lei Li wrote:
Signed-off-by: Lei Li li...@linux.vnet.ibm.com
---
qemu-options.hx |9 +
vl.c| 14 ++
2 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/qemu-options.hx b/qemu-options.hx
index 8355f9b..a975e83 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -2912,6 +2912,15 @@ STEXI
Prepare for incoming migration, listen on @var{port}.
ETEXI
+DEF(incoming-local, HAS_ARG, QEMU_OPTION_incoming_local, \
+-incoming-local p prepare for localhost incoming migration, listen on domain
unix socket p\n,
+QEMU_ARCH_ALL)
+STEXI
+@item -incoming-local @var{port}
+@findex -incoming-local
+Prepare for localhost incoming migration, listen on @var{port}
+ETEXI
+
DEF(nodefaults, 0, QEMU_OPTION_nodefaults, \
-nodefaults don't create default devices\n, QEMU_ARCH_ALL)
STEXI
diff --git a/vl.c b/vl.c
index 767e020..b820db5 100644
--- a/vl.c
+++ b/vl.c
@@ -2854,6 +2854,7 @@ int main(int argc, char **argv, char **envp)
const char *vga_model = none;
const char *pid_file = NULL;
const char *incoming = NULL;
+const char *incoming_local = NULL;
#ifdef CONFIG_VNC
int show_vnc_port = 0;
#endif
@@ -3691,6 +3692,10 @@ int main(int argc, char **argv, char **envp)
incoming = optarg;
runstate_set(RUN_STATE_INMIGRATE);
break;
+case QEMU_OPTION_incoming_local:
+incoming_local = optarg;
+runstate_set(RUN_STATE_INMIGRATE);
+break;
case QEMU_OPTION_nodefaults:
default_serial = 0;
default_parallel = 0;
@@ -4377,6 +4382,15 @@ int main(int argc, char **argv, char **envp)
error_free(local_err);
exit(1);
}
+} else if (incoming_local) {
+Error *local_err = NULL;
+qemu_start_local_incoming_migration(incoming_local, local_err);
+if (local_err) {
+fprintf(stderr, -incoming_local %s: %s\n, incoming_local,
+error_get_pretty(local_err));
+error_free(local_err);
+exit(1);
+}
} else if (autostart) {
vm_start();
}
Why can't we do: -incoming local: instead of adding a new flag?
Would be much more compatible with libvirt tools if you just add a new
URI prefix.
- Michael
Re: [Qemu-devel] [PATCH 12/12] hmp: add hmp_localhost_migration interface
On 07/25/2013 04:18 PM, Lei Li wrote:
Signed-off-by: Lei Li li...@linux.vnet.ibm.com
---
hmp-commands.hx | 17 +
hmp.c | 13 +
hmp.h |1 +
3 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 915b0d1..ed21970 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -989,6 +989,23 @@ STEXI
Set the spice/vnc connection info for the migration target. The spice/vnc
server will ask the spice/vnc client to automatically reconnect using the
new parameters (if specified) once the vm migration finished successfully.
+
+ETEXI
+
+{
+.name = localhost_migrate,
+.args_type = uri:s,
+.params = uri,
+.help = migrate to domain socket URI on localhost,
+.mhandler.cmd = hmp_localhost_migrate,
+},
+
+
+STEXI
+@item localhost_migrate @var{uri}
+@findex localhost_migrate
+Migrate to @var{uri}.
+
ETEXI
{
diff --git a/hmp.c b/hmp.c
index 494a9aa..a7e779f 100644
--- a/hmp.c
+++ b/hmp.c
@@ -1191,6 +1191,19 @@ void hmp_migrate(Monitor *mon, const QDict *qdict)
}
}
+void hmp_localhost_migrate(Monitor *mon, const QDict *qdict)
+{
+const char *uri = qdict_get_str(qdict, uri);
+Error *errp = NULL;
+
+qmp_localhost_migrate(uri, errp);
+if (errp) {
+monitor_printf(mon, local_migrate: %s\n, error_get_pretty(errp));
+error_free(errp);
+return;
+}
+}
+
void hmp_device_del(Monitor *mon, const QDict *qdict)
{
const char *id = qdict_get_str(qdict, id);
diff --git a/hmp.h b/hmp.h
index 56d2e92..9124c0e 100644
--- a/hmp.h
+++ b/hmp.h
@@ -60,6 +60,7 @@ void hmp_migrate_set_downtime(Monitor *mon, const QDict
*qdict);
void hmp_migrate_set_speed(Monitor *mon, const QDict *qdict);
void hmp_migrate_set_capability(Monitor *mon, const QDict *qdict);
void hmp_migrate_set_cache_size(Monitor *mon, const QDict *qdict);
+void hmp_localhost_migrate(Monitor *mon, const QDict *qdict);
void hmp_set_password(Monitor *mon, const QDict *qdict);
void hmp_expire_password(Monitor *mon, const QDict *qdict);
void hmp_eject(Monitor *mon, const QDict *qdict);
This could go away if you just create a new URI prefix instead of a new
command-line switch.
- Michael
Re: [Qemu-devel] [PATCH 07/12] savevm: introduce qemu_savevm_local()
On 07/25/2013 04:18 PM, Lei Li wrote:
Signed-off-by: Lei Li li...@linux.vnet.ibm.com
---
include/sysemu/sysemu.h |1 +
savevm.c| 55 +++
2 files changed, 56 insertions(+), 0 deletions(-)
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index 5b90027..9abe4c9 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -80,6 +80,7 @@ int qemu_savevm_state_iterate(QEMUFile *f);
void qemu_savevm_state_complete(QEMUFile *f);
void qemu_savevm_state_cancel(void);
uint64_t qemu_savevm_state_pending(QEMUFile *f, uint64_t max_size);
+int qemu_savevm_local(QEMUFile *f);
int qemu_save_device_state(QEMUFile *f);
int qemu_loadvm_state(QEMUFile *f);
diff --git a/savevm.c b/savevm.c
index e18ca22..c183369 100644
--- a/savevm.c
+++ b/savevm.c
@@ -2007,6 +2007,61 @@ static int qemu_savevm_state(QEMUFile *f)
}
/**
+ * Save all of the ram pages to stream QEMUFile
+ *
+ * Return: negtive for an error
+ */
+int qemu_savevm_local(QEMUFile *f)
+{
+SaveStateEntry *se;
+int ret;
+
+QTAILQ_FOREACH(se, savevm_handlers, entry) {
+if (!se-ops) {
+continue;
+}
+}
+
+qemu_put_be32(f, QEMU_VM_FILE_MAGIC);
+qemu_put_be32(f, QEMU_VM_FILE_VERSION);
+
+QTAILQ_FOREACH(se, savevm_handlers, entry) {
+int len;
+
+if (!se-ops || !se-ops-save_local_setup) {
+continue;
+}
+if (se-ops se-ops-is_block_active) {
+continue;
+}
+
+/* Section type */
+qemu_put_byte(f, QEMU_VM_SECTION_START);
+qemu_put_be32(f, se-section_id);
+
+/* ID string */
+len = strlen(se-idstr);
+qemu_put_byte(f, len);
+qemu_put_buffer(f, (uint8_t *)se-idstr, len);
+
+qemu_put_be32(f, se-instance_id);
+
+qemu_put_be32(f, se-version_id);
+
+ret = se-ops-save_local_setup(f, se-opaque);
+if (ret 0) {
+qemu_file_set_error(f, ret);
+break;
+}
+}
+
+qemu_put_byte(f, QEMU_VM_EOF);
+qemu_fflush(f);
+
+return qemu_file_get_error(f);
+}
+
+/**
* Save all of the device states to stream QEMUFile
*
* Return negtive if there has been an error
You don't have enough comments in your commit messages - please add more.
Why do you need a new savevm function?
- Michael
Re: [Qemu-devel] [RFC v2 3/5] timer: make qemu_clock_enable sync between disable and timer's cb
On Fri, Aug 02, 2013 at 11:33:40AM +0800, liu ping fan wrote: On Thu, Aug 1, 2013 at 9:28 PM, Alex Bligh a...@alex.org.uk wrote: Paolo, --On 1 August 2013 08:19:34 -0400 Paolo Bonzini pbonz...@redhat.com wrote: True, qemu_event basically works only when a single thread resets it. But there is no race condition here because qemu_run_timers cannot be executed concurrently by multiple threads (like aio_poll in your bottom half patches). ... or, if rebasing on top of my patches, qemu_run_timers *can* be executed concurrently by mulitple threads, but in respect of any given QEMUTimerList, it will only be executed by one thread. ... so the event would be placed in QEMUTimerList, not QEMUClock. Correct qemu_clock_enable then will have to visit all timer lists. That's not hard to do, Correct, v4 of my patch does this. but as locks proliferate we need to have a clear policy (e.g. BQL - clock - timerlist). But doesn't do the locking bit yet (Pingfan is going to do that I hope) Seem that Stefanha had been involved in this, and sent out his patches :) Hi Ping Fan, I dropped the series where I added locks to qemu-timer.c from a few weeks ago. With your series rebased onto Alex's series, I think my patches are no longer needed? Stefan
[Qemu-devel] [RFC V3 0/2] continuous leaky bucket throttling
This patchset implement continous leaky bucket throttling. It works mostly on the general case. The exception is where the load is composed of both reads and writes and two limits iops_rd and iops_wr are set. The resulting iops are a little above half of the given limits. I tried various strategies to avoid this: two timer, two throttled request queues or even a different algorithm using a priority queue. The problem is still the same in every version of the code: reads and writes operation seems entangled. Benoît Canet (2): throttle: Add a new throttling API implementing continuus leaky bucket. block: Enable the new throttling code in the block layer. block.c | 316 block/qapi.c | 21 +-- blockdev.c| 115 ++-- include/block/block.h |1 - include/block/block_int.h | 33 +--- include/qemu/throttle.h | 111 util/Makefile.objs|1 + util/throttle.c | 436 + 8 files changed, 698 insertions(+), 336 deletions(-) create mode 100644 include/qemu/throttle.h create mode 100644 util/throttle.c -- 1.7.10.4
Re: [Qemu-devel] [PATCH v3 5/7] migration: omit drive ref as we have bdrv_ref now
On Fri, Aug 02, 2013 at 04:13:55PM +0800, Wenchao Xia wrote: There should be a section of code in device hot unplug, checking DriverInfo's ref, fail or do nothing when ref != 1. But I haven't found that code, so not sure whether this patch will change the behavior in device hot unplug. It is not necessary to refuse device hot unplug when bs.ref 0. But a couple of fixes are required to make it safe: Background -- DriveInfo always holds a BDS refcount, so BDS can never be deleted while the DriveInfo exists. DriveInfo is the metadata that connects an emulated storage controller with its BDS. Therefore, hot unplugging an emulated storage controller may release the last DriveInfo reference and delete it. Anything that still holds the BDS reference when DriveInfo is deleted will keep the BDS alive. It turns out that a lot of commands only use BDS with bdrv_find(), not DriveInfo, so you can continue to do useful things with the BDS after its DriveInfo is deleted. The problem --- A couple of places have not been converted to use bdrv_ref() yet, so they still go through drive_get_ref(drive_get_by_blockdev(bs)). These cases will now fail! I pointed out the blockjob cases but please grep to make sure there are no others. You need to fix them before this series is safe, otherwise drive_put_ref(NULL) will segfault! Stefan
Re: [Qemu-devel] Using virtio-mmio
Hi, Im trying to test virtio-mmio too but Im having no success to boot vexpress-a9. kernel: Linux 3.10-rc6 - vexpress_defconfig qemu: 1.6.0-rc0 cmd line: qemu-system-arm\ -m 512\ -M vexpress-a9\ -kernel arch/arm/boot/zImage\ -initrd boot-kernels/initrd-modified.img \ -append root=/dev/mmcblk0p2 console=ttyAMA0 rootwait debug earlyprintk\ -sd /exports/vexpress/vexpress-a9-nano.img\ -monitor unix:/dev/tty1,nowait,server\ -serial stdio\ -d in_asm,cpu -D /tmp/qemu.log -singlestep Here I get the 'total no output' error. I tried with vexpress-v2p-ca9.dtb and from 'remotes/linaro/v3.9/vexpress' but got the same. With, qemu-system-arm\ -m 512\ -M vexpress-a15\ -kernel arch/arm/boot/zImage\ -initrd boot-kernels/initrd-modified.img\ -append root=/dev/mmcblk0p2 console=ttyAMA0 rootwait debug earlyprintk\ -dtb arch/arm/boot/dts/vexpress-v2p-ca15_a7.dtb'\ -sd /exports/vexpress/vexpress-a9-nano.img\ -monitor unix:/dev/tty1,nowait,server\ -serial stdio The kernel boots, but it cant mount the SD: mmc0: host doesn't support card's voltages mmc0: error -22 whilst initialising SD card SD: Unknown CMD1 Am I missing something?? Kind Regards, Erlon
Re: [Qemu-devel] Licensing question
On 07/31/2013 12:19:03 AM, Stefan Weil wrote: Am 31.07.2013 03:50, schrieb Erik de Castro Lopo: Hi all, I have a patch I would like to submit and I am currently running it past my employer's legal department. The legal department has identified 10 different licenses in the Qemu codebase and has asked about the two files I am modifying: linux-user/syscall.c linux-user/syscall_defs.h For the first its easy as it is clearly marked as GPLv2+. The second is unmarked. Is there some blanket statement somewhere that all files that are not explicitly marked are under say GPLv2+? Cheers, Erik No, there is no such statement. There is an agreement that files with GPL should be GPLv2+ (not only GPLv2), but files may also use other free licenses. In file LICENSE, it is said that QEMU as a whole is released under the GNU General Public License. Which, if you don't specify, could mean GPLv1. Some files are copied from Linux and therefore must use the Linux license (usually GPLv2). syscall_defs.h might be a copy from Linux (= GPLv2). If not, the default rule from LICENSE could be applied (= GPL). Some directories, such as TCG, have their own LICENSE files. These are generally BSD-style license which are donor-compatible (but not receiver-compatible) with GPLv2 or later. (If you are obligated to include this license text verbatim, but it does not actually apply to the file is an acceptable definition of compatible, but that's a legal argument nobody's made in court yet so I'm sure you're fine. Nor has anybody recently brought up whether the Software you're obligated to include it in is just source versions or requires the license text to be in the binary; Android does it to be safe, most others don't bother.) Rob (Personally I look back at the days when my Commodore 64 came bundled with a Disk Bonus Pack of public domain software mostly written by Jim Butterfield, and going why did we stop doing that again? Because awaiting hot coffee lawsuits was worse than awaiting patent troll lawsuits?)
Re: [Qemu-devel] [PATCH 00/16 RFC v6] ACPI memory hotplug
Applied. Thanks. Regards, Anthony Liguori
