Re: [Qemu-devel] [PATCH] sheepdog: implement SD_OP_FLUSH_VDI operation
On Fri, Apr 20, 2012 at 12:15:36PM -0700, MORITA Kazutaka wrote: His patch sets the SD_FLAG_CMD_CACHE flag for writes only when the user selects cache=writeback or cache=none. If SD_FLAG_CMD_CACHE is not set in the request, Sheepdog servers are forced to flush the cache like FUA commands. Ok, I missed that part and it thus seems ok. What still sems missing is error handling in case the sheepdog cluster doesn't actually support the new flag. What happens if cache=none is specified with a cluster not actually supporting it? Remember that cache=none is the default for many management frontends to qemu.
Re: [Qemu-devel] [PATCH] configure: Virtfs doesn't require libcap.
Il 22/04/2012 12:16, Kusanagi Kouichi ha scritto: Only proxy helper does. Signed-off-by: Kusanagi Kouichi sl...@ac.auone-net.jp --- configure |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/configure b/configure index 2d62d12..c8e6fe4 100755 --- a/configure +++ b/configure @@ -2860,9 +2860,11 @@ tools= if test $softmmu = yes ; then tools=qemu-img\$(EXESUF) qemu-io\$(EXESUF) $tools if test $virtfs != no ; then - if test $cap = yes test $linux = yes test $attr = yes ; then + if test $linux = yes test $attr = yes ; then virtfs=yes - tools=$tools fsdev/virtfs-proxy-helper\$(EXESUF) + if test $cap = yes ; then + tools=$tools fsdev/virtfs-proxy-helper\$(EXESUF) + fi else if test $virtfs = yes; then feature_not_found virtfs Reviewed-by: Paolo Bonzini pbonz...@redhat.com
[Qemu-devel] [Bug 986318] Re: [sdl] Mouse grab breaks GNOME 3 screensaver unlock screen
I think this is a GNOME bug. The screensaver should not activate if an X client has a grab and it cannot be stolen. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/986318 Title: [sdl] Mouse grab breaks GNOME 3 screensaver unlock screen Status in QEMU: New Bug description: When the GNOME 3 screensaver activates with the mouse cursor over the SDL window, the screensaver will not unlock unless the gnome-shell process is killed and restarted manually. This seems to be related to the fact that the key strokes are grabbed by SDL, but the screensaver will not allow the Ctrl and Alt keys to be passed to QEMU to exit the mouse grab. Qemu-kvm 1.0.1, QEMU 1.0.1, kernel 3.2.15. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/986318/+subscriptions
Re: [Qemu-devel] [Qemu-ppc] [PATCH] Bug fix for #986241: spell env correctly
On 23 April 2012 03:25, Peter Portante pport...@redhat.com wrote: Can somebody speak to the history of using a global variable for env state instead of passing it around in function calls? Is this because we could not trust the compiler to keep it in a register between function calls? If so, then do you think it might be worth a look at what the compilers can do to help simplify somewhat complicated code and still maintain the performance? Or was it that env had to be added to so many functions that it became too tedious to maintain? It's historical legacy, really. env is in a fixed register when running in TCG code, and so some functions called directly from TCG code have also been compiled to assume env to be in that fixed register, to avoid the overhead of having TCG code marshall it in as a function parameter. Blue Swirl has been working on patchsets that move towards always passing it in a register; unfortunately there is apparently a performance hit associated with this, though. -- PMM
Re: [Qemu-devel] [PATCH v3] ARM: Exynos4210 IRQ: Introduce new IRQ gate functionality.
On 23 April 2012 06:08, Evgeny Voevodin e.voevo...@samsung.com wrote: Peter, wait, n_in is a property that board sets. So it should be saved/restored. As I understand it, migration will always be between two identical configurations. So properties never need to be saved or restored. -- PMM
[Qemu-devel] compile problem
Ater I git pull to the newest version, I make qemu, the error happen: CCx86_64-softmmu/vga.o CCx86_64-softmmu/memory.o CCx86_64-softmmu/savevm.o CCx86_64-softmmu/xen-all.o cc1: warnings being treated as errors /home/mm/code-new/qemu-2012-3-19/test-new/qemu/xen-all.c: In function ‘xen_hvm_inject_msi’: /home/mm/code-new/qemu-2012-3-19/test-new/qemu/xen-all.c:132:5: error: implicit declaration of function ‘xc_hvm_inject_msi’ /home/mm/code-new/qemu-2012-3-19/test-new/qemu/xen-all.c:132:5: error: nested extern declaration of ‘xc_hvm_inject_msi’ make[1]: *** [xen-all.o] Error 1 make: *** [subdir-x86_64-softmmu] Error 2 I don't know why, can anyone help me ? thank you very much !
Re: [Qemu-devel] compile problem
Il 23/04/2012 10:13, Zhi Hui Li ha scritto: Ater I git pull to the newest version, I make qemu, the error happen: CCx86_64-softmmu/vga.o CCx86_64-softmmu/memory.o CCx86_64-softmmu/savevm.o CCx86_64-softmmu/xen-all.o cc1: warnings being treated as errors /home/mm/code-new/qemu-2012-3-19/test-new/qemu/xen-all.c: In function ‘xen_hvm_inject_msi’: /home/mm/code-new/qemu-2012-3-19/test-new/qemu/xen-all.c:132:5: error: implicit declaration of function ‘xc_hvm_inject_msi’ /home/mm/code-new/qemu-2012-3-19/test-new/qemu/xen-all.c:132:5: error: nested extern declaration of ‘xc_hvm_inject_msi’ make[1]: *** [xen-all.o] Error 1 make: *** [subdir-x86_64-softmmu] Error 2 I don't know why, can anyone help me ? thank you very much ! A pull request has been sent for this. In the meanwhile, if you don't use Xen you can just comment out the offending line. Paolo
[Qemu-devel] [PATCH] qemu-iotests: ignore fragmentation information for qed
We added image fragmentation statistics functions to qemu-img several days ago, those patches will cause ./check -qed failed. This patch will ignore fragmentation statistics information of qed format, and then ./check -qed will work. Signed-off-by: Dong Xu Wang wdon...@linux.vnet.ibm.com --- tests/qemu-iotests/check |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/qemu-iotests/check b/tests/qemu-iotests/check index aae1378..b836780 100755 --- a/tests/qemu-iotests/check +++ b/tests/qemu-iotests/check @@ -243,7 +243,7 @@ do echo - no qualified output err=true else - if diff -w $seq.out $tmp.out /dev/null 21 + if diff -w -I fragmented$ $seq.out $tmp.out /dev/null 21 then echo if $err @@ -255,7 +255,7 @@ do else echo - output mismatch (see $seq.out.bad) mv $tmp.out $seq.out.bad - $diff -w $seq.out $seq.out.bad + $diff -w -I fragmented$ $seq.out $seq.out.bad err=true fi fi -- 1.7.1
Re: [Qemu-devel] [PATCH 25/25] qdev: split part of device_finalize to device_unrealize
Il 20/04/2012 19:56, Anthony Liguori ha scritto:
On 04/03/2012 06:15 AM, Paolo Bonzini wrote:
Signed-off-by: Paolo Bonzinipbonz...@redhat.com
---
hw/qdev.c | 35 ---
1 file changed, 20 insertions(+), 15 deletions(-)
diff --git a/hw/qdev.c b/hw/qdev.c
index e674248..45f1133 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -601,27 +601,31 @@ static void device_initfn(Object *obj)
}
/* Unlink device from bus and free the structure. */
-static void device_finalize(Object *obj)
+static void device_unrealize(Object *obj)
{
DeviceState *dev = DEVICE(obj);
BusState *bus;
DeviceClass *dc = DEVICE_GET_CLASS(dev);
-if (object_is_realized(obj)) {
-while (dev-num_child_bus) {
-bus = QLIST_FIRST(dev-child_bus);
-qbus_free(bus);
-}
-if (qdev_get_vmsd(dev)) {
-vmstate_unregister(dev, qdev_get_vmsd(dev), dev);
-}
-if (dc-exit) {
-dc-exit(dev);
-}
-if (dev-opts) {
-qemu_opts_del(dev-opts);
-}
+while (dev-num_child_bus) {
+bus = QLIST_FIRST(dev-child_bus);
+qbus_free(bus);
+}
This doesn't seem symmetric to me. We don't create busses in realize(),
or at least we shouldn't IMHO. We should create child busses in
instance_init(). Should be remove them in finalize?
Perhaps yes, I'll split the patch in two.
Paolo
Re: [Qemu-devel] copy benchmarks onto qemu
On Sun, Apr 22, 2012 at 5:37 PM, Xin Tong xerox.time.t...@gmail.com wrote: i have an OS image that does not have network drivers. are there any other ways to copy a benchmark onto the os image ? You can insert a CD-ROM: (qemu) info block ide1-cd0: removable=1 locked=0 tray-open=0 io-status=ok [not inserted] ... (qemu) change ide1-cd0 my-benchmark.iso Or you could attach a USB Mass Storage device if USB is enabled. Stefan
Re: [Qemu-devel] [PATCH] qemu-iotests: ignore fragmentation information for qed
Am 23.04.2012 10:43, schrieb Dong Xu Wang: We added image fragmentation statistics functions to qemu-img several days ago, those patches will cause ./check -qed failed. This patch will ignore fragmentation statistics information of qed format, and then ./check -qed will work. Signed-off-by: Dong Xu Wang wdon...@linux.vnet.ibm.com --- tests/qemu-iotests/check |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/qemu-iotests/check b/tests/qemu-iotests/check index aae1378..b836780 100755 --- a/tests/qemu-iotests/check +++ b/tests/qemu-iotests/check @@ -243,7 +243,7 @@ do echo - no qualified output err=true else - if diff -w $seq.out $tmp.out /dev/null 21 + if diff -w -I fragmented$ $seq.out $tmp.out /dev/null 21 then echo if $err @@ -255,7 +255,7 @@ do else echo - output mismatch (see $seq.out.bad) mv $tmp.out $seq.out.bad - $diff -w $seq.out $seq.out.bad + $diff -w -I fragmented$ $seq.out $seq.out.bad err=true fi fi Please add a pipe to grep/sed to _check_test_img in common.rc instead. Kevin
Re: [Qemu-devel] copy benchmarks onto qemu
Am 22.04.2012 18:37, schrieb Xin Tong: i have an OS image that does not have network drivers. are there any other ways to copy a benchmark onto the os image ? If it is a raw image you can use kpartx to get block devices on the host that you can use for mounting the guest file system on the host (the guest must not be running, of course). If it is some image format, you can try qemu-nbd and attaching the image to the host by using an NBD client. Or maybe the easiest way is to just create an ISO image and pass that as a CD-ROM to the guest. Kevin
Re: [Qemu-devel] copy benchmarks onto qemu
On Mon, Apr 23, 2012 at 4:29 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Sun, Apr 22, 2012 at 5:37 PM, Xin Tong xerox.time.t...@gmail.com wrote: i have an OS image that does not have network drivers. are there any other ways to copy a benchmark onto the os image ? You can insert a CD-ROM: (qemu) info block ide1-cd0: removable=1 locked=0 tray-open=0 io-status=ok [not inserted] ... (qemu) change ide1-cd0 my-benchmark.iso Or you could attach a USB Mass Storage device if USB is enabled. Or you can attach this os image to one VM with network drivers as its second disk, then scp your benchmark file to this os image.:) Stefan -- Regards, Zhi Yong Wu
Re: [Qemu-devel] compile problem
On 2012年04月23日 16:21, Paolo Bonzini wrote: Il 23/04/2012 10:13, Zhi Hui Li ha scritto: Ater I git pull to the newest version, I make qemu, the error happen: CCx86_64-softmmu/vga.o CCx86_64-softmmu/memory.o CCx86_64-softmmu/savevm.o CCx86_64-softmmu/xen-all.o cc1: warnings being treated as errors /home/mm/code-new/qemu-2012-3-19/test-new/qemu/xen-all.c: In function ‘xen_hvm_inject_msi’: /home/mm/code-new/qemu-2012-3-19/test-new/qemu/xen-all.c:132:5: error: implicit declaration of function ‘xc_hvm_inject_msi’ /home/mm/code-new/qemu-2012-3-19/test-new/qemu/xen-all.c:132:5: error: nested extern declaration of ‘xc_hvm_inject_msi’ make[1]: *** [xen-all.o] Error 1 make: *** [subdir-x86_64-softmmu] Error 2 I don't know why, can anyone help me ? thank you very much ! A pull request has been sent for this. In the meanwhile, if you don't use Xen you can just comment out the offending line. Paolo Thank you very much! :)
Re: [Qemu-devel] copy benchmarks onto qemu
On Mon, Apr 23, 2012 at 4:41 PM, Zhi Yong Wu zwu.ker...@gmail.com wrote: On Mon, Apr 23, 2012 at 4:29 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Sun, Apr 22, 2012 at 5:37 PM, Xin Tong xerox.time.t...@gmail.com wrote: i have an OS image that does not have network drivers. are there any other ways to copy a benchmark onto the os image ? You can insert a CD-ROM: (qemu) info block ide1-cd0: removable=1 locked=0 tray-open=0 io-status=ok [not inserted] ... (qemu) change ide1-cd0 my-benchmark.iso Or you could attach a USB Mass Storage device if USB is enabled. Or you can attach this os image to one VM with network drivers as its second disk, then scp your benchmark file to this os image.:) Or if your benchmark file is small, you can create one floppy image where your benchmark files are, then start your VM with floppy. Stefan -- Regards, Zhi Yong Wu -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH 07/10] Do not use pa_simple PulseAudio API
On 2012-04-17 14:32, Marc-André Lureau wrote:
Unfortunately, pa_simple is a limited API which doesn't let us
retrieve the associated pa_stream. It is needed to control the volume
of the stream.
In v4:
- add missing braces
Signed-off-by: Marc-André Lureau marcandre.lur...@redhat.com
...
+
+static pa_stream *qpa_simple_new (
+const char *server,
+const char *name,
+pa_stream_direction_t dir,
+const char *dev,
+const char *stream_name,
+const pa_sample_spec *ss,
+const pa_channel_map *map,
+const pa_buffer_attr *attr,
+int *rerror)
rerror is not even used in this function...
+{
+paaudio *g = glob_paaudio;
+int r;
+pa_stream *stream;
+
+pa_threaded_mainloop_lock (g-mainloop);
+
+stream = pa_stream_new (g-context, name, ss, map);
+if (!stream) {
+goto fail;
+}
+
+pa_stream_set_state_callback (stream, stream_state_cb, g);
+pa_stream_set_read_callback (stream, stream_request_cb, g);
+pa_stream_set_write_callback (stream, stream_request_cb, g);
+
+if (dir == PA_STREAM_PLAYBACK) {
+r = pa_stream_connect_playback (stream, dev, attr,
+PA_STREAM_INTERPOLATE_TIMING
+|PA_STREAM_ADJUST_LATENCY
+|PA_STREAM_AUTO_TIMING_UPDATE, NULL,
NULL);
+} else {
+r = pa_stream_connect_record (stream, dev, attr,
+ PA_STREAM_INTERPOLATE_TIMING
+ |PA_STREAM_ADJUST_LATENCY
+ |PA_STREAM_AUTO_TIMING_UPDATE);
+}
+
+if (r 0) {
+ goto fail;
+}
+
+pa_threaded_mainloop_unlock (g-mainloop);
+
+return stream;
+
+fail:
+pa_threaded_mainloop_unlock (g-mainloop);
+
+if (stream) {
+pa_stream_unref (stream);
+}
+
+qpa_logerr (pa_context_errno (g-context),
+stream_new() failed\n);
+
+return NULL;
+}
+
static int qpa_init_out (HWVoiceOut *hw, struct audsettings *as)
{
int error;
@@ -306,24 +534,24 @@ static int qpa_init_out (HWVoiceOut *hw, struct
audsettings *as)
obt_as.fmt = pa_to_audfmt (ss.format, obt_as.endianness);
-pa-s = pa_simple_new (
-conf.server,
+pa-stream = qpa_simple_new (
+glob_paaudio.server,
qemu,
PA_STREAM_PLAYBACK,
-conf.sink,
+glob_paaudio.sink,
pcm.playback,
ss,
NULL, /* channel map */
ba,/* buffering attributes */
error
);
-if (!pa-s) {
+if (!pa-stream) {
qpa_logerr (error, pa_simple_new for playback failed\n);
...but here (and below) we depend on it to be initialized. This breaks
the build. Please fix.
Thanks,
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
Re: [Qemu-devel] copy benchmarks onto qemu
On Mon, Apr 23, 2012 at 4:46 PM, Zhi Yong Wu zwu.ker...@gmail.com wrote: On Mon, Apr 23, 2012 at 4:41 PM, Zhi Yong Wu zwu.ker...@gmail.com wrote: On Mon, Apr 23, 2012 at 4:29 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Sun, Apr 22, 2012 at 5:37 PM, Xin Tong xerox.time.t...@gmail.com wrote: i have an OS image that does not have network drivers. are there any other ways to copy a benchmark onto the os image ? You can insert a CD-ROM: (qemu) info block ide1-cd0: removable=1 locked=0 tray-open=0 io-status=ok [not inserted] ... (qemu) change ide1-cd0 my-benchmark.iso Or you could attach a USB Mass Storage device if USB is enabled. Or you can attach this os image to one VM with network drivers as its second disk, then scp your benchmark file to this os image.:) Or if your benchmark file is small, you can create one floppy image where your benchmark files are, then start your VM with floppy. Or you can use 9pfs. Stefan -- Regards, Zhi Yong Wu -- Regards, Zhi Yong Wu -- Regards, Zhi Yong Wu
Re: [Qemu-devel] copy benchmarks onto qemu
On Mon, Apr 23, 2012 at 5:00 PM, Zhi Yong Wu zwu.ker...@gmail.com wrote: On Mon, Apr 23, 2012 at 4:46 PM, Zhi Yong Wu zwu.ker...@gmail.com wrote: On Mon, Apr 23, 2012 at 4:41 PM, Zhi Yong Wu zwu.ker...@gmail.com wrote: On Mon, Apr 23, 2012 at 4:29 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Sun, Apr 22, 2012 at 5:37 PM, Xin Tong xerox.time.t...@gmail.com wrote: i have an OS image that does not have network drivers. are there any other ways to copy a benchmark onto the os image ? You can insert a CD-ROM: (qemu) info block ide1-cd0: removable=1 locked=0 tray-open=0 io-status=ok [not inserted] ... (qemu) change ide1-cd0 my-benchmark.iso Or you could attach a USB Mass Storage device if USB is enabled. Or you can attach this os image to one VM with network drivers as its second disk, then scp your benchmark file to this os image.:) Or if your benchmark file is small, you can create one floppy image where your benchmark files are, then start your VM with floppy. Or you can use 9pfs. Or you can directly use libguestfs. Stefan -- Regards, Zhi Yong Wu -- Regards, Zhi Yong Wu -- Regards, Zhi Yong Wu -- Regards, Zhi Yong Wu
[Qemu-devel] [PATCH v2] qemu-iotests: ignore fragmentation information for qed
We added image fragmentation statistics functions to qemu-img several days
ago, those patches will cause ./check -qed failed. This patch will ignore
fragmentation statistics information of qed format, and then ./check -qed
will work.
Signed-off-by: Dong Xu Wang wdon...@linux.vnet.ibm.com
---
v1-v2:
change function _check_test_img, do not touch check file.
tests/qemu-iotests/common.rc |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/tests/qemu-iotests/common.rc b/tests/qemu-iotests/common.rc
index 4cb8dae..b5f6104 100644
--- a/tests/qemu-iotests/common.rc
+++ b/tests/qemu-iotests/common.rc
@@ -106,6 +106,7 @@ _cleanup_test_img()
_check_test_img()
{
$QEMU_IMG check -f $IMGFMT $TEST_IMG 21 | \
+grep -v fragmented$ | \
sed -e 's/qemu-img\: This image format does not support checks/No
errors were found on the image./'
}
--
1.7.1
Re: [Qemu-devel] [PATCH v2] qemu-iotests: ignore fragmentation information for qed
Sorry, missed v2 Lable in title.
On Mon, Apr 23, 2012 at 17:14, Dong Xu Wang wdon...@linux.vnet.ibm.comwrote:
We added image fragmentation statistics functions to qemu-img several days
ago, those patches will cause ./check -qed failed. This patch will ignore
fragmentation statistics information of qed format, and then ./check -qed
will work.
Signed-off-by: Dong Xu Wang wdon...@linux.vnet.ibm.com
---
v1-v2:
change function _check_test_img, do not touch check file.
tests/qemu-iotests/common.rc |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/tests/qemu-iotests/common.rc b/tests/qemu-iotests/common.rc
index 4cb8dae..b5f6104 100644
--- a/tests/qemu-iotests/common.rc
+++ b/tests/qemu-iotests/common.rc
@@ -106,6 +106,7 @@ _cleanup_test_img()
_check_test_img()
{
$QEMU_IMG check -f $IMGFMT $TEST_IMG 21 | \
+grep -v fragmented$ | \
sed -e 's/qemu-img\: This image format does not support checks/No
errors were found on the image./'
}
--
1.7.1
Re: [Qemu-devel] [PATCH 00/16] QEMU vhost-scsi support
On Sat, Apr 21, 2012 at 9:51 AM, Nicholas A. Bellinger n...@linux-iscsi.org wrote: On Fri, 2012-04-20 at 12:09 +0100, Stefan Hajnoczi wrote: On Fri, Apr 20, 2012 at 8:46 AM, Paolo Bonzini pbonz...@redhat.com wrote: Il 20/04/2012 09:00, Nicholas A. Bellinger ha scritto: SNIP - no support for migration (there can be pending SCSI requests at migration time, that need to be restarted on the destination) Yes and it hasn't been thought through by me at least ;-). So migration is indeed a challenge that needs to be worked through. - no support for non-raw images (fix: use NBD on a Unix socket? perhaps add an NBD backend to lio) For me this is the biggest issue with kernel-level storage for virtual machines. We have NBD today but it goes through the network stack using a limited protocol and probably can't do zero-copy. The most promising option I found was dm-userspace (http://wiki.xensource.com/xenwiki/DmUserspace), which implements a device-mapper target with an in-kernel MMU-like lookup mechanism that calls out to userspace when block addresses need to be translated. It's not anywhere near to upstream and hasn't been pushed for several years. On the plus side we could also write a userspace implementation of this so that QEMU image formats continue to be portable to other host OSes without duplicating code. If tcm_vhost only works with raw images then I don't see it as a realistic option given the effort it will require to complete and maintain. So there has been interest in the past for creating a TCM backend that allows for a userspace passthrough, but so far the code to do this has not materialized yet.. There are pieces of logic from STGT that provide an interface for doing something similar that still exist in the upstream kernel. Allowing different QEMU formats to be processed (in userspace) through a hybrid TCM backend driver that fits into the existing HBA/DEV layout in /sys/kernel/config/target/$HBA/$DEV/ is what would be required to really do this properly.. Could you point to the existing upstream code? I think the hybrid TCM backend driver means a way for a userspace process to execute SCSI Tasks from the target - implementing a subset of se_subsystem_api in userspace? If we solve the problem at the block driver level instead of inside the SCSI target then it's also possible for the host to inspect VM disk images similar to loopback devices (mount -o loop). Do you think putting the userspace interface into the SCSI target has advantages over the block driver or device-mapper level? Stefan
Re: [Qemu-devel] [PATCH] virtio: add missing mb() on notification
On Sun, Apr 22, 2012 at 3:54 PM, Michael S. Tsirkin m...@redhat.com wrote: During normal operation, virtio host first writes a used index and then checks whether it should interrupt the guest by reading guest avail flag/used event index values. Guest does the reverse: writes the index/flag, then checks the used ring. The ordering is important: if host avail flag read bypasses the used index write, we could in effect get this timing: host avail flag/used event index read guest enable interrupts: this performs avail flag/used event index write guest check used ring: ring is empty host used index write This timing results in a lost interrupt: guest will never be notified about the used ring update. This has actually been observed in the field, when using qemu-kvm such that the guest vcpu and qemu io run on different host cpus, but only seems to trigger on some specific hardware, and only with userspace virtio: vhost has the necessary smp_mb() in place to prevent the reordering, so the same workload stalls forever waiting for an interrupt with vhost=off but works fine with vhost=on. Insert an smp_mb() barrier operation in userspace virtio to ensure the correct ordering. Applying this patch fixed the race condition we have observed. Tested on x86_64. I checked the code generated by the new macro for i386 and ppc but didn't run virtio. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- hw/virtio.c | 2 ++ qemu-barrier.h | 23 --- 2 files changed, 22 insertions(+), 3 deletions(-) Reviewed-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
[Qemu-devel] KVM call agenda for April, Tuesday 24
Hi Please send in any agenda items you are interested in covering. Thanks, Juan.
[Qemu-devel] [PATCH 2/7] [s390] fix error handling on kernel and initrd failures
If the user specifies a non-existing or non-accessable kernel or initrd
qemu does not fail, instead it ipls into the system, which then falls
into a program check loop due to the zeroed memory with no kernel.
Lets add some sanity checks.
Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com
---
hw/s390-virtio.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/hw/s390-virtio.c b/hw/s390-virtio.c
index c79784c..d17602f 100644
--- a/hw/s390-virtio.c
+++ b/hw/s390-virtio.c
@@ -230,6 +230,11 @@ static void s390_init(ram_addr_t my_ram_size,
if (kernel_size == -1UL) {
kernel_size = load_image_targphys(kernel_filename, 0, ram_size);
}
+if (kernel_size == -1UL) {
+fprintf(stderr, qemu: could not load kernel '%s'\n,
+kernel_filename);
+exit(1);
+}
/*
* we can not rely on the ELF entry point, since up to 3.2 this
* value was 0x800 (the SALIPL loader) and it wont work. For
@@ -269,6 +274,12 @@ static void s390_init(ram_addr_t my_ram_size,
}
initrd_size = load_image_targphys(initrd_filename, initrd_offset,
ram_size - initrd_offset);
+if (initrd_size == -1UL) {
+fprintf(stderr, qemu: could not load initrd '%s'\n,
+initrd_filename);
+exit(1);
+}
+
/* we have to overwrite values in the kernel image, which are rom */
memcpy(rom_ptr(INITRD_PARM_START), initrd_offset, 8);
memcpy(rom_ptr(INITRD_PARM_SIZE), initrd_size, 8);
--
1.7.9.6
Re: [Qemu-devel] [PATCH 10/10] Enable mixemu by default, add runtime option
Il 17/04/2012 16:01, malc ha scritto: On Tue, 17 Apr 2012, Marc-Andr? Lureau wrote: Without MIXEMU, volume control on the guest doesn't work (except when volume is applied by guest emulation, in Win7 for example). Instead rely on backend volume support, or fallback on mixeng if backend doesn't support volume control, except if mixemu is disabled with QEMU_MIXEMU=0. Patches 1/9 applied, thank you. [..snip..] Hi Marc-André, can you add a note about this feature to http://wiki.qemu.org/ChangeLog/Next ? I'm confused about the relationship with --enable-mixemu and the various backends, so I didn't do it myself. Paolo
Re: [Qemu-devel] [PATCH v2 0/2] [trivial] More concise handling of tracetool-generated files
On Wed, Apr 18, 2012 at 7:15 PM, Lluís Vilanova vilan...@ac.upc.edu wrote: Some trivial changes to handle tracetool-generated files more concisely. Signed-off-by: Lluís Vilanova vilan...@ac.upc.edu --- NOTE: Applies on top of the tracetool rewrite. Changes in v2: * Only remove tracetool-generated files that were actually produced by the top-level makefile. * Dropped tracetool-gen and tracetool-ci makefile functions in favour of a 'TRACETOOL' variable to invoke the script. * Slightly reorganize command formatting to make it more readable. Lluís Vilanova (2): [trivial] Generic elimination of auto-generated files [trivial] Beautify makefile commands for generation of files with tracetool Makefile | 8 Makefile.objs | 22 +++--- Makefile.target | 4 ++-- rules.mak | 3 +++ 4 files changed, 24 insertions(+), 13 deletions(-) Thanks, will add to the next tracing pull request. (Waiting for the current pull request to get merged.) Stefan
[Qemu-devel] [PATCH 1/7] [s390] fix kernel_commandline handling
From: Christian Borntraeger borntrae...@de.ibm.com
The current handling of kernel parameters is broken. The pointer
is always valid, even if no -kernel or -append is specified.
We must check if the kernel rom address is valid instead,
otherwise qemu might segfault.
Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com
---
hw/s390-virtio.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/s390-virtio.c b/hw/s390-virtio.c
index 1ebe70d..c79784c 100644
--- a/hw/s390-virtio.c
+++ b/hw/s390-virtio.c
@@ -274,7 +274,7 @@ static void s390_init(ram_addr_t my_ram_size,
memcpy(rom_ptr(INITRD_PARM_SIZE), initrd_size, 8);
}
-if (kernel_cmdline) {
+if (rom_ptr(KERN_PARM_AREA)) {
/* we have to overwrite values in the kernel image, which are rom */
memcpy(rom_ptr(KERN_PARM_AREA), kernel_cmdline,
strlen(kernel_cmdline) + 1);
--
1.7.9.6
[Qemu-devel] [PATCH 6/7] [s390] remove default cdrom, sd-card and floppy support
From: Einar Lueck elelu...@de.ibm.com
This patch simply disables CDROM, SD card and floppy support for the
s390 virtio machine. Without this patch, a default CDROM drive would
get added which has currently no backing on s390.
Signed-off-by: Einar Lueck elelu...@de.ibm.com
Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com
---
hw/s390-virtio.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/hw/s390-virtio.c b/hw/s390-virtio.c
index d17602f..d7dc857 100644
--- a/hw/s390-virtio.c
+++ b/hw/s390-virtio.c
@@ -331,8 +331,11 @@ static QEMUMachine s390_machine = {
.alias = s390,
.desc = VirtIO based S390 machine,
.init = s390_init,
+.no_cdrom = 1,
+.no_floppy = 1,
.no_serial = 1,
.no_parallel = 1,
+.no_sdcard = 1,
.use_virtcon = 1,
.max_cpus = 255,
.is_default = 1,
--
1.7.9.6
[Qemu-devel] [PATCH 4/7] [s390] reset avail and used index on reboot
From: Jens Freimann jf...@linux.vnet.ibm.com
reset the guest vring avail/used idx fields, otherwise it's possible
that old values remain in memory which would cause a reboot to fail
with a Guest moved used index message
Signed-off-by: Jens Freimann jf...@linux.vnet.ibm.com
Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com
---
hw/s390-virtio-bus.c |7 +++
hw/s390-virtio-bus.h |2 ++
2 files changed, 9 insertions(+)
diff --git a/hw/s390-virtio-bus.c b/hw/s390-virtio-bus.c
index 74419b3..084bac1 100644
--- a/hw/s390-virtio-bus.c
+++ b/hw/s390-virtio-bus.c
@@ -225,6 +225,7 @@ void s390_virtio_device_sync(VirtIOS390Device *dev)
{
VirtIOS390Bus *bus = DO_UPCAST(VirtIOS390Bus, bus, dev-qdev.parent_bus);
ram_addr_t cur_offs;
+target_phys_addr_t idx_addr;
uint8_t num_vq;
int i;
@@ -250,6 +251,12 @@ void s390_virtio_device_sync(VirtIOS390Device *dev)
vring = s390_virtio_next_ring(bus);
virtio_queue_set_addr(dev-vdev, i, vring);
virtio_queue_set_vector(dev-vdev, i, i);
+idx_addr = virtio_queue_get_avail_addr(dev-vdev, i) +
+ VIRTIO_VRING_AVAIL_IDX_OFFS;
+stw_phys(idx_addr, 0);
+idx_addr = virtio_queue_get_used_addr(dev-vdev, i) +
+ VIRTIO_VRING_USED_IDX_OFFS;
+stw_phys(idx_addr, 0);
stq_be_phys(vq + VIRTIO_VQCONFIG_OFFS_ADDRESS, vring);
stw_be_phys(vq + VIRTIO_VQCONFIG_OFFS_NUM,
virtio_queue_get_num(dev-vdev, i));
}
diff --git a/hw/s390-virtio-bus.h b/hw/s390-virtio-bus.h
index 0e60bc0..8deec1e 100644
--- a/hw/s390-virtio-bus.h
+++ b/hw/s390-virtio-bus.h
@@ -34,6 +34,8 @@
#define VIRTIO_VQCONFIG_LEN24
#define VIRTIO_RING_LEN(TARGET_PAGE_SIZE * 3)
+#define VIRTIO_VRING_AVAIL_IDX_OFFS 2
+#define VIRTIO_VRING_USED_IDX_OFFS 2
#define S390_DEVICE_PAGES 512
#define VIRTIO_PARAM_MASK 0xff
--
1.7.9.6
[Qemu-devel] [PATCH 0/7] Fixes for s390
Alex, here are some fixes for s390 kvm. The reboot patches are fixes only and are not enough to have a fully working reboot. Additional infrastructure that completes reboot will come with a later patch series. Christian Borntraeger (3): [s390] fix kernel_commandline handling [s390] fix error handling on kernel and initrd failures [s390] dont call system_shutdown on disabled wait Einar Lueck (1): [s390] remove default cdrom, sd-card and floppy support Jens Freimann (3): [s390] reboot: reset device pages on reboot [s390] reset avail and used index on reboot [s390] support reboot for kvm on s390 hw/s390-virtio-bus.c | 14 ++ hw/s390-virtio-bus.h |2 ++ hw/s390-virtio.c | 16 +++- target-s390x/kvm.c | 15 +-- 4 files changed, 44 insertions(+), 3 deletions(-) -- 1.7.9.6
[Qemu-devel] [PATCH 5/7] [s390] support reboot for kvm on s390
From: Jens Freimann jf...@linux.vnet.ibm.com This patch adds reboot support for s390x-softmmu by calling the generic reboot support in kvm. Signed-off-by: Jens Freimann jf...@linux.vnet.ibm.com Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com --- target-s390x/kvm.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/target-s390x/kvm.c b/target-s390x/kvm.c index 2b67231..956730d 100644 --- a/target-s390x/kvm.c +++ b/target-s390x/kvm.c @@ -452,8 +452,7 @@ int kvm_arch_handle_exit(CPUS390XState *env, struct kvm_run *run) ret = handle_intercept(env); break; case KVM_EXIT_S390_RESET: -fprintf(stderr, RESET not implemented\n); -exit(1); +qemu_system_reset_request(); break; default: fprintf(stderr, Unknown KVM exit: %d\n, run-exit_reason); -- 1.7.9.6
[Qemu-devel] [PATCH 3/7] [s390] reboot: reset device pages on reboot
From: Jens Freimann jf...@linux.vnet.ibm.com
This patch fixes reboot on s390 by resetting the device
page on reboot.
Signed-off-by: Jens Freimann jf...@linux.vnet.ibm.com
Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com
---
hw/s390-virtio-bus.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/hw/s390-virtio-bus.c b/hw/s390-virtio-bus.c
index be1f5f1..74419b3 100644
--- a/hw/s390-virtio-bus.c
+++ b/hw/s390-virtio-bus.c
@@ -57,6 +57,12 @@ static ram_addr_t s390_virtio_device_num_vq(VirtIOS390Device
*dev);
/* length of VirtIO device pages */
const target_phys_addr_t virtio_size = S390_DEVICE_PAGES * TARGET_PAGE_SIZE;
+static void s390_virtio_bus_reset(void *opaque)
+{
+VirtIOS390Bus *bus = opaque;
+bus-next_ring = bus-dev_page + TARGET_PAGE_SIZE;
+}
+
VirtIOS390Bus *s390_virtio_bus_init(ram_addr_t *ram_size)
{
VirtIOS390Bus *bus;
@@ -82,6 +88,7 @@ VirtIOS390Bus *s390_virtio_bus_init(ram_addr_t *ram_size)
/* Allocate RAM for VirtIO device pages (descriptors, queues, rings) */
*ram_size += S390_DEVICE_PAGES * TARGET_PAGE_SIZE;
+qemu_register_reset(s390_virtio_bus_reset, bus);
return bus;
}
--
1.7.9.6
[Qemu-devel] [PATCH 7/7] [s390] dont call system_shutdown on disabled wait
A disabled wait usually indicates a guest problem. Dont shutdown the
guest to allow guest dumping.
Have some special cases, e.g. a quiesce disabled wait. In that case
we want to shutdown.
Long term solution might be a crashed/panic indication.
Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com
---
target-s390x/kvm.c | 12
1 file changed, 12 insertions(+)
diff --git a/target-s390x/kvm.c b/target-s390x/kvm.c
index 956730d..90aad61 100644
--- a/target-s390x/kvm.c
+++ b/target-s390x/kvm.c
@@ -407,6 +407,12 @@ static int handle_instruction(CPUS390XState *env, struct
kvm_run *run)
return 0;
}
+static bool is_special_wait_psw(CPUS390XState *env)
+{
+/* signal quiesce */
+return env-kvm_run-psw_addr == 0xfffUL;
+}
+
static int handle_intercept(CPUS390XState *env)
{
struct kvm_run *run = env-kvm_run;
@@ -420,6 +426,12 @@ static int handle_intercept(CPUS390XState *env)
r = handle_instruction(env, run);
break;
case ICPT_WAITPSW:
+if (s390_del_running_cpu(env) == 0
+is_special_wait_psw(env)) {
+qemu_system_shutdown_request();
+}
+r = EXCP_HALTED;
+break;
case ICPT_CPU_STOP:
if (s390_del_running_cpu(env) == 0) {
qemu_system_shutdown_request();
--
1.7.9.6
[Qemu-devel] buildbot failure in qemu on default_i386_rhel61
The Buildbot has detected a new failure on builder default_i386_rhel61 while building qemu. Full details are available at: http://buildbot.b1-systems.de/qemu/builders/default_i386_rhel61/builds/241 Buildbot URL: http://buildbot.b1-systems.de/qemu/ Buildslave for this Build: kraxel_rhel61_32bit Build Reason: The Nightly scheduler named 'nightly_default' triggered this build Build Source Stamp: [branch master] HEAD Blamelist: BUILD FAILED: failed test sincerely, -The Buildbot
[Qemu-devel] [PATCH 1/2] virtio: set guest_features before calling set_features callback, not after
We could drop the features parameter but that's a little more work and
it's not really needed.
Signed-off-by: Alon Levy al...@redhat.com
---
hw/virtio.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/virtio.c b/hw/virtio.c
index 064aecf..aeddc81 100644
--- a/hw/virtio.c
+++ b/hw/virtio.c
@@ -770,10 +770,10 @@ int virtio_set_features(VirtIODevice *vdev, uint32_t val)
bool bad = (val ~supported_features) != 0;
val = supported_features;
+vdev-guest_features = val;
if (vdev-set_features) {
vdev-set_features(vdev, val);
}
-vdev-guest_features = val;
return bad ? -1 : 0;
}
--
1.7.10
[Qemu-devel] [PATCH 2/2] virtio-serial-bus: query guest features after guest sets them
From: Amit Shah amit.s...@redhat.com
Currently we query the virtio features w/o even waiting
for the guest to boot up and ack features.
Do the querying after set_features has succeeded.
The check to enable guest_connected for the host to be able to write to
the guest was flawed in this way, causing all ports to be initialised
with the 'guest_connected' status to on.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
hw/virtio-serial-bus.c | 26 ++
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c
index e22940e..90b3674 100644
--- a/hw/virtio-serial-bus.c
+++ b/hw/virtio-serial-bus.c
@@ -512,6 +512,23 @@ static uint32_t get_features(VirtIODevice *vdev, uint32_t
features)
return features;
}
+static void set_features(VirtIODevice *vdev, uint32_t features)
+{
+VirtIOSerial *vser;
+VirtIOSerialPort *port;
+
+vser = DO_UPCAST(VirtIOSerial, vdev, vdev);
+port = find_port_by_id(vser, 0);
+
+if (port !use_multiport(vser)) {
+/*
+ * Allow writes to guest in this case; we have no way of
+ * knowing if a guest port is connected.
+ */
+port-guest_connected = true;
+}
+}
+
/* Guest requested config info */
static void get_config(VirtIODevice *vdev, uint8_t *config_data)
{
@@ -798,14 +815,6 @@ static int virtser_port_qdev_init(DeviceState *qdev)
return ret;
}
-if (!use_multiport(port-vser)) {
-/*
- * Allow writes to guest in this case; we have no way of
- * knowing if a guest port is connected.
- */
-port-guest_connected = true;
-}
-
port-elem.out_num = 0;
QTAILQ_INSERT_TAIL(port-vser-ports, port, next);
@@ -903,6 +912,7 @@ VirtIODevice *virtio_serial_init(DeviceState *dev,
virtio_serial_conf *conf)
mark_port_added(vser, 0);
vser-vdev.get_features = get_features;
+vser-vdev.set_features = set_features;
vser-vdev.get_config = get_config;
vser-vdev.set_config = set_config;
--
1.7.10
Re: [Qemu-devel] [RFC PATCH 8/9] pc: adjust e820 map on hot-add and hot-remove
On Sun, Apr 22, 2012 at 04:58:47PM +0300, Gleb Natapov wrote: On Thu, Apr 19, 2012 at 04:08:46PM +0200, Vasilis Liaskovitis wrote: Hotplugged memory is not persistent in the e820 memory maps. After hotplugging a memslot and rebooting the VM, the hotplugged device is not present. A possible solution is to add an e820 for the new memslot in the acpi_piix4 hot-add handler. On a reset, Seabios (see next patch in series) will enable all memory devices for which it finds an e820 entry that covers the devices's address range. On hot-remove, the acpi_piix4 handler will try to remove the e820 entry corresponding to the device. This will work when no VM reboots happen between hot-add and hot-remove, but it is not a sufficient solution in general: Seabios and GuestOS merge adjacent e820 entries on machine reboot, so the sequence hot-add/ rebootVM / hot-remove will fail to remove a corresponding e820 entry at the hot-remove phase. Why do you need this path and the next one? Bios can restore the state of memslots and build e820 map by reading mems_sts. i see, that is a simpler solution. Since qemu currently creates most ram e820map entries and passes them to seabios, I tried to follow the same approach. But your suggestion makes things easier and we don't have to worry about merged e820 entries on hot-remove. I 'll rework it. thanks, Vasilis
Re: [Qemu-devel] [PATCH 1/2] virtio: set guest_features before calling set_features callback, not after
On (Mon) 23 Apr 2012 [14:26:23], Alon Levy wrote:
We could drop the features parameter but that's a little more work and
it's not really needed.
Signed-off-by: Alon Levy al...@redhat.com
Michael, can you ack this? I'm running these through the test suite
and will send them both once everything's fine.
---
hw/virtio.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/virtio.c b/hw/virtio.c
index 064aecf..aeddc81 100644
--- a/hw/virtio.c
+++ b/hw/virtio.c
@@ -770,10 +770,10 @@ int virtio_set_features(VirtIODevice *vdev, uint32_t
val)
bool bad = (val ~supported_features) != 0;
val = supported_features;
+vdev-guest_features = val;
if (vdev-set_features) {
vdev-set_features(vdev, val);
}
-vdev-guest_features = val;
return bad ? -1 : 0;
}
--
1.7.10
Amit
Re: [Qemu-devel] [RFC 0/2]: qemu-ga: drop automatic reaper
On 20.04.2012 15:36, Luiz Capitulino wrote:
On Fri, 20 Apr 2012 14:07:16 +0200
Michal Privoznik mpriv...@redhat.com wrote:
But, I think if we tell users we'll *only* send response on error,
we should do our part to *not* send the responses, rather than relying
on them having implemented the reset mechanism to throw them away after
guest wake-up. What we could do is allow a command to set a flag, after
it reaps it's child (in the case of suspend this would be after
wake-up, for shutdown it'd basically be a no-op, but worth adding
for readability sake), to have qemu-ga not send a response. We'd
implement it similarly to how we did ga_set_response_delimited().
Fine with me. Stating that do not wait for an OK response, because none
will be sent sounds clearer than an OK response may, or may not be
emitted. Or it may be emitted when the VM resumes.
Just to make this clear: this report-only-error behavior concerns only
guest-suspend-* and guest-shutdown commands, right? Because otherwise,
if we enable such behavior for all commands (e.g. fsfreeze) I think we
are entering the world of pain.
Exactly, this would only concern the suspend and shutdown commands.
From user POV there is a huge difference between those 2 sets of
commands (suspend/shutdown on one side, the others on the other side):
- the first emits an event on qemu monitor, so libvirt can catch that
and confirm suspend/shutdown has succeeded
Oops, this is a different subject but there's a problem here. Events are just
hints, they shouldn't be your definitive source of information.
For shutdown and suspend-disk, I think that the best indication that
the command has succeeded is that the VM will successfully exit. We could
also have a special exit status code for suspend-to-disk, because the
command could run in parallel with the user powering off the VM and libvirt
wouldn't know that (and would think the VM is suspended, while it's really
powered-off).
For suspend-ram and suspend-hybrid, we're missing a 'suspended' RunState.
The event serve as a good hint and you can use it, but if it's lost for some
reason (eg. libvirt crashes before it's received) then libvirt can learn the
VM state by issuing query-status.
Now, going back to the original subject. I have to admit that I'm not sure
what's the best way to go here.
I'll try to recapitulate (for myself and for those that may be confused) I'll
be
verbose a bit.
We have two qemu-ga commands that are special: guest-shutdown and the
guest-suspend
family. They are special because they shut down the VM or suspend its
execution
(meaning that the world of qemu-ga is gone or gets completely frozen).
Today, shutdown is an asynchronous operation: qemu-ga gets the shutdown
process
started and returns to accept new commands. For qemu-ga clients, this implies:
1. errors in the shutdown operation are not reported back
2. qemu-ga doesn't block
For qemu-ga this implies having a way to automatically reap terminated
children
processes.
The guest-suspend commands do the same when executing the suspend operation,
but before they do that they need to query the VM for suspend support and
this is done by executing pm-is-supported (if available). This fact shouldn't
be visible to qemu-ga clients, but it has two internal implications:
1. The operation is half synchronous and half asynchronous
2. In order to bypass the automatic process reaper in qemu-ga when executing
pm-is-supported, we have to play tricks that makes the suspend code
more complex than it should be
We have two options:
1. Keep the current behavior (explained above, shutdown is async, suspend
is half sync half async). For libvirt this means nothing changes, for
qemu-ga this means more complex code
2. Change everything to be synchronous (this series). This essentially means:
A. errors are going to reported back
B. qemu-ga will block
C. we avoid all the dirty tricks, and qemu-ga code becomes simpler
D. In theory, this should be a compatible change due to the end of world
nature of the commands involved
A third possible option would be to have asynchronous support. But I'm not
sure whether this would fit well and how complex this would be (specially
because of fork()).
Okay, thanks for recap.
One thing that I am sure will not play nicely is old libvirt with new
qemu-ga. Here's the flow:
1. User issues virDomainPMSuspend*()
2. Libvirt chews this and calls guest-suspend-* holding up return from
API until an qemu-ga answer is read
3. Guest gets suspended
... Eventually ...
4. Guest gets resumed and qemu-ga returns {'return':{}}
5. Libvirt reads response and returns from API
So, I think if we are going to change these commands, we need to spawn a
new ones so user can distinguish if he's talking to fixed or broken
qemu-ga. Or, we can introduce query-* commands family like we already
have for the
Re: [Qemu-devel] [PATCH] qcow2: Fix refcount block allocation during qcow2_allocate_cluster_at()
Am 23.04.2012 01:35, schrieb Marcelo Tosatti: On Sun, Apr 22, 2012 at 08:18:49PM -0300, Marcelo Tosatti wrote: On Fri, Apr 20, 2012 at 03:56:01PM +0200, Kevin Wolf wrote: Refcount block allocation and refcount table growth rely on s-free_cluster_index pointing to somewhere after the current allocation. Change qcow2_allocate_cluster_at() to fulfill this assumption. Without this change it could happen that a newly allocated refcount block and the allocated data block point to the same area in the image file, causing data corruption in the long run. This fixes a bug that became first visible after commit 250196f1. Signed-off-by: Kevin Wolf kw...@redhat.com Kevin, This patch fixes explicit filesystem errors (qemu-img check also OK), but autotest is still failing, see attached screenshot. It is not reproducible without f081987ad20a8c8dc391deded55161ea8d38be5f Sorry, i meant commit 250196f19c6e7df12965d74a5073e10aba06c802 Author: Kevin Wolf kw...@redhat.com Date: Fri Mar 2 14:10:54 2012 +0100 qcow2: Reduce number of I/O requests The screenshot doesn't really give a lot of information, but let's assume that _something_ must have been corrupted... Can you try finding the corrupted file (e.g. using rpm -V) and see in which way it differs from the real one? Kevin
Re: [Qemu-devel] [RFC PATCH 0/9] ACPI memory hotplug
Hi, On Sun, Apr 22, 2012 at 05:20:59PM +0300, Gleb Natapov wrote: On Sun, Apr 22, 2012 at 05:13:27PM +0300, Avi Kivity wrote: On 04/22/2012 05:09 PM, Gleb Natapov wrote: On Sun, Apr 22, 2012 at 05:06:43PM +0300, Avi Kivity wrote: On 04/22/2012 04:56 PM, Gleb Natapov wrote: start. We will need it for migration anyway. hotplug-able memory slots i.e. initial system memory is not modeled with memslots. The concept could be generalized to include all memory though, or it could more closely follow kvm-memory slots. OK, I hope final version will allow for memory 4G to be hot-pluggable. Why is that important? Because my feeling is that people that want to use this kind of feature what to start using it with VMs smaller than 4G. Of course not all memory have to be hot unpluggable. Making first 1M or event first 128M not unpluggable make perfect sense. Can't you achieve this with -m 1G, -device dimm,size=1G,populated=true -device dimm,size=1G,populated=false? From this: (for hw/pc.c PCI hole is currently [below_4g_mem_size, 4G), so hotplugged memory should start from max(4G, above_4g_mem_size). I understand that hotpluggable memory can start from above 4G only. With the config above we will have memory hole from 1G to PCI memory hole. May be not a big problem, but I do not see technical reason for the constrain. The 440fx spec mentions: The address range from the top of main DRAM to 4 Gbytes (top of physical memory space supported by the 440FX PCIset) is normally mapped to PCI. The PMC forwards all accesses within this address range to PCI. What we probably want is that the initial memory map creation takes into account all dimms specified (both populated/unpopulated) So -m 1G, -device dimm,size=1G,populated=true -device dimm,size=1G,populated=false would create a system map with top of memory and start of PCI-hole at 2G. This may require some shifting of physical address offsets around 3.5GB-4GB - is this the minimum PCI hole allowed? E.g. if we specify 4x1GB DIMMs (onlt the first initially populated) -m 1G, -device dimm,size=1G,populated=true -device dimm,size=1G,populated=false -device dimm,size=1G,populated=false -device dimm,size=1G,populated=false we create the following memory map: dimm0: [0,1G) dimm1: [1G, 2G) dimm2: [2G, 3G) dimm3: [4G, 5G) or dimm3 is split into [3G, 3.5G) and [4G, 4.5G) does either of these options sound reasonable? thanks, - Vasilis
Re: [Qemu-devel] [PATCH 2/2] virtio-serial-bus: query guest features after guest sets them
On Mon, Apr 23, 2012 at 02:26:24PM +0300, Alon Levy wrote:
From: Amit Shah amit.s...@redhat.com
Currently we query the virtio features w/o even waiting
for the guest to boot up and ack features.
Do the querying after set_features has succeeded.
The check to enable guest_connected for the host to be able to write to
the guest was flawed in this way, causing all ports to be initialised
with the 'guest_connected' status to on.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
hw/virtio-serial-bus.c | 26 ++
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c
index e22940e..90b3674 100644
--- a/hw/virtio-serial-bus.c
+++ b/hw/virtio-serial-bus.c
@@ -512,6 +512,23 @@ static uint32_t get_features(VirtIODevice *vdev,
uint32_t features)
return features;
}
+static void set_features(VirtIODevice *vdev, uint32_t features)
+{
+VirtIOSerial *vser;
+VirtIOSerialPort *port;
+
+vser = DO_UPCAST(VirtIOSerial, vdev, vdev);
+port = find_port_by_id(vser, 0);
+
+if (port !use_multiport(vser)) {
+/*
+ * Allow writes to guest in this case; we have no way of
+ * knowing if a guest port is connected.
+ */
+port-guest_connected = true;
+}
+}
+
/* Guest requested config info */
static void get_config(VirtIODevice *vdev, uint8_t *config_data)
{
@@ -798,14 +815,6 @@ static int virtser_port_qdev_init(DeviceState *qdev)
return ret;
}
-if (!use_multiport(port-vser)) {
-/*
- * Allow writes to guest in this case; we have no way of
- * knowing if a guest port is connected.
- */
-port-guest_connected = true;
-}
-
port-elem.out_num = 0;
QTAILQ_INSERT_TAIL(port-vser-ports, port, next);
@@ -903,6 +912,7 @@ VirtIODevice *virtio_serial_init(DeviceState *dev,
virtio_serial_conf *conf)
mark_port_added(vser, 0);
vser-vdev.get_features = get_features;
+vser-vdev.set_features = set_features;
vser-vdev.get_config = get_config;
vser-vdev.set_config = set_config;
Problem is I think legacy guests don't call set_features.
A cleaner way is to check on set_status calls. Guest is not connected
until driver_ok is set anyway.
So you would do
if (!use_multiport(guest)) {
port-guest_connected = status VIRTIO_CONFIG_S_DRIVER_OK;
}
You won't need patch 1/2 in this case either.
--
1.7.10
Re: [Qemu-devel] [PATCH 1/2] virtio: set guest_features before calling set_features callback, not after
On Mon, Apr 23, 2012 at 02:26:23PM +0300, Alon Levy wrote:
We could drop the features parameter but that's a little more work and
it's not really needed.
Signed-off-by: Alon Levy al...@redhat.com
I think it's fine the way it is but if you want callbacks to use
vdev-guest_features remove the features parameter.
Having both is just confusing.
---
hw/virtio.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/virtio.c b/hw/virtio.c
index 064aecf..aeddc81 100644
--- a/hw/virtio.c
+++ b/hw/virtio.c
@@ -770,10 +770,10 @@ int virtio_set_features(VirtIODevice *vdev, uint32_t
val)
bool bad = (val ~supported_features) != 0;
val = supported_features;
+vdev-guest_features = val;
if (vdev-set_features) {
vdev-set_features(vdev, val);
}
-vdev-guest_features = val;
return bad ? -1 : 0;
}
--
1.7.10
[Qemu-devel] [PATCHv2 0/3] virtio: fix memory access races
This is a follow-up to my previous patch: it turns out that a single mb() isn't sufficient as network loss could still be triggered under stress. Patch 1 is repost of v1. The following two patches fix more races found by code inspection and comparison with vhost in kernel. After applying these patches, no more network loss was observed. Michael S. Tsirkin (3): virtio: add missing mb() on notification virtio: add missing mb() on enable notification virtio: order index/descriptor reads hw/virtio.c| 11 +++ qemu-barrier.h | 28 +--- 2 files changed, 36 insertions(+), 3 deletions(-) -- MST
[Qemu-devel] [PATCHv2 2/3] virtio: add missing mb() on enable notification
This fixes an issue dual to the one fixed by
patch 'virtio: add missing mb() on notification'
and applies on top.
In this case, to enable vq kick to exit to host,
qemu writes out used flag then reads the
avail index. if these are reordered we get a race:
host avail index read: ring is empty
guest avail index write
guest flag read: exit disabled
host used flag write: enable exit
which results in a lost exit: host will never be notified about the
avail index update. Again, happens in the field but only seems to
trigger on some specific hardware.
Insert an smp_mb barrier operation to ensure the correct ordering.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
hw/virtio.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/hw/virtio.c b/hw/virtio.c
index 6449746..def0bf1 100644
--- a/hw/virtio.c
+++ b/hw/virtio.c
@@ -209,6 +209,10 @@ void virtio_queue_set_notification(VirtQueue *vq, int
enable)
} else {
vring_used_flags_set_bit(vq, VRING_USED_F_NO_NOTIFY);
}
+if (enable) {
+/* Expose avail event/used flags before caller checks the avail idx. */
+smp_mb();
+}
}
int virtio_queue_ready(VirtQueue *vq)
@@ -694,7 +698,7 @@ static bool vring_notify(VirtIODevice *vdev, VirtQueue *vq)
uint16_t old, new;
bool v;
/* We need to expose used array entries before checking used event. */
-mb();
+smp_mb();
/* Always notify when queue is empty (when feature acknowledge) */
if (((vdev-guest_features (1 VIRTIO_F_NOTIFY_ON_EMPTY))
!vq-inuse vring_avail_idx(vq) == vq-last_avail_idx)) {
--
1.7.9.111.gf3fb0
[Qemu-devel] [PATCHv2 1/3] virtio: add missing mb() on notification
During normal operation, virtio first writes a used index
and then checks whether it should interrupt the guest
by reading guest avail index/flag values.
Guest does the reverse: writes the index/flag,
then checks the used ring.
The ordering is important: if host avail flag read bypasses the used
index write, we could in effect get this timing:
host avail flag read
guest enable interrupts: avail flag write
guest check used ring: ring is empty
host used index write
which results in a lost interrupt: guest will never be notified
about the used ring update.
This actually can happen when using kvm with an io thread,
such that the guest vcpu and qemu run on different host cpus,
and this has actually been observed in the field
(but only seems to trigger on very specific processor types)
with userspace virtio: vhost has the necessary smp_mb()
in place to prevent the regordering, so the same workload stalls
forever waiting for an interrupt with vhost=off but works
fine with vhost=on.
Insert an smp_mb barrier operation in userspace virtio to
ensure the correct ordering.
Applying this patch fixed the race condition we have observed.
Tested on x86_64. I checked the code generated by the new macro
for i386 and ppc but didn't run virtio.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
hw/virtio.c|2 ++
qemu-barrier.h | 23 ---
2 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/hw/virtio.c b/hw/virtio.c
index f805790..6449746 100644
--- a/hw/virtio.c
+++ b/hw/virtio.c
@@ -693,6 +693,8 @@ static bool vring_notify(VirtIODevice *vdev, VirtQueue *vq)
{
uint16_t old, new;
bool v;
+/* We need to expose used array entries before checking used event. */
+mb();
/* Always notify when queue is empty (when feature acknowledge) */
if (((vdev-guest_features (1 VIRTIO_F_NOTIFY_ON_EMPTY))
!vq-inuse vring_avail_idx(vq) == vq-last_avail_idx)) {
diff --git a/qemu-barrier.h b/qemu-barrier.h
index c11bb2b..f6722a8 100644
--- a/qemu-barrier.h
+++ b/qemu-barrier.h
@@ -4,7 +4,7 @@
/* Compiler barrier */
#define barrier() asm volatile( ::: memory)
-#if defined(__i386__) || defined(__x86_64__)
+#if defined(__i386__)
/*
* Because of the strongly ordered x86 storage model, wmb() is a nop
@@ -13,15 +13,31 @@
* load/stores from C code.
*/
#define smp_wmb() barrier()
+/*
+ * We use GCC builtin if it's available, as that can use
+ * mfence on 32 bit as well, e.g. if built with -march=pentium-m.
+ * However, on i386, there seem to be known bugs as recently as 4.3.
+ * */
+#if defined(_GNUC__) __GNUC__ = 4 __GNUC_MINOR__ = 4
+#define smp_mb() __sync_synchronize()
+#else
+#define smp_mb() asm volatile(lock; addl $0,0(%%esp) ::: memory)
+#endif
+
+#elif defined(__x86_64__)
+
+#define smp_wmb() barrier()
+#define smp_mb() asm volatile(mfence ::: memory)
#elif defined(_ARCH_PPC)
/*
- * We use an eieio() for a wmb() on powerpc. This assumes we don't
+ * We use an eieio() for wmb() and mb() on powerpc. This assumes we don't
* need to order cacheable and non-cacheable stores with respect to
* each other
*/
#define smp_wmb() asm volatile(eieio ::: memory)
+#define smp_mb() asm volatile(eieio ::: memory)
#else
@@ -29,9 +45,10 @@
* For (host) platforms we don't have explicit barrier definitions
* for, we use the gcc __sync_synchronize() primitive to generate a
* full barrier. This should be safe on all platforms, though it may
- * be overkill.
+ * be overkill for wmb().
*/
#define smp_wmb() __sync_synchronize()
+#define smp_mb() __sync_synchronize()
#endif
--
1.7.9.111.gf3fb0
[Qemu-devel] [Bug 986770] Re: Oops: spice configured but not active
thx, this solves problem, but patches failed, i have to edit code manually -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/986770 Title: Oops: spice configured but not active Status in QEMU: New Bug description: with latest qemu-kvm from git i have following problem: /usr/bin/kvm -daemonize -smp 4 -cpu host -vga qxl -enable-kvm -m 4096 -localtime -drive file=/home/sss/vm/win_xp/tmp_sys.img,if=virtio,media=disk,cache=none -drive file=/home/sss/vm/data.img,if=virtio,media=disk,cache=none -net nic,vlan=0,model=virtio,macaddr=6a:94:fc:2d:b9:04 -net tap,vlan=0,ifname=vtap0,script=no -usb -usbdevice tablet -name Windows XP qt -spice port=5934,addr=127.0.0.1,ipv4,playback-compression=off,disable-ticketing -monitor telnet::4448,server,nowait -device virtio-serial -chardev spicevmc,id=vdagent,name=vdagent -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 -balloon virtio qemu-system-x86_64: Oops: spice configured but not active To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/986770/+subscriptions
Re: [Qemu-devel] [RFC PATCH 0/9] ACPI memory hotplug
On 04/22/2012 05:20 PM, Gleb Natapov wrote: On Sun, Apr 22, 2012 at 05:13:27PM +0300, Avi Kivity wrote: On 04/22/2012 05:09 PM, Gleb Natapov wrote: On Sun, Apr 22, 2012 at 05:06:43PM +0300, Avi Kivity wrote: On 04/22/2012 04:56 PM, Gleb Natapov wrote: start. We will need it for migration anyway. hotplug-able memory slots i.e. initial system memory is not modeled with memslots. The concept could be generalized to include all memory though, or it could more closely follow kvm-memory slots. OK, I hope final version will allow for memory 4G to be hot-pluggable. Why is that important? Because my feeling is that people that want to use this kind of feature what to start using it with VMs smaller than 4G. Of course not all memory have to be hot unpluggable. Making first 1M or event first 128M not unpluggable make perfect sense. Can't you achieve this with -m 1G, -device dimm,size=1G,populated=true -device dimm,size=1G,populated=false? From this: (for hw/pc.c PCI hole is currently [below_4g_mem_size, 4G), so hotplugged memory should start from max(4G, above_4g_mem_size). I understand that hotpluggable memory can start from above 4G only. With the config above we will have memory hole from 1G to PCI memory hole. May be not a big problem, but I do not see technical reason for the constrain. (I don't think hotplugging below 512MB is needed, but I don't have any real data on this). 512MB looks like a reasonable limitation too, but again if there is not technical reason for having the limitation why have it? I was thinking about not having tons of 128MB slots, so we don't have a configuration that is far from reality. But maybe this thinking is too conservative. -- error compiling committee.c: too many arguments to function
[Qemu-devel] Fwd: buildbot failure in qemu on rhel6-32bit
Original Message Subject: buildbot failure in qemu on rhel6-32bit Date: Mon, 23 Apr 2012 11:10:06 +0200 From: build...@spunk.home.kraxel.org To: kra...@gmail.com The Buildbot has detected a failed build on builder rhel6-32bit while building qemu. Full details are available at: http://spunk.home.kraxel.org/bb/builders/rhel6-32bit/builds/267 Buildbot URL: http://spunk.home.kraxel.org/bb/ Buildslave for this Build: mort Build Reason: scheduler Build Source Stamp: [branch master] 3c30dd5a68e9fee6af67cfd0d14ed7520820f36a Blamelist: Alon Levy al...@redhat.com,Anthony Liguori aligu...@us.ibm.com,Benoit Canet benoit.ca...@gmail.com,Blue Swirl blauwir...@gmail.com,Eric Benard e...@eukrea.com,Gerd Hoffmann kra...@redhat.com,Hans de Goede hdego...@redhat.com,Juan Quintela quint...@redhat.com,Max Filippov jcmvb...@gmail.com,Oskar Andero oskar.and...@gmail.com,Peter Maydell peter.mayd...@linaro.org,Stefan Weil s...@weilnetz.de BUILD FAILED: failed test sincerely, -The Buildbot == log tail == CCtests/test-qmp-input-visitor.o LINK tests/test-qmp-input-visitor GTESTER tests/test-qmp-input-visitor CCtests/test-qmp-input-strict.o LINK tests/test-qmp-input-strict GTESTER tests/test-qmp-input-strict CCtests/test-qmp-commands.o GEN tests/test-qmp-marshal.c CCtests/test-qmp-marshal.o LINK tests/test-qmp-commands GTESTER tests/test-qmp-commands CCtests/test-string-input-visitor.o LINK tests/test-string-input-visitor GTESTER tests/test-string-input-visitor CCtests/test-string-output-visitor.o LINK tests/test-string-output-visitor GTESTER tests/test-string-output-visitor CCtests/test-coroutine.o LINK tests/test-coroutine GTESTER tests/test-coroutine CCtests/rtc-test.o CCtests/libqtest.o LINK tests/rtc-test CCtests/m48t59-test.o LINK tests/m48t59-test GTESTER check-qtest-i386 GTESTER check-qtest-x86_64 GTESTER check-qtest-sparc ** ERROR:tests/m48t59-test.c:203:check_time: assertion failed (ABS(t - s) = wiggle): (1335163388 = 2) GTester: last random seed: R02S09b0617c84dfaf96edd6ffd1f1964d9f make: *** [check-qtest-sparc] Error 1 == full log == [ Note: IPv6 connectivity needed to access this ] http://spunk.home.kraxel.org/bb/builders/rhel6-32bit/builds/267/steps/test/logs/stdio
Re: [Qemu-devel] Optimization for amd CPUs without amd-v using sse2, 3, 4 instructions
On Sun, Apr 22, 2012 at 12:07:40PM +0800, 陳韋任 wrote: I am using qemu to run VMs on my computer with amd chip on board. However, my computer doesn't support amd-v, so the performance of the VM is low. I do have experiences in optimization of program using sse technique. Is it possible to speed up the qemu for those x86 chips that do not support hardware virtualization using sse instructions ? If so, I would like to contribute the the qemu community. Without hardware virtualization (amd-v, for example), QEMU uses binary translation to run your VM. That says each guest instruction executed by the VM is translated into TCG ops (QEMU IR), then translated into host instructions and executed. Perhaps you have to look at tcg/i386/*, which is the TCG ops - host binary part. Or, you can look at target-i386/*, which is the guest binary - TCG ops part. Currently, guest SIMD instruction is emulated by helper functions in scalar manner. Maybe you can try to map guest SIMD into host SIMD. Or, you can use LLVM to speedup QEMU! Just let LLVM worry about how to generate SSE instructions. ;) Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
[Qemu-devel] Fwd: buildbot failure in qemu on fedora-default
Original Message Subject: buildbot failure in qemu on fedora-default Date: Mon, 23 Apr 2012 12:43:39 +0200 From: build...@spunk.home.kraxel.org To: kra...@gmail.com The Buildbot has detected a failed build on builder fedora-default while building qemu. Full details are available at: http://spunk.home.kraxel.org/bb/builders/fedora-default/builds/280 Buildbot URL: http://spunk.home.kraxel.org/bb/ Buildslave for this Build: fedora Build Reason: scheduler Build Source Stamp: [branch master] 3c30dd5a68e9fee6af67cfd0d14ed7520820f36a Blamelist: Alon Levy al...@redhat.com,Anthony Liguori aligu...@us.ibm.com,Benoit Canet benoit.ca...@gmail.com,Blue Swirl blauwir...@gmail.com,Eric Benard e...@eukrea.com,Gerd Hoffmann kra...@redhat.com,Hans de Goede hdego...@redhat.com,Juan Quintela quint...@redhat.com,Max Filippov jcmvb...@gmail.com,Oskar Andero oskar.and...@gmail.com,Peter Maydell peter.mayd...@linaro.org,Stefan Weil s...@weilnetz.de BUILD FAILED: failed compile sincerely, -The Buildbot == log tail == CClibdis/lm32-dis.o GEN config-target.h CCi386-softmmu/arch_init.o CCi386-softmmu/cpus.o GEN i386-softmmu/hmp-commands.h GEN i386-softmmu/qmp-commands-old.h CCi386-softmmu/monitor.o CCi386-softmmu/machine.o CCi386-softmmu/gdbstub.o CCi386-softmmu/balloon.o CCi386-softmmu/ioport.o CCi386-softmmu/virtio.o CCi386-softmmu/virtio-blk.o CCi386-softmmu/virtio-balloon.o CCi386-softmmu/virtio-net.o CCi386-softmmu/virtio-serial-bus.o CCi386-softmmu/virtio-scsi.o CCi386-softmmu/vhost_net.o CCi386-softmmu/vhost.o CCi386-softmmu/9pfs/virtio-9p-device.o CCi386-softmmu/kvm.o CCi386-softmmu/kvm-all.o CCi386-softmmu/vga.o CCi386-softmmu/memory.o CCi386-softmmu/savevm.o CCi386-softmmu/xen-all.o /home/buildbot/slave-spunk/fedora-default/build/xen-all.c: In function ‘xen_hvm_inject_msi’: /home/buildbot/slave-spunk/fedora-default/build/xen-all.c:132:5: error: implicit declaration of function ‘xc_hvm_inject_msi’ [-Werror=implicit-function-declaration] /home/buildbot/slave-spunk/fedora-default/build/xen-all.c:132:5: error: nested extern declaration of ‘xc_hvm_inject_msi’ [-Werror=nested-externs] cc1: all warnings being treated as errors make[1]: *** [xen-all.o] Error 1 make: *** [subdir-i386-softmmu] Error 2 == full log == [ Note: IPv6 connectivity needed to access this ] http://spunk.home.kraxel.org/bb/builders/fedora-default/builds/280/steps/compile/logs/stdio
[Qemu-devel] [Bug 986770] Re: Oops: spice configured but not active
Seems commit ad1be89948f88e89708b04ccd782456ccec3a6f0 from qemu needs to
go in to qemu-kvm.
Could you try that and report if it fixes the issue for you?
commit ad1be89948f88e89708b04ccd782456ccec3a6f0
Author: Alon Levy al...@redhat.com
Date: Wed Mar 14 20:33:37 2012 +0200
spice: fix broken initialization
Commit 1b71f7c14fab6f00c2680d4489fbee7baf796e4f moved MODULE_INIT_QOM to
way before MODULE_INIT_MACHINE, thereby breaking assumptions made in
spice-core.c which registered both a type initializer and a machine
intializer.
This fix removes the type registration, and replaces it with calling
qemu_spice_init in vl.c after command line parsing (second pass) is
done, and after timers are armed, required by spice server.
Signed-off-by: Alon Levy al...@redhat.com
Signed-off-by: Gerd Hoffmann kra...@redhat.com
diff --git a/ui/spice-core.c b/ui/spice-core.c
index 80535b6..a468524 100644
--- a/ui/spice-core.c
+++ b/ui/spice-core.c
@@ -554,7 +554,7 @@ void qemu_spice_init(void)
qemu_thread_get_self(me);
- if (!opts) {
+if (!opts) {
return;
}
port = qemu_opt_get_number(opts, port, 0);
@@ -787,10 +787,3 @@ static void spice_register_config(void)
qemu_add_opts(qemu_spice_opts);
}
machine_init(spice_register_config);
-
-static void spice_register_types(void)
-{
-qemu_spice_init();
-}
-
-type_init(spice_register_types)
diff --git a/vl.c b/vl.c
index bd95539..eeb634b 100644
--- a/vl.c
+++ b/vl.c
@@ -3369,6 +3369,11 @@ int main(int argc, char **argv, char **envp)
exit(1);
}
+#ifdef CONFIG_SPICE
+/* spice needs the timers to be initialized by this point */
+qemu_spice_init();
+#endif
+
if (icount_option (kvm_enabled() || xen_enabled())) {
fprintf(stderr, -icount is not allowed with kvm or xen\n);
exit(1);
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/986770
Title:
Oops: spice configured but not active
Status in QEMU:
New
Bug description:
with latest qemu-kvm from git i have following problem:
/usr/bin/kvm -daemonize -smp 4 -cpu host -vga qxl -enable-kvm -m 4096
-localtime -drive
file=/home/sss/vm/win_xp/tmp_sys.img,if=virtio,media=disk,cache=none -drive
file=/home/sss/vm/data.img,if=virtio,media=disk,cache=none -net
nic,vlan=0,model=virtio,macaddr=6a:94:fc:2d:b9:04 -net
tap,vlan=0,ifname=vtap0,script=no -usb -usbdevice tablet -name Windows XP qt
-spice port=5934,addr=127.0.0.1,ipv4,playback-compression=off,disable-ticketing
-monitor telnet::4448,server,nowait -device virtio-serial -chardev
spicevmc,id=vdagent,name=vdagent -device
virtserialport,chardev=vdagent,name=com.redhat.spice.0 -balloon virtio
qemu-system-x86_64: Oops: spice configured but not active
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/986770/+subscriptions
[Qemu-devel] Fwd: buildbot failure in qemu on rhel5-default
Original Message Subject: buildbot failure in qemu on rhel5-default Date: Mon, 23 Apr 2012 12:04:44 +0200 From: build...@spunk.home.kraxel.org To: kra...@gmail.com The Buildbot has detected a failed build on builder rhel5-default while building qemu. Full details are available at: http://spunk.home.kraxel.org/bb/builders/rhel5-default/builds/246 Buildbot URL: http://spunk.home.kraxel.org/bb/ Buildslave for this Build: rhel5 Build Reason: scheduler Build Source Stamp: [branch master] 3c30dd5a68e9fee6af67cfd0d14ed7520820f36a Blamelist: Alon Levy al...@redhat.com,Anthony Liguori aligu...@us.ibm.com,Benoit Canet benoit.ca...@gmail.com,Blue Swirl blauwir...@gmail.com,Eric Benard e...@eukrea.com,Gerd Hoffmann kra...@redhat.com,Hans de Goede hdego...@redhat.com,Juan Quintela quint...@redhat.com,Max Filippov jcmvb...@gmail.com,Oskar Andero oskar.and...@gmail.com,Peter Maydell peter.mayd...@linaro.org,Stefan Weil s...@weilnetz.de BUILD FAILED: failed compile sincerely, -The Buildbot == log tail == CCqemu-sockets.o CCqemu-option.o CCosdep.o CCqemu-thread-posix.o GEN trace.c CCtrace.o CCtrace/default.o CCtrace/control.o CCqemu-tool.o CCqemu-timer.o CCqemu-timer-common.o CCmain-loop.o CCnotify.o CCiohandler.o CCcutils.o CCasync.o CCcompatfd.o CCqapi/qapi-visit-core.o CCqapi/qapi-dealloc-visitor.o CCqapi/qmp-input-visitor.o qapi/qmp-input-visitor.c: In function ‘qmp_input_pop’: qapi/qmp-input-visitor.c:92: error: ‘GHashTableIter’ undeclared (first use in this function) qapi/qmp-input-visitor.c:92: error: (Each undeclared identifier is reported only once qapi/qmp-input-visitor.c:92: error: for each function it appears in.) qapi/qmp-input-visitor.c:92: error: expected ‘;’ before ‘iter’ cc1: warnings being treated as errors qapi/qmp-input-visitor.c:96: warning: implicit declaration of function ‘g_hash_table_iter_init’ qapi/qmp-input-visitor.c:96: warning: nested extern declaration of ‘g_hash_table_iter_init’ qapi/qmp-input-visitor.c:96: error: ‘iter’ undeclared (first use in this function) qapi/qmp-input-visitor.c:97: warning: implicit declaration of function ‘g_hash_table_iter_next’ qapi/qmp-input-visitor.c:97: warning: nested extern declaration of ‘g_hash_table_iter_next’ make: *** [qapi/qmp-input-visitor.o] Error 1 == full log == [ Note: IPv6 connectivity needed to access this ] http://spunk.home.kraxel.org/bb/builders/rhel5-default/builds/246/steps/compile/logs/stdio
[Qemu-devel] [PATCHv2 3/3] virtio: order index/descriptor reads
virtio has the equivalent of:
if (vq-last_avail_index != vring_avail_idx(vq)) {
read descriptor head at vq-last_avail_index;
}
In theory, processor can reorder descriptor head
read to happen speculatively before the index read.
this would trigger the following race:
host descriptor head read - reads invalid head from ring
guest writes valid descriptor head
guest writes avail index
host avail index read - observes valid index
as a result host will use an invalid head value.
This was not observed in the field by me but after
the experience with the previous two races
I think it is prudent to address this theoretical race condition.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
hw/virtio.c|5 +
qemu-barrier.h |7 ++-
2 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/hw/virtio.c b/hw/virtio.c
index def0bf1..c081e1b 100644
--- a/hw/virtio.c
+++ b/hw/virtio.c
@@ -287,6 +287,11 @@ static int virtqueue_num_heads(VirtQueue *vq, unsigned int
idx)
idx, vring_avail_idx(vq));
exit(1);
}
+/* On success, callers read a descriptor at vq-last_avail_idx.
+ * Make sure descriptor read does not bypass avail index read. */
+if (num_heads) {
+smp_rmb();
+}
return num_heads;
}
diff --git a/qemu-barrier.h b/qemu-barrier.h
index f6722a8..39aa0b0 100644
--- a/qemu-barrier.h
+++ b/qemu-barrier.h
@@ -24,10 +24,13 @@
#define smp_mb() asm volatile(lock; addl $0,0(%%esp) ::: memory)
#endif
+#define smp_rmb() smp_mb()
+
#elif defined(__x86_64__)
#define smp_wmb() barrier()
#define smp_mb() asm volatile(mfence ::: memory)
+#define smp_rmb() asm volatile(lfence ::: memory)
#elif defined(_ARCH_PPC)
@@ -38,6 +41,7 @@
*/
#define smp_wmb() asm volatile(eieio ::: memory)
#define smp_mb() asm volatile(eieio ::: memory)
+#define smp_rmb() asm volatile(eieio ::: memory)
#else
@@ -45,10 +49,11 @@
* For (host) platforms we don't have explicit barrier definitions
* for, we use the gcc __sync_synchronize() primitive to generate a
* full barrier. This should be safe on all platforms, though it may
- * be overkill for wmb().
+ * be overkill for wmb() and rmb().
*/
#define smp_wmb() __sync_synchronize()
#define smp_mb() __sync_synchronize()
+#define smp_rmb() __sync_synchronize()
#endif
--
1.7.9.111.gf3fb0
Re: [Qemu-devel] [PATCH] spice: require spice-protocol = 0.8.1
Ping? This patch doesn't seem to have made it into master yet and I don't think it was in the last spice pullreq... (patchwork id http://patchwork.ozlabs.org/patch/145294/) thanks -- PMM On 7 March 2012 14:19, Alon Levy al...@redhat.com wrote: Requiring spice-server = 0.8.2 is not enough since spice-server.pc doesn't require spice-protocol (any version). Until that is fixed upstream an explicit requirement in qemu fixes compilation broken since commit 2e1a98c9c1b90ca093278c6b43244dc46604d7b7 Author: Alon Levy al...@redhat.com Date: Fri Feb 24 23:19:30 2012 +0200 qxl: introduce QXLCookie Reported-by: Peter Maydell peter.mayd...@linaro.org Signed-off-by: Alon Levy al...@redhat.com --- configure | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/configure b/configure index a5eb832..ecdfe9a 100755 --- a/configure +++ b/configure @@ -2544,6 +2544,7 @@ EOF spice_cflags=$($pkg_config --cflags spice-protocol spice-server 2/dev/null) spice_libs=$($pkg_config --libs spice-protocol spice-server 2/dev/null) if $pkg_config --atleast-version=0.8.2 spice-server /dev/null 21 \ + $pkg_config --atleast-version=0.8.1 spice-protocol /dev/null 21 \ compile_prog $spice_cflags $spice_libs ; then spice=yes libs_softmmu=$libs_softmmu $spice_libs -- 1.7.9.1
Re: [Qemu-devel] [PATCH 1/2] virtio: set guest_features before calling set_features callback, not after
On Mon, Apr 23, 2012 at 04:06:02PM +0300, Michael S. Tsirkin wrote:
On Mon, Apr 23, 2012 at 02:26:23PM +0300, Alon Levy wrote:
We could drop the features parameter but that's a little more work and
it's not really needed.
Signed-off-by: Alon Levy al...@redhat.com
I think it's fine the way it is but if you want callbacks to use
vdev-guest_features remove the features parameter.
Having both is just confusing.
I'll just drop this, it's the same with set_status, it's arbitrary.
---
hw/virtio.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/virtio.c b/hw/virtio.c
index 064aecf..aeddc81 100644
--- a/hw/virtio.c
+++ b/hw/virtio.c
@@ -770,10 +770,10 @@ int virtio_set_features(VirtIODevice *vdev, uint32_t
val)
bool bad = (val ~supported_features) != 0;
val = supported_features;
+vdev-guest_features = val;
if (vdev-set_features) {
vdev-set_features(vdev, val);
}
-vdev-guest_features = val;
return bad ? -1 : 0;
}
--
1.7.10
Re: [Qemu-devel] [RFC 0/2]: qemu-ga: drop automatic reaper
On Mon, Apr 23, 2012 at 02:20:53PM +0200, Michal Privoznik wrote:
On 20.04.2012 15:36, Luiz Capitulino wrote:
On Fri, 20 Apr 2012 14:07:16 +0200
Michal Privoznik mpriv...@redhat.com wrote:
But, I think if we tell users we'll *only* send response on error,
we should do our part to *not* send the responses, rather than relying
on them having implemented the reset mechanism to throw them away after
guest wake-up. What we could do is allow a command to set a flag, after
it reaps it's child (in the case of suspend this would be after
wake-up, for shutdown it'd basically be a no-op, but worth adding
for readability sake), to have qemu-ga not send a response. We'd
implement it similarly to how we did ga_set_response_delimited().
Fine with me. Stating that do not wait for an OK response, because none
will be sent sounds clearer than an OK response may, or may not be
emitted. Or it may be emitted when the VM resumes.
Just to make this clear: this report-only-error behavior concerns only
guest-suspend-* and guest-shutdown commands, right? Because otherwise,
if we enable such behavior for all commands (e.g. fsfreeze) I think we
are entering the world of pain.
Exactly, this would only concern the suspend and shutdown commands.
From user POV there is a huge difference between those 2 sets of
commands (suspend/shutdown on one side, the others on the other side):
- the first emits an event on qemu monitor, so libvirt can catch that
and confirm suspend/shutdown has succeeded
Oops, this is a different subject but there's a problem here. Events are
just
hints, they shouldn't be your definitive source of information.
For shutdown and suspend-disk, I think that the best indication that
the command has succeeded is that the VM will successfully exit. We could
also have a special exit status code for suspend-to-disk, because the
command could run in parallel with the user powering off the VM and libvirt
wouldn't know that (and would think the VM is suspended, while it's really
powered-off).
For suspend-ram and suspend-hybrid, we're missing a 'suspended' RunState.
The event serve as a good hint and you can use it, but if it's lost for some
reason (eg. libvirt crashes before it's received) then libvirt can learn the
VM state by issuing query-status.
Now, going back to the original subject. I have to admit that I'm not sure
what's the best way to go here.
I'll try to recapitulate (for myself and for those that may be confused)
I'll be
verbose a bit.
We have two qemu-ga commands that are special: guest-shutdown and the
guest-suspend
family. They are special because they shut down the VM or suspend its
execution
(meaning that the world of qemu-ga is gone or gets completely frozen).
Today, shutdown is an asynchronous operation: qemu-ga gets the shutdown
process
started and returns to accept new commands. For qemu-ga clients, this
implies:
1. errors in the shutdown operation are not reported back
2. qemu-ga doesn't block
For qemu-ga this implies having a way to automatically reap terminated
children
processes.
The guest-suspend commands do the same when executing the suspend operation,
but before they do that they need to query the VM for suspend support and
this is done by executing pm-is-supported (if available). This fact
shouldn't
be visible to qemu-ga clients, but it has two internal implications:
1. The operation is half synchronous and half asynchronous
2. In order to bypass the automatic process reaper in qemu-ga when
executing
pm-is-supported, we have to play tricks that makes the suspend code
more complex than it should be
We have two options:
1. Keep the current behavior (explained above, shutdown is async, suspend
is half sync half async). For libvirt this means nothing changes, for
qemu-ga this means more complex code
2. Change everything to be synchronous (this series). This essentially
means:
A. errors are going to reported back
B. qemu-ga will block
C. we avoid all the dirty tricks, and qemu-ga code becomes simpler
D. In theory, this should be a compatible change due to the end of
world
nature of the commands involved
A third possible option would be to have asynchronous support. But I'm not
sure whether this would fit well and how complex this would be (specially
because of fork()).
Okay, thanks for recap.
One thing that I am sure will not play nicely is old libvirt with new
qemu-ga. Here's the flow:
1. User issues virDomainPMSuspend*()
2. Libvirt chews this and calls guest-suspend-* holding up return from
API until an qemu-ga answer is read
3. Guest gets suspended
... Eventually ...
4. Guest gets resumed and qemu-ga returns {'return':{}}
5. Libvirt reads response and returns from API
So, I think if we are going to
Re: [Qemu-devel] Fwd: buildbot failure in qemu on fedora-default
On Mon, 23 Apr 2012, Gerd Hoffmann wrote: Original Message Subject: buildbot failure in qemu on fedora-default Date: Mon, 23 Apr 2012 12:43:39 +0200 From: build...@spunk.home.kraxel.org To: kra...@gmail.com The Buildbot has detected a failed build on builder fedora-default while building qemu. Full details are available at: http://spunk.home.kraxel.org/bb/builders/fedora-default/builds/280 Buildbot URL: http://spunk.home.kraxel.org/bb/ Buildslave for this Build: fedora Build Reason: scheduler Build Source Stamp: [branch master] 3c30dd5a68e9fee6af67cfd0d14ed7520820f36a Blamelist: Alon Levy al...@redhat.com,Anthony Liguori aligu...@us.ibm.com,Benoit Canet benoit.ca...@gmail.com,Blue Swirl blauwir...@gmail.com,Eric Benard e...@eukrea.com,Gerd Hoffmann kra...@redhat.com,Hans de Goede hdego...@redhat.com,Juan Quintela quint...@redhat.com,Max Filippov jcmvb...@gmail.com,Oskar Andero oskar.and...@gmail.com,Peter Maydell peter.mayd...@linaro.org,Stefan Weil s...@weilnetz.de BUILD FAILED: failed compile sincerely, -The Buildbot == log tail == CClibdis/lm32-dis.o GEN config-target.h CCi386-softmmu/arch_init.o CCi386-softmmu/cpus.o GEN i386-softmmu/hmp-commands.h GEN i386-softmmu/qmp-commands-old.h CCi386-softmmu/monitor.o CCi386-softmmu/machine.o CCi386-softmmu/gdbstub.o CCi386-softmmu/balloon.o CCi386-softmmu/ioport.o CCi386-softmmu/virtio.o CCi386-softmmu/virtio-blk.o CCi386-softmmu/virtio-balloon.o CCi386-softmmu/virtio-net.o CCi386-softmmu/virtio-serial-bus.o CCi386-softmmu/virtio-scsi.o CCi386-softmmu/vhost_net.o CCi386-softmmu/vhost.o CCi386-softmmu/9pfs/virtio-9p-device.o CCi386-softmmu/kvm.o CCi386-softmmu/kvm-all.o CCi386-softmmu/vga.o CCi386-softmmu/memory.o CCi386-softmmu/savevm.o CCi386-softmmu/xen-all.o /home/buildbot/slave-spunk/fedora-default/build/xen-all.c: In function ‘xen_hvm_inject_msi’: /home/buildbot/slave-spunk/fedora-default/build/xen-all.c:132:5: error: implicit declaration of function ‘xc_hvm_inject_msi’ [-Werror=implicit-function-declaration] /home/buildbot/slave-spunk/fedora-default/build/xen-all.c:132:5: error: nested extern declaration of ‘xc_hvm_inject_msi’ [-Werror=nested-externs] cc1: all warnings being treated as errors make[1]: *** [xen-all.o] Error 1 make: *** [subdir-i386-softmmu] Error 2 know issue, pull request submitted, see http://marc.info/?l=qemu-develm=133492896812150w=2
[Qemu-devel] [PATCH v3 3/6] target-cris: Start QOM'ifying CPU init
Move VR-independent code from cpu_cris_init() into an initfn.
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-cris/cpu.c |9 +
target-cris/translate.c |2 +-
2 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/target-cris/cpu.c b/target-cris/cpu.c
index 93c7e00..c596609 100644
--- a/target-cris/cpu.c
+++ b/target-cris/cpu.c
@@ -55,6 +55,14 @@ static void cris_cpu_reset(CPUState *s)
#endif
}
+static void cris_cpu_initfn(Object *obj)
+{
+CRISCPU *cpu = CRIS_CPU(obj);
+CPUCRISState *env = cpu-env;
+
+cpu_exec_init(env);
+}
+
static void cris_cpu_class_init(ObjectClass *oc, void *data)
{
CPUClass *cc = CPU_CLASS(oc);
@@ -68,6 +76,7 @@ static const TypeInfo cris_cpu_type_info = {
.name = TYPE_CRIS_CPU,
.parent = TYPE_CPU,
.instance_size = sizeof(CRISCPU),
+.instance_init = cris_cpu_initfn,
.abstract = false,
.class_size = sizeof(CRISCPUClass),
.class_init = cris_cpu_class_init,
diff --git a/target-cris/translate.c b/target-cris/translate.c
index d3dbac2..e353ea3 100644
--- a/target-cris/translate.c
+++ b/target-cris/translate.c
@@ -3514,7 +3514,7 @@ CPUCRISState *cpu_cris_init (const char *cpu_model)
env = cpu-env;
env-pregs[PR_VR] = vr_by_name(cpu_model);
- cpu_exec_init(env);
+
cpu_reset(CPU(cpu));
qemu_init_vcpu(env);
--
1.7.7
[Qemu-devel] [PATCH v3 4/6] target-microblaze: QOM'ify CPU
Embed CPUMBState as first member of QOM MicroBlazeCPU.
Let CPUClass::reset() call cpu_state_reset() for now.
Signed-off-by: Andreas Färber afaer...@suse.de
Tested-by: Peter A. G. Crosthwaite peter.crosthwa...@petalogix.com
[AF: Updated cpu.c to include cpu-qom.h indirectly via cpu.h]
---
Makefile.target |1 +
target-microblaze/cpu-qom.h | 70 +
target-microblaze/cpu.c | 59 ++
target-microblaze/cpu.h |2 +
target-microblaze/translate.c |4 ++-
5 files changed, 135 insertions(+), 1 deletions(-)
create mode 100644 target-microblaze/cpu-qom.h
create mode 100644 target-microblaze/cpu.c
diff --git a/Makefile.target b/Makefile.target
index c928a9b..ec095ed 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -95,6 +95,7 @@ libobj-$(TARGET_ARM) += neon_helper.o iwmmxt_helper.o
libobj-$(TARGET_ARM) += cpu.o
libobj-$(TARGET_CRIS) += cpu.o
libobj-$(TARGET_LM32) += cpu.o
+libobj-$(TARGET_MICROBLAZE) += cpu.o
libobj-$(TARGET_S390X) += cpu.o
ifeq ($(TARGET_BASE_ARCH), sparc)
libobj-y += fop_helper.o cc_helper.o win_helper.o mmu_helper.o ldst_helper.o
diff --git a/target-microblaze/cpu-qom.h b/target-microblaze/cpu-qom.h
new file mode 100644
index 000..4b23303
--- /dev/null
+++ b/target-microblaze/cpu-qom.h
@@ -0,0 +1,70 @@
+/*
+ * QEMU MicroBlaze CPU
+ *
+ * Copyright (c) 2012 SUSE LINUX Products GmbH
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library 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
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
+ * http://www.gnu.org/licenses/lgpl-2.1.html
+ */
+#ifndef QEMU_MICROBLAZE_CPU_QOM_H
+#define QEMU_MICROBLAZE_CPU_QOM_H
+
+#include qemu/cpu.h
+
+#define TYPE_MICROBLAZE_CPU microblaze-cpu
+
+#define MICROBLAZE_CPU_CLASS(klass) \
+OBJECT_CLASS_CHECK(MicroBlazeCPUClass, (klass), TYPE_MICROBLAZE_CPU)
+#define MICROBLAZE_CPU(obj) \
+OBJECT_CHECK(MicroBlazeCPU, (obj), TYPE_MICROBLAZE_CPU)
+#define MICROBLAZE_CPU_GET_CLASS(obj) \
+OBJECT_GET_CLASS(MicroBlazeCPUClass, (obj), TYPE_MICROBLAZE_CPU)
+
+/**
+ * MicroBlazeCPUClass:
+ * @parent_reset: The parent class' reset handler.
+ *
+ * A MicroBlaze CPU model.
+ */
+typedef struct MicroBlazeCPUClass {
+/* private */
+CPUClass parent_class;
+/* public */
+
+void (*parent_reset)(CPUState *cpu);
+} MicroBlazeCPUClass;
+
+/**
+ * MicroBlazeCPU:
+ * @env: #CPUMBState
+ *
+ * A MicroBlaze CPU.
+ */
+typedef struct MicroBlazeCPU {
+/* private */
+CPUState parent_obj;
+/* public */
+
+CPUMBState env;
+} MicroBlazeCPU;
+
+static inline MicroBlazeCPU *mb_env_get_cpu(CPUMBState *env)
+{
+return MICROBLAZE_CPU(container_of(env, MicroBlazeCPU, env));
+}
+
+#define ENV_GET_CPU(e) CPU(mb_env_get_cpu(e))
+
+
+#endif
diff --git a/target-microblaze/cpu.c b/target-microblaze/cpu.c
new file mode 100644
index 000..21b62c6
--- /dev/null
+++ b/target-microblaze/cpu.c
@@ -0,0 +1,59 @@
+/*
+ * QEMU MicroBlaze CPU
+ *
+ * Copyright (c) 2012 SUSE LINUX Products GmbH
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library 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
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
+ * http://www.gnu.org/licenses/lgpl-2.1.html
+ */
+
+#include cpu.h
+#include qemu-common.h
+
+
+/* CPUClass::reset() */
+static void mb_cpu_reset(CPUState *s)
+{
+MicroBlazeCPU *cpu = MICROBLAZE_CPU(s);
+MicroBlazeCPUClass *mcc = MICROBLAZE_CPU_GET_CLASS(cpu);
+CPUMBState *env = cpu-env;
+
+mcc-parent_reset(s);
+
+cpu_state_reset(env);
+}
+
+static void mb_cpu_class_init(ObjectClass *oc, void *data)
+{
+CPUClass *cc = CPU_CLASS(oc);
+MicroBlazeCPUClass *mcc = MICROBLAZE_CPU_CLASS(oc);
+
+mcc-parent_reset = cc-reset;
+cc-reset = mb_cpu_reset;
+}
+
+static const TypeInfo mb_cpu_type_info = {
+.name = TYPE_MICROBLAZE_CPU,
+.parent = TYPE_CPU,
+.instance_size = sizeof(MicroBlazeCPU),
+.class_size = sizeof(MicroBlazeCPUClass),
+
Re: [Qemu-devel] [PATCH 2/2] Expose tsc deadline timer cpuid to guest
On Sat, Apr 21, 2012 at 09:23:50AM +0200, Jan Kiszka wrote: On 2012-04-20 17:36, Eduardo Habkost wrote: On Fri, Apr 20, 2012 at 05:19:17PM +0200, Jan Kiszka wrote: On 2012-04-20 17:00, Eduardo Habkost wrote: On Fri, Apr 20, 2012 at 12:12:38PM +0200, Jan Kiszka wrote: On 2012-04-19 22:03, Eduardo Habkost wrote: Jan/Avi: ping? I would like to get this ABI detail clarified so it can be implemented the right way on Qemu and KVM. My proposal is to simply add tsc-deadline to the data returned by GET_SUPPORTED_CPUID, making KVM_CAP_TSC_DEADLINE_TIMER unnecessary. IIRC, there were problems with this model to exclude that the feature gets reported this way without ensuring that in-kernel irqchip is actually activated. Please browse the discussions, it should be documented there. The flag was never added to GET_SUPPORTED_CPUID on any of the git repositories I have checked, and I don't see that being done anywhere on my KVM mailing list archives, either. So I don't see how we could have had issues with GET_SUPPORTED_CPUID, if it was never present on the code. What was present on the code before the fix, was coded that unconditinally enabled the flag even if Qemu never asked for it, and that really was wrong. GET_SUPPORTED_CPUID doesn't enable any flag: it just tells userspace that the hardware and KVM supports the feature (and, surprise, this is exactly what KVM_CAP_TSC_DEADLINE_TIMER means too, isn't it?). It's up to userspace to enable the CPUID bits according to user requirements and userspace capabilities (in other words: only when userspace knows it is safe because the in-kernel irqchip is enabled). If the above is not what GET_SUPPORTED_CPUID means, I would like to get that clarified, so I can submit an updated to KVM API documentation. Does old userspace filter out flags from GET_SUPPORTED_CPUID that it does not understand? It's even more strict than that: it only enables what was explicitly enabled on the CPU model asked by the user. But: The only exception is -cpu host, that tries to enable everything, even flags Qemu never heard of, and that is something that may require some changes on the API design (or at least documentation clarifications). Today -cpu host can't differentiate (A) a feature that KVM supports and emulate by itself and can be enabled without any support from userspace and (B) a feature that KVM supports but need support from userspace to be enabled. I am sure we will be able to find multiple examples of (B) inside the flags returned by GET_SUPPORTED_CPUID today. The problem remains that exposing TSC_DEADLINE via SUPPORTED_CPUID is wrong in case userspace doesn't select the in-kernel APIC. The kernel does _nothing_ about emulating the flag if userspace provides the APIC, so it must not expose this feature. Even if this had no practical impact (but it has: old qemu[-kvm] + userspace APIC + -cpu host), it would still be semantically broken. How is that different from any other feature that requires userspace to do the right thing to make the feature work? GET_SUPPORTED_CPUID just tells userspace that the flag is supported, but userspace has to be sure it will really work, before enabling it. In other words, I always assumed that features from the (B) group were always included on GET_SUPPORTED_CPUID, too. Yes, that risks breaking -cpu host, so we will probably need a better interface to let -cpu host know what can be enabled or not, anyway. We could decide to never add any new flag to GET_SUPPORTED_CPUID if it requires additional userspace support to work, from now on, and create new KVM_CAP_* flags for them. But, we really want to do that for almost every new CPUID feature bit in the future? Most CPU features do not depend on our in-kernel irqchips. But if there is something to simplify in retrieving information about such conditional features, let's do it. But many CPU features on GET_SUPPORTED_CPUID depend on other userspace capabilities, need userspace to do the right thing to make it work, and won't work if userspace doesn't do what's required. Why configuring the in-kernel irqchip is special? We also have the problem of defining what requires support from userspace to work means: I am not sure this has the same meaning for everybody. Many new features require userspace support only for migration, and nothing else, but some users don't need migration to work. Do those features qualify as (A), or as (B)? Works for most user also means breaks for some. And that is a bug, isn't it? It is, surely, but -cpu host is the only case where CPU features are enabled blindly, and migration is not expected to be available when using -cpu host, so in that case breaks only migration would still mean works for all (becasue except for -cpu host, Qemu won't enable any feature if it still doesn't have the proper migration support working).
[Qemu-devel] [PATCH] fix BCD mask for date (Solaris 2.5 guest hang fix)
Fix BCD mask for date. The most visible effect of this patch is
Solaris 2.5.1 doesn't hang at boot if the day of month is 21.
Signed-off-by: Artyom Tarasenko atar4q...@gmail.com
---
hw/m48t59.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/m48t59.c b/hw/m48t59.c
index 60bbb00..0c50f45 100644
--- a/hw/m48t59.c
+++ b/hw/m48t59.c
@@ -239,7 +239,7 @@ void m48t59_write (void *opaque, uint32_t addr, uint32_t
val)
break;
case 0x1FF5:
/* alarm date */
-tmp = from_bcd(val 0x1F);
+tmp = from_bcd(val 0x3F);
if (tmp != 0) {
NVRAM-alarm.tm_mday = tmp;
NVRAM-buffer[0x1FF5] = val;
@@ -310,8 +310,8 @@ void m48t59_write (void *opaque, uint32_t addr, uint32_t
val)
break;
case 0x1FFD:
case 0x07FD:
-/* date */
- tmp = from_bcd(val 0x1F);
+/* date (BCD) */
+ tmp = from_bcd(val 0x3F);
if (tmp != 0) {
get_time(NVRAM, tm);
tm.tm_mday = tmp;
--
1.7.1
[Qemu-devel] [PATCH v3 5/6] target-microblaze: QOM'ify CPU reset
Move code from cpu_state_reset() to QOM mb_cpu_reset().
Signed-off-by: Andreas Färber afaer...@suse.de
Tested-by: Peter A. G. Crosthwaite peter.crosthwa...@petalogix.com
---
target-microblaze/cpu.c | 51 -
target-microblaze/translate.c | 51 +---
2 files changed, 52 insertions(+), 50 deletions(-)
diff --git a/target-microblaze/cpu.c b/target-microblaze/cpu.c
index 21b62c6..6f00b0d 100644
--- a/target-microblaze/cpu.c
+++ b/target-microblaze/cpu.c
@@ -1,6 +1,8 @@
/*
* QEMU MicroBlaze CPU
*
+ * Copyright (c) 2009 Edgar E. Iglesias
+ * Copyright (c) 2009-2012 PetaLogix Qld Pty Ltd.
* Copyright (c) 2012 SUSE LINUX Products GmbH
*
* This library is free software; you can redistribute it and/or
@@ -29,9 +31,56 @@ static void mb_cpu_reset(CPUState *s)
MicroBlazeCPUClass *mcc = MICROBLAZE_CPU_GET_CLASS(cpu);
CPUMBState *env = cpu-env;
+if (qemu_loglevel_mask(CPU_LOG_RESET)) {
+qemu_log(CPU Reset (CPU %d)\n, env-cpu_index);
+log_cpu_state(env, 0);
+}
+
mcc-parent_reset(s);
-cpu_state_reset(env);
+memset(env, 0, offsetof(CPUMBState, breakpoints));
+tlb_flush(env, 1);
+
+/* Disable stack protector. */
+env-shr = ~0;
+
+env-pvr.regs[0] = PVR0_PVR_FULL_MASK \
+ | PVR0_USE_BARREL_MASK \
+ | PVR0_USE_DIV_MASK \
+ | PVR0_USE_HW_MUL_MASK \
+ | PVR0_USE_EXC_MASK \
+ | PVR0_USE_ICACHE_MASK \
+ | PVR0_USE_DCACHE_MASK \
+ | PVR0_USE_MMU \
+ | (0xb 8);
+env-pvr.regs[2] = PVR2_D_OPB_MASK \
+| PVR2_D_LMB_MASK \
+| PVR2_I_OPB_MASK \
+| PVR2_I_LMB_MASK \
+| PVR2_USE_MSR_INSTR \
+| PVR2_USE_PCMP_INSTR \
+| PVR2_USE_BARREL_MASK \
+| PVR2_USE_DIV_MASK \
+| PVR2_USE_HW_MUL_MASK \
+| PVR2_USE_MUL64_MASK \
+| PVR2_USE_FPU_MASK \
+| PVR2_USE_FPU2_MASK \
+| PVR2_FPU_EXC_MASK \
+| 0;
+env-pvr.regs[10] = 0x0c00; /* Default to spartan 3a dsp family. */
+env-pvr.regs[11] = PVR11_USE_MMU | (16 17);
+
+#if defined(CONFIG_USER_ONLY)
+/* start in user mode with interrupts enabled. */
+env-sregs[SR_MSR] = MSR_EE | MSR_IE | MSR_VM | MSR_UM;
+env-pvr.regs[10] = 0x0c00; /* Spartan 3a dsp. */
+#else
+env-sregs[SR_MSR] = 0;
+mmu_init(env-mmu);
+env-mmu.c_mmu = 3;
+env-mmu.c_mmu_tlb_access = 3;
+env-mmu.c_mmu_zones = 16;
+#endif
}
static void mb_cpu_class_init(ObjectClass *oc, void *data)
diff --git a/target-microblaze/translate.c b/target-microblaze/translate.c
index f4d32c8..e730c32 100644
--- a/target-microblaze/translate.c
+++ b/target-microblaze/translate.c
@@ -1900,7 +1900,7 @@ CPUMBState *cpu_mb_init (const char *cpu_model)
env = cpu-env;
cpu_exec_init(env);
-cpu_state_reset(env);
+cpu_reset(CPU(cpu));
qemu_init_vcpu(env);
set_float_rounding_mode(float_round_nearest_even, env-fp_status);
@@ -1944,54 +1944,7 @@ CPUMBState *cpu_mb_init (const char *cpu_model)
void cpu_state_reset(CPUMBState *env)
{
-if (qemu_loglevel_mask(CPU_LOG_RESET)) {
-qemu_log(CPU Reset (CPU %d)\n, env-cpu_index);
-log_cpu_state(env, 0);
-}
-
-memset(env, 0, offsetof(CPUMBState, breakpoints));
-tlb_flush(env, 1);
-
-/* Disable stack protector. */
-env-shr = ~0;
-
-env-pvr.regs[0] = PVR0_PVR_FULL_MASK \
- | PVR0_USE_BARREL_MASK \
- | PVR0_USE_DIV_MASK \
- | PVR0_USE_HW_MUL_MASK \
- | PVR0_USE_EXC_MASK \
- | PVR0_USE_ICACHE_MASK \
- | PVR0_USE_DCACHE_MASK \
- | PVR0_USE_MMU \
- | (0xb 8);
-env-pvr.regs[2] = PVR2_D_OPB_MASK \
-| PVR2_D_LMB_MASK \
-| PVR2_I_OPB_MASK \
-| PVR2_I_LMB_MASK \
-| PVR2_USE_MSR_INSTR \
-| PVR2_USE_PCMP_INSTR \
-| PVR2_USE_BARREL_MASK \
-| PVR2_USE_DIV_MASK \
-| PVR2_USE_HW_MUL_MASK \
-| PVR2_USE_MUL64_MASK \
-| PVR2_USE_FPU_MASK \
-| PVR2_USE_FPU2_MASK \
-| PVR2_FPU_EXC_MASK \
-| 0;
-env-pvr.regs[10] = 0x0c00; /* Default to spartan 3a dsp family. */
-env-pvr.regs[11] = PVR11_USE_MMU | (16 17);
-
-#if defined(CONFIG_USER_ONLY)
-/* start in user mode with interrupts
[Qemu-devel] [PATCH v3 2/6] target-cris: QOM'ify CPU reset
Move code from cpu_state_reset() into QOM cris_cpu_reset().
Let CPU init call cpu_reset().
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-cris/cpu.c | 23 ++-
target-cris/translate.c | 22 ++
2 files changed, 24 insertions(+), 21 deletions(-)
diff --git a/target-cris/cpu.c b/target-cris/cpu.c
index 784846b..93c7e00 100644
--- a/target-cris/cpu.c
+++ b/target-cris/cpu.c
@@ -1,6 +1,9 @@
/*
* QEMU CRIS CPU
*
+ * Copyright (c) 2008 AXIS Communications AB
+ * Written by Edgar E. Iglesias.
+ *
* Copyright (c) 2012 SUSE LINUX Products GmbH
*
* This library is free software; you can redistribute it and/or
@@ -20,6 +23,7 @@
#include cpu.h
#include qemu-common.h
+#include mmu.h
/* CPUClass::reset() */
@@ -28,10 +32,27 @@ static void cris_cpu_reset(CPUState *s)
CRISCPU *cpu = CRIS_CPU(s);
CRISCPUClass *ccc = CRIS_CPU_GET_CLASS(cpu);
CPUCRISState *env = cpu-env;
+uint32_t vr;
+
+if (qemu_loglevel_mask(CPU_LOG_RESET)) {
+qemu_log(CPU Reset (CPU %d)\n, env-cpu_index);
+log_cpu_state(env, 0);
+}
ccc-parent_reset(s);
-cpu_state_reset(env);
+vr = env-pregs[PR_VR];
+memset(env, 0, offsetof(CPUCRISState, breakpoints));
+env-pregs[PR_VR] = vr;
+tlb_flush(env, 1);
+
+#if defined(CONFIG_USER_ONLY)
+/* start in user mode with interrupts enabled. */
+env-pregs[PR_CCS] |= U_FLAG | I_FLAG | P_FLAG;
+#else
+cris_mmu_init(env);
+env-pregs[PR_CCS] = 0;
+#endif
}
static void cris_cpu_class_init(ObjectClass *oc, void *data)
diff --git a/target-cris/translate.c b/target-cris/translate.c
index 26c3f0b..d3dbac2 100644
--- a/target-cris/translate.c
+++ b/target-cris/translate.c
@@ -3515,7 +3515,7 @@ CPUCRISState *cpu_cris_init (const char *cpu_model)
env-pregs[PR_VR] = vr_by_name(cpu_model);
cpu_exec_init(env);
-cpu_state_reset(env);
+cpu_reset(CPU(cpu));
qemu_init_vcpu(env);
if (tcg_initialized)
@@ -3577,25 +3577,7 @@ CPUCRISState *cpu_cris_init (const char *cpu_model)
void cpu_state_reset(CPUCRISState *env)
{
- uint32_t vr;
-
- if (qemu_loglevel_mask(CPU_LOG_RESET)) {
- qemu_log(CPU Reset (CPU %d)\n, env-cpu_index);
- log_cpu_state(env, 0);
- }
-
- vr = env-pregs[PR_VR];
- memset(env, 0, offsetof(CPUCRISState, breakpoints));
- env-pregs[PR_VR] = vr;
- tlb_flush(env, 1);
-
-#if defined(CONFIG_USER_ONLY)
- /* start in user mode with interrupts enabled. */
- env-pregs[PR_CCS] |= U_FLAG | I_FLAG | P_FLAG;
-#else
- cris_mmu_init(env);
- env-pregs[PR_CCS] = 0;
-#endif
+cpu_reset(ENV_GET_CPU(env));
}
void restore_state_to_opc(CPUCRISState *env, TranslationBlock *tb, int pc_pos)
--
1.7.7
Re: [Qemu-devel] [PATCH] fix BCD mask for date (Solaris 2.5 guest hang fix)
Am 23.04.2012 16:48, schrieb Artyom Tarasenko:
Fix BCD mask for date. The most visible effect of this patch is
Solaris 2.5.1 doesn't hang at boot if the day of month is 21.
Signed-off-by: Artyom Tarasenko atar4q...@gmail.com
---
hw/m48t59.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
Blue has just added tests/m48t59-test.c - care to add a test case for
this? Ideally the patch would also indicate that it's about m48t59: .
Andreas
diff --git a/hw/m48t59.c b/hw/m48t59.c
index 60bbb00..0c50f45 100644
--- a/hw/m48t59.c
+++ b/hw/m48t59.c
@@ -239,7 +239,7 @@ void m48t59_write (void *opaque, uint32_t addr, uint32_t
val)
break;
case 0x1FF5:
/* alarm date */
-tmp = from_bcd(val 0x1F);
+tmp = from_bcd(val 0x3F);
if (tmp != 0) {
NVRAM-alarm.tm_mday = tmp;
NVRAM-buffer[0x1FF5] = val;
@@ -310,8 +310,8 @@ void m48t59_write (void *opaque, uint32_t addr, uint32_t
val)
break;
case 0x1FFD:
case 0x07FD:
-/* date */
- tmp = from_bcd(val 0x1F);
+/* date (BCD) */
+ tmp = from_bcd(val 0x3F);
if (tmp != 0) {
get_time(NVRAM, tm);
tm.tm_mday = tmp;
--
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] [PATCH] virtio-serial-bus: fix guest_connected pre-driver
guest_connected should be false before guest driver initialization, and
true after, both for multiport aware and non multiport aware drivers.
Don't set it before the guest_features are available, instead use
set_status which is called by io to VIRTIO_PCI_STATUS with
VIRTIO_CONFIG_S_DRIVER_OK by even older non multiport drivers.
Signed-off-by: Alon Levy al...@redhat.com
---
hw/virtio-serial-bus.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c
index e22940e..8788da2 100644
--- a/hw/virtio-serial-bus.c
+++ b/hw/virtio-serial-bus.c
@@ -528,6 +528,18 @@ static void set_config(VirtIODevice *vdev, const uint8_t
*config_data)
memcpy(config, config_data, sizeof(config));
}
+static void set_status(VirtIODevice *vdev, uint8_t status)
+{
+VirtIOSerial *vser;
+VirtIOSerialPort *port;
+
+vser = DO_UPCAST(VirtIOSerial, vdev, vdev);
+port = find_port_by_id(vser, 0);
+if (port !use_multiport(port-vser)) {
+port-guest_connected = status VIRTIO_CONFIG_S_DRIVER_OK;
+}
+}
+
static void virtio_serial_save(QEMUFile *f, void *opaque)
{
VirtIOSerial *s = opaque;
@@ -798,14 +810,6 @@ static int virtser_port_qdev_init(DeviceState *qdev)
return ret;
}
-if (!use_multiport(port-vser)) {
-/*
- * Allow writes to guest in this case; we have no way of
- * knowing if a guest port is connected.
- */
-port-guest_connected = true;
-}
-
port-elem.out_num = 0;
QTAILQ_INSERT_TAIL(port-vser-ports, port, next);
@@ -905,6 +909,7 @@ VirtIODevice *virtio_serial_init(DeviceState *dev,
virtio_serial_conf *conf)
vser-vdev.get_features = get_features;
vser-vdev.get_config = get_config;
vser-vdev.set_config = set_config;
+vser-vdev.set_status = set_status;
vser-qdev = dev;
--
1.7.10
[Qemu-devel] [PULL] QOM CPUState for cris and microblaze
Hello Edgar,
Ask and thou shall receive: Please pull the cris and microblaze QOM CPU
conversions.
Changes from v2:
* Rebased onto master (all preceding targets got merged in the meantime).
* target-cris/{cpu.c,cpu-qom.h}: Include cpu.h from cpu.c, not from cpu-qom.h.
* target-microblaze/{cpu.c,cpu-qom.h}: Dito.
* target-microblaze/{cpu.c,translate.c}: Do not move cpu_reset() into initfn.
It should instead go into a realizefn once available.
Cc: Edgar E. Iglesias edgar.igles...@gmail.com
The following changes since commit 3c30dd5a68e9fee6af67cfd0d14ed7520820f36a:
target-arm: Move reset handling to arm_cpu_reset (2012-04-21 18:13:22 +)
are available in the git repository at:
git://github.com/afaerber/qemu-cpu.git qom-cpu-cris+mb.v3
Andreas Färber (6):
target-cris: QOM'ify CPU
target-cris: QOM'ify CPU reset
target-cris: Start QOM'ifying CPU init
target-microblaze: QOM'ify CPU
target-microblaze: QOM'ify CPU reset
target-microblaze: QOM'ify CPU init
Makefile.target |2 +
target-cris/cpu-qom.h | 70
target-cris/cpu.c | 90 +++
target-cris/cpu.h |2 +
target-cris/translate.c | 28 ++
target-microblaze/cpu-qom.h | 70
target-microblaze/cpu.c | 119 +
target-microblaze/cpu.h |2 +
target-microblaze/translate.c | 57 ++--
9 files changed, 366 insertions(+), 74 deletions(-)
create mode 100644 target-cris/cpu-qom.h
create mode 100644 target-cris/cpu.c
create mode 100644 target-microblaze/cpu-qom.h
create mode 100644 target-microblaze/cpu.c
[Qemu-devel] [PATCH v3 6/6] target-microblaze: QOM'ify CPU init
Move code from cpu_mb_init() to a QOM initfn.
Signed-off-by: Andreas Färber afaer...@suse.de
Tested-by: Peter A. G. Crosthwaite peter.crosthwa...@petalogix.com
[AF: Leave cpu_reset() call in cpu_mb_init()]
---
target-microblaze/cpu.c | 11 +++
target-microblaze/translate.c |2 --
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/target-microblaze/cpu.c b/target-microblaze/cpu.c
index 6f00b0d..9c3b74e 100644
--- a/target-microblaze/cpu.c
+++ b/target-microblaze/cpu.c
@@ -83,6 +83,16 @@ static void mb_cpu_reset(CPUState *s)
#endif
}
+static void mb_cpu_initfn(Object *obj)
+{
+MicroBlazeCPU *cpu = MICROBLAZE_CPU(obj);
+CPUMBState *env = cpu-env;
+
+cpu_exec_init(env);
+
+set_float_rounding_mode(float_round_nearest_even, env-fp_status);
+}
+
static void mb_cpu_class_init(ObjectClass *oc, void *data)
{
CPUClass *cc = CPU_CLASS(oc);
@@ -96,6 +106,7 @@ static const TypeInfo mb_cpu_type_info = {
.name = TYPE_MICROBLAZE_CPU,
.parent = TYPE_CPU,
.instance_size = sizeof(MicroBlazeCPU),
+.instance_init = mb_cpu_initfn,
.class_size = sizeof(MicroBlazeCPUClass),
.class_init = mb_cpu_class_init,
};
diff --git a/target-microblaze/translate.c b/target-microblaze/translate.c
index e730c32..742b395 100644
--- a/target-microblaze/translate.c
+++ b/target-microblaze/translate.c
@@ -1899,10 +1899,8 @@ CPUMBState *cpu_mb_init (const char *cpu_model)
cpu = MICROBLAZE_CPU(object_new(TYPE_MICROBLAZE_CPU));
env = cpu-env;
-cpu_exec_init(env);
cpu_reset(CPU(cpu));
qemu_init_vcpu(env);
-set_float_rounding_mode(float_round_nearest_even, env-fp_status);
if (tcg_initialized)
return env;
--
1.7.7
[Qemu-devel] [Bug 965867] Re: 9p virtual file system on qemu slow
Thanks, Max. Marked as affecting upstream QEMU per the last comment. ** Changed in: qemu-kvm (Ubuntu) Status: Incomplete = Confirmed ** Also 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/965867 Title: 9p virtual file system on qemu slow Status in QEMU: New Status in “qemu-kvm” package in Ubuntu: Confirmed Bug description: Hi, The 9p virtual file system is slow. Several examples below: - Host for the first time: $ time ls bam.unsorted/ ... real0m0.084s user0m0.000s sys 0m0.028s -- Host second and following: real0m0.009s user0m0.000s sys 0m0.008s -- VM for the first time: $ time ls bam.unsorted/ real0m23.141s user0m0.064s sys 0m2.156s -- VM for the second time real0m3.643s user0m0.024s sys 0m0.424s Copy on host: $ time cp 5173T.root.bak test.tmp real0m30.346s user0m0.004s sys 0m5.324s $ ls -lahs test.tmp 2.7G -rw--- 1 oneadmin cloud 2.7G Mar 26 21:47 test.tmp --- $ copy on VM for the same file time cp 5173T.root.bak test.tmp real5m46.978s user0m0.352s sys 1m38.962s To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/965867/+subscriptions
[Qemu-devel] [PATCH v3 1/6] target-cris: QOM'ify CPU
Embed CPUCRISState as first member of QOM CRISCPU.
Let CPUClass::reset() call cpu_state_reset() for now.
Signed-off-by: Andreas Färber afaer...@suse.de
---
Makefile.target |1 +
target-cris/cpu-qom.h | 70 +++
target-cris/cpu.c | 60
target-cris/cpu.h |2 +
target-cris/translate.c |4 ++-
5 files changed, 136 insertions(+), 1 deletions(-)
create mode 100644 target-cris/cpu-qom.h
create mode 100644 target-cris/cpu.c
diff --git a/Makefile.target b/Makefile.target
index b6a9330..c928a9b 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -93,6 +93,7 @@ libobj-$(TARGET_SPARC64) += vis_helper.o
libobj-$(CONFIG_NEED_MMU) += mmu.o
libobj-$(TARGET_ARM) += neon_helper.o iwmmxt_helper.o
libobj-$(TARGET_ARM) += cpu.o
+libobj-$(TARGET_CRIS) += cpu.o
libobj-$(TARGET_LM32) += cpu.o
libobj-$(TARGET_S390X) += cpu.o
ifeq ($(TARGET_BASE_ARCH), sparc)
diff --git a/target-cris/cpu-qom.h b/target-cris/cpu-qom.h
new file mode 100644
index 000..d0e5f04
--- /dev/null
+++ b/target-cris/cpu-qom.h
@@ -0,0 +1,70 @@
+/*
+ * QEMU CRIS CPU
+ *
+ * Copyright (c) 2012 SUSE LINUX Products GmbH
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library 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
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
+ * http://www.gnu.org/licenses/lgpl-2.1.html
+ */
+#ifndef QEMU_CRIS_CPU_QOM_H
+#define QEMU_CRIS_CPU_QOM_H
+
+#include qemu/cpu.h
+
+#define TYPE_CRIS_CPU cris-cpu
+
+#define CRIS_CPU_CLASS(klass) \
+OBJECT_CLASS_CHECK(CRISCPUClass, (klass), TYPE_CRIS_CPU)
+#define CRIS_CPU(obj) \
+OBJECT_CHECK(CRISCPU, (obj), TYPE_CRIS_CPU)
+#define CRIS_CPU_GET_CLASS(obj) \
+OBJECT_GET_CLASS(CRISCPUClass, (obj), TYPE_CRIS_CPU)
+
+/**
+ * CRISCPUClass:
+ * @parent_reset: The parent class' reset handler.
+ *
+ * A CRIS CPU model.
+ */
+typedef struct CRISCPUClass {
+/* private */
+CPUClass parent_class;
+/* public */
+
+void (*parent_reset)(CPUState *cpu);
+} CRISCPUClass;
+
+/**
+ * CRISCPU:
+ * @env: #CPUCRISState
+ *
+ * A CRIS CPU.
+ */
+typedef struct CRISCPU {
+/* private */
+CPUState parent_obj;
+/* public */
+
+CPUCRISState env;
+} CRISCPU;
+
+static inline CRISCPU *cris_env_get_cpu(CPUCRISState *env)
+{
+return CRIS_CPU(container_of(env, CRISCPU, env));
+}
+
+#define ENV_GET_CPU(e) CPU(cris_env_get_cpu(e))
+
+
+#endif
diff --git a/target-cris/cpu.c b/target-cris/cpu.c
new file mode 100644
index 000..784846b
--- /dev/null
+++ b/target-cris/cpu.c
@@ -0,0 +1,60 @@
+/*
+ * QEMU CRIS CPU
+ *
+ * Copyright (c) 2012 SUSE LINUX Products GmbH
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library 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
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
+ * http://www.gnu.org/licenses/lgpl-2.1.html
+ */
+
+#include cpu.h
+#include qemu-common.h
+
+
+/* CPUClass::reset() */
+static void cris_cpu_reset(CPUState *s)
+{
+CRISCPU *cpu = CRIS_CPU(s);
+CRISCPUClass *ccc = CRIS_CPU_GET_CLASS(cpu);
+CPUCRISState *env = cpu-env;
+
+ccc-parent_reset(s);
+
+cpu_state_reset(env);
+}
+
+static void cris_cpu_class_init(ObjectClass *oc, void *data)
+{
+CPUClass *cc = CPU_CLASS(oc);
+CRISCPUClass *ccc = CRIS_CPU_CLASS(oc);
+
+ccc-parent_reset = cc-reset;
+cc-reset = cris_cpu_reset;
+}
+
+static const TypeInfo cris_cpu_type_info = {
+.name = TYPE_CRIS_CPU,
+.parent = TYPE_CPU,
+.instance_size = sizeof(CRISCPU),
+.abstract = false,
+.class_size = sizeof(CRISCPUClass),
+.class_init = cris_cpu_class_init,
+};
+
+static void cris_cpu_register_types(void)
+{
+type_register_static(cris_cpu_type_info);
+}
+
+type_init(cris_cpu_register_types)
diff --git a/target-cris/cpu.h b/target-cris/cpu.h
index 31899c2..5449cc4 100644
--- a/target-cris/cpu.h
+++ b/target-cris/cpu.h
@@ -169,6 +169,8 @@ typedef struct CPUCRISState {
void *load_info;
} CPUCRISState;
[Qemu-devel] [PATCH 1/4] block: use Error mechanism instead of -errno for block_job_create()
The block job API uses -errno return values internally and we convert
these to Error in the QMP functions. This is ugly because the Error
should be created at the point where we still have all the relevant
information. More importantly, it is hard to add new error cases to
this case since we quickly run out of -errno values without losing
information.
Go ahead an use Error directly and don't convert later.
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
block.c|4 +++-
block/stream.c | 11 +--
block_int.h| 11 +++
blockdev.c | 14 +++---
4 files changed, 18 insertions(+), 22 deletions(-)
diff --git a/block.c b/block.c
index c0c90f0..528b696 100644
--- a/block.c
+++ b/block.c
@@ -4072,11 +4072,13 @@ out:
}
void *block_job_create(const BlockJobType *job_type, BlockDriverState *bs,
- BlockDriverCompletionFunc *cb, void *opaque)
+ BlockDriverCompletionFunc *cb, void *opaque,
+ Error **errp)
{
BlockJob *job;
if (bs-job || bdrv_in_use(bs)) {
+error_set(errp, QERR_DEVICE_IN_USE, bdrv_get_device_name(bs));
return NULL;
}
bdrv_set_in_use(bs, 1);
diff --git a/block/stream.c b/block/stream.c
index 0efe1ad..0aa7083 100644
--- a/block/stream.c
+++ b/block/stream.c
@@ -280,16 +280,16 @@ static BlockJobType stream_job_type = {
.set_speed = stream_set_speed,
};
-int stream_start(BlockDriverState *bs, BlockDriverState *base,
- const char *base_id, BlockDriverCompletionFunc *cb,
- void *opaque)
+void stream_start(BlockDriverState *bs, BlockDriverState *base,
+ const char *base_id, BlockDriverCompletionFunc *cb,
+ void *opaque, Error **errp)
{
StreamBlockJob *s;
Coroutine *co;
-s = block_job_create(stream_job_type, bs, cb, opaque);
+s = block_job_create(stream_job_type, bs, cb, opaque, errp);
if (!s) {
-return -EBUSY; /* bs must already be in use */
+return; /* bs must already be in use */
}
s-base = base;
@@ -300,5 +300,4 @@ int stream_start(BlockDriverState *bs, BlockDriverState
*base,
co = qemu_coroutine_create(stream_run);
trace_stream_start(bs, base, s, co, opaque);
qemu_coroutine_enter(co, s);
-return 0;
}
diff --git a/block_int.h b/block_int.h
index 0e5a032..1557d5c 100644
--- a/block_int.h
+++ b/block_int.h
@@ -345,6 +345,7 @@ int is_windows_drive(const char *filename);
* @bs: The block
* @cb: Completion function for the job.
* @opaque: Opaque pointer value passed to @cb.
+ * @errp: A location to return DeviceInUse.
*
* Create a new long-running block device job and return it. The job
* will call @cb asynchronously when the job completes. Note that
@@ -356,7 +357,8 @@ int is_windows_drive(const char *filename);
* called from a wrapper that is specific to the job type.
*/
void *block_job_create(const BlockJobType *job_type, BlockDriverState *bs,
- BlockDriverCompletionFunc *cb, void *opaque);
+ BlockDriverCompletionFunc *cb, void *opaque,
+ Error **errp);
/**
* block_job_complete:
@@ -416,6 +418,7 @@ void block_job_cancel_sync(BlockJob *job);
* backing file if the job completes. Ignored if @base is %NULL.
* @cb: Completion function for the job.
* @opaque: Opaque pointer value passed to @cb.
+ * @errp: A location to return DeviceInUse.
*
* Start a streaming operation on @bs. Clusters that are unallocated
* in @bs, but allocated in any image between @base and @bs (both
@@ -423,8 +426,8 @@ void block_job_cancel_sync(BlockJob *job);
* streaming job, the backing file of @bs will be changed to
* @base_id in the written image and to @base in the live BlockDriverState.
*/
-int stream_start(BlockDriverState *bs, BlockDriverState *base,
- const char *base_id, BlockDriverCompletionFunc *cb,
- void *opaque);
+void stream_start(BlockDriverState *bs, BlockDriverState *base,
+ const char *base_id, BlockDriverCompletionFunc *cb,
+ void *opaque, Error **errp);
#endif /* BLOCK_INT_H */
diff --git a/blockdev.c b/blockdev.c
index 0c2440e..202c3ae 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -1095,7 +1095,6 @@ void qmp_block_stream(const char *device, bool has_base,
{
BlockDriverState *bs;
BlockDriverState *base_bs = NULL;
-int ret;
bs = bdrv_find(device);
if (!bs) {
@@ -,16 +1110,9 @@ void qmp_block_stream(const char *device, bool has_base,
}
}
-ret = stream_start(bs, base_bs, base, block_stream_cb, bs);
-if (ret 0) {
-switch (ret) {
-case -EBUSY:
-error_set(errp, QERR_DEVICE_IN_USE, device);
-return;
-default:
-error_set(errp, QERR_NOT_SUPPORTED);
-return;
-}
+stream_start(bs, base_bs, base,
[Qemu-devel] [PATCH 4/4] qemu-iotests: add block-stream with invalid speed value test
Add a test to exercise the BlockJobSpeedInvalid error code path in the
block-stream command. The 'speed' parameter allows the speed limit of
the job to be applied immediately when the job starts instead of issuing
a separate block-job-set-speed command later. If the parameter has an
invalid value we expect to get an error and the job is not created.
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
tests/qemu-iotests/030 |9 +
tests/qemu-iotests/030.out |4 ++--
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/tests/qemu-iotests/030 b/tests/qemu-iotests/030
index 978fd82..7f31841 100755
--- a/tests/qemu-iotests/030
+++ b/tests/qemu-iotests/030
@@ -147,5 +147,14 @@ class TestSetSpeed(ImageStreamingTestCase):
self.assert_no_active_streams()
+def test_set_speed_invalid(self):
+self.assert_no_active_streams()
+
+result = self.vm.qmp('block-stream', device='drive0', speed=-1)
+self.assert_qmp(result, 'error/class', 'BlockJobSpeedInvalid')
+self.assert_qmp(result, 'error/data/value', -1)
+
+self.assert_no_active_streams()
+
if __name__ == '__main__':
iotests.main(supported_fmts=['qcow2', 'qed'])
diff --git a/tests/qemu-iotests/030.out b/tests/qemu-iotests/030.out
index 8d7e996..89968f3 100644
--- a/tests/qemu-iotests/030.out
+++ b/tests/qemu-iotests/030.out
@@ -1,5 +1,5 @@
-...
+
--
-Ran 3 tests
+Ran 4 tests
OK
--
1.7.9.5
Re: [Qemu-devel] [PATCH 1/4] block: use Error mechanism instead of -errno for block_job_create()
Il 23/04/2012 17:39, Stefan Hajnoczi ha scritto:
+stream_start(bs, base_bs, base, block_stream_cb, bs, errp);
+if (error_is_set(errp)) {
+return;
}
This needs to be
Error *local_err = NULL;
stream_start(bs, base_bs, base, block_stream_cb, bs, local_err);
if (local_err) {
error_propagate(errp, local_err);
return;
}
Otherwise looks good.
Paolo
Re: [Qemu-devel] [PATCH v2] qemu-iotests: ignore fragmentation information for qed
Am 23.04.2012 11:14, schrieb Dong Xu Wang: We added image fragmentation statistics functions to qemu-img several days ago, those patches will cause ./check -qed failed. This patch will ignore fragmentation statistics information of qed format, and then ./check -qed will work. Signed-off-by: Dong Xu Wang wdon...@linux.vnet.ibm.com Thanks, applied to the block branch. Kevin
[Qemu-devel] [PATCH 0/4] block: add optional 'speed' parameter to block-stream
This series is based on Luiz' latest QMP pull request at git://repo.or.cz/qemu/qmp-unstable.git queue/qmp (d980956d5bfa9f4fd56c00a0b168c3c0f67bc0d2). This dependency is necessary because this series conflicts with the block_stream - block-stream rename. Eric Blake raised concerns about the inability to start block jobs with a speed limit. Current the user needs to follow up the block-stream command with block-job-set-speed. There is a window of time while the new block job is running but block-job-set-speed has not been processed yet. This series adds an optional 'speed' parameter to block-stream so streaming can be started with a speed limit that takes effect immediately. I considered several other approaches, including adding a default_block_job_speed field to BlockDriverState but ultimately the cleanest solution is to pass in a speed parameter on job creation. This way we do not change semantics of existing commands, we only add an optional parameter. We also do not need to add state to BlockDriverState, which is already huge and messy. Stefan Hajnoczi (4): block: use Error mechanism instead of -errno for block_job_create() block: use Error mechanism instead of -errno for block_job_set_speed() block: add 'speed' optional parameter to block-stream qemu-iotests: add block-stream with invalid speed value test block.c| 35 +++ block/stream.c | 18 +- block_int.h| 19 +-- blockdev.c | 22 +++--- hmp-commands.hx|4 ++-- hmp.c |4 +++- qapi-schema.json |7 ++- qerror.c |4 qerror.h |3 +++ qmp-commands.hx|2 +- tests/qemu-iotests/030 |9 + tests/qemu-iotests/030.out |4 ++-- 12 files changed, 86 insertions(+), 45 deletions(-) -- 1.7.9.5
Re: [Qemu-devel] [PATCH 1/4] block: use Error mechanism instead of -errno for block_job_create()
On Mon, Apr 23, 2012 at 4:42 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 23/04/2012 17:39, Stefan Hajnoczi ha scritto:
+ stream_start(bs, base_bs, base, block_stream_cb, bs, errp);
+ if (error_is_set(errp)) {
+ return;
}
This needs to be
Error *local_err = NULL;
stream_start(bs, base_bs, base, block_stream_cb, bs, local_err);
if (local_err) {
error_propagate(errp, local_err);
return;
}
Otherwise looks good.
Right, thanks for spotting this. Perhaps we should assert(errp) at
some point so we don't need to do this dance every time. Ignoring
errors is usually a bad idea...
For now I'll do the local_err thing.
Stefan
Re: [Qemu-devel] [PATCH 2/4] block: use Error mechanism instead of -errno for block_job_set_speed()
Il 23/04/2012 17:39, Stefan Hajnoczi ha scritto:
There are at least two different errors that can occur in
block_job_set_speed(): the job might not support setting speeds or the
value might be invalid.
Use the Error mechanism to report the error where it occurs. This patch
adds the new BlockJobSpeedInvalid QError. The error is specific to
block job speeds so we can add a speed argument to block-stream in the
future and clearly identify the invalid parameter.
Cc: Luiz Capitulino lcapitul...@redhat.com
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
block.c | 17 ++---
block/stream.c |6 +++---
block_int.h |5 +++--
blockdev.c |4 +---
qapi-schema.json |1 +
qerror.c |4
qerror.h |3 +++
7 files changed, 25 insertions(+), 15 deletions(-)
diff --git a/block.c b/block.c
index 528b696..7056d8c 100644
--- a/block.c
+++ b/block.c
@@ -4103,18 +4103,21 @@ void block_job_complete(BlockJob *job, int ret)
bdrv_set_in_use(bs, 0);
}
-int block_job_set_speed(BlockJob *job, int64_t value)
+void block_job_set_speed(BlockJob *job, int64_t value, Error **errp)
{
-int rc;
+Error *local_error = NULL;
if (!job-job_type-set_speed) {
-return -ENOTSUP;
+error_set(errp, QERR_NOT_SUPPORTED);
+return;
}
-rc = job-job_type-set_speed(job, value);
-if (rc == 0) {
-job-speed = value;
+job-job_type-set_speed(job, value, local_error);
+if (error_is_set(local_error)) {
+error_propagate(errp, local_error);
+return;
}
-return rc;
+
+job-speed = value;
I don't think this is the right place to add Error handling. By doing
it at QAPI entry points we can reuse an existing error such as
QERR_INVALID_PARAMETER_VALUE.
If we need to introduce a specific error for each parameter type, we
will end up with N errors per function.
Luiz, what do you think?
Paolo
}
void block_job_cancel(BlockJob *job)
diff --git a/block/stream.c b/block/stream.c
index 0aa7083..f0486a3 100644
--- a/block/stream.c
+++ b/block/stream.c
@@ -263,15 +263,15 @@ retry:
block_job_complete(s-common, ret);
}
-static int stream_set_speed(BlockJob *job, int64_t value)
+static void stream_set_speed(BlockJob *job, int64_t value, Error **errp)
{
StreamBlockJob *s = container_of(job, StreamBlockJob, common);
if (value 0) {
-return -EINVAL;
+error_set(errp, QERR_BLOCK_JOB_SPEED_INVALID, value);
+return;
}
ratelimit_set_speed(s-limit, value / BDRV_SECTOR_SIZE);
-return 0;
}
static BlockJobType stream_job_type = {
diff --git a/block_int.h b/block_int.h
index 1557d5c..6015c27 100644
--- a/block_int.h
+++ b/block_int.h
@@ -78,7 +78,7 @@ typedef struct BlockJobType {
const char *job_type;
/** Optional callback for job types that support setting a speed limit */
-int (*set_speed)(BlockJob *job, int64_t value);
+void (*set_speed)(BlockJob *job, int64_t value, Error **errp);
} BlockJobType;
/**
@@ -374,11 +374,12 @@ void block_job_complete(BlockJob *job, int ret);
* block_job_set_speed:
* @job: The job to set the speed for.
* @speed: The new value
+ * @errp: A location to return NotSupported or BlockJobSpeedInvalid.
*
* Set a rate-limiting parameter for the job; the actual meaning may
* vary depending on the job type.
*/
-int block_job_set_speed(BlockJob *job, int64_t value);
+void block_job_set_speed(BlockJob *job, int64_t value, Error **errp);
/**
* block_job_cancel:
diff --git a/blockdev.c b/blockdev.c
index 202c3ae..c484259 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -1143,9 +1143,7 @@ void qmp_block_job_set_speed(const char *device,
int64_t value, Error **errp)
return;
}
-if (block_job_set_speed(job, value) 0) {
-error_set(errp, QERR_NOT_SUPPORTED);
-}
+block_job_set_speed(job, value, errp);
}
void qmp_block_job_cancel(const char *device, Error **errp)
diff --git a/qapi-schema.json b/qapi-schema.json
index 6499895..d0d4f693 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -1596,6 +1596,7 @@
#
# Returns: Nothing on success
# If the job type does not support throttling, NotSupported
+# If the speed value is invalid, BlockJobSpeedInvalid
# If streaming is not active on this device, DeviceNotActive
#
# Since: 1.1
diff --git a/qerror.c b/qerror.c
index 96fbe71..6aee606 100644
--- a/qerror.c
+++ b/qerror.c
@@ -64,6 +64,10 @@ static const QErrorStringTable qerror_table[] = {
.desc = Block format '%(format)' used by device '%(name)' does
not support feature '%(feature)',
},
{
+.error_fmt = QERR_BLOCK_JOB_SPEED_INVALID,
+.desc = Block job speed value '%(value)' is invalid,
+},
+{
.error_fmt =
Re: [Qemu-devel] [PATCH 3/4] block: add 'speed' optional parameter to block-stream
Il 23/04/2012 17:39, Stefan Hajnoczi ha scritto:
+/* Only set speed when necessary to avoid NotSupported error */
+if (speed != 0) {
+Error *local_err = NULL;
+
+block_job_set_speed(job, speed, local_err);
+if (error_is_set(local_err)) {
+bs-job = NULL;
+g_free(job);
+bdrv_set_in_use(bs, 0);
+error_propagate(errp, local_err);
+return NULL;
+}
+}
Similarly, here I would instead modify the QAPI entry point, and add a
call to qmp_block_job_set_speed there.
In patch 2, qmp_block_job_set_speed can parse the return code to
distinguish ENOTSUP from EINVAL.
Paolo
Re: [Qemu-devel] [PATCH 4/4] qemu-iotests: add block-stream with invalid speed value test
Il 23/04/2012 17:39, Stefan Hajnoczi ha scritto:
+
+result = self.vm.qmp('block-stream', device='drive0', speed=-1)
+self.assert_qmp(result, 'error/class', 'BlockJobSpeedInvalid')
+self.assert_qmp(result, 'error/data/value', -1)
Apart from /me disagreeing on introducing a new error value, for which
I'll defer to Luiz, looks good.
Paolo
Re: [Qemu-devel] [PATCH] virtio-serial-bus: fix guest_connected pre-driver
On Mon, Apr 23, 2012 at 06:23:10PM +0300, Alon Levy wrote:
guest_connected should be false before guest driver initialization, and
true after, both for multiport aware and non multiport aware drivers.
Don't set it before the guest_features are available, instead use
set_status which is called by io to VIRTIO_PCI_STATUS with
VIRTIO_CONFIG_S_DRIVER_OK by even older non multiport drivers.
Signed-off-by: Alon Levy al...@redhat.com
Acked-by: Michael S. Tsirkin m...@redhat.com
---
hw/virtio-serial-bus.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c
index e22940e..8788da2 100644
--- a/hw/virtio-serial-bus.c
+++ b/hw/virtio-serial-bus.c
@@ -528,6 +528,18 @@ static void set_config(VirtIODevice *vdev, const uint8_t
*config_data)
memcpy(config, config_data, sizeof(config));
}
+static void set_status(VirtIODevice *vdev, uint8_t status)
+{
+VirtIOSerial *vser;
+VirtIOSerialPort *port;
+
+vser = DO_UPCAST(VirtIOSerial, vdev, vdev);
+port = find_port_by_id(vser, 0);
+if (port !use_multiport(port-vser)) {
+port-guest_connected = status VIRTIO_CONFIG_S_DRIVER_OK;
+}
+}
+
static void virtio_serial_save(QEMUFile *f, void *opaque)
{
VirtIOSerial *s = opaque;
@@ -798,14 +810,6 @@ static int virtser_port_qdev_init(DeviceState *qdev)
return ret;
}
-if (!use_multiport(port-vser)) {
-/*
- * Allow writes to guest in this case; we have no way of
- * knowing if a guest port is connected.
- */
-port-guest_connected = true;
-}
-
port-elem.out_num = 0;
QTAILQ_INSERT_TAIL(port-vser-ports, port, next);
@@ -905,6 +909,7 @@ VirtIODevice *virtio_serial_init(DeviceState *dev,
virtio_serial_conf *conf)
vser-vdev.get_features = get_features;
vser-vdev.get_config = get_config;
vser-vdev.set_config = set_config;
+vser-vdev.set_status = set_status;
vser-qdev = dev;
--
1.7.10
Re: [Qemu-devel] [PATCH v6 5/5] FreeSCALE i.MX31 support: KZM-ARM11-01 evaluation board
On 23 April 2012 00:31, Peter Chubb peter.ch...@nicta.com.au wrote:
Board support for Kyoto Micro's KZM-ARM11-01, an evaluation board built
around the FreeScale i.MX31.
+ if (serial_hds[3]) {
+ serial_mm_init(address_space_mem, KZM_FPGA, 0,
+ qdev_get_gpio_in(dev, 52),
+ 14745600, serial_hds[3],
+ DEVICE_NATIVE_ENDIAN);
+ }
+ if (serial_hds[2]) { /* touchscreen */
+ serial_mm_init(address_space_mem, KZM_FPGA+0x10, 0,
+ qdev_get_gpio_in(dev, 52),
+ 14745600, serial_hds[2],
+ DEVICE_NATIVE_ENDIAN);
+ }
Are these two devices really on the same IRQ?
-- PMM
Re: [Qemu-devel] setjmp and longjmp in qemu
On 23 April 2012 01:06, Xin Tong xerox.time.t...@gmail.com wrote: QEMU uses this very hard to understand setjmp and longjmp to handle asynchronous interrupt. what i do not understand is that say one of the process is doing a context switching in the guest os. tlb_flush gets called, what if in the middle of tlb_flush, an interrupt comes in ( longjmp executed ). We don't do a longjmp for interrupts. Mostly they're used for exceptions (eg memory access faulted), so they only happen in fairly restricted contexts where it is safe to longjmp. -- PMM
[Qemu-devel] [PATCH 3/4] block: add 'speed' optional parameter to block-stream
Allow streaming operations to be started with an initial speed limit.
This eliminates the window of time between starting streaming and
issuing block-job-set-speed. Users should use the new optional 'speed'
parameter instead so that speed limits are in effect immediately when
the job starts.
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
block.c | 18 --
block/stream.c |5 +++--
block_int.h |9 ++---
blockdev.c |6 --
hmp-commands.hx |4 ++--
hmp.c|4 +++-
qapi-schema.json |6 +-
qmp-commands.hx |2 +-
8 files changed, 40 insertions(+), 14 deletions(-)
diff --git a/block.c b/block.c
index 7056d8c..e3c1483 100644
--- a/block.c
+++ b/block.c
@@ -4072,8 +4072,8 @@ out:
}
void *block_job_create(const BlockJobType *job_type, BlockDriverState *bs,
- BlockDriverCompletionFunc *cb, void *opaque,
- Error **errp)
+ int64_t speed, BlockDriverCompletionFunc *cb,
+ void *opaque, Error **errp)
{
BlockJob *job;
@@ -4089,6 +4089,20 @@ void *block_job_create(const BlockJobType *job_type,
BlockDriverState *bs,
job-cb= cb;
job-opaque= opaque;
bs-job = job;
+
+/* Only set speed when necessary to avoid NotSupported error */
+if (speed != 0) {
+Error *local_err = NULL;
+
+block_job_set_speed(job, speed, local_err);
+if (error_is_set(local_err)) {
+bs-job = NULL;
+g_free(job);
+bdrv_set_in_use(bs, 0);
+error_propagate(errp, local_err);
+return NULL;
+}
+}
return job;
}
diff --git a/block/stream.c b/block/stream.c
index f0486a3..dc15fb6 100644
--- a/block/stream.c
+++ b/block/stream.c
@@ -281,13 +281,14 @@ static BlockJobType stream_job_type = {
};
void stream_start(BlockDriverState *bs, BlockDriverState *base,
- const char *base_id, BlockDriverCompletionFunc *cb,
+ const char *base_id, int64_t speed,
+ BlockDriverCompletionFunc *cb,
void *opaque, Error **errp)
{
StreamBlockJob *s;
Coroutine *co;
-s = block_job_create(stream_job_type, bs, cb, opaque, errp);
+s = block_job_create(stream_job_type, bs, speed, cb, opaque, errp);
if (!s) {
return; /* bs must already be in use */
}
diff --git a/block_int.h b/block_int.h
index 6015c27..bffca35 100644
--- a/block_int.h
+++ b/block_int.h
@@ -343,6 +343,7 @@ int is_windows_drive(const char *filename);
* block_job_create:
* @job_type: The class object for the newly-created job.
* @bs: The block
+ * @speed: The maximum speed, in bytes per second, or 0 for unlimited.
* @cb: Completion function for the job.
* @opaque: Opaque pointer value passed to @cb.
* @errp: A location to return DeviceInUse.
@@ -357,8 +358,8 @@ int is_windows_drive(const char *filename);
* called from a wrapper that is specific to the job type.
*/
void *block_job_create(const BlockJobType *job_type, BlockDriverState *bs,
- BlockDriverCompletionFunc *cb, void *opaque,
- Error **errp);
+ int64_t speed, BlockDriverCompletionFunc *cb,
+ void *opaque, Error **errp);
/**
* block_job_complete:
@@ -417,6 +418,7 @@ void block_job_cancel_sync(BlockJob *job);
* flatten the whole backing file chain onto @bs.
* @base_id: The file name that will be written to @bs as the new
* backing file if the job completes. Ignored if @base is %NULL.
+ * @speed: The maximum speed, in bytes per second, or 0 for unlimited.
* @cb: Completion function for the job.
* @opaque: Opaque pointer value passed to @cb.
* @errp: A location to return DeviceInUse.
@@ -428,7 +430,8 @@ void block_job_cancel_sync(BlockJob *job);
* @base_id in the written image and to @base in the live BlockDriverState.
*/
void stream_start(BlockDriverState *bs, BlockDriverState *base,
- const char *base_id, BlockDriverCompletionFunc *cb,
+ const char *base_id, int64_t speed,
+ BlockDriverCompletionFunc *cb,
void *opaque, Error **errp);
#endif /* BLOCK_INT_H */
diff --git a/blockdev.c b/blockdev.c
index c484259..f18af16 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -1091,7 +1091,8 @@ static void block_stream_cb(void *opaque, int ret)
}
void qmp_block_stream(const char *device, bool has_base,
- const char *base, Error **errp)
+ const char *base, bool has_speed,
+ int64_t speed, Error **errp)
{
BlockDriverState *bs;
BlockDriverState *base_bs = NULL;
@@ -1110,7 +,8 @@ void qmp_block_stream(const char *device, bool has_base,
}
}
-stream_start(bs, base_bs, base, block_stream_cb, bs, errp);
+stream_start(bs, base_bs, base,
[Qemu-devel] [PATCH 2/4] block: use Error mechanism instead of -errno for block_job_set_speed()
There are at least two different errors that can occur in
block_job_set_speed(): the job might not support setting speeds or the
value might be invalid.
Use the Error mechanism to report the error where it occurs. This patch
adds the new BlockJobSpeedInvalid QError. The error is specific to
block job speeds so we can add a speed argument to block-stream in the
future and clearly identify the invalid parameter.
Cc: Luiz Capitulino lcapitul...@redhat.com
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
block.c | 17 ++---
block/stream.c |6 +++---
block_int.h |5 +++--
blockdev.c |4 +---
qapi-schema.json |1 +
qerror.c |4
qerror.h |3 +++
7 files changed, 25 insertions(+), 15 deletions(-)
diff --git a/block.c b/block.c
index 528b696..7056d8c 100644
--- a/block.c
+++ b/block.c
@@ -4103,18 +4103,21 @@ void block_job_complete(BlockJob *job, int ret)
bdrv_set_in_use(bs, 0);
}
-int block_job_set_speed(BlockJob *job, int64_t value)
+void block_job_set_speed(BlockJob *job, int64_t value, Error **errp)
{
-int rc;
+Error *local_error = NULL;
if (!job-job_type-set_speed) {
-return -ENOTSUP;
+error_set(errp, QERR_NOT_SUPPORTED);
+return;
}
-rc = job-job_type-set_speed(job, value);
-if (rc == 0) {
-job-speed = value;
+job-job_type-set_speed(job, value, local_error);
+if (error_is_set(local_error)) {
+error_propagate(errp, local_error);
+return;
}
-return rc;
+
+job-speed = value;
}
void block_job_cancel(BlockJob *job)
diff --git a/block/stream.c b/block/stream.c
index 0aa7083..f0486a3 100644
--- a/block/stream.c
+++ b/block/stream.c
@@ -263,15 +263,15 @@ retry:
block_job_complete(s-common, ret);
}
-static int stream_set_speed(BlockJob *job, int64_t value)
+static void stream_set_speed(BlockJob *job, int64_t value, Error **errp)
{
StreamBlockJob *s = container_of(job, StreamBlockJob, common);
if (value 0) {
-return -EINVAL;
+error_set(errp, QERR_BLOCK_JOB_SPEED_INVALID, value);
+return;
}
ratelimit_set_speed(s-limit, value / BDRV_SECTOR_SIZE);
-return 0;
}
static BlockJobType stream_job_type = {
diff --git a/block_int.h b/block_int.h
index 1557d5c..6015c27 100644
--- a/block_int.h
+++ b/block_int.h
@@ -78,7 +78,7 @@ typedef struct BlockJobType {
const char *job_type;
/** Optional callback for job types that support setting a speed limit */
-int (*set_speed)(BlockJob *job, int64_t value);
+void (*set_speed)(BlockJob *job, int64_t value, Error **errp);
} BlockJobType;
/**
@@ -374,11 +374,12 @@ void block_job_complete(BlockJob *job, int ret);
* block_job_set_speed:
* @job: The job to set the speed for.
* @speed: The new value
+ * @errp: A location to return NotSupported or BlockJobSpeedInvalid.
*
* Set a rate-limiting parameter for the job; the actual meaning may
* vary depending on the job type.
*/
-int block_job_set_speed(BlockJob *job, int64_t value);
+void block_job_set_speed(BlockJob *job, int64_t value, Error **errp);
/**
* block_job_cancel:
diff --git a/blockdev.c b/blockdev.c
index 202c3ae..c484259 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -1143,9 +1143,7 @@ void qmp_block_job_set_speed(const char *device, int64_t
value, Error **errp)
return;
}
-if (block_job_set_speed(job, value) 0) {
-error_set(errp, QERR_NOT_SUPPORTED);
-}
+block_job_set_speed(job, value, errp);
}
void qmp_block_job_cancel(const char *device, Error **errp)
diff --git a/qapi-schema.json b/qapi-schema.json
index 6499895..d0d4f693 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -1596,6 +1596,7 @@
#
# Returns: Nothing on success
# If the job type does not support throttling, NotSupported
+# If the speed value is invalid, BlockJobSpeedInvalid
# If streaming is not active on this device, DeviceNotActive
#
# Since: 1.1
diff --git a/qerror.c b/qerror.c
index 96fbe71..6aee606 100644
--- a/qerror.c
+++ b/qerror.c
@@ -64,6 +64,10 @@ static const QErrorStringTable qerror_table[] = {
.desc = Block format '%(format)' used by device '%(name)' does
not support feature '%(feature)',
},
{
+.error_fmt = QERR_BLOCK_JOB_SPEED_INVALID,
+.desc = Block job speed value '%(value)' is invalid,
+},
+{
.error_fmt = QERR_BUS_NO_HOTPLUG,
.desc = Bus '%(bus)' does not support hotplugging,
},
diff --git a/qerror.h b/qerror.h
index 5c23c1f..e239ef1 100644
--- a/qerror.h
+++ b/qerror.h
@@ -67,6 +67,9 @@ QError *qobject_to_qerror(const QObject *obj);
#define QERR_BLOCK_FORMAT_FEATURE_NOT_SUPPORTED \
{ 'class': 'BlockFormatFeatureNotSupported', 'data': { 'format': %s,
'name': %s, 'feature': %s } }
+#define QERR_BLOCK_JOB_SPEED_INVALID \
+{ 'class': 'BlockJobSpeedInvalid', 'data': { 'value':
Re: [Qemu-devel] [PATCH v6 2/5] Implement i.MX31 Clock Control Module
On 23 April 2012 00:31, Peter Chubb peter.ch...@nicta.com.au wrote:
+ /* Frequencies precalculated on register changes */
+ uint32_t pll_refclk_freq;
+ uint32_t mcu_clk_freq;
+ uint32_t hsp_clk_freq;
+ uint32_t ipg_clk_freq;
+} IMXCCMState;
+
+static const VMStateDescription vmstate_imx_ccm = {
+ .name = imx-ccm,
+ .version_id = 1,
+ .minimum_version_id = 1,
+ .minimum_version_id_old = 1,
+ .fields = (VMStateField[]) {
+ VMSTATE_UINT32(ccmr, IMXCCMState),
+ VMSTATE_UINT32(pdr0, IMXCCMState),
+ VMSTATE_UINT32(pdr1, IMXCCMState),
+ VMSTATE_UINT32(mpctl, IMXCCMState),
+ VMSTATE_UINT32(spctl, IMXCCMState),
+ VMSTATE_UINT32_ARRAY(cgr, IMXCCMState, 3),
+ VMSTATE_UINT32(pmcr0, IMXCCMState),
+ VMSTATE_UINT32(pmcr1, IMXCCMState),
+ VMSTATE_UINT32(pll_refclk_freq, IMXCCMState),
+ VMSTATE_UINT32(mcu_clk_freq, IMXCCMState),
+ VMSTATE_UINT32(hsp_clk_freq, IMXCCMState),
+ VMSTATE_UINT32(ipg_clk_freq, IMXCCMState),
Rather than having the *_clk_freq saved and loaded
in the vmstate, I think it would be nicer to have a
post-load-hook that called update_clocks().
+static uint32_t calc_pll(uint32_t pllreg, uint32_t base_freq)
+{
+ int32_t mfn = MFN(pllreg); /* Numerator */
+ uint32_t mfi = MFI(pllreg); /* Integer part */
+ uint32_t mfd = 1 + MFD(pllreg); /* Denominator */
+ uint32_t pd = 1 + PD(pllreg); /* Pre-divider */
+
+ if (mfi 5) {
+ mfi = 5;
+ }
+ /* mfn is 10-bit signed twos-complement */
+ mfn -= (mfn 0x200);
What is this calculation supposed to do? It doesn't
convert a 10-bit signed twos-complement number into an
int32_t, unless I'm confused... Also, it's a rather
opaque way to write mfn = 0x200;.
-- PMM
[Qemu-devel] [PULL 0/2]: QMP queue
Two small QMP/QAPI fixes. The changes (since 3c30dd5a68e9fee6af67cfd0d14ed7520820f36a) are available in the following repository: git://repo.or.cz/qemu/qmp-unstable.git queue/qmp NODA, Kai (1): qapi: g_hash_table_find() instead of GHashTableIter. Stefan Hajnoczi (1): qmp: make block job command naming consistent qapi-schema.json | 15 --- qapi/qmp-input-visitor.c | 25 + qmp-commands.hx |6 +++--- tests/qemu-iotests/030 | 12 ++-- 4 files changed, 34 insertions(+), 24 deletions(-)
[Qemu-devel] [PULL 2/2] qapi: g_hash_table_find() instead of GHashTableIter.
From: NODA, Kai noda...@gmail.com
GHashTableIter was first introduced in glib 2.16.
This patch removes it in favor of older g_hash_table_find()
for better compatibility with RHEL5.
Signed-off-by: NODA, Kai noda...@gmail.com
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
qapi/qmp-input-visitor.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/qapi/qmp-input-visitor.c b/qapi/qmp-input-visitor.c
index 74386b9..4cdc47d 100644
--- a/qapi/qmp-input-visitor.c
+++ b/qapi/qmp-input-visitor.c
@@ -87,20 +87,29 @@ static void qmp_input_push(QmpInputVisitor *qiv, QObject
*obj, Error **errp)
qiv-nb_stack++;
}
+/** Only for qmp_input_pop. */
+static gboolean always_true(gpointer key, gpointer val, gpointer user_pkey)
+{
+*(const char **)user_pkey = (const char *)key;
+return TRUE;
+}
+
static void qmp_input_pop(QmpInputVisitor *qiv, Error **errp)
{
-GHashTableIter iter;
-gpointer key;
+assert(qiv-nb_stack 0);
-if (qiv-strict qiv-stack[qiv-nb_stack - 1].h) {
-g_hash_table_iter_init(iter, qiv-stack[qiv-nb_stack - 1].h);
-if (g_hash_table_iter_next(iter, key, NULL)) {
-error_set(errp, QERR_QMP_EXTRA_MEMBER, (char *) key);
+if (qiv-strict) {
+GHashTable * const top_ht = qiv-stack[qiv-nb_stack - 1].h;
+if (top_ht) {
+if (g_hash_table_size(top_ht)) {
+const char *key;
+g_hash_table_find(top_ht, always_true, key);
+error_set(errp, QERR_QMP_EXTRA_MEMBER, key);
+}
+g_hash_table_unref(top_ht);
}
-g_hash_table_unref(qiv-stack[qiv-nb_stack - 1].h);
}
-assert(qiv-nb_stack 0);
qiv-nb_stack--;
}
--
1.7.9.2.384.g4a92a
[Qemu-devel] [PULL 1/2] qmp: make block job command naming consistent
From: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
The block streaming and job commands used '_' instead of '-' for reasons
of compatibility with libvirt, which already included support for the
'_' naming. However, the semantics of block_job_cancel have changed and
libvirt now needs to handle the new semantics.
Since the old semantics were never in a QEMU release we can still rename
the commands to use '-' instead of '_'. Libvirt is also happy because
the new name can be used to distinguish QEMU binaries that support the
latest block-job-cancel semantics from those that include a downstream
block_job_cancel command.
Therefore, let's apply the QAPI/QMP naming rules to the block streaming
and job commands. QEMU 1.1 will be the first release with these
commands so no upstream users can break.
Note that HMP commands are left with '_' because that is the convention
there.
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
Reviewed-by: Eric Blake ebl...@redhat.com
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
qapi-schema.json | 15 ---
qmp-commands.hx|6 +++---
tests/qemu-iotests/030 | 12 ++--
3 files changed, 17 insertions(+), 16 deletions(-)
diff --git a/qapi-schema.json b/qapi-schema.json
index ace55f3..6499895 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -1548,7 +1548,8 @@
'data': { 'device': 'str', 'bps': 'int', 'bps_rd': 'int', 'bps_wr': 'int',
'iops': 'int', 'iops_rd': 'int', 'iops_wr': 'int' } }
-# @block_stream:
+##
+# @block-stream:
#
# Copy data from a backing file into a block device.
#
@@ -1556,7 +1557,7 @@
# backing file has been copied. This command returns immediately once
streaming
# has started. The status of ongoing block streaming operations can be checked
# with query-block-jobs. The operation can be stopped before it has completed
-# using the block_job_cancel command.
+# using the block-job-cancel command.
#
# If a base file is specified then sectors are not copied from that base file
and
# its backing chain. When streaming completes the image file will have the
base
@@ -1578,10 +1579,10 @@
#
# Since: 1.1
##
-{ 'command': 'block_stream', 'data': { 'device': 'str', '*base': 'str' } }
+{ 'command': 'block-stream', 'data': { 'device': 'str', '*base': 'str' } }
##
-# @block_job_set_speed:
+# @block-job-set-speed:
#
# Set maximum speed for a background block operation.
#
@@ -1599,11 +1600,11 @@
#
# Since: 1.1
##
-{ 'command': 'block_job_set_speed',
+{ 'command': 'block-job-set-speed',
'data': { 'device': 'str', 'value': 'int' } }
##
-# @block_job_cancel:
+# @block-job-cancel:
#
# Stop an active block streaming operation.
#
@@ -1629,7 +1630,7 @@
#
# Since: 1.1
##
-{ 'command': 'block_job_cancel', 'data': { 'device': 'str' } }
+{ 'command': 'block-job-cancel', 'data': { 'device': 'str' } }
##
# @ObjectTypeInfo:
diff --git a/qmp-commands.hx b/qmp-commands.hx
index c09ee85..f972332 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -687,19 +687,19 @@ Example:
EQMP
{
-.name = block_stream,
+.name = block-stream,
.args_type = device:B,base:s?,
.mhandler.cmd_new = qmp_marshal_input_block_stream,
},
{
-.name = block_job_set_speed,
+.name = block-job-set-speed,
.args_type = device:B,value:o,
.mhandler.cmd_new = qmp_marshal_input_block_job_set_speed,
},
{
-.name = block_job_cancel,
+.name = block-job-cancel,
.args_type = device:B,
.mhandler.cmd_new = qmp_marshal_input_block_job_cancel,
},
diff --git a/tests/qemu-iotests/030 b/tests/qemu-iotests/030
index 1faf984..978fd82 100755
--- a/tests/qemu-iotests/030
+++ b/tests/qemu-iotests/030
@@ -49,7 +49,7 @@ class TestSingleDrive(ImageStreamingTestCase):
def test_stream(self):
self.assert_no_active_streams()
-result = self.vm.qmp('block_stream', device='drive0')
+result = self.vm.qmp('block-stream', device='drive0')
self.assert_qmp(result, 'return', {})
completed = False
@@ -68,7 +68,7 @@ class TestSingleDrive(ImageStreamingTestCase):
'image file not fully populated after streaming')
def test_device_not_found(self):
-result = self.vm.qmp('block_stream', device='nonexistent')
+result = self.vm.qmp('block-stream', device='nonexistent')
self.assert_qmp(result, 'error/class', 'DeviceNotFound')
class TestStreamStop(ImageStreamingTestCase):
@@ -90,14 +90,14 @@ class TestStreamStop(ImageStreamingTestCase):
self.assert_no_active_streams()
-result = self.vm.qmp('block_stream', device='drive0')
+result = self.vm.qmp('block-stream', device='drive0')
self.assert_qmp(result, 'return', {})
time.sleep(1)
events = self.vm.get_qmp_events(wait=False)
self.assertEqual(events, [],
Re: [Qemu-devel] [PATCH v6 3/5] FreeSCALE i.MX31 support: Timers
On 23 April 2012 00:31, Peter Chubb peter.ch...@nicta.com.au wrote: Implement the timers on the FreeScale i.MX31 SoC. This is not a complete implementation, but gives enough for Linux to boot and run. In particular external triggers, which are not useful under QEMU, are not implemented. Reviewed-by: Peter Maydell peter.mayd...@linaro.org (though I didn't look too hard at the details...) -- PMM
Re: [Qemu-devel] [PATCH] sheepdog: implement SD_OP_FLUSH_VDI operation
At Mon, 23 Apr 2012 08:08:46 +0200, Christoph Hellwig wrote: On Fri, Apr 20, 2012 at 12:15:36PM -0700, MORITA Kazutaka wrote: His patch sets the SD_FLAG_CMD_CACHE flag for writes only when the user selects cache=writeback or cache=none. If SD_FLAG_CMD_CACHE is not set in the request, Sheepdog servers are forced to flush the cache like FUA commands. Ok, I missed that part and it thus seems ok. What still sems missing is error handling in case the sheepdog cluster doesn't actually support the new flag. What happens if cache=none is specified with a cluster not actually supporting it? Remember that cache=none is the default for many management frontends to qemu. SD_FLAG_CMD_CACHE is ignored in the older version of Sheepdog, so, even if we specify cache=writeback or cache=none, the data is written with O_DSYNC always and cannot be cached in the server's page cache or volatile disk cache either. I think it is safe. It seems that there is another version problem with this patch; bdrv_co_flush_to_disk() results in error with the older Sheepdog which doesn't support SD_OP_FLUSH_VDI. The simple fix is to increment SD_PROTO_VER and prevent the newer qemu from connecting to the older Sheepdog cluster, I think. Thanks, Kazutaka
Re: [Qemu-devel] [PATCH 2/2] Expose tsc deadline timer cpuid to guest
On 2012-04-23 16:48, Eduardo Habkost wrote: Trying to summarize the points above: Groups (A) and (B) are: A) a feature that KVM supports and emulate by itself and can be enabled by userspace blindly, without requiring any additional userspace code to work. B) a feature that KVM supports but need support from userspace to work. We have to differentiate those two groups somehow, otherwise -cpu host will always risk being unstable (in case we can't identify group (B) and end up enabling a feature that will break) or useless (if group (A) is considered always empty). (If you think this two-group model is not sufficient, please let me know.) Note that I am discussing two things above: - Whether GET_SUPPORTED_CPUID should expose only features from group (A), or group (B) too. - One problem here is that today GET_SUPPORTED_CPUIDS have many examples of (B) features inside it. Should we stop doing that? We have exactly two for the category that I was concerned about: TSC deadline and X2APIC. The latter is already exposed unconditionally, even if the kernel does not provide emulation. So, you are right, TSC deadline is not a new scenario. - TSC-deadline is the first case where we are _not_ doing that. It is the first CPU feature in KVM that can be enabled by userspace (as long as userspace does the proper setup), but it's not included on GET_SUPPORTED_CPUIDs. - Even the current documentation implies that group (B) is included: This ioctl returns x86 cpuid features which are supported by both the hardware and kvm. Userspace can use the information returned by this ioctl to construct cpuid information (for KVM_SET_CPUID2) that is consistent with hardware, kernel, and userspace capabilities, and ^^ with user requirements (for example, the user may wish to constrain cpuid to emulate older hardware, or for feature consistency across a cluster). In the specific case of TSC-deadline, I consider Qemu knowing that TSC-deadline can be enabled only if in-kernel irqchip is enabled as an userpace capability. - How to precisely define the groups (A) and (B)? - requires additional code only if migration is required qualifies as (B) or (A)? - requires in-kernel irqchip to be enabled to work qualifies as (B), doesn't it? My problem is that features like X2APIC and TSC deadline are exposed by the kernel without contributing to them (if in-kernel irqchip is off). However, that was how I interpreted this GET_SUPPORTED_CPUID. In fact, it is used as kernel or hardware does not _prevent_ already. And in that sense, it's ok to enable even features that are not in kernel/hardware hands. We should point out this fact in the documentation. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH] qapi: g_hash_table_find() instead of GHashTableIter.
On Sat, 21 Apr 2012 22:41:27 +0900
NODA, Kai noda...@gmail.com wrote:
From: NODA, Kai noda...@gmail.com
GHashTableIter was first introduced in glib 2.16.
This patch removes it in favor of older g_hash_table_find()
for better compatibility with RHEL5.
Signed-off-by: NODA, Kai noda...@gmail.com
Forgot to say this was applied, but you probably now that by now :)
---
Added sign-off. Sorry for inconvenience!
qapi/qmp-input-visitor.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/qapi/qmp-input-visitor.c b/qapi/qmp-input-visitor.c
index 74386b9..4cdc47d 100644
--- a/qapi/qmp-input-visitor.c
+++ b/qapi/qmp-input-visitor.c
@@ -87,20 +87,29 @@ static void qmp_input_push(QmpInputVisitor *qiv, QObject
*obj, Error **errp)
qiv-nb_stack++;
}
+/** Only for qmp_input_pop. */
+static gboolean always_true(gpointer key, gpointer val, gpointer user_pkey)
+{
+*(const char **)user_pkey = (const char *)key;
+return TRUE;
+}
+
static void qmp_input_pop(QmpInputVisitor *qiv, Error **errp)
{
-GHashTableIter iter;
-gpointer key;
+assert(qiv-nb_stack 0);
-if (qiv-strict qiv-stack[qiv-nb_stack - 1].h) {
-g_hash_table_iter_init(iter, qiv-stack[qiv-nb_stack - 1].h);
-if (g_hash_table_iter_next(iter, key, NULL)) {
-error_set(errp, QERR_QMP_EXTRA_MEMBER, (char *) key);
+if (qiv-strict) {
+GHashTable * const top_ht = qiv-stack[qiv-nb_stack - 1].h;
+if (top_ht) {
+if (g_hash_table_size(top_ht)) {
+const char *key;
+g_hash_table_find(top_ht, always_true, key);
+error_set(errp, QERR_QMP_EXTRA_MEMBER, key);
+}
+g_hash_table_unref(top_ht);
}
-g_hash_table_unref(qiv-stack[qiv-nb_stack - 1].h);
}
-assert(qiv-nb_stack 0);
qiv-nb_stack--;
}
Re: [Qemu-devel] [PATCH] fix BCD mask for date (Solaris 2.5 guest hang fix)
On Mon, Apr 23, 2012 at 5:18 PM, Andreas Färber afaer...@suse.de wrote:
Am 23.04.2012 16:48, schrieb Artyom Tarasenko:
Fix BCD mask for date. The most visible effect of this patch is
Solaris 2.5.1 doesn't hang at boot if the day of month is 21.
Signed-off-by: Artyom Tarasenko atar4q...@gmail.com
---
hw/m48t59.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
Blue has just added tests/m48t59-test.c - care to add a test case for
this?
It looks like BCD math is already covered in the check_time test.
I'm not sure though how m48t59 is initialized there.
Ideally the patch would also indicate that it's about m48t59: .
You mean, like [PATCH,m48t59] fix BCD mask for date (Solaris 2.5
guest hang fix) ?
Can resend if it's necessary.
Artyom
Andreas
diff --git a/hw/m48t59.c b/hw/m48t59.c
index 60bbb00..0c50f45 100644
--- a/hw/m48t59.c
+++ b/hw/m48t59.c
@@ -239,7 +239,7 @@ void m48t59_write (void *opaque, uint32_t addr, uint32_t
val)
break;
case 0x1FF5:
/* alarm date */
- tmp = from_bcd(val 0x1F);
+ tmp = from_bcd(val 0x3F);
if (tmp != 0) {
NVRAM-alarm.tm_mday = tmp;
NVRAM-buffer[0x1FF5] = val;
@@ -310,8 +310,8 @@ void m48t59_write (void *opaque, uint32_t addr, uint32_t
val)
break;
case 0x1FFD:
case 0x07FD:
- /* date */
- tmp = from_bcd(val 0x1F);
+ /* date (BCD) */
+ tmp = from_bcd(val 0x3F);
if (tmp != 0) {
get_time(NVRAM, tm);
tm.tm_mday = tmp;
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
Regards,
Artyom Tarasenko
solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu
Re: [Qemu-devel] [PATCH 1/2] target-arm: Change cpu_arm_init() return type to ARMCPU
On 20 April 2012 18:39, Andreas Färber afaer...@suse.de wrote: Make cpu_arm_init() return a QOM ARMCPU, so that we don't need to obtain an ARMCPU through arm_env_get_cpu() in machine init code. This requires to adjust the inclusion site of cpu-qom.h and in turn, forward-looking, to homogenize its include order. cpu_init() must still return a CPUARMState for backwards and cross-target compatibility, so adjust the cpu_init macro. So is the plan that all boards should eventually move over to calling cpu_arm_init() rather than cpu_init() ? -- PMM
Re: [Qemu-devel] [PATCH] fix BCD mask for date (Solaris 2.5 guest hang fix)
On Mon, Apr 23, 2012 at 14:48, Artyom Tarasenko atar4q...@gmail.com wrote:
Fix BCD mask for date. The most visible effect of this patch is
Solaris 2.5.1 doesn't hang at boot if the day of month is 21.
Thanks, applied.
Signed-off-by: Artyom Tarasenko atar4q...@gmail.com
---
hw/m48t59.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/m48t59.c b/hw/m48t59.c
index 60bbb00..0c50f45 100644
--- a/hw/m48t59.c
+++ b/hw/m48t59.c
@@ -239,7 +239,7 @@ void m48t59_write (void *opaque, uint32_t addr, uint32_t
val)
break;
case 0x1FF5:
/* alarm date */
- tmp = from_bcd(val 0x1F);
+ tmp = from_bcd(val 0x3F);
if (tmp != 0) {
NVRAM-alarm.tm_mday = tmp;
NVRAM-buffer[0x1FF5] = val;
@@ -310,8 +310,8 @@ void m48t59_write (void *opaque, uint32_t addr, uint32_t
val)
break;
case 0x1FFD:
case 0x07FD:
- /* date */
- tmp = from_bcd(val 0x1F);
+ /* date (BCD) */
+ tmp = from_bcd(val 0x3F);
if (tmp != 0) {
get_time(NVRAM, tm);
tm.tm_mday = tmp;
--
1.7.1
[Qemu-devel] [PATCH v4 1/4] target-sh4: QOM'ify CPU
Embed CPUSH4State as first member of SuperHCPU.
Let CPUClass::reset() call cpu_state_reset() for now.
Signed-off-by: Andreas Färber afaer...@suse.de
Reviewed-by: Peter Maydell peter.mayd...@linaro.org
---
Makefile.target|1 +
target-sh4/cpu-qom.h | 70
target-sh4/cpu.c | 60 +
target-sh4/cpu.h |2 +
target-sh4/translate.c |4 ++-
5 files changed, 136 insertions(+), 1 deletions(-)
create mode 100644 target-sh4/cpu-qom.h
create mode 100644 target-sh4/cpu.c
diff --git a/Makefile.target b/Makefile.target
index ec095ed..69f93f0 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -97,6 +97,7 @@ libobj-$(TARGET_CRIS) += cpu.o
libobj-$(TARGET_LM32) += cpu.o
libobj-$(TARGET_MICROBLAZE) += cpu.o
libobj-$(TARGET_S390X) += cpu.o
+libobj-$(TARGET_SH4) += cpu.o
ifeq ($(TARGET_BASE_ARCH), sparc)
libobj-y += fop_helper.o cc_helper.o win_helper.o mmu_helper.o ldst_helper.o
libobj-y += cpu.o
diff --git a/target-sh4/cpu-qom.h b/target-sh4/cpu-qom.h
new file mode 100644
index 000..c41164a
--- /dev/null
+++ b/target-sh4/cpu-qom.h
@@ -0,0 +1,70 @@
+/*
+ * QEMU SuperH CPU
+ *
+ * Copyright (c) 2012 SUSE LINUX Products GmbH
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library 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
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
+ * http://www.gnu.org/licenses/lgpl-2.1.html
+ */
+#ifndef QEMU_SUPERH_CPU_QOM_H
+#define QEMU_SUPERH_CPU_QOM_H
+
+#include qemu/cpu.h
+
+#define TYPE_SUPERH_CPU superh-cpu
+
+#define SUPERH_CPU_CLASS(klass) \
+OBJECT_CLASS_CHECK(SuperHCPUClass, (klass), TYPE_SUPERH_CPU)
+#define SUPERH_CPU(obj) \
+OBJECT_CHECK(SuperHCPU, (obj), TYPE_SUPERH_CPU)
+#define SUPERH_CPU_GET_CLASS(obj) \
+OBJECT_GET_CLASS(SuperHCPUClass, (obj), TYPE_SUPERH_CPU)
+
+/**
+ * SuperHCPUClass:
+ * @parent_reset: The parent class' reset handler.
+ *
+ * A SuperH CPU model.
+ */
+typedef struct SuperHCPUClass {
+/* private */
+CPUClass parent_class;
+/* public */
+
+void (*parent_reset)(CPUState *cpu);
+} SuperHCPUClass;
+
+/**
+ * SuperHCPU:
+ * @env: #CPUSH4State
+ *
+ * A SuperH CPU.
+ */
+typedef struct SuperHCPU {
+/* private */
+CPUState parent_obj;
+/* public */
+
+CPUSH4State env;
+} SuperHCPU;
+
+static inline SuperHCPU *sh_env_get_cpu(CPUSH4State *env)
+{
+return SUPERH_CPU(container_of(env, SuperHCPU, env));
+}
+
+#define ENV_GET_CPU(e) CPU(sh_env_get_cpu(e))
+
+
+#endif
diff --git a/target-sh4/cpu.c b/target-sh4/cpu.c
new file mode 100644
index 000..e110f98
--- /dev/null
+++ b/target-sh4/cpu.c
@@ -0,0 +1,60 @@
+/*
+ * QEMU SuperH CPU
+ *
+ * Copyright (c) 2012 SUSE LINUX Products GmbH
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library 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
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
+ * http://www.gnu.org/licenses/lgpl-2.1.html
+ */
+
+#include cpu.h
+#include qemu-common.h
+
+
+/* CPUClass::reset() */
+static void superh_cpu_reset(CPUState *s)
+{
+SuperHCPU *cpu = SUPERH_CPU(s);
+SuperHCPUClass *scc = SUPERH_CPU_GET_CLASS(cpu);
+CPUSH4State *env = cpu-env;
+
+scc-parent_reset(s);
+
+cpu_state_reset(env);
+}
+
+static void superh_cpu_class_init(ObjectClass *oc, void *data)
+{
+CPUClass *cc = CPU_CLASS(oc);
+SuperHCPUClass *scc = SUPERH_CPU_CLASS(oc);
+
+scc-parent_reset = cc-reset;
+cc-reset = superh_cpu_reset;
+}
+
+static const TypeInfo superh_cpu_type_info = {
+.name = TYPE_SUPERH_CPU,
+.parent = TYPE_CPU,
+.instance_size = sizeof(SuperHCPU),
+.abstract = false,
+.class_size = sizeof(SuperHCPUClass),
+.class_init = superh_cpu_class_init,
+};
+
+static void superh_cpu_register_types(void)
+{
+type_register_static(superh_cpu_type_info);
+}
+
+type_init(superh_cpu_register_types)
diff --git a/target-sh4/cpu.h b/target-sh4/cpu.h
index 965536d..b6768f1 100644
--- a/target-sh4/cpu.h
+++
[Qemu-devel] [PATCH v4 0/4] QOM'ify SuperH CPU
Hello, This series converts the SuperH CPU to QOM. Subclasses, the feature flags bugfix and its consequences throughout code as well as the controversial QOM'ification of the SH7750 SoC are postponed. I tested it using the sh-test-0.2 test image. Available at: git://github.com/afaerber/qemu-cpu.git qom-cpu-sh4.v4 https://github.com/afaerber/qemu-cpu/commits/qom-cpu-sh4.v4 Note: Depends on cris and microblaze series wrt Makefile.target; branch is for testing and cherry-picking, not for pulling. Cf. http://wiki.qemu.org/Features/QOM/CPU#Status Regards, Andreas Cc: Aurélien Jarno aurel...@aurel32.net Cc: Peter Maydell peter.mayd...@linaro.org v3 - v4: * Move cpu_reset() to a new realizefn instead of the initfn (inspired by Peter). * Drop feature flags reset bugfix and its follow-up patches for now. v2 - v3: * #include cpu.h rather than cpu-qom.h in cpu.c to get consistent include order. * Replace duplicated typedef in cpu.h by relocating #include of cpu-qom.h. v1 - v2: * Rebased, now ordered after microblaze QOM'ification. * Fix LGPLv2.1 license notice (Library vs. Lesser bug in German GNU webpage). * Split QOM'ification into three steps to show code movements. * Drop subclasses and SoC QOM'ification for now. Andreas Färber (4): target-sh4: QOM'ify CPU target-sh4: QOM'ify CPU reset target-sh4: Start QOM'ifying CPU init target-sh4: Introduce realizefn for SuperHCPU Makefile.target|1 + target-sh4/cpu-qom.h | 73 +++ target-sh4/cpu.c | 98 target-sh4/cpu.h |2 + target-sh4/translate.c | 29 ++ 5 files changed, 179 insertions(+), 24 deletions(-) create mode 100644 target-sh4/cpu-qom.h create mode 100644 target-sh4/cpu.c -- 1.7.7
[Qemu-devel] [PATCH v4 2/4] target-sh4: QOM'ify CPU reset
Move code from cpu_state_reset() to QOM superh_cpu_reset().
Signed-off-by: Andreas Färber afaer...@suse.de
Reviewed-by: Peter Maydell peter.mayd...@linaro.org
---
target-sh4/cpu.c | 21 -
target-sh4/translate.c | 22 ++
2 files changed, 22 insertions(+), 21 deletions(-)
diff --git a/target-sh4/cpu.c b/target-sh4/cpu.c
index e110f98..84d4672 100644
--- a/target-sh4/cpu.c
+++ b/target-sh4/cpu.c
@@ -1,6 +1,7 @@
/*
* QEMU SuperH CPU
*
+ * Copyright (c) 2005 Samuel Tardieu
* Copyright (c) 2012 SUSE LINUX Products GmbH
*
* This library is free software; you can redistribute it and/or
@@ -29,9 +30,27 @@ static void superh_cpu_reset(CPUState *s)
SuperHCPUClass *scc = SUPERH_CPU_GET_CLASS(cpu);
CPUSH4State *env = cpu-env;
+if (qemu_loglevel_mask(CPU_LOG_RESET)) {
+qemu_log(CPU Reset (CPU %d)\n, env-cpu_index);
+log_cpu_state(env, 0);
+}
+
scc-parent_reset(s);
-cpu_state_reset(env);
+memset(env, 0, offsetof(CPUSH4State, breakpoints));
+tlb_flush(env, 1);
+
+env-pc = 0xA000;
+#if defined(CONFIG_USER_ONLY)
+env-fpscr = FPSCR_PR; /* value for userspace according to the kernel */
+set_float_rounding_mode(float_round_nearest_even, env-fp_status); /* ?!
*/
+#else
+env-sr = SR_MD | SR_RB | SR_BL | SR_I3 | SR_I2 | SR_I1 | SR_I0;
+env-fpscr = FPSCR_DN | FPSCR_RM_ZERO; /* CPU reset value according to SH4
manual */
+set_float_rounding_mode(float_round_to_zero, env-fp_status);
+set_flush_to_zero(1, env-fp_status);
+#endif
+set_default_nan_mode(1, env-fp_status);
}
static void superh_cpu_class_init(ObjectClass *oc, void *data)
diff --git a/target-sh4/translate.c b/target-sh4/translate.c
index 6309e85..d0568e2 100644
--- a/target-sh4/translate.c
+++ b/target-sh4/translate.c
@@ -180,25 +180,7 @@ void cpu_dump_state(CPUSH4State * env, FILE * f,
void cpu_state_reset(CPUSH4State *env)
{
-if (qemu_loglevel_mask(CPU_LOG_RESET)) {
-qemu_log(CPU Reset (CPU %d)\n, env-cpu_index);
-log_cpu_state(env, 0);
-}
-
-memset(env, 0, offsetof(CPUSH4State, breakpoints));
-tlb_flush(env, 1);
-
-env-pc = 0xA000;
-#if defined(CONFIG_USER_ONLY)
-env-fpscr = FPSCR_PR; /* value for userspace according to the kernel */
-set_float_rounding_mode(float_round_nearest_even, env-fp_status); /* ?!
*/
-#else
-env-sr = SR_MD | SR_RB | SR_BL | SR_I3 | SR_I2 | SR_I1 | SR_I0;
-env-fpscr = FPSCR_DN | FPSCR_RM_ZERO; /* CPU reset value according to SH4
manual */
-set_float_rounding_mode(float_round_to_zero, env-fp_status);
-set_flush_to_zero(1, env-fp_status);
-#endif
-set_default_nan_mode(1, env-fp_status);
+cpu_reset(ENV_GET_CPU(env));
}
typedef struct {
@@ -281,7 +263,7 @@ CPUSH4State *cpu_sh4_init(const char *cpu_model)
env-movcal_backup_tail = (env-movcal_backup);
sh4_translate_init();
env-cpu_model_str = cpu_model;
-cpu_state_reset(env);
+cpu_reset(CPU(cpu));
cpu_register(env, def);
qemu_init_vcpu(env);
return env;
--
1.7.7
Re: [Qemu-devel] copy benchmarks onto qemu
I tried to insert a cdrom using this command. but when i go under the guest /dev/cdrom. i see nothing ./qemu-system-x86_64 -hda /home/xtong/qemu/qemu-0.14.1/x86_64-softmmu/debian_lenny_amd64_standard.qcow2 -cdrom /home/xtong/qemu/qemu-0.14.1/x86_64-softmmu/ubuntu-11.10-server-amd64.iso On Mon, Apr 23, 2012 at 5:04 AM, Zhi Yong Wu zwu.ker...@gmail.com wrote: On Mon, Apr 23, 2012 at 5:00 PM, Zhi Yong Wu zwu.ker...@gmail.com wrote: On Mon, Apr 23, 2012 at 4:46 PM, Zhi Yong Wu zwu.ker...@gmail.com wrote: On Mon, Apr 23, 2012 at 4:41 PM, Zhi Yong Wu zwu.ker...@gmail.com wrote: On Mon, Apr 23, 2012 at 4:29 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Sun, Apr 22, 2012 at 5:37 PM, Xin Tong xerox.time.t...@gmail.com wrote: i have an OS image that does not have network drivers. are there any other ways to copy a benchmark onto the os image ? You can insert a CD-ROM: (qemu) info block ide1-cd0: removable=1 locked=0 tray-open=0 io-status=ok [not inserted] ... (qemu) change ide1-cd0 my-benchmark.iso Or you could attach a USB Mass Storage device if USB is enabled. Or you can attach this os image to one VM with network drivers as its second disk, then scp your benchmark file to this os image.:) Or if your benchmark file is small, you can create one floppy image where your benchmark files are, then start your VM with floppy. Or you can use 9pfs. Or you can directly use libguestfs. Stefan -- Regards, Zhi Yong Wu -- Regards, Zhi Yong Wu -- Regards, Zhi Yong Wu -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH 1/2] target-arm: Change cpu_arm_init() return type to ARMCPU
Am 23.04.2012 19:00, schrieb Peter Maydell: On 20 April 2012 18:39, Andreas Färber afaer...@suse.de wrote: Make cpu_arm_init() return a QOM ARMCPU, so that we don't need to obtain an ARMCPU through arm_env_get_cpu() in machine init code. This requires to adjust the inclusion site of cpu-qom.h and in turn, forward-looking, to homogenize its include order. cpu_init() must still return a CPUARMState for backwards and cross-target compatibility, so adjust the cpu_init macro. So is the plan that all boards should eventually move over to calling cpu_arm_init() rather than cpu_init() ? Iff they need ARMCPU, they need to call an ARM-specific function. Currently not all do, so there's no need for mass conversions; since cpu_copy() still needs the cpu_init alias there'd be no benefit either. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
