Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU
On 12/19/2011 07:13 PM, Anthony Liguori wrote:
Hi,
I've published a set of tests I wrote over the weekend on qemu.org. My
motivations were 1) to prevent regressions like the libguestfs one and
2) to have an easier way to do development testing as I work on QEMU
Object Model.
Now before sending the obligatory, "What about using KVM autotest"
reply, note that this is significantly different than KVM autotest and
really occupies a different use-case.
Well, I'm still not convinced that a new standalone package should
handle these cases instead of kvm autotest. I'll be happy to integrate
the tests to kvm autotest anyway and the more the merrier but imho it's
a duplicate.
kvm-unit-test is a case for unit tests since it replaces the guest
kernel itself and test for really low level tests like task switch,
instruction emulation, etc.
It has the following characteristics:
1) It builds a custom kernel and initramfs based on busybox. This is
fairly important to ensure that we can run tests with no device
pre-requisites.
This can be done easily w/ autotest too.
2) Tests are scripts that are launched in the initramfs
3) The test controls exactly how QEMU is launched which allows easy
testing of various QEMU options
afaik kvm autotest do the same. It's true that kvm autotest might look
less friendly but its may only be this way since it has lots of options.
4) Tests can interact with the monitor via QMP while the test is running
ditto for kvm autotest
5) The tests execute very quickly, can be run stand alone, and do not
require root privileges
ditto for kvm auotest. It's possible to configure it w/o root too which
is not a huge issue.
Please compare your own virtio-serial test w/ the autotest version of
it:
https://github.com/autotest/autotest/blob/master/client/tests/kvm/tests/virtio_console.py
This single file tests functionality, limits, console, live migration
and performance. Of course one can add a very basic 'hello world' sanity
test too that will run quickly and will identify basic breakage fast.
Noways we abstract kvm autotest so libvirt will be optionally tested too
w/ the same tests.
Again, I'm not advocating that kvm autotest is a solution for anything
but for plain guest-host communication, monitor commands, etc it's a
really good tool.
I agree that kvm autotest may be less friendly for developer users since
it carries allot of options for testing a huge matrix. Lucas and Cleber
are working these days to add a make kvmautotest target to qemu so one
would be able to quickly execute autotest and we can think of additional
parameters like sanity-set, migration-set, etc.
6) They are random by nature with the ability to fix the seed in order
to be used in git-bisect.
I think Gerd had been looking at doing something similar with a custom
initrd.
I've tried to consider other architectures and had hoped that we could
commit the vmlinuz and initramfs into git so that it was easy to test
other architectures without having a full build environment.
Unfortunately, busybox doesn't link statically with glibc and I can't
see an obvious way to commit binaries while respecting the GPL since we
need to pull glibc into the initramfs.
I know buildroot exists specifically to deal with this but in my
experience, buildroot is very unreliable and extremely heavy weight
since it rebuilds gcc multiple times in order to bootstrap a ulibc
environment.
Anyway, the code is available at:
http://git.qemu.org/qemu-test.git
See the README for instructions on how to use it.
Regards,
Anthony Liguori
--- Begin Message ---
This is a pretty simple test that just confirms that virtio-serial shows up and
is writable. It also tests the alias for virtio-serial-pci.
Signed-off-by: Anthony Liguori
---
tests/virtio-serial.sh | 52
1 files changed, 52 insertions(+), 0 deletions(-)
create mode 100755 tests/virtio-serial.sh
diff --git a/tests/virtio-serial.sh b/tests/virtio-serial.sh
new file mode 100755
index 000..e95ae6e
--- /dev/null
+++ b/tests/virtio-serial.sh
@@ -0,0 +1,52 @@
+#!/bin/sh
+
+canary="** waiting for... **"
+
+in_host() {
+tmpchr=$tmpdir/chr.log
+
+# Also test alias
+devname=`choose virtio-serial virtio-serial-pci`
+
+qemu -nographic -enable-kvm -device $devname \
+-device virtserialport,name=org.qemu.test,chardev=chr0 \
+-chardev file,path=$tmpchr,id=chr0
+rc=$?
+
+if test $rc = 0; then
+ if ! grep "$canary" $tmpchr >/dev/null; then
+ echo "Failed to see output from guest!"
+ rc=1
+ fi
+fi
+
+rm -f $tmpchr
+
+return $rc
+}
+
+in_guest() {
+sysfspath=/sys/bus/virtio/devices/virtio0/virtio-ports/vport0p1
+if ! test -e $sysfspath/name; then
+ echo "Device not visible!"
+ return 1
+fi
+
+name=`cat $sysfspath/name`
+
+if test "$name" != "org.qemu.test"; then
+ echo "Device has wrong name!
[Qemu-devel] [PATCH] tcg/arm: Use r6 as TCG_AREG0 to avoid clash with Thumb framepointer
On ARM, in Thumb mode r7 is used for the framepointer; this meant
that we would fail to compile in debug mode because we were using r7
for TCG_AREG0. Shift to r6 instead to avoid this clash.
(Bug reported as LP:870990.)
Signed-off-by: Peter Maydell
---
I did an extremely rough-and-ready benchmark with using a highreg
instead and it didn't seem to make any difference, so I've stuck
with using a lowreg as we do at the moment.
dyngen-exec.h|2 +-
tcg/arm/tcg-target.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/dyngen-exec.h b/dyngen-exec.h
index 3544372..09be9ea 100644
--- a/dyngen-exec.h
+++ b/dyngen-exec.h
@@ -31,7 +31,7 @@
#elif defined(_ARCH_PPC)
#define AREG0 "r27"
#elif defined(__arm__)
-#define AREG0 "r7"
+#define AREG0 "r6"
#elif defined(__hppa__)
#define AREG0 "r17"
#elif defined(__mips__)
diff --git a/tcg/arm/tcg-target.h b/tcg/arm/tcg-target.h
index 48586c3..0035b47 100644
--- a/tcg/arm/tcg-target.h
+++ b/tcg/arm/tcg-target.h
@@ -78,7 +78,7 @@ typedef enum {
enum {
/* Note: must be synced with dyngen-exec.h */
-TCG_AREG0 = TCG_REG_R7,
+TCG_AREG0 = TCG_REG_R6,
};
static inline void flush_icache_range(unsigned long start, unsigned long stop)
--
1.7.5.4
Re: [Qemu-devel] [PATCH v2] w32: Build windows and console executables
On Fri, Dec 23, 2011 at 21:47, Stefan Weil wrote: > Am 23.12.2011 03:31, schrieb TeLeMan: > >> On Thu, Dec 22, 2011 at 18:20, Stefan Weil wrote: >>> >>> System emulation executables with SDL are typically windows >>> executables. Sometimes console executables are more useful, >>> so create both variants if linker option -mwindows was detected. >>> >>> v2: >>> This version uses QEMU_PROGW / QEMU_PROG instead of QEMU_PROG / >>> QEMU_PROGC. >>> >>> Signed-off-by: Stefan Weil >>> --- >>> Makefile.target | 16 +++- >>> 1 files changed, 15 insertions(+), 1 deletions(-) >>> >>> diff --git a/Makefile.target b/Makefile.target >>> index 3261383..0182e41 100644 >>> --- a/Makefile.target >>> +++ b/Makefile.target >>> @@ -27,10 +27,17 @@ ifdef CONFIG_USER_ONLY >>> QEMU_PROG=qemu-$(TARGET_ARCH2) >>> else >>> # system emulator name >>> +ifneq (,$(findstring -mwindows,$(LIBS))) >>> +# Terminate program name with a 'w' because the linker builds a windows >>> executable. >>> +QEMU_PROGW=qemu-system-$(TARGET_ARCH2)w$(EXESUF) >>> +endif # windows executable >>> QEMU_PROG=qemu-system-$(TARGET_ARCH2)$(EXESUF) >>> endif >>> >>> PROGS=$(QEMU_PROG) >>> +ifdef QEMU_PROGW >>> +PROGS+=$(QEMU_PROGW) >>> +endif >>> STPFILES= >>> >>> ifndef CONFIG_HAIKU >>> @@ -403,9 +410,16 @@ endif # CONFIG_LINUX_USER >>> >>> obj-$(CONFIG_GDBSTUB_XML) += gdbstub-xml.o >>> >>> +ifdef QEMU_PROGW >>> +# The linker builds a windows executable. Make also a console >>> executable. >>> +$(QEMU_PROGW): $(obj-y) $(obj-$(TARGET_BASE_ARCH)-y) >>> + $(call LINK,$^) >>> +$(QEMU_PROG): $(QEMU_PROGW) >>> + $(call quiet-command,$(OBJCOPY) --subsystem console $(QEMU_PROGW) >>> $(QEMU_PROG)," GEN $(TARGET_DIR)$(QEMU_PROG)") >>> +else >>> $(QEMU_PROG): $(obj-y) $(obj-$(TARGET_BASE_ARCH)-y) >>> $(call LINK,$^) >>> - >>> +endif >>> >>> gdbstub-xml.c: $(TARGET_XML_FILES) $(SRC_PATH)/scripts/feature_to_c.sh >>> $(call quiet-command,rm -f $@ && $(SHELL) >>> $(SRC_PATH)/scripts/feature_to_c.sh $@ $(TARGET_XML_FILES)," GEN >>> $(TARGET_DIR)$@") >>> -- >>> 1.7.2.5 >>> >> Failed to make: >> Makefile:416: *** multiple target patterns. Stop. > > > It works here (native and cross compilations) with MinGW, > so I have to guess and need your help. > > This is the relevant code from Makefile.target when my patch was applied: > > $(QEMU_PROGW): $(obj-y) $(obj-$(TARGET_BASE_ARCH)-y) > $(call LINK,$^) > $(QEMU_PROG): $(QEMU_PROGW) > > $(call quiet-command,$(OBJCOPY) --subsystem console $(QEMU_PROGW) > $(QEMU_PROG)," GEN $(TARGET_DIR)$(QEMU_PROG)") > > Line 416 is the 2nd line which was not changed by my patch. > It contains no target pattern at all. > > Or do you have a different line counting caused by local > modifications or an older version of the QEMU sources? > > Does an empty line between 2nd and 3rd line help? > > Do you run a native or a cross compilation? > > If native: which line endings do you use (CRLF or LF, > depends on git settings and MinGW mount options)? > Do you use Cygwin, MinGW or MinGW-w64? > Which make do you use? > > Try to run make in verbose mode (make V=1). > > This page describes the error which you got: > http://www.gnu.org/savannah-checkouts/gnu/make/manual/html_node/Error-Messages.html I found this problem. After I copied & pasted your patch, the tabs were converted to spaces. Thanks for your patience. Now it is working. > Cheers, > Stefan Weil > >
Re: [Qemu-devel] [Spice-devel] Seem thread Competition
On Thu, Dec 22, 2011 at 8:49 PM, ZhouPeng wrote:
> On Thu, Dec 22, 2011 at 6:53 PM, Alon Levy wrote:
>> On Thu, Dec 22, 2011 at 10:00:18AM +, Alon Levy wrote:
>>> On Thu, Dec 22, 2011 at 05:42:29PM +0800, ZhouPeng wrote:
>>> > On Thu, Dec 22, 2011 at 4:42 PM, Alon Levy wrote:
>>> > > On Thu, Dec 22, 2011 at 10:13:50AM +0800, ZhouPeng wrote:
>>> > >> Hi,
>>> > >>
>>> > >> I meet the err:
>>> > >>
>>> > >> # virsh dumpxml 63
>>> > >> error: internal error cannot parse json {"timestamp": {"seconds":
>>> > >> 1323332828, "microseco{"timest35p":39}, "econds":PICE_D 1CO3233TE828,
>>> > >> Dmicrosec "ds"data"52}, : {"ser: "SPrCE_DIS"ONNEC{ED", "port": {"serve
>>> > >> ": {6299": "62, "famiamily": "ipv:", "hist": pv4"1 "hos6":
>>> > >> "182.168.12.231"}, "2lient.: {"p2rt": 3350196, "fa"ily": "}, "cl,
>>> > >> "ho{sport":t"35020", ": "19y": "i2.4", "168.1.": "19}: lexical error:
>>> > >> invalid string in json text.
>>> > >> ds": 1323332828, "microseco{"timest35p":39}, "econds":PICE_D
>>> > >>
>>> > >> This similar bug seems has been reported by:
>>> > >> https://bugzilla.redhat.com/show_bug.cgi?id=744105
>>> > >>
>>> > >> The patch(http://cgit.freedesktop.org/spice/qemu/commit/?h=spice.v42)
>>> > >> seems be related with the competition.
>>> > >> But I searched the upstream qemu, it has not been merged in.
>>> > >>
>>> > >> My qemu is qemu-kvm-0.15.1 on 3.1.2-1.fc16.x86_64
>>> > >>
>>> > >> Is there any plan about this bug, it seems be some serious.
>>> > >>
>>> > >
>>> > > The patch Daniel Berrange mentioned wotrked around it in qemu and is in
>>> > > qemu 1.0-rc0 and onward, still checking qemu-kvm. There is another patch
>>> >
>>> > Yea, I searched in spice-core.c again and the patch is in qemu unstable
>>> > Sorry, I carelessly search by " me " but not " me;" before.
>>>
>>> It is in qemu-kvm-1.0 as well. But like you said fedora carries 0.15.1
>>> that doesn't have it.
>>>
>>> > > in spice-0.10 and in 0.8, still need to check if it's in fedora. Which
>>> > > version of spice are you using?
>>> >
>>> > spice-server.x86_64 version 0.9.1
>>>
>>> which doesn't have the spice side fix. but 0.10.0 has it, and it is
>>> closest to 0.9.1. I assume this is from the fedora package as well since
>>> you mentioned qemu-kvm is from a fedora package? seems the latest is
>>> indeed 0.9.1-1, can you test
>>> http://koji.fedoraproject.org/koji/buildinfo?buildID=273917
>>> (spice-server-0.10.0-1)?
>>>
>>
>> If you find it fixes your problem and doesn't introduce any new ones
>> please +1 spice-0.10.0-1.fc16 at
>> https://admin.fedoraproject.org/updates/spice-0.10.0-1.fc16
Have +1, Thanks.
>
> After the steps below, I am sure it is spice-server-0.10.0-1.fc16.x86_64
> works.
> [root@localhost pkgconfig]# ldd /usr/bin/qemu-kvm
> libspice-server.so.1 => /usr/lib64/libspice-server.so.1
> (0x7f5f02799000)
>
> [root@localhost ~]# rpm --erase spice-server-0.9.1-1.fc16.x86_64 --nodeps
> [root@localhost ~]# rpm --erase spice-server-0.10.0-1.fc16.x86_64 --nodeps
> [root@localhost ~]# ls /usr/lib64/libspice-server* -l
> lrwxrwxrwx. 1 root root 24 Dec 20 06:43 /usr/lib64/libspice-server.so
> -> libspice-server.so.1.0.2
> [root@localhost ~]# virsh restore 43.ckp
> error: Failed to restore domain from 43.ckp
> error: internal error Child process (LC_ALL=C
> PATH=/sbin:/usr/sbin:/bin:/usr/bin /usr/bin/qemu-kvm -help) status
> unexpected: exit status 127
> //Note: libspice-server.so.1.0.2 doesn't exists
>
> [root@localhost ~]# rpm -i spice-server-0.10.0-1.fc16.x86_64.rpm
> [root@localhost ~]# ls /usr/lib64/libspice-server* -l
> lrwxrwxrwx. 1 root root 24 Dec 20 06:43
> /usr/lib64/libspice-server.so -> libspice-server.so.1.0.2
> lrwxrwxrwx 1 root root 24 Dec 22 07:21
> /usr/lib64/libspice-server.so.1 -> libspice-server.so.1.0.2
> -rwxr-xr-x 1 root root 983600 Nov 14 08:08
> /usr/lib64/libspice-server.so.1.0.2
> [root@localhost ~]# virsh restore 43.ckp
> Domain restored from 43.ckp
>
> The software suits related:
>
> spice-server x86_64 0.10.0-1.fc16installed
> qemu-kvm x86_64 2:0.15.1-3.fc16 @updates
>
> This random bug appears at least 2 time one day before fixing.
> So in the coming 2 days, if this bug does't appear again, I will
> assume spice-server-0.10.0-1.fc16.x86_64.rpm fix it :)
The bug does appear again, So I think
spice-server-0.10.0-1.fc16.x86_64.rpm can fix.
The bug appear in my software before, in steps below:
1) virsh restore vm.ckp vm.xml
2) spice client connect
some time later go step 3)
3) virsh dump vm vm.xml
4) virsh save vm vm.ckp
some time later go step 1) again
The err always appears in step 3) at random.
Anyway it is fixed.
Thanks,
--
Zhou Peng
