[Qemu-devel] [Bug 1058225] Re: When setting hardware clock on linux guest, hwclock shows crazy date (in the year 2043)

[Lucas Meneghel Rodrigues]

Paolo fixed the problem with upstream commit:

commit b6db4aca20e9af4f62c9c9e08b9b9672a6ed3390
Author: Paolo Bonzini 
Date:   Mon Oct 1 14:22:06 2012 +0200

rtc: fix overflow in mktimegm

When setting a date in 1980, Linux is actually disregarding the century
byte and setting the year to 2080.  This causes a year-2038 overflow
in mktimegm.  Fix this by doing the days-to-seconds computation in
64-bit math.

Reported-by: Lucas Meneghel Rodrigues 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Anthony Liguori 

Confirmed that problem is solved. Closing bug.

** Changed in: qemu
   Status: New => Confirmed

** Changed in: qemu
   Status: Confirmed => Fix Committed

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1058225

Title:
  When setting hardware clock on linux guest, hwclock shows crazy date
  (in the year 2043)

Status in QEMU:
  Fix Committed

Bug description:
  Very easy to reproduce:

  1) Build the latest qemu.git (we've captured this on internal
  automated testing, verified manually), the commit for reference is:

  14:07:02 INFO | git commit ID is
  6f8fd2530e9a530f237240daf1c981fa5df7f978 (tag v1.2.0-461-g6f8fd25)

  2) Install a linux guest in it (caught with RHEL 6.2, verified with
  Fedora 17)

  3) In the linux guest, set the hardware clock with hwclock:

  /sbin/hwclock --set --date "2/2/80 03:04:00"

  4) Verify if hardware clock was set back to the eighties:

  LC_ALL=C /sbin/hwclock

  5) Observe amazed that hwclock reports a date in the year 2043:

  14:09:34 INFO |  ('hwclock', 'FAIL', 2, "Failed to set hwclock
  back to the eighties. Output of hwclock is 'Sun Dec 27 20:35:46 2043
  -0.489664 seconds'")

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1058225/+subscriptions

Re: [Qemu-devel] [PATCH] add isa-debug-exit device.

[Lucas Meneghel Rodrigues]

On 12/12/2012 01:29 PM, Paolo Bonzini wrote:

Il 12/12/2012 16:23, Gerd Hoffmann ha scritto:

When present it makes qemu exit on any write.
Mapped to port 0x501 by default.

Without this patch Anthony doesn't allow me to
remove the bochs bios debug ports because his
test suite uses this.


Wasn't this patch submitted already by Herve' first and Lucas second? :)

Lucas, what happened to your testdev patches?


I talked to Marcelo, he said he'd assume the patchset I sent to carry 
out with upstream inclusion. Since then I got absorbed in other tasks, 
so I really haven't checked the status.


Since it seem things got stalled, I'll resume from where I left, will 
re-send the patches soon.


Cheers,

Lucas


Paolo


Signed-off-by: Gerd Hoffmann 
---
  hw/debugexit.c|   71 +
  hw/i386/Makefile.objs |2 +-
  2 files changed, 72 insertions(+), 1 deletions(-)
  create mode 100644 hw/debugexit.c

diff --git a/hw/debugexit.c b/hw/debugexit.c
new file mode 100644
index 000..e1f7570
--- /dev/null
+++ b/hw/debugexit.c
@@ -0,0 +1,71 @@
+/*
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 or
+ * (at your option) version 3 of the License.
+ */
+
+#include "hw.h"
+#include "isa.h"
+
+#define TYPE_ISA_DEBUG_EXIT_DEVICE "isa-debug-exit"
+#define ISA_DEBUG_EXIT_DEVICE(obj) \
+ OBJECT_CHECK(ISADebugExitState, (obj), TYPE_ISA_DEBUG_EXIT_DEVICE)
+
+typedef struct ISADebugExitState {
+ISADevice parent_obj;
+
+uint32_t iobase;
+MemoryRegion io;
+} ISADebugExitState;
+
+static void debug_exit_write(void *opaque, hwaddr addr, uint64_t val,
+ unsigned width)
+{
+exit((val << 1) | 1);
+}
+
+static const MemoryRegionOps debug_exit_ops = {
+.write = debug_exit_write,
+.valid.min_access_size = 1,
+.valid.max_access_size = 1,
+.endianness = DEVICE_LITTLE_ENDIAN,
+};
+
+static int debug_exit_initfn(ISADevice *dev)
+{
+ISADebugExitState *isa = ISA_DEBUG_EXIT_DEVICE(dev);
+
+memory_region_init_io(&isa->io, &debug_exit_ops, isa,
+  TYPE_ISA_DEBUG_EXIT_DEVICE, 1);
+memory_region_add_subregion(isa_address_space_io(dev),
+isa->iobase, &isa->io);
+return 0;
+}
+
+static Property debug_exit_properties[] = {
+DEFINE_PROP_HEX32("iobase", ISADebugExitState, iobase, 0x501),
+DEFINE_PROP_END_OF_LIST(),
+};
+
+static void debug_exit_class_initfn(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+ISADeviceClass *ic = ISA_DEVICE_CLASS(klass);
+ic->init = debug_exit_initfn;
+dc->props = debug_exit_properties;
+}
+
+static TypeInfo debug_exit_info = {
+.name  = TYPE_ISA_DEBUG_EXIT_DEVICE,
+.parent= TYPE_ISA_DEVICE,
+.instance_size = sizeof(ISADebugExitState),
+.class_init= debug_exit_class_initfn,
+};
+
+static void debug_exit_register_types(void)
+{
+type_register_static(&debug_exit_info);
+}
+
+type_init(debug_exit_register_types)
diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
index 0d3f6a8..56aaa9d 100644
--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -3,7 +3,7 @@ obj-y += apic_common.o apic.o kvmvapic.o
  obj-y += sga.o ioapic_common.o ioapic.o piix_pci.o
  obj-y += vmport.o
  obj-y += pci-hotplug.o smbios.o wdt_ib700.o
-obj-y += debugcon.o multiboot.o
+obj-y += debugcon.o debugexit.o multiboot.o
  obj-y += pc_piix.o
  obj-y += pc_sysfw.o
  obj-y += lpc_ich9.o q35.o pc_q35.o

[Qemu-devel] [PATCH 0/2] Add pc-testdev to qemu v4

[Lucas Meneghel Rodrigues]

These two patches introduce:

 1) A ISA debugexit port device, that when written, causes qemu
to exit with the exit code passed as parameter.
 2) A port of the existing testdev present on qemu-kvm to qemu

I took Gerd's recent patch and modified it to include the access-size
property, as well as fixed problems pointed in previous reviews of
the test device itself.

I did notice that with the new test device, a lot of the
kvm-unit-tests are failing. The same tests are passing fine
under qemu-kvm, meaning there are some bugs we need to address.

Example:

qemu-kvm:

$ x86_64-softmmu/qemu-system-x86_64 -device testdev -serial stdio -kernel 
/path/to/kvm/unittests/pcid.flat
VNC server running on `127.0.0.1:5900'
enabling apic
CPUID consistency: PASS
Test on PCID when disabled: PASS
Test on INVPCID when disabled: PASS
3 tests, 0 failures
$ echo $?
0

qemu:

$ x86_64-softmmu/qemu-system-x86_64 -device pc-testdev -serial stdio -device 
isa-debugexit,iobase=0xf4,access-size=4 -kernel /path/to/kvm/unittests/pcid.flat
VNC server running on `127.0.0.1:5900'
enabling apic
CPUID consistency: PASS
Test on PCID when disabled: FAIL
Test on INVPCID when disabled: PASS
3 tests, 1 failures
$ echo $?
3

Gerd Hoffmann (1):
  add isa-debug-exit device

Lucas Meneghel Rodrigues (1):
  hw: Add test device for unittests execution v5

 hw/debugexit.c|   73 +++
 hw/i386/Makefile.objs |3 +-
 hw/pc-testdev.c   |  156 +
 3 files changed, 231 insertions(+), 1 deletion(-)
 create mode 100644 hw/debugexit.c
 create mode 100644 hw/pc-testdev.c

-- 
1.7.10.4

[Qemu-devel] [PATCH 1/2] add isa-debug-exit device

[Lucas Meneghel Rodrigues]

From: Gerd Hoffmann 

When present it makes qemu exit on any write.
Mapped to port 0x501 by default.

Without this patch Anthony doesn't allow me to
remove the bochs bios debug ports because his
test suite uses this.

Changes from v1: Add access_size property to the
device, needed for kvm-unit-tests.

Signed-off-by: Gerd Hoffmann 
---
 hw/debugexit.c|   73 +
 hw/i386/Makefile.objs |2 +-
 hw/pc-testdev.c   |  167 +
 3 files changed, 241 insertions(+), 1 deletion(-)
 create mode 100644 hw/debugexit.c
 create mode 100644 hw/pc-testdev.c

diff --git a/hw/debugexit.c b/hw/debugexit.c
new file mode 100644
index 000..dfe1b2d
--- /dev/null
+++ b/hw/debugexit.c
@@ -0,0 +1,73 @@
+/*
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 or
+ * (at your option) version 3 of the License.
+ */
+
+#include "hw.h"
+#include "isa.h"
+
+#define TYPE_ISA_DEBUG_EXIT_DEVICE "isa-debug-exit"
+#define ISA_DEBUG_EXIT_DEVICE(obj) \
+ OBJECT_CHECK(ISADebugExitState, (obj), TYPE_ISA_DEBUG_EXIT_DEVICE)
+
+typedef struct ISADebugExitState {
+ISADevice parent_obj;
+
+uint32_t iobase;
+uint8_t access_size;
+MemoryRegion io;
+} ISADebugExitState;
+
+static void debug_exit_write(void *opaque, hwaddr addr, uint64_t val,
+ unsigned width)
+{
+exit((val << 1) | 1);
+}
+
+static const MemoryRegionOps debug_exit_ops = {
+.write = debug_exit_write,
+.valid.min_access_size = 1,
+.valid.max_access_size = 1,
+.endianness = DEVICE_LITTLE_ENDIAN,
+};
+
+static int debug_exit_initfn(ISADevice *dev)
+{
+ISADebugExitState *isa = ISA_DEBUG_EXIT_DEVICE(dev);
+
+memory_region_init_io(&isa->io, &debug_exit_ops, isa,
+  TYPE_ISA_DEBUG_EXIT_DEVICE, isa->access_size);
+memory_region_add_subregion(isa_address_space_io(dev),
+isa->iobase, &isa->io);
+return 0;
+}
+
+static Property debug_exit_properties[] = {
+DEFINE_PROP_HEX32("iobase", ISADebugExitState, iobase, 0x501),
+DEFINE_PROP_UINT8("access-size", ISADebugExitState, access_size, 1),
+DEFINE_PROP_END_OF_LIST(),
+};
+
+static void debug_exit_class_initfn(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+ISADeviceClass *ic = ISA_DEVICE_CLASS(klass);
+ic->init = debug_exit_initfn;
+dc->props = debug_exit_properties;
+}
+
+static TypeInfo debug_exit_info = {
+.name  = TYPE_ISA_DEBUG_EXIT_DEVICE,
+.parent= TYPE_ISA_DEVICE,
+.instance_size = sizeof(ISADebugExitState),
+.class_init= debug_exit_class_initfn,
+};
+
+static void debug_exit_register_types(void)
+{
+type_register_static(&debug_exit_info);
+}
+
+type_init(debug_exit_register_types)
diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
index 0d3f6a8..56aaa9d 100644
--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -3,7 +3,7 @@ obj-y += apic_common.o apic.o kvmvapic.o
 obj-y += sga.o ioapic_common.o ioapic.o piix_pci.o
 obj-y += vmport.o
 obj-y += pci-hotplug.o smbios.o wdt_ib700.o
-obj-y += debugcon.o multiboot.o
+obj-y += debugcon.o debugexit.o multiboot.o
 obj-y += pc_piix.o
 obj-y += pc_sysfw.o
 obj-y += lpc_ich9.o q35.o pc_q35.o
diff --git a/hw/pc-testdev.c b/hw/pc-testdev.c
new file mode 100644
index 000..b652956
--- /dev/null
+++ b/hw/pc-testdev.c
@@ -0,0 +1,167 @@
+/*
+ * QEMU x86 ISA testdev
+ *
+ * Copyright (c) 2012 Avi Kivity, Gerd Hoffmann, Marcelo Tosatti
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+/*
+ * This device is used to test KVM features specific to the x86 port, such
+ * as emulation, power management, interrupt routing, among others. It's meant
+ * to be used like:
+ *
+ * qemu-system-x86_64 -device pc-testdev -seria

[Qemu-devel] [PATCH 1/2] add isa-debug-exit device

[Lucas Meneghel Rodrigues]

From: Gerd Hoffmann 

When present it makes qemu exit on any write.
Mapped to port 0x501 by default.

Without this patch Anthony doesn't allow me to
remove the bochs bios debug ports because his
test suite uses this.

Changes from v1: Add access_size property to the
device, needed for kvm-unit-tests.

Signed-off-by: Gerd Hoffmann 
---
 hw/debugexit.c|   73 +
 hw/i386/Makefile.objs |2 +-
 hw/pc-testdev.c   |  167 +
 3 files changed, 241 insertions(+), 1 deletion(-)
 create mode 100644 hw/debugexit.c
 create mode 100644 hw/pc-testdev.c

diff --git a/hw/debugexit.c b/hw/debugexit.c
new file mode 100644
index 000..dfe1b2d
--- /dev/null
+++ b/hw/debugexit.c
@@ -0,0 +1,73 @@
+/*
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 or
+ * (at your option) version 3 of the License.
+ */
+
+#include "hw.h"
+#include "isa.h"
+
+#define TYPE_ISA_DEBUG_EXIT_DEVICE "isa-debug-exit"
+#define ISA_DEBUG_EXIT_DEVICE(obj) \
+ OBJECT_CHECK(ISADebugExitState, (obj), TYPE_ISA_DEBUG_EXIT_DEVICE)
+
+typedef struct ISADebugExitState {
+ISADevice parent_obj;
+
+uint32_t iobase;
+uint8_t access_size;
+MemoryRegion io;
+} ISADebugExitState;
+
+static void debug_exit_write(void *opaque, hwaddr addr, uint64_t val,
+ unsigned width)
+{
+exit((val << 1) | 1);
+}
+
+static const MemoryRegionOps debug_exit_ops = {
+.write = debug_exit_write,
+.valid.min_access_size = 1,
+.valid.max_access_size = 1,
+.endianness = DEVICE_LITTLE_ENDIAN,
+};
+
+static int debug_exit_initfn(ISADevice *dev)
+{
+ISADebugExitState *isa = ISA_DEBUG_EXIT_DEVICE(dev);
+
+memory_region_init_io(&isa->io, &debug_exit_ops, isa,
+  TYPE_ISA_DEBUG_EXIT_DEVICE, isa->access_size);
+memory_region_add_subregion(isa_address_space_io(dev),
+isa->iobase, &isa->io);
+return 0;
+}
+
+static Property debug_exit_properties[] = {
+DEFINE_PROP_HEX32("iobase", ISADebugExitState, iobase, 0x501),
+DEFINE_PROP_UINT8("access-size", ISADebugExitState, access_size, 1),
+DEFINE_PROP_END_OF_LIST(),
+};
+
+static void debug_exit_class_initfn(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+ISADeviceClass *ic = ISA_DEVICE_CLASS(klass);
+ic->init = debug_exit_initfn;
+dc->props = debug_exit_properties;
+}
+
+static TypeInfo debug_exit_info = {
+.name  = TYPE_ISA_DEBUG_EXIT_DEVICE,
+.parent= TYPE_ISA_DEVICE,
+.instance_size = sizeof(ISADebugExitState),
+.class_init= debug_exit_class_initfn,
+};
+
+static void debug_exit_register_types(void)
+{
+type_register_static(&debug_exit_info);
+}
+
+type_init(debug_exit_register_types)
diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
index 0d3f6a8..56aaa9d 100644
--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -3,7 +3,7 @@ obj-y += apic_common.o apic.o kvmvapic.o
 obj-y += sga.o ioapic_common.o ioapic.o piix_pci.o
 obj-y += vmport.o
 obj-y += pci-hotplug.o smbios.o wdt_ib700.o
-obj-y += debugcon.o multiboot.o
+obj-y += debugcon.o debugexit.o multiboot.o
 obj-y += pc_piix.o
 obj-y += pc_sysfw.o
 obj-y += lpc_ich9.o q35.o pc_q35.o
diff --git a/hw/pc-testdev.c b/hw/pc-testdev.c
new file mode 100644
index 000..b652956
--- /dev/null
+++ b/hw/pc-testdev.c
@@ -0,0 +1,167 @@
+/*
+ * QEMU x86 ISA testdev
+ *
+ * Copyright (c) 2012 Avi Kivity, Gerd Hoffmann, Marcelo Tosatti
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+/*
+ * This device is used to test KVM features specific to the x86 port, such
+ * as emulation, power management, interrupt routing, among others. It's meant
+ * to be used like:
+ *
+ * qemu-system-x86_64 -device pc-testdev -seria

[Qemu-devel] [PATCH 0/2] Add pc-testdev to qemu v4

[Lucas Meneghel Rodrigues]

These two patches introduce:

 1) A ISA debugexit port device, that when written, causes qemu
to exit with the exit code passed as parameter.
 2) A port of the existing testdev present on qemu-kvm to qemu

I took Gerd's recent patch and modified it to include the access-size
property, as well as fixed problems pointed in previous reviews of
the test device itself.

I did notice that with the new test device, a lot of the
kvm-unit-tests are failing. The same tests are passing fine
under qemu-kvm, meaning there are some bugs we need to address.

Example:

qemu-kvm:

$ x86_64-softmmu/qemu-system-x86_64 -device testdev -serial stdio -kernel 
/path/to/kvm/unittests/pcid.flat
VNC server running on `127.0.0.1:5900'
enabling apic
CPUID consistency: PASS
Test on PCID when disabled: PASS
Test on INVPCID when disabled: PASS
3 tests, 0 failures
$ echo $?
0

qemu:

$ x86_64-softmmu/qemu-system-x86_64 -device pc-testdev -serial stdio -device 
isa-debugexit,iobase=0xf4,access-size=4 -kernel /path/to/kvm/unittests/pcid.flat
VNC server running on `127.0.0.1:5900'
enabling apic
CPUID consistency: PASS
Test on PCID when disabled: FAIL
Test on INVPCID when disabled: PASS
3 tests, 1 failures
$ echo $?
3

Gerd Hoffmann (1):
  add isa-debug-exit device

Lucas Meneghel Rodrigues (1):
  hw: Add test device for unittests execution v5

 hw/debugexit.c|   73 +++
 hw/i386/Makefile.objs |3 +-
 hw/pc-testdev.c   |  156 +
 3 files changed, 231 insertions(+), 1 deletion(-)
 create mode 100644 hw/debugexit.c
 create mode 100644 hw/pc-testdev.c

-- 
1.7.10.4

[Qemu-devel] [PATCH 2/2] hw: Add test device for unittests execution v5

[Lucas Meneghel Rodrigues]

Add a test device which supports the kvmctl ioports,
so one can run the KVM unittest suite.

Intended Usage:

qemu-system-x86_64\
-device pc-testdev -serial stdio \
-device isa-debugexit,iobase=0xf4,access-size=4 \
-kernel /path/to/kvm/unittests/msr.flat

Where msr.flat is one of the KVM unittests, present on a
separate repo,

git://git.kernel.org/pub/scm/virt/kvm/kvm-unit-tests.git

Changes from v4:
* Pass iomem_buf as an opaque, as requested by Blue
* Ported to new MMIO schema, as requested by Jan

Changes from v3:
* Ported all register_ioport functions to memory API

Changes from v2:

* Rename struct testdev to PCTestdev
* Embed ioport_data into PCTestdev struct
* Porting most register_ioport functions to memory API

Changes from v1:

* Removed unused testdev member
* Renamed device to a less generic name, pc-testdev

Initial changes from initial attempt:

* Removed port 0xf1, since now kvm-unit-tests use
  serial
* Removed exit code port 0xf4, since that can be
  replaced by

-device isa-debugexit,iobase=0xf4,access-size=4

* Removed ram size port 0xd1, since guest memory
  size can be retrieved from firmware, there's a
  patch for kvm-unit-tests including an API to
  retrieve that value.

CC: Paolo Bonzini 
Signed-off-by: Alexander Graf 
Signed-off-by: Gerd Hoffmann 
Signed-off-by: Marcelo Tosatti 
Signed-off-by: Lucas Meneghel Rodrigues 
---
 hw/i386/Makefile.objs |1 +
 hw/pc-testdev.c   |   55 -
 2 files changed, 23 insertions(+), 33 deletions(-)

diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
index 56aaa9d..1ac5fc5 100644
--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -12,5 +12,6 @@ obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
 obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o xen_pt_msi.o
 obj-y += kvm/
 obj-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o
+obj-y += pc-testdev.o
 
 obj-y := $(addprefix ../,$(obj-y))
diff --git a/hw/pc-testdev.c b/hw/pc-testdev.c
index b652956..75889e7 100644
--- a/hw/pc-testdev.c
+++ b/hw/pc-testdev.c
@@ -41,10 +41,13 @@
 #include "isa.h"
 #include "exec-memory.h"
 
+#define IOMEM_LEN0x1
+
 typedef struct PCTestdev {
 ISADevice dev;
 MemoryRegion iomem;
 uint32_t ioport_data;
+char iomem_buf[IOMEM_LEN];
 } PCTestdev;
 
 #define TYPE_TESTDEV "pc-testdev"
@@ -74,48 +77,35 @@ static void test_device_flush_page(void *opaque, uint32_t 
addr, uint32_t data)
 hwaddr len = 4096;
 void *a = cpu_physical_memory_map(data & ~0xffful, &len, 0);
 
-mprotect(a, 4096, PROT_NONE);
-mprotect(a, 4096, PROT_READ|PROT_WRITE);
+/* We might not be able to get the full page, only mprotect what we 
actually
+   have mapped */
+mprotect(a, len, PROT_NONE);
+mprotect(a, len, PROT_READ|PROT_WRITE);
 cpu_physical_memory_unmap(a, len, 0, 0);
 }
 
-static char *iomem_buf;
-
-static uint32_t test_iomem_readb(void *opaque, hwaddr addr)
-{
-return iomem_buf[addr];
-}
-
-static uint32_t test_iomem_readw(void *opaque, hwaddr addr)
-{
-return *(uint16_t*)(iomem_buf + addr);
-}
-
-static uint32_t test_iomem_readl(void *opaque, hwaddr addr)
+static uint64_t test_iomem_read(void *opaque, hwaddr addr, unsigned len)
 {
-return *(uint32_t*)(iomem_buf + addr);
-}
-
-static void test_iomem_writeb(void *opaque, hwaddr addr, uint32_t val)
-{
-iomem_buf[addr] = val;
-}
+struct PCTestdev *dev = opaque;
+uint64_t ret = 0;
+memcpy(&ret, &dev->iomem_buf[addr], len);
+ret = le64_to_cpu(ret);
 
-static void test_iomem_writew(void *opaque, hwaddr addr, uint32_t val)
-{
-*(uint16_t*)(iomem_buf + addr) = val;
+return ret;
 }
 
-static void test_iomem_writel(void *opaque, hwaddr addr, uint32_t val)
+static void test_iomem_write(void *opaque, hwaddr addr, uint64_t val,
+ unsigned len)
 {
-*(uint32_t*)(iomem_buf + addr) = val;
+struct PCTestdev *dev = opaque;
+val = cpu_to_le64(val);
+memcpy(&dev->iomem_buf[addr], &val, len);
+dev->iomem_buf[addr] = val;
 }
 
 static const MemoryRegionOps test_iomem_ops = {
-.old_mmio = {
-.read = { test_iomem_readb, test_iomem_readw, test_iomem_readl, },
-.write = { test_iomem_writeb, test_iomem_writew, test_iomem_writel, },
-},
+.read = test_iomem_read,
+.write = test_iomem_write,
 .endianness = DEVICE_LITTLE_ENDIAN,
 };
 
@@ -137,9 +127,8 @@ static int init_test_device(ISADevice *isa)
  NULL, "pc-testdev");
 portio_list_add(test_dev_port_list, get_system_io(), 0x0);
 
-iomem_buf = g_malloc0(0x1);
 memory_region_init_io(&dev->iomem, &test_iomem_ops, dev,
-  "pc-testdev", 0x1);
+  "pc-testdev", IOMEM_LEN);
 memory_region_add_subregion(isa_address_space(&dev->dev), 0xff00,
   &dev->iomem);
 return 0;
-- 
1.7.10.4

[Qemu-devel] [PATCH 0/2] Add pc-testdev to qemu v6

[Lucas Meneghel Rodrigues]

These two patches introduce:

 1) A ISA debugexit port device, that when written, causes qemu
to exit with the exit code passed as parameter.
 2) A port of the existing testdev present on qemu-kvm to qemu

I took Gerd's recent patch and modified it to include the access-size
property, as well as fixed problems pointed in previous reviews of
the test device itself.

I did notice that with the new test device, a lot of the
kvm-unit-tests are failing. The same tests are passing fine
under qemu-kvm, meaning there are some bugs we need to address.

Example:

qemu-kvm:

$ x86_64-softmmu/qemu-system-x86_64 -device testdev -serial stdio -kernel 
/path/to/kvm/unittests/pcid.flat
VNC server running on `127.0.0.1:5900'
enabling apic
CPUID consistency: PASS
Test on PCID when disabled: PASS
Test on INVPCID when disabled: PASS
3 tests, 0 failures
$ echo $?
0

qemu:

$ x86_64-softmmu/qemu-system-x86_64 -device pc-testdev -serial stdio -device 
isa-debugexit,iobase=0xf4,access-size=4 -kernel /path/to/kvm/unittests/pcid.flat
VNC server running on `127.0.0.1:5900'
enabling apic
CPUID consistency: PASS
Test on PCID when disabled: FAIL
Test on INVPCID when disabled: PASS
3 tests, 1 failures
$ echo $?
3


Gerd Hoffmann (1):
  hw: add isa-debug-exit device v3

Lucas Meneghel Rodrigues (1):
  hw: Add test device for unittests execution v6

 hw/debugexit.c|   73 +++
 hw/i386/Makefile.objs |3 +-
 hw/pc-testdev.c   |  156 +
 3 files changed, 231 insertions(+), 1 deletion(-)
 create mode 100644 hw/debugexit.c
 create mode 100644 hw/pc-testdev.c

-- 
1.7.10.4

[Qemu-devel] [PATCH 1/2] hw: add isa-debug-exit device v3

[Lucas Meneghel Rodrigues]

From: Gerd Hoffmann 

When present it makes qemu exit on any write.
Mapped to port 0x501 by default.

Without this patch Anthony doesn't allow me to
remove the bochs bios debug ports because his
test suite uses this.

Changes from v2: Fixed rebase mistake

Changes from v1: Add access_size property to the
device, needed for kvm-unit-tests.

Signed-off-by: Gerd Hoffmann 
---
 hw/debugexit.c|   73 +
 hw/i386/Makefile.objs |2 +-
 2 files changed, 74 insertions(+), 1 deletion(-)
 create mode 100644 hw/debugexit.c

diff --git a/hw/debugexit.c b/hw/debugexit.c
new file mode 100644
index 000..dfe1b2d
--- /dev/null
+++ b/hw/debugexit.c
@@ -0,0 +1,73 @@
+/*
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 or
+ * (at your option) version 3 of the License.
+ */
+
+#include "hw.h"
+#include "isa.h"
+
+#define TYPE_ISA_DEBUG_EXIT_DEVICE "isa-debug-exit"
+#define ISA_DEBUG_EXIT_DEVICE(obj) \
+ OBJECT_CHECK(ISADebugExitState, (obj), TYPE_ISA_DEBUG_EXIT_DEVICE)
+
+typedef struct ISADebugExitState {
+ISADevice parent_obj;
+
+uint32_t iobase;
+uint8_t access_size;
+MemoryRegion io;
+} ISADebugExitState;
+
+static void debug_exit_write(void *opaque, hwaddr addr, uint64_t val,
+ unsigned width)
+{
+exit((val << 1) | 1);
+}
+
+static const MemoryRegionOps debug_exit_ops = {
+.write = debug_exit_write,
+.valid.min_access_size = 1,
+.valid.max_access_size = 1,
+.endianness = DEVICE_LITTLE_ENDIAN,
+};
+
+static int debug_exit_initfn(ISADevice *dev)
+{
+ISADebugExitState *isa = ISA_DEBUG_EXIT_DEVICE(dev);
+
+memory_region_init_io(&isa->io, &debug_exit_ops, isa,
+  TYPE_ISA_DEBUG_EXIT_DEVICE, isa->access_size);
+memory_region_add_subregion(isa_address_space_io(dev),
+isa->iobase, &isa->io);
+return 0;
+}
+
+static Property debug_exit_properties[] = {
+DEFINE_PROP_HEX32("iobase", ISADebugExitState, iobase, 0x501),
+DEFINE_PROP_UINT8("access-size", ISADebugExitState, access_size, 1),
+DEFINE_PROP_END_OF_LIST(),
+};
+
+static void debug_exit_class_initfn(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+ISADeviceClass *ic = ISA_DEVICE_CLASS(klass);
+ic->init = debug_exit_initfn;
+dc->props = debug_exit_properties;
+}
+
+static TypeInfo debug_exit_info = {
+.name  = TYPE_ISA_DEBUG_EXIT_DEVICE,
+.parent= TYPE_ISA_DEVICE,
+.instance_size = sizeof(ISADebugExitState),
+.class_init= debug_exit_class_initfn,
+};
+
+static void debug_exit_register_types(void)
+{
+type_register_static(&debug_exit_info);
+}
+
+type_init(debug_exit_register_types)
diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
index 0d3f6a8..56aaa9d 100644
--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -3,7 +3,7 @@ obj-y += apic_common.o apic.o kvmvapic.o
 obj-y += sga.o ioapic_common.o ioapic.o piix_pci.o
 obj-y += vmport.o
 obj-y += pci-hotplug.o smbios.o wdt_ib700.o
-obj-y += debugcon.o multiboot.o
+obj-y += debugcon.o debugexit.o multiboot.o
 obj-y += pc_piix.o
 obj-y += pc_sysfw.o
 obj-y += lpc_ich9.o q35.o pc_q35.o
-- 
1.7.10.4

[Qemu-devel] [PATCH 1/2] hw: add isa-debug-exit device

[Lucas Meneghel Rodrigues]

From: Gerd Hoffmann 

When present it makes qemu exit on any write.
Mapped to port 0x501 by default.

Without this patch Anthony doesn't allow me to
remove the bochs bios debug ports because his
test suite uses this.

Changes from v1: Add access_size property to the
device, needed for kvm-unit-tests.

Signed-off-by: Gerd Hoffmann 
---
 hw/debugexit.c|   73 +
 hw/i386/Makefile.objs |2 +-
 2 files changed, 74 insertions(+), 1 deletion(-)
 create mode 100644 hw/debugexit.c

diff --git a/hw/debugexit.c b/hw/debugexit.c
new file mode 100644
index 000..dfe1b2d
--- /dev/null
+++ b/hw/debugexit.c
@@ -0,0 +1,73 @@
+/*
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 or
+ * (at your option) version 3 of the License.
+ */
+
+#include "hw.h"
+#include "isa.h"
+
+#define TYPE_ISA_DEBUG_EXIT_DEVICE "isa-debug-exit"
+#define ISA_DEBUG_EXIT_DEVICE(obj) \
+ OBJECT_CHECK(ISADebugExitState, (obj), TYPE_ISA_DEBUG_EXIT_DEVICE)
+
+typedef struct ISADebugExitState {
+ISADevice parent_obj;
+
+uint32_t iobase;
+uint8_t access_size;
+MemoryRegion io;
+} ISADebugExitState;
+
+static void debug_exit_write(void *opaque, hwaddr addr, uint64_t val,
+ unsigned width)
+{
+exit((val << 1) | 1);
+}
+
+static const MemoryRegionOps debug_exit_ops = {
+.write = debug_exit_write,
+.valid.min_access_size = 1,
+.valid.max_access_size = 1,
+.endianness = DEVICE_LITTLE_ENDIAN,
+};
+
+static int debug_exit_initfn(ISADevice *dev)
+{
+ISADebugExitState *isa = ISA_DEBUG_EXIT_DEVICE(dev);
+
+memory_region_init_io(&isa->io, &debug_exit_ops, isa,
+  TYPE_ISA_DEBUG_EXIT_DEVICE, isa->access_size);
+memory_region_add_subregion(isa_address_space_io(dev),
+isa->iobase, &isa->io);
+return 0;
+}
+
+static Property debug_exit_properties[] = {
+DEFINE_PROP_HEX32("iobase", ISADebugExitState, iobase, 0x501),
+DEFINE_PROP_UINT8("access-size", ISADebugExitState, access_size, 1),
+DEFINE_PROP_END_OF_LIST(),
+};
+
+static void debug_exit_class_initfn(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+ISADeviceClass *ic = ISA_DEVICE_CLASS(klass);
+ic->init = debug_exit_initfn;
+dc->props = debug_exit_properties;
+}
+
+static TypeInfo debug_exit_info = {
+.name  = TYPE_ISA_DEBUG_EXIT_DEVICE,
+.parent= TYPE_ISA_DEVICE,
+.instance_size = sizeof(ISADebugExitState),
+.class_init= debug_exit_class_initfn,
+};
+
+static void debug_exit_register_types(void)
+{
+type_register_static(&debug_exit_info);
+}
+
+type_init(debug_exit_register_types)
diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
index 0d3f6a8..56aaa9d 100644
--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -3,7 +3,7 @@ obj-y += apic_common.o apic.o kvmvapic.o
 obj-y += sga.o ioapic_common.o ioapic.o piix_pci.o
 obj-y += vmport.o
 obj-y += pci-hotplug.o smbios.o wdt_ib700.o
-obj-y += debugcon.o multiboot.o
+obj-y += debugcon.o debugexit.o multiboot.o
 obj-y += pc_piix.o
 obj-y += pc_sysfw.o
 obj-y += lpc_ich9.o q35.o pc_q35.o
-- 
1.7.10.4

[Qemu-devel] [PATCH 2/2] hw: Add test device for unittests execution v6

[Lucas Meneghel Rodrigues]

Add a test device which supports the kvmctl ioports,
so one can run the KVM unittest suite.

Intended Usage:

qemu-system-x86_64\
-device pc-testdev -serial stdio \
-device isa-debugexit,iobase=0xf4,access-size=4 \
-kernel /path/to/kvm/unittests/msr.flat

Where msr.flat is one of the KVM unittests, present on a
separate repo,

git://git.kernel.org/pub/scm/virt/kvm/kvm-unit-tests.git

Changes from v5:
* Fixed rebase mistake

Changes from v4:
* Pass iomem_buf as an opaque, as requested by Blue
* Ported to new MMIO schema, as requested by Jan

Changes from v3:
* Ported all register_ioport functions to memory API

Changes from v2:

* Rename struct testdev to PCTestdev
* Embed ioport_data into PCTestdev struct
* Porting most register_ioport functions to memory API

Changes from v1:

* Removed unused testdev member
* Renamed device to a less generic name, pc-testdev

Initial changes from initial attempt:

* Removed port 0xf1, since now kvm-unit-tests use
  serial
* Removed exit code port 0xf4, since that can be
  replaced by

-device isa-debugexit,iobase=0xf4,access-size=4

* Removed ram size port 0xd1, since guest memory
  size can be retrieved from firmware, there's a
  patch for kvm-unit-tests including an API to
  retrieve that value.

CC: Paolo Bonzini 
Signed-off-by: Alexander Graf 
Signed-off-by: Gerd Hoffmann 
Signed-off-by: Marcelo Tosatti 
Signed-off-by: Lucas Meneghel Rodrigues 
---
 hw/i386/Makefile.objs |1 +
 hw/pc-testdev.c   |  156 +
 2 files changed, 157 insertions(+)
 create mode 100644 hw/pc-testdev.c

diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
index 56aaa9d..1ac5fc5 100644
--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -12,5 +12,6 @@ obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
 obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o xen_pt_msi.o
 obj-y += kvm/
 obj-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o
+obj-y += pc-testdev.o
 
 obj-y := $(addprefix ../,$(obj-y))
diff --git a/hw/pc-testdev.c b/hw/pc-testdev.c
new file mode 100644
index 000..75889e7
--- /dev/null
+++ b/hw/pc-testdev.c
@@ -0,0 +1,156 @@
+/*
+ * QEMU x86 ISA testdev
+ *
+ * Copyright (c) 2012 Avi Kivity, Gerd Hoffmann, Marcelo Tosatti
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+/*
+ * This device is used to test KVM features specific to the x86 port, such
+ * as emulation, power management, interrupt routing, among others. It's meant
+ * to be used like:
+ *
+ * qemu-system-x86_64 -device pc-testdev -serial stdio \
+ * -device isa-debugexit,iobase=0xf4,access-size=2 \
+ * -kernel /home/lmr/Code/virt-test.git/kvm/unittests/msr.flat
+ *
+ * Where msr.flat is one of the KVM unittests, present on a separate repo,
+ * git://git.kernel.org/pub/scm/virt/kvm/kvm-unit-tests.git
+*/
+
+#include 
+#include "hw.h"
+#include "qdev.h"
+#include "isa.h"
+#include "exec-memory.h"
+
+#define IOMEM_LEN0x1
+
+typedef struct PCTestdev {
+ISADevice dev;
+MemoryRegion iomem;
+uint32_t ioport_data;
+char iomem_buf[IOMEM_LEN];
+} PCTestdev;
+
+#define TYPE_TESTDEV "pc-testdev"
+#define TESTDEV(obj) \
+ OBJECT_CHECK(struct PCTestdev, (obj), TYPE_TESTDEV)
+
+static void test_device_irq_line(void *opaque, uint32_t addr, uint32_t data)
+{
+struct PCTestdev *dev = opaque;
+qemu_set_irq(isa_get_irq(&dev->dev, addr - 0x2000), !!data);
+}
+
+static void test_device_ioport_write(void *opaque, uint32_t addr, uint32_t 
data)
+{
+struct PCTestdev *dev = opaque;
+dev->ioport_data = data;
+}
+
+static uint32_t test_device_ioport_read(void *opaque, uint32_t addr)
+{
+struct PCTestdev *dev = opaque;
+return dev->ioport_data;
+}
+
+static void test_device_flush_page(void *opaque, uint32_t addr, uint32_t data)
+{
+hwaddr len = 4096;
+void *a = cpu_physi

[Qemu-devel] [PATCH 1/2] hw: add isa-debug-exit device

[Lucas Meneghel Rodrigues]

From: Gerd Hoffmann 

When present it makes qemu exit on any write.
Mapped to port 0x501 by default.

Without this patch Anthony doesn't allow me to
remove the bochs bios debug ports because his
test suite uses this.

Changes from v1: Add access_size property to the
device, needed for kvm-unit-tests.

Signed-off-by: Gerd Hoffmann 
---
 hw/debugexit.c|   73 +
 hw/i386/Makefile.objs |2 +-
 2 files changed, 74 insertions(+), 1 deletion(-)
 create mode 100644 hw/debugexit.c

diff --git a/hw/debugexit.c b/hw/debugexit.c
new file mode 100644
index 000..dfe1b2d
--- /dev/null
+++ b/hw/debugexit.c
@@ -0,0 +1,73 @@
+/*
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 or
+ * (at your option) version 3 of the License.
+ */
+
+#include "hw.h"
+#include "isa.h"
+
+#define TYPE_ISA_DEBUG_EXIT_DEVICE "isa-debug-exit"
+#define ISA_DEBUG_EXIT_DEVICE(obj) \
+ OBJECT_CHECK(ISADebugExitState, (obj), TYPE_ISA_DEBUG_EXIT_DEVICE)
+
+typedef struct ISADebugExitState {
+ISADevice parent_obj;
+
+uint32_t iobase;
+uint8_t access_size;
+MemoryRegion io;
+} ISADebugExitState;
+
+static void debug_exit_write(void *opaque, hwaddr addr, uint64_t val,
+ unsigned width)
+{
+exit((val << 1) | 1);
+}
+
+static const MemoryRegionOps debug_exit_ops = {
+.write = debug_exit_write,
+.valid.min_access_size = 1,
+.valid.max_access_size = 1,
+.endianness = DEVICE_LITTLE_ENDIAN,
+};
+
+static int debug_exit_initfn(ISADevice *dev)
+{
+ISADebugExitState *isa = ISA_DEBUG_EXIT_DEVICE(dev);
+
+memory_region_init_io(&isa->io, &debug_exit_ops, isa,
+  TYPE_ISA_DEBUG_EXIT_DEVICE, isa->access_size);
+memory_region_add_subregion(isa_address_space_io(dev),
+isa->iobase, &isa->io);
+return 0;
+}
+
+static Property debug_exit_properties[] = {
+DEFINE_PROP_HEX32("iobase", ISADebugExitState, iobase, 0x501),
+DEFINE_PROP_UINT8("access-size", ISADebugExitState, access_size, 1),
+DEFINE_PROP_END_OF_LIST(),
+};
+
+static void debug_exit_class_initfn(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+ISADeviceClass *ic = ISA_DEVICE_CLASS(klass);
+ic->init = debug_exit_initfn;
+dc->props = debug_exit_properties;
+}
+
+static TypeInfo debug_exit_info = {
+.name  = TYPE_ISA_DEBUG_EXIT_DEVICE,
+.parent= TYPE_ISA_DEVICE,
+.instance_size = sizeof(ISADebugExitState),
+.class_init= debug_exit_class_initfn,
+};
+
+static void debug_exit_register_types(void)
+{
+type_register_static(&debug_exit_info);
+}
+
+type_init(debug_exit_register_types)
diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
index 0d3f6a8..56aaa9d 100644
--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -3,7 +3,7 @@ obj-y += apic_common.o apic.o kvmvapic.o
 obj-y += sga.o ioapic_common.o ioapic.o piix_pci.o
 obj-y += vmport.o
 obj-y += pci-hotplug.o smbios.o wdt_ib700.o
-obj-y += debugcon.o multiboot.o
+obj-y += debugcon.o debugexit.o multiboot.o
 obj-y += pc_piix.o
 obj-y += pc_sysfw.o
 obj-y += lpc_ich9.o q35.o pc_q35.o
-- 
1.7.10.4

[Qemu-devel] [PATCH 1/2] hw: add isa-debug-exit device v3

[Lucas Meneghel Rodrigues]

From: Gerd Hoffmann 

When present it makes qemu exit on any write.
Mapped to port 0x501 by default.

Without this patch Anthony doesn't allow me to
remove the bochs bios debug ports because his
test suite uses this.

Changes from v2: Fixed rebase mistake

Changes from v1: Add access_size property to the
device, needed for kvm-unit-tests.

Signed-off-by: Gerd Hoffmann 
---
 hw/debugexit.c|   73 +
 hw/i386/Makefile.objs |2 +-
 2 files changed, 74 insertions(+), 1 deletion(-)
 create mode 100644 hw/debugexit.c

diff --git a/hw/debugexit.c b/hw/debugexit.c
new file mode 100644
index 000..dfe1b2d
--- /dev/null
+++ b/hw/debugexit.c
@@ -0,0 +1,73 @@
+/*
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 or
+ * (at your option) version 3 of the License.
+ */
+
+#include "hw.h"
+#include "isa.h"
+
+#define TYPE_ISA_DEBUG_EXIT_DEVICE "isa-debug-exit"
+#define ISA_DEBUG_EXIT_DEVICE(obj) \
+ OBJECT_CHECK(ISADebugExitState, (obj), TYPE_ISA_DEBUG_EXIT_DEVICE)
+
+typedef struct ISADebugExitState {
+ISADevice parent_obj;
+
+uint32_t iobase;
+uint8_t access_size;
+MemoryRegion io;
+} ISADebugExitState;
+
+static void debug_exit_write(void *opaque, hwaddr addr, uint64_t val,
+ unsigned width)
+{
+exit((val << 1) | 1);
+}
+
+static const MemoryRegionOps debug_exit_ops = {
+.write = debug_exit_write,
+.valid.min_access_size = 1,
+.valid.max_access_size = 1,
+.endianness = DEVICE_LITTLE_ENDIAN,
+};
+
+static int debug_exit_initfn(ISADevice *dev)
+{
+ISADebugExitState *isa = ISA_DEBUG_EXIT_DEVICE(dev);
+
+memory_region_init_io(&isa->io, &debug_exit_ops, isa,
+  TYPE_ISA_DEBUG_EXIT_DEVICE, isa->access_size);
+memory_region_add_subregion(isa_address_space_io(dev),
+isa->iobase, &isa->io);
+return 0;
+}
+
+static Property debug_exit_properties[] = {
+DEFINE_PROP_HEX32("iobase", ISADebugExitState, iobase, 0x501),
+DEFINE_PROP_UINT8("access-size", ISADebugExitState, access_size, 1),
+DEFINE_PROP_END_OF_LIST(),
+};
+
+static void debug_exit_class_initfn(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+ISADeviceClass *ic = ISA_DEVICE_CLASS(klass);
+ic->init = debug_exit_initfn;
+dc->props = debug_exit_properties;
+}
+
+static TypeInfo debug_exit_info = {
+.name  = TYPE_ISA_DEBUG_EXIT_DEVICE,
+.parent= TYPE_ISA_DEVICE,
+.instance_size = sizeof(ISADebugExitState),
+.class_init= debug_exit_class_initfn,
+};
+
+static void debug_exit_register_types(void)
+{
+type_register_static(&debug_exit_info);
+}
+
+type_init(debug_exit_register_types)
diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
index 0d3f6a8..56aaa9d 100644
--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -3,7 +3,7 @@ obj-y += apic_common.o apic.o kvmvapic.o
 obj-y += sga.o ioapic_common.o ioapic.o piix_pci.o
 obj-y += vmport.o
 obj-y += pci-hotplug.o smbios.o wdt_ib700.o
-obj-y += debugcon.o multiboot.o
+obj-y += debugcon.o debugexit.o multiboot.o
 obj-y += pc_piix.o
 obj-y += pc_sysfw.o
 obj-y += lpc_ich9.o q35.o pc_q35.o
-- 
1.7.10.4

[Qemu-devel] [PATCH 0/2] Add pc-testdev to qemu v6

[Lucas Meneghel Rodrigues]

These two patches introduce:

 1) A ISA debugexit port device, that when written, causes qemu
to exit with the exit code passed as parameter.
 2) A port of the existing testdev present on qemu-kvm to qemu

I took Gerd's recent patch and modified it to include the access-size
property, as well as fixed problems pointed in previous reviews of
the test device itself.

I did notice that with the new test device, a lot of the
kvm-unit-tests are failing. The same tests are passing fine
under qemu-kvm, meaning there are some bugs we need to address.

Example:

qemu-kvm:

$ x86_64-softmmu/qemu-system-x86_64 -device testdev -serial stdio -kernel 
/path/to/kvm/unittests/pcid.flat
VNC server running on `127.0.0.1:5900'
enabling apic
CPUID consistency: PASS
Test on PCID when disabled: PASS
Test on INVPCID when disabled: PASS
3 tests, 0 failures
$ echo $?
0

qemu:

$ x86_64-softmmu/qemu-system-x86_64 -device pc-testdev -serial stdio -device 
isa-debugexit,iobase=0xf4,access-size=4 -kernel /path/to/kvm/unittests/pcid.flat
VNC server running on `127.0.0.1:5900'
enabling apic
CPUID consistency: PASS
Test on PCID when disabled: FAIL
Test on INVPCID when disabled: PASS
3 tests, 1 failures
$ echo $?
3


Gerd Hoffmann (1):
  hw: add isa-debug-exit device v3

Lucas Meneghel Rodrigues (1):
  hw: Add test device for unittests execution v6

 hw/debugexit.c|   73 +++
 hw/i386/Makefile.objs |3 +-
 hw/pc-testdev.c   |  156 +
 3 files changed, 231 insertions(+), 1 deletion(-)
 create mode 100644 hw/debugexit.c
 create mode 100644 hw/pc-testdev.c

-- 
1.7.10.4

[Qemu-devel] [PATCH 0/2] Add pc-testdev to qemu v6

[Lucas Meneghel Rodrigues]

These two patches introduce:

 1) A ISA debugexit port device, that when written, causes qemu
to exit with the exit code passed as parameter.
 2) A port of the existing testdev present on qemu-kvm to qemu

I took Gerd's recent patch and modified it to include the access-size
property, as well as fixed problems pointed in previous reviews of
the test device itself.

I did notice that with the new test device, a lot of the
kvm-unit-tests are failing. The same tests are passing fine
under qemu-kvm, meaning there are some bugs we need to address.

Example:

qemu-kvm:

$ x86_64-softmmu/qemu-system-x86_64 -device testdev -serial stdio -kernel 
/path/to/kvm/unittests/pcid.flat
VNC server running on `127.0.0.1:5900'
enabling apic
CPUID consistency: PASS
Test on PCID when disabled: PASS
Test on INVPCID when disabled: PASS
3 tests, 0 failures
$ echo $?
0

qemu:

$ x86_64-softmmu/qemu-system-x86_64 -device pc-testdev -serial stdio -device 
isa-debugexit,iobase=0xf4,access-size=4 -kernel /path/to/kvm/unittests/pcid.flat
VNC server running on `127.0.0.1:5900'
enabling apic
CPUID consistency: PASS
Test on PCID when disabled: FAIL
Test on INVPCID when disabled: PASS
3 tests, 1 failures
$ echo $?
3

Gerd Hoffmann (1):
  hw: add isa-debug-exit device v4

Lucas Meneghel Rodrigues (1):
  hw: Add test device for unittests execution v7

 hw/debugexit.c|   87 ++
 hw/i386/Makefile.objs |3 +-
 hw/pc-testdev.c   |  161 +
 3 files changed, 250 insertions(+), 1 deletion(-)
 create mode 100644 hw/debugexit.c
 create mode 100644 hw/pc-testdev.c

-- 
1.7.10.4

[Qemu-devel] [PATCH 1/2] hw: add isa-debug-exit device v4

[Lucas Meneghel Rodrigues]

From: Gerd Hoffmann 

When present it makes qemu exit on any write.
Mapped to port 0x501 by default.

Without this patch Anthony doesn't allow me to
remove the bochs bios debug ports because his
test suite uses this.

Changes from v3:
 * Added a short description
 * Added a copyright notice
 * Added Signed-off-by line to the commit
   message
 * Made the GPL license header to say
   'or any later version', to simplify
   things and be more in line with other
   qemu source files
 * Turned TypeInfo into static const

Changes from v2:
 * Fixed rebase mistake

Changes from v1:
 * Add access_size property to the device,
   needed for kvm-unit-tests.

Signed-off-by: Gerd Hoffmann 
Signed-off-by: Lucas Meneghel Rodrigues 
---
 hw/debugexit.c|   87 +++
 hw/i386/Makefile.objs |2 +-
 hw/pc-testdev.c   |  156 +
 3 files changed, 244 insertions(+), 1 deletion(-)
 create mode 100644 hw/debugexit.c
 create mode 100644 hw/pc-testdev.c

diff --git a/hw/debugexit.c b/hw/debugexit.c
new file mode 100644
index 000..b90983b
--- /dev/null
+++ b/hw/debugexit.c
@@ -0,0 +1,87 @@
+/*
+ * QEMU debug exit port ("LGPL'ed-VGA-BIOS-style port 501/502") emulation
+ *
+ * Copyright (c) 2012 Gerd Hoffmann
+ *
+ * (Based on previous work from Herve Poussineau)
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ * See the GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include "hw.h"
+#include "isa.h"
+
+#define TYPE_ISA_DEBUG_EXIT_DEVICE "isa-debug-exit"
+#define ISA_DEBUG_EXIT_DEVICE(obj) \
+ OBJECT_CHECK(ISADebugExitState, (obj), TYPE_ISA_DEBUG_EXIT_DEVICE)
+
+typedef struct ISADebugExitState {
+ISADevice parent_obj;
+
+uint32_t iobase;
+uint8_t access_size;
+MemoryRegion io;
+} ISADebugExitState;
+
+static void debug_exit_write(void *opaque, hwaddr addr, uint64_t val,
+ unsigned width)
+{
+exit((val << 1) | 1);
+}
+
+static const MemoryRegionOps debug_exit_ops = {
+.write = debug_exit_write,
+.valid.min_access_size = 1,
+.valid.max_access_size = 1,
+.endianness = DEVICE_LITTLE_ENDIAN,
+};
+
+static int debug_exit_initfn(ISADevice *dev)
+{
+ISADebugExitState *isa = ISA_DEBUG_EXIT_DEVICE(dev);
+
+memory_region_init_io(&isa->io, &debug_exit_ops, isa,
+  TYPE_ISA_DEBUG_EXIT_DEVICE, isa->access_size);
+memory_region_add_subregion(isa_address_space_io(dev),
+isa->iobase, &isa->io);
+return 0;
+}
+
+static Property debug_exit_properties[] = {
+DEFINE_PROP_HEX32("iobase", ISADebugExitState, iobase, 0x501),
+DEFINE_PROP_UINT8("access-size", ISADebugExitState, access_size, 1),
+DEFINE_PROP_END_OF_LIST(),
+};
+
+static void debug_exit_class_initfn(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+ISADeviceClass *ic = ISA_DEVICE_CLASS(klass);
+ic->init = debug_exit_initfn;
+dc->props = debug_exit_properties;
+}
+
+static const TypeInfo debug_exit_info = {
+.name  = TYPE_ISA_DEBUG_EXIT_DEVICE,
+.parent= TYPE_ISA_DEVICE,
+.instance_size = sizeof(ISADebugExitState),
+.class_init= debug_exit_class_initfn,
+};
+
+static void debug_exit_register_types(void)
+{
+type_register_static(&debug_exit_info);
+}
+
+type_init(debug_exit_register_types)
diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
index 0d3f6a8..56aaa9d 100644
--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -3,7 +3,7 @@ obj-y += apic_common.o apic.o kvmvapic.o
 obj-y += sga.o ioapic_common.o ioapic.o piix_pci.o
 obj-y += vmport.o
 obj-y += pci-hotplug.o smbios.o wdt_ib700.o
-obj-y += debugcon.o multiboot.o
+obj-y += debugcon.o debugexit.o multiboot.o
 obj-y += pc_piix.o
 obj-y += pc_sysfw.o
 obj-y += lpc_ich9.o q35.o pc_q35.o
diff --git a/hw/pc-testdev.c b/hw/pc-testdev.c
new file mode 100644
index 000..06cf872
--- /dev/null
+++ b/hw/pc-testdev.c
@@ -0,0 +1,156 @@
+/*
+ * QEMU x86 ISA testdev
+ *
+ * Copyright (c) 2012 Avi Kivity, Gerd Hoffmann, Marcelo Tosatti
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction,

[Qemu-devel] [PATCH 2/2] hw: Add test device for unittests execution v7

[Lucas Meneghel Rodrigues]

Add a test device which supports the kvmctl ioports,
so one can run the KVM unittest suite.

Intended Usage:

qemu-system-x86_64\
-device pc-testdev -serial stdio \
-device isa-debugexit,iobase=0xf4,access-size=4 \
-kernel /path/to/kvm/unittests/msr.flat

Where msr.flat is one of the KVM unittests, present on a
separate repo,

git://git.kernel.org/pub/scm/virt/kvm/kvm-unit-tests.git

Changes from v6:
* Only use sys/mman.h and mprotect on non windows
  platforms

Changes from v5:
* Fixed rebase mistake

Changes from v4:
* Pass iomem_buf as an opaque, as requested by Blue
* Ported to new MMIO schema, as requested by Jan

Changes from v3:
* Ported all register_ioport functions to memory API

Changes from v2:

* Rename struct testdev to PCTestdev
* Embed ioport_data into PCTestdev struct
* Porting most register_ioport functions to memory API

Changes from v1:

* Removed unused testdev member
* Renamed device to a less generic name, pc-testdev

Initial changes from initial attempt:

* Removed port 0xf1, since now kvm-unit-tests use
  serial
* Removed exit code port 0xf4, since that can be
  replaced by

-device isa-debugexit,iobase=0xf4,access-size=4

* Removed ram size port 0xd1, since guest memory
  size can be retrieved from firmware, there's a
  patch for kvm-unit-tests including an API to
  retrieve that value.

CC: Paolo Bonzini 
Signed-off-by: Alexander Graf 
Signed-off-by: Gerd Hoffmann 
Signed-off-by: Marcelo Tosatti 
Signed-off-by: Lucas Meneghel Rodrigues 
---
 hw/i386/Makefile.objs |1 +
 hw/pc-testdev.c   |5 +
 2 files changed, 6 insertions(+)

diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
index 56aaa9d..1ac5fc5 100644
--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -12,5 +12,6 @@ obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
 obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o xen_pt_msi.o
 obj-y += kvm/
 obj-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o
+obj-y += pc-testdev.o
 
 obj-y := $(addprefix ../,$(obj-y))
diff --git a/hw/pc-testdev.c b/hw/pc-testdev.c
index 06cf872..1bea8ea 100644
--- a/hw/pc-testdev.c
+++ b/hw/pc-testdev.c
@@ -35,7 +35,10 @@
  * git://git.kernel.org/pub/scm/virt/kvm/kvm-unit-tests.git
  */
 
+#ifndef _WIN32
 #include 
+#endif
+
 #include "hw.h"
 #include "qdev.h"
 #include "isa.h"
@@ -77,10 +80,12 @@ static void test_device_flush_page(void *opaque, uint32_t 
addr, uint32_t data)
 hwaddr len = 4096;
 void *a = cpu_physical_memory_map(data & ~0xffful, &len, 0);
 
+#ifndef _WIN32
 /* We might not be able to get the full page, only mprotect what we 
actually
have mapped */
 mprotect(a, len, PROT_NONE);
 mprotect(a, len, PROT_READ|PROT_WRITE);
+#endif
 cpu_physical_memory_unmap(a, len, 0, 0);
 }
 
-- 
1.7.10.4

[Qemu-devel] [PATCH 2/2] hw: Add test device for unittests execution v8

[Lucas Meneghel Rodrigues]

Add a test device which supports the kvmctl ioports,
so one can run the KVM unittest suite.

Intended Usage:

qemu-system-x86_64\
-device pc-testdev -serial stdio \
-device isa-debugexit,iobase=0xf4,access-size=4 \
-kernel /path/to/kvm/unittests/msr.flat

Where msr.flat is one of the KVM unittests, present on a
separate repo,

git://git.kernel.org/pub/scm/virt/kvm/kvm-unit-tests.git

Changes from v7:
* Fixed rebase mistake... again.

Changes from v6:
* Only use sys/mman.h and mprotect on non windows
  platforms

Changes from v5:
* Fixed rebase mistake

Changes from v4:
* Pass iomem_buf as an opaque, as requested by Blue
* Ported to new MMIO schema, as requested by Jan

Changes from v3:
* Ported all register_ioport functions to memory API

Changes from v2:

* Rename struct testdev to PCTestdev
* Embed ioport_data into PCTestdev struct
* Porting most register_ioport functions to memory API

Changes from v1:

* Removed unused testdev member
* Renamed device to a less generic name, pc-testdev

Initial changes from initial attempt:

* Removed port 0xf1, since now kvm-unit-tests use
  serial
* Removed exit code port 0xf4, since that can be
  replaced by

-device isa-debugexit,iobase=0xf4,access-size=4

* Removed ram size port 0xd1, since guest memory
  size can be retrieved from firmware, there's a
  patch for kvm-unit-tests including an API to
  retrieve that value.

CC: Paolo Bonzini 
Signed-off-by: Alexander Graf 
Signed-off-by: Gerd Hoffmann 
Signed-off-by: Marcelo Tosatti 
Signed-off-by: Lucas Meneghel Rodrigues 
---
 hw/i386/Makefile.objs |1 +
 hw/pc-testdev.c   |  161 +
 2 files changed, 162 insertions(+)
 create mode 100644 hw/pc-testdev.c

diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
index 56aaa9d..1ac5fc5 100644
--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -12,5 +12,6 @@ obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
 obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o xen_pt_msi.o
 obj-y += kvm/
 obj-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o
+obj-y += pc-testdev.o
 
 obj-y := $(addprefix ../,$(obj-y))
diff --git a/hw/pc-testdev.c b/hw/pc-testdev.c
new file mode 100644
index 000..1bea8ea
--- /dev/null
+++ b/hw/pc-testdev.c
@@ -0,0 +1,161 @@
+/*
+ * QEMU x86 ISA testdev
+ *
+ * Copyright (c) 2012 Avi Kivity, Gerd Hoffmann, Marcelo Tosatti
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+/*
+ * This device is used to test KVM features specific to the x86 port, such
+ * as emulation, power management, interrupt routing, among others. It's meant
+ * to be used like:
+ *
+ * qemu-system-x86_64 -device pc-testdev -serial stdio \
+ * -device isa-debugexit,iobase=0xf4,access-size=2 \
+ * -kernel /home/lmr/Code/virt-test.git/kvm/unittests/msr.flat
+ *
+ * Where msr.flat is one of the KVM unittests, present on a separate repo,
+ * git://git.kernel.org/pub/scm/virt/kvm/kvm-unit-tests.git
+ */
+
+#ifndef _WIN32
+#include 
+#endif
+
+#include "hw.h"
+#include "qdev.h"
+#include "isa.h"
+#include "exec-memory.h"
+
+#define IOMEM_LEN0x1
+
+typedef struct PCTestdev {
+ISADevice dev;
+MemoryRegion iomem;
+uint32_t ioport_data;
+char iomem_buf[IOMEM_LEN];
+} PCTestdev;
+
+#define TYPE_TESTDEV "pc-testdev"
+#define TESTDEV(obj) \
+ OBJECT_CHECK(struct PCTestdev, (obj), TYPE_TESTDEV)
+
+static void test_device_irq_line(void *opaque, uint32_t addr, uint32_t data)
+{
+struct PCTestdev *dev = opaque;
+qemu_set_irq(isa_get_irq(&dev->dev, addr - 0x2000), !!data);
+}
+
+static void test_device_ioport_write(void *opaque, uint32_t addr, uint32_t 
data)
+{
+struct PCTestdev *dev = opaque;
+dev->ioport_data = data;
+}
+
+static uint32_t test_device_ioport_read(void *opaque, uint32_t addr)
+{
+struct PCTestdev *dev = opaque;
+ret

[Qemu-devel] [PATCH 1/2] hw: add isa-debug-exit device v5

[Lucas Meneghel Rodrigues]

From: Gerd Hoffmann 

When present it makes qemu exit on any write.
Mapped to port 0x501 by default.

Without this patch Anthony doesn't allow me to
remove the bochs bios debug ports because his
test suite uses this.

Changes from v4:
 * Fixed rebase mistake... again.

Changes from v3:
 * Added a short description
 * Added a copyright notice
 * Added Signed-off-by line to the commit
   message
 * Made the GPL license header to say
   'or any later version', to simplify
   things and be more in line with other
   qemu source files
 * Turned TypeInfo into static const

Changes from v2:
 * Fixed rebase mistake

Changes from v1:
 * Add access_size property to the device,
   needed for kvm-unit-tests.

Signed-off-by: Gerd Hoffmann 
Signed-off-by: Lucas Meneghel Rodrigues 
---
 hw/debugexit.c|   87 +
 hw/i386/Makefile.objs |2 +-
 2 files changed, 88 insertions(+), 1 deletion(-)
 create mode 100644 hw/debugexit.c

diff --git a/hw/debugexit.c b/hw/debugexit.c
new file mode 100644
index 000..b90983b
--- /dev/null
+++ b/hw/debugexit.c
@@ -0,0 +1,87 @@
+/*
+ * QEMU debug exit port ("LGPL'ed-VGA-BIOS-style port 501/502") emulation
+ *
+ * Copyright (c) 2012 Gerd Hoffmann
+ *
+ * (Based on previous work from Herve Poussineau)
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ * See the GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include "hw.h"
+#include "isa.h"
+
+#define TYPE_ISA_DEBUG_EXIT_DEVICE "isa-debug-exit"
+#define ISA_DEBUG_EXIT_DEVICE(obj) \
+ OBJECT_CHECK(ISADebugExitState, (obj), TYPE_ISA_DEBUG_EXIT_DEVICE)
+
+typedef struct ISADebugExitState {
+ISADevice parent_obj;
+
+uint32_t iobase;
+uint8_t access_size;
+MemoryRegion io;
+} ISADebugExitState;
+
+static void debug_exit_write(void *opaque, hwaddr addr, uint64_t val,
+ unsigned width)
+{
+exit((val << 1) | 1);
+}
+
+static const MemoryRegionOps debug_exit_ops = {
+.write = debug_exit_write,
+.valid.min_access_size = 1,
+.valid.max_access_size = 1,
+.endianness = DEVICE_LITTLE_ENDIAN,
+};
+
+static int debug_exit_initfn(ISADevice *dev)
+{
+ISADebugExitState *isa = ISA_DEBUG_EXIT_DEVICE(dev);
+
+memory_region_init_io(&isa->io, &debug_exit_ops, isa,
+  TYPE_ISA_DEBUG_EXIT_DEVICE, isa->access_size);
+memory_region_add_subregion(isa_address_space_io(dev),
+isa->iobase, &isa->io);
+return 0;
+}
+
+static Property debug_exit_properties[] = {
+DEFINE_PROP_HEX32("iobase", ISADebugExitState, iobase, 0x501),
+DEFINE_PROP_UINT8("access-size", ISADebugExitState, access_size, 1),
+DEFINE_PROP_END_OF_LIST(),
+};
+
+static void debug_exit_class_initfn(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+ISADeviceClass *ic = ISA_DEVICE_CLASS(klass);
+ic->init = debug_exit_initfn;
+dc->props = debug_exit_properties;
+}
+
+static const TypeInfo debug_exit_info = {
+.name  = TYPE_ISA_DEBUG_EXIT_DEVICE,
+.parent= TYPE_ISA_DEVICE,
+.instance_size = sizeof(ISADebugExitState),
+.class_init= debug_exit_class_initfn,
+};
+
+static void debug_exit_register_types(void)
+{
+type_register_static(&debug_exit_info);
+}
+
+type_init(debug_exit_register_types)
diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
index 0d3f6a8..56aaa9d 100644
--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -3,7 +3,7 @@ obj-y += apic_common.o apic.o kvmvapic.o
 obj-y += sga.o ioapic_common.o ioapic.o piix_pci.o
 obj-y += vmport.o
 obj-y += pci-hotplug.o smbios.o wdt_ib700.o
-obj-y += debugcon.o multiboot.o
+obj-y += debugcon.o debugexit.o multiboot.o
 obj-y += pc_piix.o
 obj-y += pc_sysfw.o
 obj-y += lpc_ich9.o q35.o pc_q35.o
-- 
1.7.10.4

[Qemu-devel] [PATCH 0/2] Add pc-testdev to qemu v7

[Lucas Meneghel Rodrigues]

These two patches introduce:

 1) A ISA debugexit port device, that when written, causes qemu
to exit with the exit code passed as parameter.
 2) A port of the existing testdev present on qemu-kvm to qemu

I took Gerd's recent patch and modified it to include the access-size
property, as well as fixed problems pointed in previous reviews of
the test device itself. Had to fix silly rebase mistakes, twice.

I did notice that with the new test device, a lot of the
kvm-unit-tests are failing. The same tests are passing fine
under qemu-kvm, meaning there are some bugs we need to address.

Example:

qemu-kvm:

$ x86_64-softmmu/qemu-system-x86_64 -device testdev -serial stdio -kernel 
/path/to/kvm/unittests/pcid.flat
VNC server running on `127.0.0.1:5900'
enabling apic
CPUID consistency: PASS
Test on PCID when disabled: PASS
Test on INVPCID when disabled: PASS
3 tests, 0 failures
$ echo $?
0

qemu:

$ x86_64-softmmu/qemu-system-x86_64 -device pc-testdev -serial stdio -device 
isa-debugexit,iobase=0xf4,access-size=4 -kernel /path/to/kvm/unittests/pcid.flat
VNC server running on `127.0.0.1:5900'
enabling apic
CPUID consistency: PASS
Test on PCID when disabled: FAIL
Test on INVPCID when disabled: PASS
3 tests, 1 failures
$ echo $?
3

Gerd Hoffmann (1):
  hw: add isa-debug-exit device v5

Lucas Meneghel Rodrigues (1):
  hw: Add test device for unittests execution v8

 hw/i386/Makefile.objs |3 +-
 hw/pc-testdev.c   |  161 +
 2 files changed, 163 insertions(+), 1 deletion(-)
 create mode 100644 hw/pc-testdev.c

-- 
1.7.10.4

Re: [Qemu-devel] [Virt-test-devel] [Autotest PATCH 1/2] virt run: fix typo in help message

[Lucas Meneghel Rodrigues]

Ok, this looks good, applied, thanks!

On Sat, Dec 29, 2012 at 11:02 PM, Amos Kong  wrote:
> type 'kvm' already been changed to 'qemu'
>
> Signed-off-by: Amos Kong 
> ---
>  run |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/run b/run
> index 97dcdad..aac332a 100755
> --- a/run
> +++ b/run
> @@ -145,7 +145,7 @@ class VirtTestRunParser(optparse.OptionParser):
>  general.add_option("-v", "--verbose", action="store_true",
> dest="verbose", help="Exhibit debug messages")
>  general.add_option("-t", "--type", action="store", dest="type",
> -   help="Choose test type (kvm, libvirt, v2v)")
> +   help="Choose test type (qemu, libvirt, v2v)")
>  general.add_option("-c", "--config", action="store", dest="config",
> help="Explicitly choose a cartesian config")
>  general.add_option("-r", "--restore-image", action="store_true",
> @@ -174,7 +174,7 @@ class VirtTestRunParser(optparse.OptionParser):
>   "%default"))
>  self.add_option_group(general)
>
> -qemu = optparse.OptionGroup(self, 'Options specific to the kvm test')
> +qemu = optparse.OptionGroup(self, 'Options specific to the qemu 
> test')
>  qemu.add_option("--qemu-bin", action="store", dest="qemu",
>  help=("Path to a custom qemu binary to be tested. "
>"Default path: %s" % qemu_bin_path))
> --
> 1.7.1
>
> ___
> Virt-test-devel mailing list
> virt-test-de...@redhat.com
> https://www.redhat.com/mailman/listinfo/virt-test-devel



-- 
Lucas

Re: [Qemu-devel] [Autotest PATCH 2/2] virt run: add three logical case filters

[Lucas Meneghel Rodrigues]

Hmmm, about this one, I'm worried about making things more complex...

The way I see the problem at hand, I'd say if people want to customize
things, they'd be better of creating their own, specialized config
files rather than adding command line flags to manipulate the test
sets.

So my initial stand on this particular patch is NACK, but you might
convince me otherwise :)

On Sat, Dec 29, 2012 at 11:10 PM, Amos Kong  wrote:
> On Sun, Dec 30, 2012 at 09:02:09AM +0800, Amos Kong wrote:
>> This patch added there options for filtering cases by logics,
>>
>> For example:
>> ./run -t qemu -c tests.cfg --oronly="WinXP Win7" --andonly="boot 64" 
>> --not="sp1"
>
> Oh! a typo in commitlog
>
>  ./run -t qemu -c tests.cfg --or="WinXP Win7" --and="boot 64" --not="sp1"
>
>>   (following cases will be executed)
>>
>> Test1: virtio_blk.smp2.virtio_net.WinXP.64.boot
>> Test2: virtio_blk.smp2.virtio_net.Win7.64.boot
> ...
>
> Amos
>



-- 
Lucas

Re: [Qemu-devel] Headsup: windows virtio networking does not work on current git

[Lucas Meneghel Rodrigues]

On 02/05/2013 11:49 PM, Lucas Meneghel Rodrigues wrote:

On 02/05/2013 09:58 AM, Michael S. Tsirkin wrote:

Vadim, can you please describe in a bit more details what the actual
issue
here is, from the windows or windows driver point of view?  Is it really
that bad that the config space size changed?  Why it has this effect?
Is this size specified in the inf file somehow?  Just for us to actually
understand the issue?

Thanks!

/mjt


This should be educational:
https://github.com/YanVugenfirer/kvm-guest-drivers-windows/commit/10413d2bbef295cc0e0e75131147793ccc382155



I guess I chose a bad timing to do test grid maintenance. I've stopped
the grid last Thursday to upgrade the test code, then when I resumed
operations yesterday, I was checking out on the qemu.git results.

I found out that all Windows tests were failing due to a failure to
start the virtio driver. Attached there's an ogg video of what happens.
I found this thread and then things make sense...

Well, anyway, once a fix is in place, it'll be easy to verify whether
the problem is solved. I'll keep checking on this thread for a fix and
report whether it was successful or not.



Just reporting that the latest build of the internal virtio drivers 
(-54) passed all tests on latest qemu.git, no more networking problems.


Kernel (kvm.git):

02/06 18:31:29 INFO |   git:0153| git commit ID is 
949db153b6466c6f7cad5a427ecea94985927311 (tag kvm-3.8-1-13793-g949db15)


QEMU (qemu.git):

02/06 18:46:06 INFO |   git:0153| git commit ID is 
5f876756c57c15f5e14d4136fc432b74f05f082b (tag v1.4.0-rc0-15-g5f87675)


Windows Drivers build: 54 (Iso built automatically during the night).

[Qemu-devel] qemu throws KVM internal error - Any ideas?

[Lucas Meneghel Rodrigues]

Hey Gleb, Marcelo:

I was looking at the sanity jobs for qemu.git and found this error that 
happened during RHEL 6.3 guest reboot test:


 02/09 05:16:45 INFO |   aexpect:0797| [qemu output] KVM internal 
error. Suberror: 1

 02/09 05:16:45 INFO |   aexpect:0797| [qemu output] emulation failure
 02/09 05:16:45 INFO |   aexpect:0797| [qemu output] 
RAX=81000122 RBX=01f92000 RCX=01d4e000 
RDX=0100
 02/09 05:16:45 INFO |   aexpect:0797| [qemu output] 
RSI=00093780 RDI=01a8c000 RBP= 
RSP=02367040
 02/09 05:16:45 INFO |   aexpect:0797| [qemu output] R8 
=01a8c000 R9 = R10=0038 
R11=0038
 02/09 05:16:45 INFO |   aexpect:0797| [qemu output] 
R12= R13= R14= 
R15=
 02/09 05:16:45 INFO |   aexpect:0797| [qemu output] 
RIP=81000122 RFL=00010006 [-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
 02/09 05:16:45 INFO |   aexpect:0797| [qemu output] ES = 
  00c0
 02/09 05:16:45 INFO |   aexpect:0797| [qemu output] CS =0010 
  00a09b00 DPL=0 CS64 [-RA]
 02/09 05:16:45 INFO |   aexpect:0797| [qemu output] SS = 
  00c0
 02/09 05:16:45 INFO |   aexpect:0797| [qemu output] DS = 
  00c0
 02/09 05:16:45 INFO |   aexpect:0797| [qemu output] FS = 
  00c0
 02/09 05:16:45 INFO |   aexpect:0797| [qemu output] GS = 
  00c0
 02/09 05:16:45 INFO |   aexpect:0797| [qemu output] LDT= 
  00c0
 02/09 05:16:45 INFO |   aexpect:0797| [qemu output] TR =0020 
 0fff 00808b00 DPL=0 TSS64-busy
 02/09 05:16:45 INFO |   aexpect:0797| [qemu output] GDT= 
004c9ff8 0030
 02/09 05:16:45 INFO |   aexpect:0797| [qemu output] IDT= 
 
 02/09 05:16:45 INFO |   aexpect:0797| [qemu output] CR0=8011 
CR2= CR3=9238e090 CR4=00a0
 02/09 05:16:45 INFO |   aexpect:0797| [qemu output] 
DR0= DR1= DR2= 
DR3=
 02/09 05:16:45 INFO |   aexpect:0797| [qemu output] 
DR6=0ff0 DR7=0400

 02/09 05:16:45 INFO |   aexpect:0797| [qemu output] EFER=0500
 02/09 05:16:45 INFO |   aexpect:0797| [qemu output] Code=?? ?? ?? ?? 
?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??


qemu.git SHA1:

 02/09 04:41:50 INFO |   git:0153| git commit ID is 
70ef6a5b7121cb54d7f9713d6315fb8547761bfc (tag v1.4.0-rc1-7-g70ef6a5)


kvm.git SHA1:

 02/09 04:26:44 INFO |   git:0153| git commit ID is 
949db153b6466c6f7cad5a427ecea94985927311 (tag kvm-3.8-1-13793-g949db15)


I'm not sure this is reproducible (1st time I've seen this), I thought 
it'd be good to report it here though. We also seen the sieve unittest 
failure that I have already reported a couple of days ago.


Cheers,

Lucas

Re: [Qemu-devel] [PATCH] qemu:cpuid: speedup test by 3x times if grub2 is available

[Lucas Meneghel Rodrigues]

On 02/14/2013 11:41 AM, Eduardo Habkost wrote:

I'd glad to amend patch, if there are suggestions how to generalize it and
improve "create boot image" process for distros that doesn't have
grub2-mkrescue.


A reusable tool/script would be useful even outside virt-test. Anybody
who uses -kernel/-initrd today may want a more efficient solution (IIRC,
virt-install uses -kernel/-initrd when installing from a Fedora
repository URL).

But if we made that an independent tool we would have the additional
problem of having the new tool packaged and installed on the host. So
having something specific inside virt-test makes sense by now.


Absolutely, agreed.

Re: [Qemu-devel] [PATCH] qemu:cpuid: speedup test by 3x times if grub2 is available

[Lucas Meneghel Rodrigues]

On 02/14/2013 05:57 PM, Eduardo Habkost wrote:

On Thu, Feb 14, 2013 at 08:28:03PM +0100, Igor Mammedov wrote:

On Thu, 14 Feb 2013 13:13:18 +0100
Paolo Bonzini  wrote:


Il 14/02/2013 12:18, Eduardo Habkost ha scritto:

qemu boots from disk image 3 times faster than direct kernel load.

That's surprising. Do you have any idea why that happens?


Because kernel load uses MMIO (from fw_cfg), while booting from disk
uses at worst PCI DMA and at best virtio.

Paolo

I've tried Paolo's suggestion to run in TCG mode with instruction logging,
and it spends too much time reading 11K kernel from qemu compared to
kvm-unit-test kernel. I'll need debug it further to find out why.
But this patch looks unnecessary if I could fix qemu/seabios or test kernel
to reach the same load time as kvm-unit-test kernel.


Agreed.

Lucas, please don't apply this patch yet, until we find the actual cause
of the slow booting.


Okey dokey.

[Qemu-devel] qemu.git/qemu-kvm.git bugs during migrate + reboot

[Lucas Meneghel Rodrigues]

Hi guys,

We're seeing the following problem during upstream testing:

qemu: VQ 0 size 0x80 Guest index 0x2d6
inconsistent with Host index 0x18: delta 0x2be
qemu: warning:  error while loading state for
instance 0x0 of device ':00:04.0/virtio-blk'
load of migration failed

This is happening consistently with qemu and qemu-kvm. Test case is 
simple, while the vm goes through a reboot loop, a parallel ping-pong 
migration loop happens.


I'm happy to provide more details and logs.

Lucas

Re: [Qemu-devel] qemu.git/qemu-kvm.git bugs during migrate + reboot

[Lucas Meneghel Rodrigues]

On 09/25/2012 09:59 AM, Anthony Liguori wrote:

Lucas Meneghel Rodrigues  writes:


Hi guys,

We're seeing the following problem during upstream testing:

qemu: VQ 0 size 0x80 Guest index 0x2d6
  inconsistent with Host index 0x18: delta 0x2be
  qemu: warning:  error while loading state for
  instance 0x0 of device ':00:04.0/virtio-blk'
  load of migration failed

This is happening consistently with qemu and qemu-kvm. Test case is
simple, while the vm goes through a reboot loop, a parallel ping-pong
migration loop happens.

I'm happy to provide more details and logs.


Can you provide the full command line?


Sure. The problem happens with *all* migration protocols, let's use as 
an example the protocol fd. The vm is started with:


09/22 07:26:19 INFO |kvm_vm:1605| /usr/local/autotest/tests/kvm/qemu
09/22 07:26:19 INFO |kvm_vm:1605| -S
09/22 07:26:19 INFO |kvm_vm:1605| -name 'vm1'
09/22 07:26:19 INFO |kvm_vm:1605| -nodefaults
09/22 07:26:19 INFO |kvm_vm:1605| -chardev 
socket,id=hmp_id_humanmonitor1,path=/tmp/monitor-humanmonitor1-20120922-072139-HDnHgnLh,server,nowait 

09/22 07:26:19 INFO |kvm_vm:1605| -mon 
chardev=hmp_id_humanmonitor1,mode=readline
09/22 07:26:19 INFO |kvm_vm:1605| -chardev 
socket,id=qmp_id_qmpmonitor1,path=/tmp/monitor-qmpmonitor1-20120922-072139-HDnHgnLh,server,nowait 

09/22 07:26:19 INFO |kvm_vm:1605| -mon 
chardev=qmp_id_qmpmonitor1,mode=control
09/22 07:26:19 INFO |kvm_vm:1605| -chardev 
socket,id=serial_id_20120922-072139-HDnHgnLh,path=/tmp/serial-20120922-072139-HDnHgnLh,server,nowait 

09/22 07:26:19 INFO |kvm_vm:1605| -device 
isa-serial,chardev=serial_id_20120922-072139-HDnHgnLh
09/22 07:26:19 INFO |kvm_vm:1605| -chardev 
socket,id=seabioslog_id_20120922-072139-HDnHgnLh,path=/tmp/seabios-20120922-072139-HDnHgnLh,server,nowait 

09/22 07:26:19 INFO |kvm_vm:1605| -device 
isa-debugcon,chardev=seabioslog_id_20120922-072139-HDnHgnLh,iobase=0x402

09/22 07:26:19 INFO |kvm_vm:1605| -device ich9-usb-uhci1,id=usb1
09/22 07:26:19 INFO |kvm_vm:1605| -drive 
file='/tmp/kvm_autotest_root/images/rhel62-64.qcow2',if=none,cache=none,id=virtio0 

09/22 07:26:19 INFO |kvm_vm:1605| -device 
virtio-blk-pci,drive=virtio0
09/22 07:26:19 INFO |kvm_vm:1605| -device 
virtio-net-pci,netdev=idPQlGQt,mac='9a:4b:4c:4d:4e:4f',id='id01mORp'

09/22 07:26:19 INFO |kvm_vm:1605| -netdev tap,id=idPQlGQt,fd=24
09/22 07:26:19 INFO |kvm_vm:1605| -m 2048
09/22 07:26:19 INFO |kvm_vm:1605| -smp 
2,cores=1,threads=1,sockets=2
09/22 07:26:19 INFO |kvm_vm:1605| -device 
usb-tablet,id=usb-tablet1,bus=usb1.0,port=1

09/22 07:26:19 INFO |kvm_vm:1605| -vnc :0
09/22 07:26:19 INFO |kvm_vm:1605| -vga std
09/22 07:26:19 INFO |kvm_vm:1605| -rtc 
base=utc,clock=host,driftfix=none

09/22 07:26:19 INFO |kvm_vm:1605| -boot order=cdn,once=c,menu=off
09/22 07:26:19 INFO |kvm_vm:1605| -enable-kvm
09/22 07:26:19 INFO |kvm_vm:1605| -enable-kvm

Then the state will be migrated to a new process:

09/22 07:26:48 INFO |kvm_vm:1605| /usr/local/autotest/tests/kvm/qemu
09/22 07:26:48 INFO |kvm_vm:1605| -S
09/22 07:26:48 INFO |kvm_vm:1605| -name 'vm1'
09/22 07:26:48 INFO |kvm_vm:1605| -nodefaults
09/22 07:26:48 INFO |kvm_vm:1605| -chardev 
socket,id=hmp_id_humanmonitor1,path=/tmp/monitor-humanmonitor1-20120922-072648-g6gL8thp,server,nowait 

09/22 07:26:48 INFO |kvm_vm:1605| -mon 
chardev=hmp_id_humanmonitor1,mode=readline
09/22 07:26:48 INFO |kvm_vm:1605| -chardev 
socket,id=qmp_id_qmpmonitor1,path=/tmp/monitor-qmpmonitor1-20120922-072648-g6gL8thp,server,nowait 

09/22 07:26:48 INFO |kvm_vm:1605| -mon 
chardev=qmp_id_qmpmonitor1,mode=control
09/22 07:26:48 INFO |kvm_vm:1605| -chardev 
socket,id=serial_id_20120922-072648-g6gL8thp,path=/tmp/serial-20120922-072648-g6gL8thp,server,nowait 

09/22 07:26:48 INFO |kvm_vm:1605| -device 
isa-serial,chardev=serial_id_20120922-072648-g6gL8thp
09/22 07:26:48 INFO |kvm_vm:1605| -chardev 
socket,id=seabioslog_id_20120922-072648-g6gL8thp,path=/tmp/seabios-20120922-072648-g6gL8thp,server,nowait 

09/22 07:26:48 INFO |kvm_vm:1605| -device 
isa-debugcon,chardev=seabioslog_id_20120922-072648-g6gL8thp,iobase=0x402

09/22 07:26:48 INFO |kvm_vm:1605| -device ich9-usb-uhci1,id=usb1
09/22 07:26:48 INFO |kvm_vm:1605| -drive 
file='/tmp/kvm_autotest_root/images/rhel62-64.qcow2',if=none,cache=none,id=virtio0 

09/22 07:26:48 INFO |kvm_vm:1605| -device 
virtio-blk-pci,drive=virtio0
09/22 07:26:48 INFO |kvm_vm:1605| -device 
virtio-net-pci,netdev=idSld9kt,mac='9a:4b:4c:4d:4e:4f',id='idFBA7Vj'

09/22 07:26:48 INFO |kvm_vm:1605| -netdev tap,id=idSld9kt,fd=45
09/22 07:2

[Qemu-devel] Bug: When setting hardware clock on linux guest, hwclock shows crazy date (in the year 2043)

[Lucas Meneghel Rodrigues]

Very easy to reproduce:

1) Build the latest qemu.git (we've captured this on internal automated 
testing, verified manually), the commit for reference is:


14:07:02 INFO | git commit ID is 
6f8fd2530e9a530f237240daf1c981fa5df7f978 (tag v1.2.0-461-g6f8fd25)


2) Install a linux guest in it (caught with RHEL 6.2, verified with 
Fedora 17)


3) In the linux guest, set the hardware clock with hwclock:

/sbin/hwclock --set --date "2/2/80 03:04:00"

4) Verify if hardware clock was set back to the eighties:

LC_ALL=C /sbin/hwclock

5) Observe amazed that hwclock reports a date in the year 2043:

14:09:34 INFO | ('hwclock', 'FAIL', 2, "Failed to set hwclock back to 
the eighties. Output of hwclock is 'Sun Dec 27 20:35:46 2043 -0.489664 
seconds'")

[Qemu-devel] [Bug 1058225] [NEW] When setting hardware clock on linux guest, hwclock shows crazy date (in the year 2043)

[Lucas Meneghel Rodrigues]

Public bug reported:

Very easy to reproduce:

1) Build the latest qemu.git (we've captured this on internal automated
testing, verified manually), the commit for reference is:

14:07:02 INFO | git commit ID is
6f8fd2530e9a530f237240daf1c981fa5df7f978 (tag v1.2.0-461-g6f8fd25)

2) Install a linux guest in it (caught with RHEL 6.2, verified with
Fedora 17)

3) In the linux guest, set the hardware clock with hwclock:

/sbin/hwclock --set --date "2/2/80 03:04:00"

4) Verify if hardware clock was set back to the eighties:

LC_ALL=C /sbin/hwclock

5) Observe amazed that hwclock reports a date in the year 2043:

14:09:34 INFO |  ('hwclock', 'FAIL', 2, "Failed to set hwclock
back to the eighties. Output of hwclock is 'Sun Dec 27 20:35:46 2043
-0.489664 seconds'")

** Affects: qemu
 Importance: Undecided
 Status: New


** Tags: kvmclock

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1058225

Title:
  When setting hardware clock on linux guest, hwclock shows crazy date
  (in the year 2043)

Status in QEMU:
  New

Bug description:
  Very easy to reproduce:

  1) Build the latest qemu.git (we've captured this on internal
  automated testing, verified manually), the commit for reference is:

  14:07:02 INFO | git commit ID is
  6f8fd2530e9a530f237240daf1c981fa5df7f978 (tag v1.2.0-461-g6f8fd25)

  2) Install a linux guest in it (caught with RHEL 6.2, verified with
  Fedora 17)

  3) In the linux guest, set the hardware clock with hwclock:

  /sbin/hwclock --set --date "2/2/80 03:04:00"

  4) Verify if hardware clock was set back to the eighties:

  LC_ALL=C /sbin/hwclock

  5) Observe amazed that hwclock reports a date in the year 2043:

  14:09:34 INFO |  ('hwclock', 'FAIL', 2, "Failed to set hwclock
  back to the eighties. Output of hwclock is 'Sun Dec 27 20:35:46 2043
  -0.489664 seconds'")

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1058225/+subscriptions

Re: [Qemu-devel] qemu-kvm: remove "boot=on|off" drive parameter compatibility

[Lucas Meneghel Rodrigues]

On 10/03/2012 06:55 AM, Gleb Natapov wrote:

On Mon, Oct 01, 2012 at 03:26:05PM +0200, Jan Kiszka wrote:

On 2012-10-01 15:19, Anthony Liguori wrote:

Jan Kiszka  writes:


On 2012-10-01 11:31, Marcelo Tosatti wrote:

It's not just about default configs. We need to validate if the
migration formats are truly compatible (qemu-kvm -> QEMU, the other way
around definitely not). For the command line switches, we could provide
a wrapper script that translates them into upstream format or simply
ignores them. That should be harmless to carry upstream.


qemu-kvm has:

  -no-kvm
  -no-kvm-irqchip
  -no-kvm-pit
  -no-kvm-pit-reinjection
  -tdf <- does nothing

There are replacements for all of the above.  If we need to add them to
qemu.git, it's not big deal to add them.


But I don't think we should add them to the source code. This can
perfectly be handled my a (disposable) script layer on top of
qemu-system-x86_64 - the namespace (qemu-kvm in most cases) is also free.



  -drive ...,boot= <- this is ignored

cpu_set command for CPU hotplug which is known broken in qemu-kvm.


Right, so nothing is lost when migrating to QEMU.



testdev which is nice but only used for development


Jan, do you have a plan for testdev device? It would be a pity to have
qemu-kvm just for that.


Yep, I did send patches with the testdev device present on qemu-kvm.git 
to qemu.git a while ago, but there were many comments on the review, I 
ended up not implementing everything that was asked and the patches were 
archived.


If nobody wants to step up to port it, I'll re-read the original thread 
and will spin up new patches (and try to go through the end with it). 
Executing the KVM unittests is something that we can't afford to lose, 
so I'd say it's important on this last mile effort to get rid of qemu-kvm.

[Qemu-devel] [PATCH] hw: Add test device for unittests execution

[Lucas Meneghel Rodrigues]

Add a test device which supports the kvmctl ioports,
so one can run the KVM unittest suite [1].

Usage:

qemu -device testdev

1) Removed port 0xf1, since now kvm-unit-tests use
   serial

2) Removed exit code port 0xf4, since that can be
   replaced by

-device isa-debugexit,iobase=0xf4,access-size=2

3) Removed ram size port 0xd1, since guest memory
   size can be retrieved from firmware, there's a
   patch for kvm-unit-tests including an API to
   retrieve that value.

[1] Preliminary versions of this patch were posted
to the mailing list about a year ago, I re-read the
comments of the thread, and had guidance from
Paolo about which ports to remove from the test
device.

CC: Paolo Bonzini 
Signed-off-by: Gerd Hoffmann 
Signed-off-by: Avi Kivity 
Signed-off-by: Marcelo Tosatti 
Signed-off-by: Lucas Meneghel Rodrigues 
---
 hw/i386/Makefile.objs |   1 +
 hw/testdev.c  | 131 ++
 2 files changed, 132 insertions(+)
 create mode 100644 hw/testdev.c

diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
index 8c764bb..64d2787 100644
--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -11,5 +11,6 @@ obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
 obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o xen_pt_msi.o
 obj-y += kvm/
 obj-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o
+obj-y += testdev.o
 
 obj-y := $(addprefix ../,$(obj-y))
diff --git a/hw/testdev.c b/hw/testdev.c
new file mode 100644
index 000..44070f2
--- /dev/null
+++ b/hw/testdev.c
@@ -0,0 +1,131 @@
+#include 
+#include "hw.h"
+#include "qdev.h"
+#include "isa.h"
+
+struct testdev {
+ISADevice dev;
+MemoryRegion iomem;
+CharDriverState *chr;
+};
+
+#define TYPE_TESTDEV "testdev"
+#define TESTDEV(obj) \
+ OBJECT_CHECK(struct testdev, (obj), TYPE_TESTDEV)
+
+static void test_device_irq_line(void *opaque, uint32_t addr, uint32_t data)
+{
+struct testdev *dev = opaque;
+
+qemu_set_irq(isa_get_irq(&dev->dev, addr - 0x2000), !!data);
+}
+
+static uint32 test_device_ioport_data;
+
+static void test_device_ioport_write(void *opaque, uint32_t addr, uint32_t 
data)
+{
+test_device_ioport_data = data;
+}
+
+static uint32_t test_device_ioport_read(void *opaque, uint32_t addr)
+{
+return test_device_ioport_data;
+}
+
+static void test_device_flush_page(void *opaque, uint32_t addr, uint32_t data)
+{
+target_phys_addr_t len = 4096;
+void *a = cpu_physical_memory_map(data & ~0xffful, &len, 0);
+
+mprotect(a, 4096, PROT_NONE);
+mprotect(a, 4096, PROT_READ|PROT_WRITE);
+cpu_physical_memory_unmap(a, len, 0, 0);
+}
+
+static char *iomem_buf;
+
+static uint32_t test_iomem_readb(void *opaque, target_phys_addr_t addr)
+{
+return iomem_buf[addr];
+}
+
+static uint32_t test_iomem_readw(void *opaque, target_phys_addr_t addr)
+{
+return *(uint16_t*)(iomem_buf + addr);
+}
+
+static uint32_t test_iomem_readl(void *opaque, target_phys_addr_t addr)
+{
+return *(uint32_t*)(iomem_buf + addr);
+}
+
+static void test_iomem_writeb(void *opaque, target_phys_addr_t addr, uint32_t 
val)
+{
+iomem_buf[addr] = val;
+}
+
+static void test_iomem_writew(void *opaque, target_phys_addr_t addr, uint32_t 
val)
+{
+*(uint16_t*)(iomem_buf + addr) = val;
+}
+
+static void test_iomem_writel(void *opaque, target_phys_addr_t addr, uint32_t 
val)
+{
+*(uint32_t*)(iomem_buf + addr) = val;
+}
+
+static const MemoryRegionOps test_iomem_ops = {
+.old_mmio = {
+.read = { test_iomem_readb, test_iomem_readw, test_iomem_readl, },
+.write = { test_iomem_writeb, test_iomem_writew, test_iomem_writel, },
+},
+.endianness = DEVICE_LITTLE_ENDIAN,
+};
+
+static int init_test_device(ISADevice *isa)
+{
+struct testdev *dev = DO_UPCAST(struct testdev, dev, isa);
+
+register_ioport_read(0xe0, 1, 1, test_device_ioport_read, dev);
+register_ioport_write(0xe0, 1, 1, test_device_ioport_write, dev);
+register_ioport_read(0xe0, 1, 2, test_device_ioport_read, dev);
+register_ioport_write(0xe0, 1, 2, test_device_ioport_write, dev);
+register_ioport_read(0xe0, 1, 4, test_device_ioport_read, dev);
+register_ioport_write(0xe0, 1, 4, test_device_ioport_write, dev);
+register_ioport_write(0xe4, 1, 4, test_device_flush_page, dev);
+register_ioport_write(0x2000, 24, 1, test_device_irq_line, NULL);
+iomem_buf = g_malloc0(0x1);
+memory_region_init_io(&dev->iomem, &test_iomem_ops, dev,
+  "testdev", 0x1);
+memory_region_add_subregion(isa_address_space(&dev->dev), 0xff00,
+  &dev->iomem);
+return 0;
+}
+
+static Property testdev_isa_properties[] = {
+DEFINE_PROP_CHR("chardev", struct testdev, chr),
+DEFINE_PROP_END_OF_LIST(),
+};
+
+static void testdev_class_init(ObjectClass *klass, v

Re: [Qemu-devel] [PATCH] hw: Add test device for unittests execution

[Lucas Meneghel Rodrigues]

On 10/04/2012 12:49 AM, Lucas Meneghel Rodrigues wrote:

Add a test device which supports the kvmctl ioports,
so one can run the KVM unittest suite [1].

Usage:

qemu -device testdev

1) Removed port 0xf1, since now kvm-unit-tests use
serial

2) Removed exit code port 0xf4, since that can be
replaced by

-device isa-debugexit,iobase=0xf4,access-size=2


I forgot to mention that this would work *if* the isa-debugexit device 
gets upstream. Paolo pointed this thread:


http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg00818.html

But it appears that no consensus was reached.


3) Removed ram size port 0xd1, since guest memory
size can be retrieved from firmware, there's a
patch for kvm-unit-tests including an API to
retrieve that value.

[1] Preliminary versions of this patch were posted
to the mailing list about a year ago, I re-read the
comments of the thread, and had guidance from
Paolo about which ports to remove from the test
device.

CC: Paolo Bonzini 
Signed-off-by: Gerd Hoffmann 
Signed-off-by: Avi Kivity 
Signed-off-by: Marcelo Tosatti 
Signed-off-by: Lucas Meneghel Rodrigues 
---
  hw/i386/Makefile.objs |   1 +
  hw/testdev.c  | 131 ++
  2 files changed, 132 insertions(+)
  create mode 100644 hw/testdev.c

diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
index 8c764bb..64d2787 100644
--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -11,5 +11,6 @@ obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o 
xen_pt_msi.o
  obj-y += kvm/
  obj-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o
+obj-y += testdev.o

  obj-y := $(addprefix ../,$(obj-y))
diff --git a/hw/testdev.c b/hw/testdev.c
new file mode 100644
index 000..44070f2
--- /dev/null
+++ b/hw/testdev.c
@@ -0,0 +1,131 @@
+#include 
+#include "hw.h"
+#include "qdev.h"
+#include "isa.h"
+
+struct testdev {
+ISADevice dev;
+MemoryRegion iomem;
+CharDriverState *chr;
+};
+
+#define TYPE_TESTDEV "testdev"
+#define TESTDEV(obj) \
+ OBJECT_CHECK(struct testdev, (obj), TYPE_TESTDEV)
+
+static void test_device_irq_line(void *opaque, uint32_t addr, uint32_t data)
+{
+struct testdev *dev = opaque;
+
+qemu_set_irq(isa_get_irq(&dev->dev, addr - 0x2000), !!data);
+}
+
+static uint32 test_device_ioport_data;
+
+static void test_device_ioport_write(void *opaque, uint32_t addr, uint32_t 
data)
+{
+test_device_ioport_data = data;
+}
+
+static uint32_t test_device_ioport_read(void *opaque, uint32_t addr)
+{
+return test_device_ioport_data;
+}
+
+static void test_device_flush_page(void *opaque, uint32_t addr, uint32_t data)
+{
+target_phys_addr_t len = 4096;
+void *a = cpu_physical_memory_map(data & ~0xffful, &len, 0);
+
+mprotect(a, 4096, PROT_NONE);
+mprotect(a, 4096, PROT_READ|PROT_WRITE);
+cpu_physical_memory_unmap(a, len, 0, 0);
+}
+
+static char *iomem_buf;
+
+static uint32_t test_iomem_readb(void *opaque, target_phys_addr_t addr)
+{
+return iomem_buf[addr];
+}
+
+static uint32_t test_iomem_readw(void *opaque, target_phys_addr_t addr)
+{
+return *(uint16_t*)(iomem_buf + addr);
+}
+
+static uint32_t test_iomem_readl(void *opaque, target_phys_addr_t addr)
+{
+return *(uint32_t*)(iomem_buf + addr);
+}
+
+static void test_iomem_writeb(void *opaque, target_phys_addr_t addr, uint32_t 
val)
+{
+iomem_buf[addr] = val;
+}
+
+static void test_iomem_writew(void *opaque, target_phys_addr_t addr, uint32_t 
val)
+{
+*(uint16_t*)(iomem_buf + addr) = val;
+}
+
+static void test_iomem_writel(void *opaque, target_phys_addr_t addr, uint32_t 
val)
+{
+*(uint32_t*)(iomem_buf + addr) = val;
+}
+
+static const MemoryRegionOps test_iomem_ops = {
+.old_mmio = {
+.read = { test_iomem_readb, test_iomem_readw, test_iomem_readl, },
+.write = { test_iomem_writeb, test_iomem_writew, test_iomem_writel, },
+},
+.endianness = DEVICE_LITTLE_ENDIAN,
+};
+
+static int init_test_device(ISADevice *isa)
+{
+struct testdev *dev = DO_UPCAST(struct testdev, dev, isa);
+
+register_ioport_read(0xe0, 1, 1, test_device_ioport_read, dev);
+register_ioport_write(0xe0, 1, 1, test_device_ioport_write, dev);
+register_ioport_read(0xe0, 1, 2, test_device_ioport_read, dev);
+register_ioport_write(0xe0, 1, 2, test_device_ioport_write, dev);
+register_ioport_read(0xe0, 1, 4, test_device_ioport_read, dev);
+register_ioport_write(0xe0, 1, 4, test_device_ioport_write, dev);
+register_ioport_write(0xe4, 1, 4, test_device_flush_page, dev);
+register_ioport_write(0x2000, 24, 1, test_device_irq_line, NULL);
+iomem_buf = g_malloc0(0x1);
+memory_region_init_io(&dev->iomem, &test_iomem_ops, dev,
+  "testdev", 0x1);
+memory_region_add_subregion(isa_address_space(&dev->dev), 0x

Re: [Qemu-devel] qemu-kvm: remove "boot=on|off" drive parameter compatibility

[Lucas Meneghel Rodrigues]

On 10/04/2012 07:48 AM, Jan Kiszka wrote:

On 2012-10-03 15:19, Paolo Bonzini wrote:

Il 03/10/2012 12:57, Lucas Meneghel Rodrigues ha scritto:

Yep, I did send patches with the testdev device present on qemu-kvm.git
to qemu.git a while ago, but there were many comments on the review, I
ended up not implementing everything that was asked and the patches were
archived.

If nobody wants to step up to port it, I'll re-read the original thread
and will spin up new patches (and try to go through the end with it).
Executing the KVM unittests is something that we can't afford to lose,
so I'd say it's important on this last mile effort to get rid of qemu-kvm.


Absolutely, IIRC the problem was that testdev did a little bit of
everything... let's see what's the functionality of testdev:

- write (port 0xf1), can be replaced in autotest with:
-device isa-debugcon,iobase=0xf1,chardev=...

- exit code (port 0xf4), see this series:
http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg00818.html

- ram size (port 0xd1).  If we can also patch kvm-unittests, the memory
is available in the CMOS or in fwcfg.  Here is the SeaBIOS code:

 u32 rs = ((inb_cmos(0x34) << 16) | (inb_cmos(0x35) << 24));
 if (rs)
 rs += 16 * 1024 * 1024;
 else
 rs = (((inb_cmos(0x30) << 10) | (inb_cmos(0x31) << 18))
   + 1 * 1024 * 1024);

The rest (ports 0xe0..0xe7, 0x2000..0x2017, MMIO) can be left in testdev.


IIRC, one of the biggest problem with testdev was its hack to inject
interrupts.


Jan, I assume this commit helps to fix this, right?

commit b334ec567f1de9a60349991e7b75083d569ddb0a
Author: Jan Kiszka 
Date:   Fri Mar 2 10:30:47 2012 +0100

qemu-kvm: Use upstream kvm-i8259

Drop the qemu-kvm version in favor of the equivalent upstream
implementation. This allows to move the i8259 back into the hwlib.

Note that this also drops the testdev hack and restores proper
isa_get_irq. If testdev scripts exist that inject > IRQ15, they need
fixing. Testing for these interrupts on the PIIX3 makes no practical
sense anyway as those lines are unused.

Signed-off-by: Jan Kiszka 
Signed-off-by: Avi Kivity 

Re: [Qemu-devel] qemu-kvm: remove "boot=on|off" drive parameter compatibility

[Lucas Meneghel Rodrigues]

On 10/04/2012 09:27 AM, Jan Kiszka wrote:

On 2012-10-04 14:10, Lucas Meneghel Rodrigues wrote:

On 10/04/2012 07:48 AM, Jan Kiszka wrote:

On 2012-10-03 15:19, Paolo Bonzini wrote:

Il 03/10/2012 12:57, Lucas Meneghel Rodrigues ha scritto:

Yep, I did send patches with the testdev device present on qemu-kvm.git
to qemu.git a while ago, but there were many comments on the review, I
ended up not implementing everything that was asked and the patches were
archived.

If nobody wants to step up to port it, I'll re-read the original thread
and will spin up new patches (and try to go through the end with it).
Executing the KVM unittests is something that we can't afford to lose,
so I'd say it's important on this last mile effort to get rid of qemu-kvm.


Absolutely, IIRC the problem was that testdev did a little bit of
everything... let's see what's the functionality of testdev:

- write (port 0xf1), can be replaced in autotest with:
-device isa-debugcon,iobase=0xf1,chardev=...

- exit code (port 0xf4), see this series:
http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg00818.html

- ram size (port 0xd1).  If we can also patch kvm-unittests, the memory
is available in the CMOS or in fwcfg.  Here is the SeaBIOS code:

  u32 rs = ((inb_cmos(0x34) << 16) | (inb_cmos(0x35) << 24));
  if (rs)
  rs += 16 * 1024 * 1024;
  else
  rs = (((inb_cmos(0x30) << 10) | (inb_cmos(0x31) << 18))
+ 1 * 1024 * 1024);

The rest (ports 0xe0..0xe7, 0x2000..0x2017, MMIO) can be left in testdev.


IIRC, one of the biggest problem with testdev was its hack to inject
interrupts.


Jan, I assume this commit helps to fix this, right?

commit b334ec567f1de9a60349991e7b75083d569ddb0a
Author: Jan Kiszka 
Date:   Fri Mar 2 10:30:47 2012 +0100

  qemu-kvm: Use upstream kvm-i8259

  Drop the qemu-kvm version in favor of the equivalent upstream
  implementation. This allows to move the i8259 back into the hwlib.

  Note that this also drops the testdev hack and restores proper
  isa_get_irq. If testdev scripts exist that inject > IRQ15, they need
  fixing. Testing for these interrupts on the PIIX3 makes no practical
  sense anyway as those lines are unused.

  Signed-off-by: Jan Kiszka 
  Signed-off-by: Avi Kivity 


Yes, this improved it a lot as we no longer depend on additional
changes. I'm not sure if there was resistance beyond that.

When cleaning up the code: register_ioport_read must be replaced with
the memory API.


I did look at the MemoryRegionOps/memory_region_init_io and still did 
not figure out how to port things. I'll send a v2 addressing all the 
comments made so far but this one, just to see if people are OK with the 
direction of the full patch, then if you could give me some pointers of 
how to do this conversion, it'd be great.

[Qemu-devel] [PATCH 0/2] Adding pc-testdev to qemu

[Lucas Meneghel Rodrigues]

These two patches introduce:

 1) A ISA debugexit port device, that when written, causes qemu
to exit with the exit code passed as parameter.
 2) A port of the existing testdev present on qemu-kvm to qemu

One particular comment of previous reviews wasn't addressed, but
I'd like people to see this to see if we're in the right direction.

Another thing I did notice is that with the new test device, a lot
of the kvm-unit-tests are failing. The same tests are passing fine
under qemu-kvm, meaning there are some bugs we need to address.

Example:

qemu-kvm:

$ x86_64-softmmu/qemu-system-x86_64 -device testdev -serial stdio -kernel 
/path/to/kvm/unittests/pcid.flat 
VNC server running on `127.0.0.1:5900'
enabling apic
CPUID consistency: PASS
Test on PCID when disabled: PASS
Test on INVPCID when disabled: PASS
3 tests, 0 failures
$ echo $?
0

qemu:

$ x86_64-softmmu/qemu-system-x86_64 -device pc-testdev -serial stdio -device 
isa-debugexit,iobase=0xf4,access-size=4 -kernel 
/path/to/kvm/unittests/pcid.flat 
VNC server running on `127.0.0.1:5900'
enabling apic
CPUID consistency: PASS
Test on PCID when disabled: FAIL
Test on INVPCID when disabled: PASS
3 tests, 1 failures
$ echo $?
3


Hervé Poussineau (1):
  debugexit: support for custom exit port (LGPL VGA BIOS port 0x501)

Lucas Meneghel Rodrigues (1):
  hw: Add test device for unittests execution v2

 hw/debugexit.c|  68 +
 hw/i386/Makefile.objs |   3 +-
 hw/pc-testdev.c   | 160 ++
 3 files changed, 230 insertions(+), 1 deletion(-)
 create mode 100644 hw/debugexit.c
 create mode 100644 hw/pc-testdev.c

-- 
1.7.11.4

[Qemu-devel] [PATCH 2/2] hw: Add test device for unittests execution v2

[Lucas Meneghel Rodrigues]

Add a test device which supports the kvmctl ioports,
so one can run the KVM unittest suite.

Intended Usage:

qemu-system-x86_64 -device pc-testdev -serial stdio \
-device isa-debugexit,iobase=0xf4,access-size=4 \
-kernel /path/to/kvm/unittests/msr.flat

Where msr.flat is one of the KVM unittests, present on a
separate repo,

git://git.kernel.org/pub/scm/virt/kvm/kvm-unit-tests.git

I still didn't figure out how to port register_ioport_read
to the memory API, but hopefully we'll get there.

Changes from v2:

1) Removed unused testdev member
2) Renamed device to a less generic name, pc-testdev

Initial changes from initial attempt:

1) Removed port 0xf1, since now kvm-unit-tests use
   serial
2) Removed exit code port 0xf4, since that can be
   replaced by

-device isa-debugexit,iobase=0xf4,access-size=4

3) Removed ram size port 0xd1, since guest memory
   size can be retrieved from firmware, there's a
   patch for kvm-unit-tests including an API to
   retrieve that value.

CC: Paolo Bonzini 
Signed-off-by: Gerd Hoffmann 
Signed-off-by: Avi Kivity 
Signed-off-by: Marcelo Tosatti 
Signed-off-by: Lucas Meneghel Rodrigues 
---
 hw/i386/Makefile.objs |   1 +
 hw/pc-testdev.c   | 160 ++
 2 files changed, 161 insertions(+)
 create mode 100644 hw/pc-testdev.c

diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
index b34c61c..3ef3b4a 100644
--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -11,5 +11,6 @@ obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
 obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o xen_pt_msi.o
 obj-y += kvm/
 obj-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o
+obj-y += pc-testdev.o
 
 obj-y := $(addprefix ../,$(obj-y))
diff --git a/hw/pc-testdev.c b/hw/pc-testdev.c
new file mode 100644
index 000..0234adb
--- /dev/null
+++ b/hw/pc-testdev.c
@@ -0,0 +1,160 @@
+/*
+ * QEMU x86 ISA testdev
+ *
+ * Copyright (c) 2012 Avi Kivity, Gerd Hoffmann, Marcelo Tosatti
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+/*
+ * This device is used to test KVM features specific to the x86 port, such
+ * as emulation, power management, interrupt routing, among others. It's meant
+ * to be used like:
+ *
+ * qemu-system-x86_64 -device pc-testdev -serial stdio \
+ * -device isa-debugexit,iobase=0xf4,access-size=2 \
+ * -kernel /home/lmr/Code/virt-test.git/kvm/unittests/msr.flat
+ *
+ * Where msr.flat is one of the KVM unittests, present on a separate repo,
+ * git://git.kernel.org/pub/scm/virt/kvm/kvm-unit-tests.git
+*/
+
+#include 
+#include "hw.h"
+#include "qdev.h"
+#include "isa.h"
+
+struct testdev {
+ISADevice dev;
+MemoryRegion iomem;
+};
+
+#define TYPE_TESTDEV "pc-testdev"
+#define TESTDEV(obj) \
+ OBJECT_CHECK(struct testdev, (obj), TYPE_TESTDEV)
+
+static void test_device_irq_line(void *opaque, uint32_t addr, uint32_t data)
+{
+struct testdev *dev = opaque;
+
+qemu_set_irq(isa_get_irq(&dev->dev, addr - 0x2000), !!data);
+}
+
+static uint32 test_device_ioport_data;
+
+static void test_device_ioport_write(void *opaque, uint32_t addr, uint32_t 
data)
+{
+test_device_ioport_data = data;
+}
+
+static uint32_t test_device_ioport_read(void *opaque, uint32_t addr)
+{
+return test_device_ioport_data;
+}
+
+static void test_device_flush_page(void *opaque, uint32_t addr, uint32_t data)
+{
+target_phys_addr_t len = 4096;
+void *a = cpu_physical_memory_map(data & ~0xffful, &len, 0);
+
+mprotect(a, 4096, PROT_NONE);
+mprotect(a, 4096, PROT_READ|PROT_WRITE);
+cpu_physical_memory_unmap(a, len, 0, 0);
+}
+
+static char *iomem_buf;
+
+static uint32_t test_iomem_readb(void *opaque, target_phys_addr_t addr)
+{
+return iomem_buf[addr];
+}
+
+static uint32_t test_iomem_readw(void *opaque, target_phys_addr_t addr)
+{
+return *(uint16_t*)(

[Qemu-devel] [PATCH 1/2] debugexit: support for custom exit port (LGPL VGA BIOS port 0x501)

[Lucas Meneghel Rodrigues]

From: Hervé Poussineau 

Add generic support for simple I/O port which, when written to, cause
QEMU to exit with the given written value.

There is no vmstate associated with the debugging port, simply because
the entire interface is a single, stateless, write-only port.

Signed-off-by: Hervé Poussineau 
---
 hw/debugexit.c| 68 +++
 hw/i386/Makefile.objs |  2 +-
 2 files changed, 69 insertions(+), 1 deletion(-)
 create mode 100644 hw/debugexit.c

diff --git a/hw/debugexit.c b/hw/debugexit.c
new file mode 100644
index 000..5c0d726
--- /dev/null
+++ b/hw/debugexit.c
@@ -0,0 +1,68 @@
+/*
+ * QEMU debug exit port ("LGPL'ed-VGA-BIOS-style port 501/502") emulation
+ *
+ * Copyright (c) 2012 Herve Poussineau
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ * See the GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see .
+ */
+
+#include "isa.h"
+
+typedef struct ISADebugExitState {
+ISADevice dev;
+uint32_t iobase;
+uint8_t access_size;
+} ISADebugExitState;
+
+static void debugexit_ioport_write(void *opaque, uint32_t addr, uint32_t val)
+{
+exit((val << 1) | 1);
+}
+
+static int debugexit_isa_initfn(ISADevice *dev)
+{
+ISADebugExitState *isa = DO_UPCAST(ISADebugExitState, dev, dev);
+
+register_ioport_write(isa->iobase, 1, isa->access_size,
+  debugexit_ioport_write, NULL);
+return 0;
+}
+
+static Property debugexit_isa_properties[] = {
+DEFINE_PROP_HEX32("iobase", ISADebugExitState, iobase, 0x501),
+DEFINE_PROP_UINT8("access-size", ISADebugExitState, access_size, 1),
+DEFINE_PROP_END_OF_LIST(),
+};
+
+static void debugexit_isa_class_initfn(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+ISADeviceClass *ic = ISA_DEVICE_CLASS(klass);
+ic->init = debugexit_isa_initfn;
+dc->props = debugexit_isa_properties;
+}
+
+static TypeInfo debugexit_isa_info = {
+.name  = "isa-debugexit",
+.parent= TYPE_ISA_DEVICE,
+.instance_size = sizeof(ISADebugExitState),
+.class_init= debugexit_isa_class_initfn,
+};
+
+static void debugexit_register_types(void)
+{
+type_register_static(&debugexit_isa_info);
+}
+
+type_init(debugexit_register_types)
diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
index 8c764bb..b34c61c 100644
--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -3,7 +3,7 @@ obj-y += apic_common.o apic.o kvmvapic.o
 obj-y += sga.o ioapic_common.o ioapic.o piix_pci.o
 obj-y += vmport.o
 obj-y += pci-hotplug.o smbios.o wdt_ib700.o
-obj-y += debugcon.o multiboot.o
+obj-y += debugcon.o debugexit.o multiboot.o
 obj-y += pc_piix.o
 obj-y += pc_sysfw.o
 obj-$(CONFIG_XEN) += xen_platform.o xen_apic.o
-- 
1.7.11.4

[Qemu-devel] [Bug 1062411] [NEW] QEMU fails during migration and reports "qemu: VQ 0 size 0x80 Guest index 0x2d6 inconsistent with Host index 0x18: delta 0x2be"

[Lucas Meneghel Rodrigues]

Public bug reported:

This issue is reproducing consistently on automated testing, verified on
manual testing (although it may require many tries).

Steps to reproduce:

1) Start a linux guest. The command line used by automated testing was:

10/05 06:48:27 INFO |kvm_vm:1605| MALLOC_PERTURB_=1 
/usr/local/autotest/tests/kvm/qemu 
10/05 06:48:27 INFO |kvm_vm:1605| -S 
10/05 06:48:27 INFO |kvm_vm:1605| -name 'vm1' 
10/05 06:48:27 INFO |kvm_vm:1605| -nodefaults 
10/05 06:48:27 INFO |kvm_vm:1605| -chardev 
socket,id=hmp_id_humanmonitor1,path=/tmp/monitor-humanmonitor1-20121005-062311-r6UwQhzg,server,nowait
 
10/05 06:48:27 INFO |kvm_vm:1605| -mon 
chardev=hmp_id_humanmonitor1,mode=readline 
10/05 06:48:27 INFO |kvm_vm:1605| -chardev 
socket,id=qmp_id_qmpmonitor1,path=/tmp/monitor-qmpmonitor1-20121005-062311-r6UwQhzg,server,nowait
 
10/05 06:48:27 INFO |kvm_vm:1605| -mon 
chardev=qmp_id_qmpmonitor1,mode=control 
10/05 06:48:27 INFO |kvm_vm:1605| -chardev 
socket,id=serial_id_20121005-062311-r6UwQhzg,path=/tmp/serial-20121005-062311-r6UwQhzg,server,nowait
 
10/05 06:48:27 INFO |kvm_vm:1605| -device 
isa-serial,chardev=serial_id_20121005-062311-r6UwQhzg 
10/05 06:48:27 INFO |kvm_vm:1605| -chardev 
socket,id=seabioslog_id_20121005-062311-r6UwQhzg,path=/tmp/seabios-20121005-062311-r6UwQhzg,server,nowait
 
10/05 06:48:27 INFO |kvm_vm:1605| -device 
isa-debugcon,chardev=seabioslog_id_20121005-062311-r6UwQhzg,iobase=0x402 
10/05 06:48:27 INFO |kvm_vm:1605| -device ich9-usb-uhci1,id=usb1 
10/05 06:48:27 INFO |kvm_vm:1605| -drive 
file='/tmp/kvm_autotest_root/images/rhel62-64.qcow2',if=none,cache=none,id=virtio0
 
10/05 06:48:27 INFO |kvm_vm:1605| -device virtio-blk-pci,drive=virtio0 
10/05 06:48:27 INFO |kvm_vm:1605| -device 
virtio-net-pci,netdev=idbdMz8N,mac='9a:cf:d0:d1:d2:d3',id='ida0Kc7l' 
10/05 06:48:27 INFO |kvm_vm:1605| -netdev tap,id=idbdMz8N,fd=21 
10/05 06:48:27 INFO |kvm_vm:1605| -m 2048 
10/05 06:48:27 INFO |kvm_vm:1605| -smp 2,cores=1,threads=1,sockets=2 
10/05 06:48:27 INFO |kvm_vm:1605| -device 
usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 
10/05 06:48:27 INFO |kvm_vm:1605| -vnc :0 
10/05 06:48:27 INFO |kvm_vm:1605| -vga std 
10/05 06:48:27 INFO |kvm_vm:1605| -rtc 
base=utc,clock=host,driftfix=none  
10/05 06:48:27 INFO |kvm_vm:1605| -boot order=cdn,once=c,menu=off  
10/05 06:48:27 INFO |kvm_vm:1605| -enable-kvm

Start a new VM in incoming mode. The example on this bug is using TCP
protocol:

10/05 07:18:56 INFO |kvm_vm:1605| MALLOC_PERTURB_=1 
/usr/local/autotest/tests/kvm/qemu 
10/05 07:18:56 INFO |kvm_vm:1605| -S 
10/05 07:18:56 INFO |kvm_vm:1605| -name 'vm1' 
10/05 07:18:56 INFO |kvm_vm:1605| -nodefaults 
10/05 07:18:56 INFO |kvm_vm:1605| -chardev 
socket,id=hmp_id_humanmonitor1,path=/tmp/monitor-humanmonitor1-20121005-071855-5QYsCtRS,server,nowait
 
10/05 07:18:56 INFO |kvm_vm:1605| -mon 
chardev=hmp_id_humanmonitor1,mode=readline 
10/05 07:18:56 INFO |kvm_vm:1605| -chardev 
socket,id=qmp_id_qmpmonitor1,path=/tmp/monitor-qmpmonitor1-20121005-071855-5QYsCtRS,server,nowait
 
10/05 07:18:56 INFO |kvm_vm:1605| -mon 
chardev=qmp_id_qmpmonitor1,mode=control 
10/05 07:18:56 INFO |kvm_vm:1605| -chardev 
socket,id=serial_id_20121005-071855-5QYsCtRS,path=/tmp/serial-20121005-071855-5QYsCtRS,server,nowait
 
10/05 07:18:56 INFO |kvm_vm:1605| -device 
isa-serial,chardev=serial_id_20121005-071855-5QYsCtRS 
10/05 07:18:56 INFO |kvm_vm:1605| -chardev 
socket,id=seabioslog_id_20121005-071855-5QYsCtRS,path=/tmp/seabios-20121005-071855-5QYsCtRS,server,nowait
 
10/05 07:18:56 INFO |kvm_vm:1605| -device 
isa-debugcon,chardev=seabioslog_id_20121005-071855-5QYsCtRS,iobase=0x402 
10/05 07:18:56 INFO |kvm_vm:1605| -device ich9-usb-uhci1,id=usb1 
10/05 07:18:56 INFO |kvm_vm:1605| -drive 
file='/tmp/kvm_autotest_root/images/rhel62-64.qcow2',if=none,cache=none,id=virtio0
 
10/05 07:18:56 INFO |kvm_vm:1605| -device virtio-blk-pci,drive=virtio0 
10/05 07:18:56 INFO |kvm_vm:1605| -device 
virtio-net-pci,netdev=idERNnUO,mac='9a:cf:d0:d1:d2:d3',id='ideI7zfw' 
10/05 07:18:56 INFO |kvm_vm:1605| -netdev tap,id=idERNnUO,fd=32 
10/05 07:18:56 INFO |kvm_vm:1605| -m 2048 
10/05 07:18:56 INFO |kvm_vm:1605| -smp 2,cores=1,threads=1,sockets=2 
10/05 07:18:56 INFO |kvm_vm:1605| -device 
usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 
10/05 07:18:56 INFO |kvm_vm:1605| -vnc :1 
10/05 07:18:56 INFO |kvm_vm:1605| -vga std 
10/05 07:18:56 INFO |kvm_vm:1605| -rtc 
base=utc,clock=host,driftfix=none  
10/05 07:18:56 INFO |kvm_vm:1605| -boot order=cdn,once=c,menu=off  
10/05 07:18:56 INFO |kvm_vm:1605| -enable-kvm 
10/05 07:18:56 INFO |kvm_vm:1605| -incoming tcp

[Qemu-devel] [Bug 1062411] Re: QEMU fails during migration and reports "qemu: VQ 0 size 0x80 Guest index 0x2d6 inconsistent with Host index 0x18: delta 0x2be"

[Lucas Meneghel Rodrigues]

No, I haven't. I'll do my best to reserve time this week to do so.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1062411

Title:
  QEMU fails during migration and reports "qemu: VQ 0 size 0x80 Guest
  index 0x2d6 inconsistent with Host index 0x18: delta 0x2be"

Status in QEMU:
  New

Bug description:
  This issue is reproducing consistently on automated testing, verified
  on manual testing (although it may require many tries).

  Steps to reproduce:

  1) Start a linux guest. The command line used by automated testing
  was:

  10/05 06:48:27 INFO |kvm_vm:1605| MALLOC_PERTURB_=1 
/usr/local/autotest/tests/kvm/qemu 
  10/05 06:48:27 INFO |kvm_vm:1605| -S 
  10/05 06:48:27 INFO |kvm_vm:1605| -name 'vm1' 
  10/05 06:48:27 INFO |kvm_vm:1605| -nodefaults 
  10/05 06:48:27 INFO |kvm_vm:1605| -chardev 
socket,id=hmp_id_humanmonitor1,path=/tmp/monitor-humanmonitor1-20121005-062311-r6UwQhzg,server,nowait
 
  10/05 06:48:27 INFO |kvm_vm:1605| -mon 
chardev=hmp_id_humanmonitor1,mode=readline 
  10/05 06:48:27 INFO |kvm_vm:1605| -chardev 
socket,id=qmp_id_qmpmonitor1,path=/tmp/monitor-qmpmonitor1-20121005-062311-r6UwQhzg,server,nowait
 
  10/05 06:48:27 INFO |kvm_vm:1605| -mon 
chardev=qmp_id_qmpmonitor1,mode=control 
  10/05 06:48:27 INFO |kvm_vm:1605| -chardev 
socket,id=serial_id_20121005-062311-r6UwQhzg,path=/tmp/serial-20121005-062311-r6UwQhzg,server,nowait
 
  10/05 06:48:27 INFO |kvm_vm:1605| -device 
isa-serial,chardev=serial_id_20121005-062311-r6UwQhzg 
  10/05 06:48:27 INFO |kvm_vm:1605| -chardev 
socket,id=seabioslog_id_20121005-062311-r6UwQhzg,path=/tmp/seabios-20121005-062311-r6UwQhzg,server,nowait
 
  10/05 06:48:27 INFO |kvm_vm:1605| -device 
isa-debugcon,chardev=seabioslog_id_20121005-062311-r6UwQhzg,iobase=0x402 
  10/05 06:48:27 INFO |kvm_vm:1605| -device ich9-usb-uhci1,id=usb1 
  10/05 06:48:27 INFO |kvm_vm:1605| -drive 
file='/tmp/kvm_autotest_root/images/rhel62-64.qcow2',if=none,cache=none,id=virtio0
 
  10/05 06:48:27 INFO |kvm_vm:1605| -device 
virtio-blk-pci,drive=virtio0 
  10/05 06:48:27 INFO |kvm_vm:1605| -device 
virtio-net-pci,netdev=idbdMz8N,mac='9a:cf:d0:d1:d2:d3',id='ida0Kc7l' 
  10/05 06:48:27 INFO |kvm_vm:1605| -netdev tap,id=idbdMz8N,fd=21 
  10/05 06:48:27 INFO |kvm_vm:1605| -m 2048 
  10/05 06:48:27 INFO |kvm_vm:1605| -smp 2,cores=1,threads=1,sockets=2 
  10/05 06:48:27 INFO |kvm_vm:1605| -device 
usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 
  10/05 06:48:27 INFO |kvm_vm:1605| -vnc :0 
  10/05 06:48:27 INFO |kvm_vm:1605| -vga std 
  10/05 06:48:27 INFO |kvm_vm:1605| -rtc 
base=utc,clock=host,driftfix=none  
  10/05 06:48:27 INFO |kvm_vm:1605| -boot order=cdn,once=c,menu=off  
  10/05 06:48:27 INFO |kvm_vm:1605| -enable-kvm

  Start a new VM in incoming mode. The example on this bug is using TCP
  protocol:

  10/05 07:18:56 INFO |kvm_vm:1605| MALLOC_PERTURB_=1 
/usr/local/autotest/tests/kvm/qemu 
  10/05 07:18:56 INFO |kvm_vm:1605| -S 
  10/05 07:18:56 INFO |kvm_vm:1605| -name 'vm1' 
  10/05 07:18:56 INFO |kvm_vm:1605| -nodefaults 
  10/05 07:18:56 INFO |kvm_vm:1605| -chardev 
socket,id=hmp_id_humanmonitor1,path=/tmp/monitor-humanmonitor1-20121005-071855-5QYsCtRS,server,nowait
 
  10/05 07:18:56 INFO |kvm_vm:1605| -mon 
chardev=hmp_id_humanmonitor1,mode=readline 
  10/05 07:18:56 INFO |kvm_vm:1605| -chardev 
socket,id=qmp_id_qmpmonitor1,path=/tmp/monitor-qmpmonitor1-20121005-071855-5QYsCtRS,server,nowait
 
  10/05 07:18:56 INFO |kvm_vm:1605| -mon 
chardev=qmp_id_qmpmonitor1,mode=control 
  10/05 07:18:56 INFO |kvm_vm:1605| -chardev 
socket,id=serial_id_20121005-071855-5QYsCtRS,path=/tmp/serial-20121005-071855-5QYsCtRS,server,nowait
 
  10/05 07:18:56 INFO |kvm_vm:1605| -device 
isa-serial,chardev=serial_id_20121005-071855-5QYsCtRS 
  10/05 07:18:56 INFO |kvm_vm:1605| -chardev 
socket,id=seabioslog_id_20121005-071855-5QYsCtRS,path=/tmp/seabios-20121005-071855-5QYsCtRS,server,nowait
 
  10/05 07:18:56 INFO |kvm_vm:1605| -device 
isa-debugcon,chardev=seabioslog_id_20121005-071855-5QYsCtRS,iobase=0x402 
  10/05 07:18:56 INFO |kvm_vm:1605| -device ich9-usb-uhci1,id=usb1 
  10/05 07:18:56 INFO |kvm_vm:1605| -drive 
file='/tmp/kvm_autotest_root/images/rhel62-64.qcow2',if=none,cache=none,id=virtio0
 
  10/05 07:18:56 INFO |kvm_vm:1605| -device 
virtio-blk-pci,drive=virtio0 
  10/05 07:18:56 INFO |kvm_vm:1605| -device 
virtio-net-pci,netdev=idERNnUO,mac='9a:cf:d0:d1:d2:d3',id='ideI7zfw' 
  10/05 07:18:56 INFO |kvm_vm:1605| -netdev tap,id=idERNnUO,fd=32 
  10/05 07:18:56 INFO |kvm_vm:1605| -m 2048 
  10/05 07:18:56 INFO |kvm_vm:1605| -smp 2,cores=1,threads

[Qemu-devel] [PATCH 1/2] debugexit: support for custom exit port (LGPL VGA BIOS port 0x501) v2

[Lucas Meneghel Rodrigues]

From: Hervé Poussineau 

Add generic support for simple I/O port which, when written to, cause
QEMU to exit with the given written value.

There is no vmstate associated with the debugging port, simply because
the entire interface is a single, stateless, write-only port.

Changes from v1:

 * Changing PIO from MMIO, as requested during review.

Signed-off-by: Hervé Poussineau 
---
 hw/debugexit.c| 75 +++
 hw/i386/Makefile.objs |  2 +-
 2 files changed, 76 insertions(+), 1 deletion(-)
 create mode 100644 hw/debugexit.c

diff --git a/hw/debugexit.c b/hw/debugexit.c
new file mode 100644
index 000..fe4608c
--- /dev/null
+++ b/hw/debugexit.c
@@ -0,0 +1,75 @@
+/*
+ * QEMU debug exit port ("LGPL'ed-VGA-BIOS-style port 501/502") emulation
+ *
+ * Copyright (c) 2012 Herve Poussineau
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ * See the GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see .
+ */
+
+#include "isa.h"
+#include "exec-memory.h"
+
+typedef struct ISADebugExitState {
+ISADevice dev;
+uint32_t iobase;
+uint8_t access_size;
+} ISADebugExitState;
+
+static void debugexit_ioport_write(void *opaque, uint32_t addr, uint32_t val)
+{
+exit((val << 1) | 1);
+}
+
+static int debugexit_isa_initfn(ISADevice *dev)
+{
+ISADebugExitState *isa = DO_UPCAST(ISADebugExitState, dev, dev);
+
+const struct MemoryRegionPortio debugexit_portio_list[] = {
+{ isa->iobase, 1, isa->access_size, .write = debugexit_ioport_write, },
+PORTIO_END_OF_LIST(),
+};
+PortioList *debugexit_port_list = g_new(PortioList, 1);
+portio_list_init(debugexit_port_list, debugexit_portio_list,
+ NULL, "isa-debugexit");
+portio_list_add(debugexit_port_list, get_system_io(), 0x0);
+return 0;
+}
+
+static Property debugexit_isa_properties[] = {
+DEFINE_PROP_HEX32("iobase", ISADebugExitState, iobase, 0x501),
+DEFINE_PROP_UINT8("access-size", ISADebugExitState, access_size, 1),
+DEFINE_PROP_END_OF_LIST(),
+};
+
+static void debugexit_isa_class_initfn(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+ISADeviceClass *ic = ISA_DEVICE_CLASS(klass);
+ic->init = debugexit_isa_initfn;
+dc->props = debugexit_isa_properties;
+}
+
+static TypeInfo debugexit_isa_info = {
+.name  = "isa-debugexit",
+.parent= TYPE_ISA_DEVICE,
+.instance_size = sizeof(ISADebugExitState),
+.class_init= debugexit_isa_class_initfn,
+};
+
+static void debugexit_register_types(void)
+{
+type_register_static(&debugexit_isa_info);
+}
+
+type_init(debugexit_register_types)
diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
index 8c764bb..b34c61c 100644
--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -3,7 +3,7 @@ obj-y += apic_common.o apic.o kvmvapic.o
 obj-y += sga.o ioapic_common.o ioapic.o piix_pci.o
 obj-y += vmport.o
 obj-y += pci-hotplug.o smbios.o wdt_ib700.o
-obj-y += debugcon.o multiboot.o
+obj-y += debugcon.o debugexit.o multiboot.o
 obj-y += pc_piix.o
 obj-y += pc_sysfw.o
 obj-$(CONFIG_XEN) += xen_platform.o xen_apic.o
-- 
1.7.11.4

[Qemu-devel] [PATCH 2/2] hw: Add test device for unittests execution v4

[Lucas Meneghel Rodrigues]

Add a test device which supports the kvmctl ioports,
so one can run the KVM unittest suite.

Intended Usage:

qemu-system-x86_64 -device pc-testdev -serial stdio \
-device isa-debugexit,iobase=0xf4,access-size=4 \
-kernel /path/to/kvm/unittests/msr.flat

Where msr.flat is one of the KVM unittests, present on a
separate repo,

git://git.kernel.org/pub/scm/virt/kvm/kvm-unit-tests.git

Changes from v3:
* Ported all register_ioport functions to memory API

Changes from v2:

* Rename struct testdev to PCTestdev
* Embed ioport_data into PCTestdev struct
* Porting most register_ioport functions to memory API

Changes from v1:

* Removed unused testdev member
* Renamed device to a less generic name, pc-testdev

Initial changes from initial attempt:

* Removed port 0xf1, since now kvm-unit-tests use
  serial
* Removed exit code port 0xf4, since that can be
  replaced by

-device isa-debugexit,iobase=0xf4,access-size=4

* Removed ram size port 0xd1, since guest memory
  size can be retrieved from firmware, there's a
  patch for kvm-unit-tests including an API to
  retrieve that value.

CC: Paolo Bonzini 
Signed-off-by: Gerd Hoffmann 
Signed-off-by: Avi Kivity 
Signed-off-by: Marcelo Tosatti 
Signed-off-by: Lucas Meneghel Rodrigues 
---
 hw/i386/Makefile.objs |   1 +
 hw/pc-testdev.c   | 167 ++
 2 files changed, 168 insertions(+)
 create mode 100644 hw/pc-testdev.c

diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
index b34c61c..3ef3b4a 100644
--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -11,5 +11,6 @@ obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
 obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o xen_pt_msi.o
 obj-y += kvm/
 obj-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o
+obj-y += pc-testdev.o
 
 obj-y := $(addprefix ../,$(obj-y))
diff --git a/hw/pc-testdev.c b/hw/pc-testdev.c
new file mode 100644
index 000..d326e01
--- /dev/null
+++ b/hw/pc-testdev.c
@@ -0,0 +1,167 @@
+/*
+ * QEMU x86 ISA testdev
+ *
+ * Copyright (c) 2012 Avi Kivity, Gerd Hoffmann, Marcelo Tosatti
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+/*
+ * This device is used to test KVM features specific to the x86 port, such
+ * as emulation, power management, interrupt routing, among others. It's meant
+ * to be used like:
+ *
+ * qemu-system-x86_64 -device pc-testdev -serial stdio \
+ * -device isa-debugexit,iobase=0xf4,access-size=2 \
+ * -kernel /home/lmr/Code/virt-test.git/kvm/unittests/msr.flat
+ *
+ * Where msr.flat is one of the KVM unittests, present on a separate repo,
+ * git://git.kernel.org/pub/scm/virt/kvm/kvm-unit-tests.git
+*/
+
+#include 
+#include "hw.h"
+#include "qdev.h"
+#include "isa.h"
+#include "exec-memory.h"
+
+typedef struct PCTestdev {
+ISADevice dev;
+MemoryRegion iomem;
+uint32_t ioport_data;
+} PCTestdev;
+
+#define TYPE_TESTDEV "pc-testdev"
+#define TESTDEV(obj) \
+ OBJECT_CHECK(struct PCTestdev, (obj), TYPE_TESTDEV)
+
+static void test_device_irq_line(void *opaque, uint32_t addr, uint32_t data)
+{
+struct PCTestdev *dev = opaque;
+qemu_set_irq(isa_get_irq(&dev->dev, addr - 0x2000), !!data);
+}
+
+static void test_device_ioport_write(void *opaque, uint32_t addr, uint32_t 
data)
+{
+struct PCTestdev *dev = opaque;
+dev->ioport_data = data;
+}
+
+static uint32_t test_device_ioport_read(void *opaque, uint32_t addr)
+{
+struct PCTestdev *dev = opaque;
+return dev->ioport_data;
+}
+
+static void test_device_flush_page(void *opaque, uint32_t addr, uint32_t data)
+{
+target_phys_addr_t len = 4096;
+void *a = cpu_physical_memory_map(data & ~0xffful, &len, 0);
+
+mprotect(a, 4096, PROT_NONE);
+mprotect(a, 4096, PROT_READ|PROT_WRITE);
+cpu_physical_memory_unmap(a, len, 0, 0);
+}
+
+static char *iomem_buf;
+
+

[Qemu-devel] [PATCH 0/2] Adding pc-testdev to qemu v3

[Lucas Meneghel Rodrigues]

These two patches introduce:

 1) A ISA debugexit port device, that when written, causes qemu
to exit with the exit code passed as parameter.
 2) A port of the existing testdev present on qemu-kvm to qemu

I think now I've got all comments made by Jan sorted out.

I did notice that with the new test device, a lot of the
kvm-unit-tests are failing. The same tests are passing fine
under qemu-kvm, meaning there are some bugs we need to address.

Example:

qemu-kvm:

$ x86_64-softmmu/qemu-system-x86_64 -device testdev -serial stdio -kernel 
/path/to/kvm/unittests/pcid.flat
VNC server running on `127.0.0.1:5900'
enabling apic
CPUID consistency: PASS
Test on PCID when disabled: PASS
Test on INVPCID when disabled: PASS
3 tests, 0 failures
$ echo $?
0

qemu:

$ x86_64-softmmu/qemu-system-x86_64 -device pc-testdev -serial stdio -device 
isa-debugexit,iobase=0xf4,access-size=4 -kernel /path/to/kvm/unittests/pcid.flat
VNC server running on `127.0.0.1:5900'
enabling apic
CPUID consistency: PASS
Test on PCID when disabled: FAIL
Test on INVPCID when disabled: PASS
3 tests, 1 failures
$ echo $?
3

Hervé Poussineau (1):
  debugexit: support for custom exit port (LGPL VGA BIOS port 0x501) v2

Lucas Meneghel Rodrigues (1):
  hw: Add test device for unittests execution v4

 hw/debugexit.c|  75 +++
 hw/i386/Makefile.objs |   3 +-
 hw/pc-testdev.c   | 167 ++
 3 files changed, 244 insertions(+), 1 deletion(-)
 create mode 100644 hw/debugexit.c
 create mode 100644 hw/pc-testdev.c

-- 
1.7.11.4

[Qemu-devel] [Bug 1047576] Re: qemu unittest emulator failure on latest git master

[Lucas Meneghel Rodrigues]

** Attachment added: "results.tar.bz2"
   
https://bugs.launchpad.net/bugs/1047576/+attachment/3299328/+files/results.tar.bz2

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1047576

Title:
  qemu unittest emulator failure on latest git master

Status in QEMU:
  New

Bug description:
  Running the emulator unittest, using the cmdline:

  16:01:30 INFO | Running emulator
  16:01:30 INFO | Running qemu command (reformatted):
  16:01:30 INFO | 
/home/lmr/Code/autotest.git/autotest/client/tests/virt/kvm/qemu 
  16:01:30 INFO | -S 
  16:01:30 INFO | -name 'unittest_vm' 
  16:01:30 INFO | -nodefaults 
  16:01:30 INFO | -chardev 
socket,id=hmp_id_humanmonitor1,path=/tmp/monitor-humanmonitor1-20120907-155940-WomlFZY3,server,nowait
 
  16:01:30 INFO | -mon chardev=hmp_id_humanmonitor1,mode=readline 
  16:01:30 INFO | -chardev 
socket,id=serial_id_20120907-155940-WomlFZY3,path=/tmp/serial-20120907-155940-WomlFZY3,server,nowait
 
  16:01:30 INFO | -device 
isa-serial,chardev=serial_id_20120907-155940-WomlFZY3 
  16:01:30 INFO | -chardev 
socket,id=seabioslog_id_20120907-155940-WomlFZY3,path=/tmp/seabios-20120907-155940-WomlFZY3,server,nowait
 
  16:01:30 INFO | -device 
isa-debugcon,chardev=seabioslog_id_20120907-155940-WomlFZY3,iobase=0x402 
  16:01:30 INFO | -m 512 
  16:01:30 INFO | -smp 2,cores=1,threads=1,sockets=2 
  16:01:30 INFO | -kernel 
'/home/lmr/Code/autotest.git/autotest/client/tests/virt/kvm/unittests/emulator.flat'
 
  16:01:30 INFO | -vnc :0 
  16:01:30 INFO | -chardev 
file,id=testlog,path=/tmp/testlog-20120907-155940-WomlFZY3 
  16:01:30 INFO | -device testdev,chardev=testlog 
  16:01:30 INFO | -rtc base=utc,clock=host,driftfix=none  
  16:01:30 INFO | -boot order=cdn,once=c,menu=off   
  16:01:30 INFO | -S 
  16:01:30 INFO | -enable-kvm

  We get

  16:01:32 INFO | Waiting for unittest emulator to complete, timeout 600, 
output in /tmp/testlog-20120907-155940-WomlFZY3
  16:01:32 INFO | [qemu output] KVM internal error. Suberror: 1
  16:01:32 INFO | [qemu output] emulation failure
  16:01:32 INFO | [qemu output] RAX=eff8 RBX=e000 
RCX=f000 RDX=0044d2b0
  16:01:32 INFO | [qemu output] RSI=0044c9fa RDI=0044e370 
RBP=eff8 RSP=0044d2b0
  16:01:32 INFO | [qemu output] R8 =000a R9 =03f8 
R10= R11=
  16:01:32 INFO | [qemu output] R12=e000 R13=1fff6000 
R14=1fff5000 R15=
  16:01:32 INFO | [qemu output] RIP=00400a89 RFL=00010002 [---] 
CPL=0 II=0 A20=1 SMM=0 HLT=0
  16:01:32 INFO | [qemu output] ES =0010   00c09300 
DPL=0 DS   [-WA]
  16:01:32 INFO | [qemu output] CS =0008   00a09b00 
DPL=0 CS64 [-RA]
  16:01:32 INFO | [qemu output] SS =   
  16:01:32 INFO | [qemu output] DS =0010   00c09300 
DPL=0 DS   [-WA]
  16:01:32 INFO | [qemu output] FS =0010   00c09300 
DPL=0 DS   [-WA]
  16:01:32 INFO | [qemu output] GS =0010 0044c370  00c09300 
DPL=0 DS   [-WA]
  16:01:32 INFO | [qemu output] LDT=   8200 
DPL=0 LDT
  16:01:32 INFO | [qemu output] TR =0048 0040a452  8b00 
DPL=0 TSS64-busy
  16:01:32 INFO | [qemu output] GDT= 0040a00a 0447
  16:01:32 INFO | [qemu output] IDT=  0fff
  16:01:32 INFO | [qemu output] CR0=80010011 CR2= 
CR3=1000 CR4=0020
  16:01:32 INFO | [qemu output] DR0= DR1= 
DR2= DR3=
  16:01:32 INFO | [qemu output] DR6=0ff0 DR7=0400
  16:01:32 INFO | [qemu output] EFER=0500
  16:01:32 INFO | [qemu output] Code=88 77 00 49 8d 84 24 f8 0f 00 00 48 89 e2 
48 89 e9 48 89 c5  48 87 e2 48 87 e9 48 81 f9 99 88 77 00 0f 94 c0 48 39 d5 
40 0f 94 c6 40 0f b6 f6 21 c6

  More logs will be attached to this bug report.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1047576/+subscriptions

[Qemu-devel] [Bug 1047576] Re: qemu unittest emulator failure on latest git master

[Lucas Meneghel Rodrigues]

Adding relevant qemu and unittest versions

software_version_qemu_kvm=git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git:master:4c3e02beed9878a5f760eeceb6cd42c475cf0127
software_version_kvm_unit_tests=git://git.kernel.org/pub/scm/virt/kvm/kvm-unit-tests.git:master:09b657b6d3a80d0424b8b370462a77d284117926

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1047576

Title:
  qemu unittest emulator failure on latest git master

Status in QEMU:
  New

Bug description:
  Running the emulator unittest, using the cmdline:

  16:01:30 INFO | Running emulator
  16:01:30 INFO | Running qemu command (reformatted):
  16:01:30 INFO | 
/home/lmr/Code/autotest.git/autotest/client/tests/virt/kvm/qemu 
  16:01:30 INFO | -S 
  16:01:30 INFO | -name 'unittest_vm' 
  16:01:30 INFO | -nodefaults 
  16:01:30 INFO | -chardev 
socket,id=hmp_id_humanmonitor1,path=/tmp/monitor-humanmonitor1-20120907-155940-WomlFZY3,server,nowait
 
  16:01:30 INFO | -mon chardev=hmp_id_humanmonitor1,mode=readline 
  16:01:30 INFO | -chardev 
socket,id=serial_id_20120907-155940-WomlFZY3,path=/tmp/serial-20120907-155940-WomlFZY3,server,nowait
 
  16:01:30 INFO | -device 
isa-serial,chardev=serial_id_20120907-155940-WomlFZY3 
  16:01:30 INFO | -chardev 
socket,id=seabioslog_id_20120907-155940-WomlFZY3,path=/tmp/seabios-20120907-155940-WomlFZY3,server,nowait
 
  16:01:30 INFO | -device 
isa-debugcon,chardev=seabioslog_id_20120907-155940-WomlFZY3,iobase=0x402 
  16:01:30 INFO | -m 512 
  16:01:30 INFO | -smp 2,cores=1,threads=1,sockets=2 
  16:01:30 INFO | -kernel 
'/home/lmr/Code/autotest.git/autotest/client/tests/virt/kvm/unittests/emulator.flat'
 
  16:01:30 INFO | -vnc :0 
  16:01:30 INFO | -chardev 
file,id=testlog,path=/tmp/testlog-20120907-155940-WomlFZY3 
  16:01:30 INFO | -device testdev,chardev=testlog 
  16:01:30 INFO | -rtc base=utc,clock=host,driftfix=none  
  16:01:30 INFO | -boot order=cdn,once=c,menu=off   
  16:01:30 INFO | -S 
  16:01:30 INFO | -enable-kvm

  We get

  16:01:32 INFO | Waiting for unittest emulator to complete, timeout 600, 
output in /tmp/testlog-20120907-155940-WomlFZY3
  16:01:32 INFO | [qemu output] KVM internal error. Suberror: 1
  16:01:32 INFO | [qemu output] emulation failure
  16:01:32 INFO | [qemu output] RAX=eff8 RBX=e000 
RCX=f000 RDX=0044d2b0
  16:01:32 INFO | [qemu output] RSI=0044c9fa RDI=0044e370 
RBP=eff8 RSP=0044d2b0
  16:01:32 INFO | [qemu output] R8 =000a R9 =03f8 
R10= R11=
  16:01:32 INFO | [qemu output] R12=e000 R13=1fff6000 
R14=1fff5000 R15=
  16:01:32 INFO | [qemu output] RIP=00400a89 RFL=00010002 [---] 
CPL=0 II=0 A20=1 SMM=0 HLT=0
  16:01:32 INFO | [qemu output] ES =0010   00c09300 
DPL=0 DS   [-WA]
  16:01:32 INFO | [qemu output] CS =0008   00a09b00 
DPL=0 CS64 [-RA]
  16:01:32 INFO | [qemu output] SS =   
  16:01:32 INFO | [qemu output] DS =0010   00c09300 
DPL=0 DS   [-WA]
  16:01:32 INFO | [qemu output] FS =0010   00c09300 
DPL=0 DS   [-WA]
  16:01:32 INFO | [qemu output] GS =0010 0044c370  00c09300 
DPL=0 DS   [-WA]
  16:01:32 INFO | [qemu output] LDT=   8200 
DPL=0 LDT
  16:01:32 INFO | [qemu output] TR =0048 0040a452  8b00 
DPL=0 TSS64-busy
  16:01:32 INFO | [qemu output] GDT= 0040a00a 0447
  16:01:32 INFO | [qemu output] IDT=  0fff
  16:01:32 INFO | [qemu output] CR0=80010011 CR2= 
CR3=1000 CR4=0020
  16:01:32 INFO | [qemu output] DR0= DR1= 
DR2= DR3=
  16:01:32 INFO | [qemu output] DR6=0ff0 DR7=0400
  16:01:32 INFO | [qemu output] EFER=0500
  16:01:32 INFO | [qemu output] Code=88 77 00 49 8d 84 24 f8 0f 00 00 48 89 e2 
48 89 e9 48 89 c5  48 87 e2 48 87 e9 48 81 f9 99 88 77 00 0f 94 c0 48 39 d5 
40 0f 94 c6 40 0f b6 f6 21 c6

  More logs will be attached to this bug report.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1047576/+subscriptions

[Qemu-devel] [Bug 1047576] [NEW] qemu unittest emulator failure on latest git master

[Lucas Meneghel Rodrigues]

Public bug reported:

Running the emulator unittest, using the cmdline:

16:01:30 INFO | Running emulator
16:01:30 INFO | Running qemu command (reformatted):
16:01:30 INFO | /home/lmr/Code/autotest.git/autotest/client/tests/virt/kvm/qemu 
16:01:30 INFO | -S 
16:01:30 INFO | -name 'unittest_vm' 
16:01:30 INFO | -nodefaults 
16:01:30 INFO | -chardev 
socket,id=hmp_id_humanmonitor1,path=/tmp/monitor-humanmonitor1-20120907-155940-WomlFZY3,server,nowait
 
16:01:30 INFO | -mon chardev=hmp_id_humanmonitor1,mode=readline 
16:01:30 INFO | -chardev 
socket,id=serial_id_20120907-155940-WomlFZY3,path=/tmp/serial-20120907-155940-WomlFZY3,server,nowait
 
16:01:30 INFO | -device 
isa-serial,chardev=serial_id_20120907-155940-WomlFZY3 
16:01:30 INFO | -chardev 
socket,id=seabioslog_id_20120907-155940-WomlFZY3,path=/tmp/seabios-20120907-155940-WomlFZY3,server,nowait
 
16:01:30 INFO | -device 
isa-debugcon,chardev=seabioslog_id_20120907-155940-WomlFZY3,iobase=0x402 
16:01:30 INFO | -m 512 
16:01:30 INFO | -smp 2,cores=1,threads=1,sockets=2 
16:01:30 INFO | -kernel 
'/home/lmr/Code/autotest.git/autotest/client/tests/virt/kvm/unittests/emulator.flat'
 
16:01:30 INFO | -vnc :0 
16:01:30 INFO | -chardev 
file,id=testlog,path=/tmp/testlog-20120907-155940-WomlFZY3 
16:01:30 INFO | -device testdev,chardev=testlog 
16:01:30 INFO | -rtc base=utc,clock=host,driftfix=none  
16:01:30 INFO | -boot order=cdn,once=c,menu=off   
16:01:30 INFO | -S 
16:01:30 INFO | -enable-kvm

We get

16:01:32 INFO | Waiting for unittest emulator to complete, timeout 600, output 
in /tmp/testlog-20120907-155940-WomlFZY3
16:01:32 INFO | [qemu output] KVM internal error. Suberror: 1
16:01:32 INFO | [qemu output] emulation failure
16:01:32 INFO | [qemu output] RAX=eff8 RBX=e000 
RCX=f000 RDX=0044d2b0
16:01:32 INFO | [qemu output] RSI=0044c9fa RDI=0044e370 
RBP=eff8 RSP=0044d2b0
16:01:32 INFO | [qemu output] R8 =000a R9 =03f8 
R10= R11=
16:01:32 INFO | [qemu output] R12=e000 R13=1fff6000 
R14=1fff5000 R15=
16:01:32 INFO | [qemu output] RIP=00400a89 RFL=00010002 [---] CPL=0 
II=0 A20=1 SMM=0 HLT=0
16:01:32 INFO | [qemu output] ES =0010   00c09300 DPL=0 
DS   [-WA]
16:01:32 INFO | [qemu output] CS =0008   00a09b00 DPL=0 
CS64 [-RA]
16:01:32 INFO | [qemu output] SS =   
16:01:32 INFO | [qemu output] DS =0010   00c09300 DPL=0 
DS   [-WA]
16:01:32 INFO | [qemu output] FS =0010   00c09300 DPL=0 
DS   [-WA]
16:01:32 INFO | [qemu output] GS =0010 0044c370  00c09300 DPL=0 
DS   [-WA]
16:01:32 INFO | [qemu output] LDT=   8200 DPL=0 
LDT
16:01:32 INFO | [qemu output] TR =0048 0040a452  8b00 DPL=0 
TSS64-busy
16:01:32 INFO | [qemu output] GDT= 0040a00a 0447
16:01:32 INFO | [qemu output] IDT=  0fff
16:01:32 INFO | [qemu output] CR0=80010011 CR2= 
CR3=1000 CR4=0020
16:01:32 INFO | [qemu output] DR0= DR1= 
DR2= DR3=
16:01:32 INFO | [qemu output] DR6=0ff0 DR7=0400
16:01:32 INFO | [qemu output] EFER=0500
16:01:32 INFO | [qemu output] Code=88 77 00 49 8d 84 24 f8 0f 00 00 48 89 e2 48 
89 e9 48 89 c5  48 87 e2 48 87 e9 48 81 f9 99 88 77 00 0f 94 c0 48 39 d5 40 
0f 94 c6 40 0f b6 f6 21 c6

More logs will be attached to this bug report.

** Affects: qemu
 Importance: Undecided
 Status: New


** Tags: unittest

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1047576

Title:
  qemu unittest emulator failure on latest git master

Status in QEMU:
  New

Bug description:
  Running the emulator unittest, using the cmdline:

  16:01:30 INFO | Running emulator
  16:01:30 INFO | Running qemu command (reformatted):
  16:01:30 INFO | 
/home/lmr/Code/autotest.git/autotest/client/tests/virt/kvm/qemu 
  16:01:30 INFO | -S 
  16:01:30 INFO | -name 'unittest_vm' 
  16:01:30 INFO | -nodefaults 
  16:01:30 INFO | -chardev 
socket,id=hmp_id_humanmonitor1,path=/tmp/monitor-humanmonitor1-20120907-155940-WomlFZY3,server,nowait
 
  16:01:30 INFO | -mon chardev=hmp_id_humanmonitor1,mode=readline 
  16:01:30 INFO | -chardev 
socket,id=serial_id_20120907-155940-WomlFZY3,path=/tmp/serial-20120907-155940-WomlFZY3,server,nowait
 
  16:01:30 INFO | -device 
isa-serial,chardev=serial_id_20120907-155940-WomlFZY3 
  16:01:30 INFO | -chardev 
socket,id=seabioslog_id_20120907-155940-WomlFZY3,path=/tmp/seabios-20120907-155940-WomlFZY3,server,nowait
 
 

Re: [Qemu-devel] The state of testing

[Lucas Meneghel Rodrigues]

On 03/05/2013 07:11 AM, Amit Shah wrote:

On (Mon) 04 Mar 2013 [16:53:55], Stefan Hajnoczi wrote:

People are working on testing for various parts of QEMU.  I started
this thread to gather an update on the state of testing and see where
we still need help.

I'm not sure yet if we should propose Google Summer of Code projects
to help with the testing infrastructure.  Perhaps working on libqtest
support for PCI, USB, virtio, etc would be a cool project.

Buildbot

The buildbot performs nightly builds and "make check".  Test coverage
is still minimal but it's a starting point where we can add more tests
that will run every day.

Block

tests/qemu-iotests/ contains 49 tests for the block layer.  These
tests mostly cover image format features like backing files,
snapshots, resize, and basic I/O verify tests.

The test suite has a few areas for improvement:

1. aio is not well-supported.  We need to be able to control the order
in which asynchronous requests complete in order to test all possible
code paths.  This issue also means the current aio tests are not
deterministic and can fail randomly due to reordered output.

2. make check-block is not run by the buildbot.  We should do so to
get nightly coverage of basic qcow2 tests.  I will send a buildbot
config patch to fix this.

Net
---
No tests!

How are things looking with device emulation, migration, monitor, char, etc?


I have a few tests coded up for virtio-serial at

http://fedorapeople.org/cgit/amitshah/public_git/test-virtserial.git/

which indirectly test chardevs.

Autotest (virt-tests) also has virtio-serial tests which end up
testing chardevs.



chardevs, being an external interface to qemu, do get tested whenever
anyone starts qemu with e.g. libvirt.

Also, autotest has libvirt-based tests, which exercise the monitor.
However, I don't think there's anything comprehensive anywhere.


The virtio console tests span over 130 tests, and take ~4 hours to run, 
I'd consider they are comprehensive.

Re: [Qemu-devel] The state of testing

[Lucas Meneghel Rodrigues]

On 03/05/2013 08:17 AM, Gerd Hoffmann wrote:

On 03/05/13 11:46, Stefan Hajnoczi wrote:

On Mon, Mar 04, 2013 at 05:22:34PM +0100, Gerd Hoffmann wrote:

   Hi,


How are things looking with device emulation, migration, monitor, char, etc?


At the moment autotest/virt-test is pretty much the only workable thing
for non-trivial devices because libqtest lacks infrastructure for pci
and anything building on top of pci.

usb has no in-tree tests, but has autotest coverage.

chardevs have some autotest coverage, /me wrote a test for
chardev-{add,remove} qmp commands.  Still need to rebase + polish +
submit that one though.


Do the USB and chardev tests run regularly against qemu.git/master?


^ No. We still didn't add usb tests to the sanity/stable test sets, but 
it's something doable, we will add them.



I don't think we have *any* regular autotest coverage for master, have we?


^ Yes, there is coverage. There's a daily job called sanity that takes 
about 2.5 hours, that builds the latest kvm.git and installs it in the 
host, then reboots the box, builds the latest qemu master and runs:


1) Linux guest install (RHEL 6.3) with the latest virtio drivers build
2) Migration testing
3) Some more basic checks

4) Linux guest install (Windows 7 SP1) with the latest virtio drivers build
5) Migration testing
6) Some more basic checks

There are more extensive test sets that take about 8 hours, that 
exercise things like migration with file transfer, timedrift, among others.


This not only runs on master, but RHEL 5.x, 6.x and Fedora 17, 18.

Re: [Qemu-devel] The state of testing

[Lucas Meneghel Rodrigues]

On 03/04/2013 01:22 PM, Gerd Hoffmann wrote:

   Hi,


How are things looking with device emulation, migration, monitor, char, etc?


At the moment autotest/virt-test is pretty much the only workable thing
for non-trivial devices because libqtest lacks infrastructure for pci
and anything building on top of pci.

usb has no in-tree tests, but has autotest coverage.

chardevs have some autotest coverage, /me wrote a test for
chardev-{add,remove} qmp commands.  Still need to rebase + polish +
submit that one though.

Migration coverage is pretty bad overall I think.


On virt-tests there are at least 48 tests that are easy to run and 
involve migration. A subset of them is executed regularly in the daily jobs:


./run -t qemu -g Fedora.18.x86_64 --list-tests | grep migrat | grep -v 
multi_host


21 balloon_check.balloon-migrate
51 cpuflags.stress_guest.qemu_test_migration_with_additional_flags
65 migrate.default.tcp
66 migrate.default.unix
67 migrate.default.exec
68 migrate.default.fd
69 migrate.default.mig_cancel
70 migrate.with_speed_measurement.tcp
71 migrate.with_speed_measurement.unix
72 migrate.with_speed_measurement.exec
73 migrate.with_speed_measurement.fd
74 migrate.with_set_speed.tcp
75 migrate.with_set_speed.unix
76 migrate.with_set_speed.exec
77 migrate.with_set_speed.fd
78 migrate.with_reboot.tcp
79 migrate.with_reboot.unix
80 migrate.with_reboot.exec
81 migrate.with_reboot.fd
82 migrate.with_file_transfer.tcp
83 migrate.with_file_transfer.unix
84 migrate.with_file_transfer.exec
85 migrate.with_file_transfer.fd
86 migrate.with_autotest.dbench.tcp
87 migrate.with_autotest.dbench.unix
88 migrate.with_autotest.dbench.exec
89 migrate.with_autotest.dbench.fd
90 migrate.with_autotest.stress.tcp
91 migrate.with_autotest.stress.unix
92 migrate.with_autotest.stress.exec
93 migrate.with_autotest.stress.fd
94 migrate.with_autotest.monotonic_time.tcp
95 migrate.with_autotest.monotonic_time.unix
96 migrate.with_autotest.monotonic_time.exec
97 migrate.with_autotest.monotonic_time.fd
2146 nic_hotplug.migration.nic_8139 (requires root)
2147 nic_hotplug.migration.nic_virtio (requires root)
2148 nic_hotplug.migration.nic_e1000 (requires root)
2483 
virtio_console.spread_linear.specifiable.virtserialport.with_vm.migration.offline
2484 
virtio_console.spread_linear.specifiable.virtserialport.with_vm.migration.online
2515 
virtio_console.spread_linear.specifiable.virtconsole.with_vm.migration.offline
2516 
virtio_console.spread_linear.specifiable.virtconsole.with_vm.migration.online
2561 
virtio_console.spread_2.specifiable.virtserialport.with_vm.migration.offline
2562 
virtio_console.spread_2.specifiable.virtserialport.with_vm.migration.online
2584 
virtio_console.spread_2.specifiable.virtconsole.with_vm.migration.offline
2585 
virtio_console.spread_2.specifiable.virtconsole.with_vm.migration.online

2672 timedrift.ntp.with_migration
2676 timedrift.date.with_migration

Those can be run with relative ease on every developer laptop, not 
counting the many multi host tests involving migration, that are still 
not being executed on a regular basis on our test farm. So I don't think 
migration coverage is that bad.

Re: [Qemu-devel] The state of testing

[Lucas Meneghel Rodrigues]

On 03/05/2013 01:14 PM, Gerd Hoffmann wrote:

   Hi,


I don't think we have *any* regular autotest coverage for master, have
we?


^ Yes, there is coverage. There's a daily job called sanity that takes
about 2.5 hours, that builds the latest kvm.git and installs it in the
host, then reboots the box, builds the latest qemu master and runs:


Oh, good.  I guess it would be a good idea to send reports to
qemu-devel, maybe a weekly status or mails on regressions simliar to the
buildbot build failures.  So people (a) aware that the service exists in
the first place and (b) get informed that something broke which should
be fixed.


No doubt, I did try that before, but from my experience, the reports are 
likely to be ignored and people will complain about SPAM.


So we ended up creating an internal mailing list where Gleb and Marcelo 
are subscribed to, in case they want to look at the reports, and I'd 
look at the reports and report on the ML in case something bad happens.

Re: [Qemu-devel] The state of testing

[Lucas Meneghel Rodrigues]

On 03/05/2013 01:23 PM, Gerd Hoffmann wrote:

   Hi,


On virt-tests there are at least 48 tests that are easy to run and
involve migration. A subset of them is executed regularly in the daily
jobs:


Sure, there are a bunch of tests already, which is good.
But there are also important areas which are not covered at all yet.

For example there are no cross-version migration tests, which is an area
where we often have bugs, they often went unnoticed for quite a while
and they tend to be nasty to fix when noticed after release ...


Ok, I see your point. There are some provisions to implement tests for 
cross-version migration due to jzupka's work, but myself and Cleber 
could not get around to create multi host jobs in the test grid yet.

[Qemu-devel] [BUG latest master] - qemu segfaults when issuing screendump cmd

[Lucas Meneghel Rodrigues]

Latest qemu.git master is failing big time to pass sanity checks:

https://bugs.launchpad.net/qemu/+bug/1169254

We've had some issues with the test jobs, and finally managed to
stabilize the grid, so we don't have results for the last couple of
weeks to bisect the problem.

[Qemu-devel] [Bug 1169254] [NEW] latest qemu.git master -> qemu-system-x86_64 crashes when issuing screendump command over monitor

[Lucas Meneghel Rodrigues]

Public bug reported:

Found the problem during sanity test of the 'next' branch

git commit ID is e2ec3f976803b360c70d9ae2ba13852fa5d11665 (tag
v1.4.0-1202-ge2ec3f9)

For reference, kernel is upstream kvm.git

git commit ID is 31880c37c11e28cb81c70757e38392b42e695dc6 (tag
v3.8-12524-g31880c3)

Steps to reproduce:

Start qemu, reference cmd:

MALLOC_PERTURB_=1 /usr/local/autotest/tests/virt/qemu/qemu \
-S \
-name 'vm1' \
-nodefaults \
-chardev 
socket,id=hmp_id_hmp1,path=/tmp/monitor-hmp1-20130415-120337-CX4dw84y,server,nowait
 \
-mon chardev=hmp_id_hmp1,mode=readline \
-chardev 
socket,id=qmp_id_qmp1,path=/tmp/monitor-qmp1-20130415-120337-CX4dw84y,server,nowait
 \
-mon chardev=qmp_id_qmp1,mode=control \
-chardev 
socket,id=serial_id_serial1,path=/tmp/serial-serial1-20130415-120337-CX4dw84y,server,nowait
 \
-device isa-serial,chardev=serial_id_serial1 \
-chardev 
socket,id=seabioslog_id_20130415-120337-CX4dw84y,path=/tmp/seabios-20130415-120337-CX4dw84y,server,nowait
 \
-device 
isa-debugcon,chardev=seabioslog_id_20130415-120337-CX4dw84y,iobase=0x402 \
-device ich9-usb-uhci1,id=usb1 \
-drive 
file='/usr/local/autotest/tests/virt/shared/data/images/rhel63-64.qcow2',if=none,id=virtio0
 \
-device virtio-blk-pci,drive=virtio0,bootindex=1 \
-device 
virtio-net-pci,netdev=id7t6ont,mac='9a:16:17:18:19:1a',id='idQ3SyRX' \
-netdev tap,id=id7t6ont,vhost=on,fd=24 \
-m 2048 \
-smp 2,maxcpus=2,cores=1,threads=1,sockets=2 \
-cpu 'Opteron_G3' \
-M pc \
-drive 
file='/usr/local/autotest/tests/virt/shared/data/isos/linux/RHEL-6.3-x86_64-DVD.iso',media=cdrom,index=2
 \
-drive 
file='/usr/local/autotest/tests/virt/shared/data/images/rhel63-64/ks.iso',media=cdrom,index=1
 \
-device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 \
-kernel 
'/usr/local/autotest/tests/virt/shared/data/images/rhel63-64/vmlinuz' \
-append 'ks=cdrom nicdelay=60 console=ttyS0,115200 console=tty0' \
-initrd 
'/usr/local/autotest/tests/virt/shared/data/images/rhel63-64/initrd.img' \
-vnc :0 \
-vga std \
-rtc base=utc,clock=host,driftfix=none  \
-boot order=cdn,once=d,menu=off  \
-enable-kvm

2) Connect to the monitor

nc -U /tmp/monitor-hmp1-20130415-120337-CX4dw84y,server,nowait

3) Unpause the VM

[root@virtblade03 autotest]# nc -U /tmp/monitor-hmp1-20130415-120943-D6zKUQFO
QEMU 1.4.50 monitor - type 'help' for more information
(qemu) cont
cont

4) Ask for a screendump

(qemu) screendump abc.ppm
screendump abc.ppm

At this point, qemu crashes.

 Program terminated with signal 11, Segmentation fault.
 #0  pixman_image_get_width (image=0x101010101010101) at pixman-image.c:834
 834 if (image->type == BITS)
 (gdb) bt
 #0  pixman_image_get_width (image=0x101010101010101) at pixman-image.c:834
 #1  0x7f0b44158374 in ppm_save (filename=0x7f0b46762a30 
"/dev/shm/scrdump-miGZom.ppm", ds=0x7f0b466b7a50, errp=0x7fff41c08260)
 at /usr/local/autotest/tmp/virt/src/qemu/hw/display/vga.c:2401
 #2  0x7f0b4410f18e in qmp_screendump (filename=0x7f0b46762a30 
"/dev/shm/scrdump-miGZom.ppm", errp=0x7fff41c08260) at ui/console.c:195
 #3  0x7f0b43ffc77a in hmp_screen_dump (mon=0x7f0b46530d80, 
qdict=) at hmp.c:1335
 #4  0x7f0b4418c889 in handle_user_command (mon=mon@entry=0x7f0b46530d80, 
cmdline=) at /usr/local/autotest/tmp/virt/src/qemu/monitor.c:4007
 #5  0x7f0b4418cc0b in monitor_command_cb (mon=0x7f0b46530d80, 
cmdline=, opaque=)
 at /usr/local/autotest/tmp/virt/src/qemu/monitor.c:4623
 #6  0x7f0b440fe69b in readline_handle_byte (rs=0x7f0b46689a30, 
ch=) at readline.c:373
 #7  0x7f0b4418c954 in monitor_read (opaque=, buf=, size=) at 
/usr/local/autotest/tmp/virt/src/qemu/monitor.c:4609
 #8  0x7f0b440ec029 in qemu_chr_be_write (len=, 
buf=0x7fff41c08400 "\n", s=0x7f0b46506c00) at qemu-char.c:187
 #9  tcp_chr_read (chan=, cond=, 
opaque=0x7f0b46506c00) at qemu-char.c:2519
 #10 0x7f0b43622a75 in g_main_dispatch (context=0x7f0b46506240) at 
gmain.c:2715
 #11 g_main_context_dispatch (context=context@entry=0x7f0b46506240) at 
gmain.c:3219
 #12 0x7f0b440c4c78 in glib_pollfds_poll () at main-loop.c:187
 #13 os_host_main_loop_wait (timeout=) at main-loop.c:232
 #14 main_loop_wait (nonblocking=) at main-loop.c:468
 #15 0x7f0b43faab55 in main_loop () at vl.c:2043
 #16 main (argc=, argv=, envp=) at 
vl.c:4432

 if (image->type == BITS)
 image=0x101010101010101

The pointer to the image is invalid. Need to investigate why.

** 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/1169254

Title:
  latest qemu.git master -> qemu-system-x86_64 crashes when issuing
  screendump command over monitor

Status in QEMU:
  New

Bug description:
  Found the problem during sanity test of the 'next' branch

  git commit ID is e2ec3f976803b360c70d9ae2ba13852fa5d11665

[Qemu-devel] [Bug 1169254] Re: latest qemu.git master -> qemu-system-x86_64 crashes when issuing screendump command over monitor

[Lucas Meneghel Rodrigues]

1 thing I don't see in your command line: MALLOC_PERTURB=1. I did build
it on my Fedora 19 work laptop and it is easily reproducible. I just
didn't use the echo -e:

[lmr@thinkpad-t420s qemu]$ MALLOC_PERTURB_=1 x86_64-softmmu/qemu-system-x86_64 
-monitor stdio -vga std -S -vnc :0 -enable-kvm -nodefaults
QEMU 1.4.50 monitor - type 'help' for more information
(qemu) cont
(qemu) screendump abc.ppm
Segmentation fault

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1169254

Title:
  latest qemu.git master -> qemu-system-x86_64 crashes when issuing
  screendump command over monitor

Status in QEMU:
  New

Bug description:
  Found the problem during sanity test of the 'next' branch

  git commit ID is e2ec3f976803b360c70d9ae2ba13852fa5d11665 (tag
  v1.4.0-1202-ge2ec3f9)

  For reference, kernel is upstream kvm.git

  git commit ID is 31880c37c11e28cb81c70757e38392b42e695dc6 (tag
  v3.8-12524-g31880c3)

  Steps to reproduce:

  Start qemu, reference cmd:

  MALLOC_PERTURB_=1 /usr/local/autotest/tests/virt/qemu/qemu \
  -S \
  -name 'vm1' \
  -nodefaults \
  -chardev 
socket,id=hmp_id_hmp1,path=/tmp/monitor-hmp1-20130415-120337-CX4dw84y,server,nowait
 \
  -mon chardev=hmp_id_hmp1,mode=readline \
  -chardev 
socket,id=qmp_id_qmp1,path=/tmp/monitor-qmp1-20130415-120337-CX4dw84y,server,nowait
 \
  -mon chardev=qmp_id_qmp1,mode=control \
  -chardev 
socket,id=serial_id_serial1,path=/tmp/serial-serial1-20130415-120337-CX4dw84y,server,nowait
 \
  -device isa-serial,chardev=serial_id_serial1 \
  -chardev 
socket,id=seabioslog_id_20130415-120337-CX4dw84y,path=/tmp/seabios-20130415-120337-CX4dw84y,server,nowait
 \
  -device 
isa-debugcon,chardev=seabioslog_id_20130415-120337-CX4dw84y,iobase=0x402 \
  -device ich9-usb-uhci1,id=usb1 \
  -drive 
file='/usr/local/autotest/tests/virt/shared/data/images/rhel63-64.qcow2',if=none,id=virtio0
 \
  -device virtio-blk-pci,drive=virtio0,bootindex=1 \
  -device 
virtio-net-pci,netdev=id7t6ont,mac='9a:16:17:18:19:1a',id='idQ3SyRX' \
  -netdev tap,id=id7t6ont,vhost=on,fd=24 \
  -m 2048 \
  -smp 2,maxcpus=2,cores=1,threads=1,sockets=2 \
  -cpu 'Opteron_G3' \
  -M pc \
  -drive 
file='/usr/local/autotest/tests/virt/shared/data/isos/linux/RHEL-6.3-x86_64-DVD.iso',media=cdrom,index=2
 \
  -drive 
file='/usr/local/autotest/tests/virt/shared/data/images/rhel63-64/ks.iso',media=cdrom,index=1
 \
  -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 \
  -kernel 
'/usr/local/autotest/tests/virt/shared/data/images/rhel63-64/vmlinuz' \
  -append 'ks=cdrom nicdelay=60 console=ttyS0,115200 console=tty0' \
  -initrd 
'/usr/local/autotest/tests/virt/shared/data/images/rhel63-64/initrd.img' \
  -vnc :0 \
  -vga std \
  -rtc base=utc,clock=host,driftfix=none  \
  -boot order=cdn,once=d,menu=off  \
  -enable-kvm

  2) Connect to the monitor

  nc -U /tmp/monitor-hmp1-20130415-120337-CX4dw84y,server,nowait

  3) Unpause the VM

  [root@virtblade03 autotest]# nc -U /tmp/monitor-hmp1-20130415-120943-D6zKUQFO
  QEMU 1.4.50 monitor - type 'help' for more information
  (qemu) cont
  cont

  4) Ask for a screendump

  (qemu) screendump abc.ppm
  screendump abc.ppm

  At this point, qemu crashes.

   Program terminated with signal 11, Segmentation fault.
   #0  pixman_image_get_width (image=0x101010101010101) at pixman-image.c:834
   834 if (image->type == BITS)
   (gdb) bt
   #0  pixman_image_get_width (image=0x101010101010101) at pixman-image.c:834
   #1  0x7f0b44158374 in ppm_save (filename=0x7f0b46762a30 
"/dev/shm/scrdump-miGZom.ppm", ds=0x7f0b466b7a50, errp=0x7fff41c08260)
   at /usr/local/autotest/tmp/virt/src/qemu/hw/display/vga.c:2401
   #2  0x7f0b4410f18e in qmp_screendump (filename=0x7f0b46762a30 
"/dev/shm/scrdump-miGZom.ppm", errp=0x7fff41c08260) at ui/console.c:195
   #3  0x7f0b43ffc77a in hmp_screen_dump (mon=0x7f0b46530d80, 
qdict=) at hmp.c:1335
   #4  0x7f0b4418c889 in handle_user_command (mon=mon@entry=0x7f0b46530d80, 
cmdline=) at /usr/local/autotest/tmp/virt/src/qemu/monitor.c:4007
   #5  0x7f0b4418cc0b in monitor_command_cb (mon=0x7f0b46530d80, 
cmdline=, opaque=)
   at /usr/local/autotest/tmp/virt/src/qemu/monitor.c:4623
   #6  0x7f0b440fe69b in readline_handle_byte (rs=0x7f0b46689a30, 
ch=) at readline.c:373
   #7  0x7f0b4418c954 in monitor_read (opaque=, 
buf=, size=) at 
/usr/local/autotest/tmp/virt/src/qemu/monitor.c:4609
   #8  0x7f0b440ec029 in qemu_chr_be_write (len=, 
buf=0x7fff41c08400 "\n", s=0x7f0b46506c00) at qemu-char.c:187
   #9  tcp_chr_read (chan=, cond=, 
opaque=0x7f0b46506c00) at qemu-char.c:2519
   #10 0x7f0b43622a75 in g_main_dispatch (context=0x7f0b46506240) at 
gmain.c:2715
   #11 g_main_context_dispatch (context=context@entry=0x7f0b46506240) at 
gmain.c:3219
   #12 0x7f0b440c4c78 in glib_pollfds_pol

[Qemu-devel] [Bug 1169254] Re: latest qemu.git master -> qemu-system-x86_64 crashes when issuing screendump command over monitor

[Lucas Meneghel Rodrigues]

I've hacked up a (admittedly not very pretty) reproducer script

PATH_DEVEL=x86_64-softmmu/qemu-system-x86_64
MALLOC_PERTURB_=1 $PATH_DEVEL -chardev 
socket,id=hmp1,path=/tmp/hmp1-lmr,server,nowait -mon chardev=hmp1,mode=readline 
-vga std -S -vnc :0 -enable-kvm -nodefaults&
QEMU_PID=$(pidof qemu-system-x86_64)

echo "QEMU PID is $QEMU_PID"
sleep 2
echo 'cont' | nc -U /tmp/hmp1-lmr
sleep 2
echo 'screendump abc.ppm' | nc -U /tmp/hmp1-lmr

if ps -p $QEMU_PID > /dev/null
then
echo "PASS: QEMU is still alive"
kill $QEMU_PID
exit 0
else
echo "FAIL: QEMU segfaulted"
exit 1
fi

And let me try git bisect here...

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1169254

Title:
  latest qemu.git master -> qemu-system-x86_64 crashes when issuing
  screendump command over monitor

Status in QEMU:
  New

Bug description:
  Found the problem during sanity test of the 'next' branch

  git commit ID is e2ec3f976803b360c70d9ae2ba13852fa5d11665 (tag
  v1.4.0-1202-ge2ec3f9)

  For reference, kernel is upstream kvm.git

  git commit ID is 31880c37c11e28cb81c70757e38392b42e695dc6 (tag
  v3.8-12524-g31880c3)

  Steps to reproduce:

  Start qemu, reference cmd:

  MALLOC_PERTURB_=1 /usr/local/autotest/tests/virt/qemu/qemu \
  -S \
  -name 'vm1' \
  -nodefaults \
  -chardev 
socket,id=hmp_id_hmp1,path=/tmp/monitor-hmp1-20130415-120337-CX4dw84y,server,nowait
 \
  -mon chardev=hmp_id_hmp1,mode=readline \
  -chardev 
socket,id=qmp_id_qmp1,path=/tmp/monitor-qmp1-20130415-120337-CX4dw84y,server,nowait
 \
  -mon chardev=qmp_id_qmp1,mode=control \
  -chardev 
socket,id=serial_id_serial1,path=/tmp/serial-serial1-20130415-120337-CX4dw84y,server,nowait
 \
  -device isa-serial,chardev=serial_id_serial1 \
  -chardev 
socket,id=seabioslog_id_20130415-120337-CX4dw84y,path=/tmp/seabios-20130415-120337-CX4dw84y,server,nowait
 \
  -device 
isa-debugcon,chardev=seabioslog_id_20130415-120337-CX4dw84y,iobase=0x402 \
  -device ich9-usb-uhci1,id=usb1 \
  -drive 
file='/usr/local/autotest/tests/virt/shared/data/images/rhel63-64.qcow2',if=none,id=virtio0
 \
  -device virtio-blk-pci,drive=virtio0,bootindex=1 \
  -device 
virtio-net-pci,netdev=id7t6ont,mac='9a:16:17:18:19:1a',id='idQ3SyRX' \
  -netdev tap,id=id7t6ont,vhost=on,fd=24 \
  -m 2048 \
  -smp 2,maxcpus=2,cores=1,threads=1,sockets=2 \
  -cpu 'Opteron_G3' \
  -M pc \
  -drive 
file='/usr/local/autotest/tests/virt/shared/data/isos/linux/RHEL-6.3-x86_64-DVD.iso',media=cdrom,index=2
 \
  -drive 
file='/usr/local/autotest/tests/virt/shared/data/images/rhel63-64/ks.iso',media=cdrom,index=1
 \
  -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 \
  -kernel 
'/usr/local/autotest/tests/virt/shared/data/images/rhel63-64/vmlinuz' \
  -append 'ks=cdrom nicdelay=60 console=ttyS0,115200 console=tty0' \
  -initrd 
'/usr/local/autotest/tests/virt/shared/data/images/rhel63-64/initrd.img' \
  -vnc :0 \
  -vga std \
  -rtc base=utc,clock=host,driftfix=none  \
  -boot order=cdn,once=d,menu=off  \
  -enable-kvm

  2) Connect to the monitor

  nc -U /tmp/monitor-hmp1-20130415-120337-CX4dw84y,server,nowait

  3) Unpause the VM

  [root@virtblade03 autotest]# nc -U /tmp/monitor-hmp1-20130415-120943-D6zKUQFO
  QEMU 1.4.50 monitor - type 'help' for more information
  (qemu) cont
  cont

  4) Ask for a screendump

  (qemu) screendump abc.ppm
  screendump abc.ppm

  At this point, qemu crashes.

   Program terminated with signal 11, Segmentation fault.
   #0  pixman_image_get_width (image=0x101010101010101) at pixman-image.c:834
   834 if (image->type == BITS)
   (gdb) bt
   #0  pixman_image_get_width (image=0x101010101010101) at pixman-image.c:834
   #1  0x7f0b44158374 in ppm_save (filename=0x7f0b46762a30 
"/dev/shm/scrdump-miGZom.ppm", ds=0x7f0b466b7a50, errp=0x7fff41c08260)
   at /usr/local/autotest/tmp/virt/src/qemu/hw/display/vga.c:2401
   #2  0x7f0b4410f18e in qmp_screendump (filename=0x7f0b46762a30 
"/dev/shm/scrdump-miGZom.ppm", errp=0x7fff41c08260) at ui/console.c:195
   #3  0x7f0b43ffc77a in hmp_screen_dump (mon=0x7f0b46530d80, 
qdict=) at hmp.c:1335
   #4  0x7f0b4418c889 in handle_user_command (mon=mon@entry=0x7f0b46530d80, 
cmdline=) at /usr/local/autotest/tmp/virt/src/qemu/monitor.c:4007
   #5  0x7f0b4418cc0b in monitor_command_cb (mon=0x7f0b46530d80, 
cmdline=, opaque=)
   at /usr/local/autotest/tmp/virt/src/qemu/monitor.c:4623
   #6  0x7f0b440fe69b in readline_handle_byte (rs=0x7f0b46689a30, 
ch=) at readline.c:373
   #7  0x7f0b4418c954 in monitor_read (opaque=, 
buf=, size=) at 
/usr/local/autotest/tmp/virt/src/qemu/monitor.c:4609
   #8  0x7f0b440ec029 in qemu_chr_be_write (len=, 
buf=0x7fff41c08400 "\n", s=0x7f0b46506c00) at qemu-char.c:187
   #9  tcp_chr_read (chan=, cond=, 
opaque=0x7f0b46506c00) at qemu-char.c:2519
   #

[Qemu-devel] [Bug 1169254] Re: latest qemu.git master -> qemu-system-x86_64 crashes when issuing screendump command over monitor

[Lucas Meneghel Rodrigues]

First bad commit is

commit c78f71378a345ea240c288993ca1378ded5504b9
Author: Gerd Hoffmann 
Date:   Tue Mar 5 15:24:14 2013 +0100

console: stop using DisplayState in gfx hardware emulation

Use QemuConsole instead.  Updates interfaces in console.[ch] and adapts
gfx hardware emulation code.

Signed-off-by: Gerd Hoffmann 

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1169254

Title:
  latest qemu.git master -> qemu-system-x86_64 crashes when issuing
  screendump command over monitor

Status in QEMU:
  New

Bug description:
  Found the problem during sanity test of the 'next' branch

  git commit ID is e2ec3f976803b360c70d9ae2ba13852fa5d11665 (tag
  v1.4.0-1202-ge2ec3f9)

  For reference, kernel is upstream kvm.git

  git commit ID is 31880c37c11e28cb81c70757e38392b42e695dc6 (tag
  v3.8-12524-g31880c3)

  Steps to reproduce:

  Start qemu, reference cmd:

  MALLOC_PERTURB_=1 /usr/local/autotest/tests/virt/qemu/qemu \
  -S \
  -name 'vm1' \
  -nodefaults \
  -chardev 
socket,id=hmp_id_hmp1,path=/tmp/monitor-hmp1-20130415-120337-CX4dw84y,server,nowait
 \
  -mon chardev=hmp_id_hmp1,mode=readline \
  -chardev 
socket,id=qmp_id_qmp1,path=/tmp/monitor-qmp1-20130415-120337-CX4dw84y,server,nowait
 \
  -mon chardev=qmp_id_qmp1,mode=control \
  -chardev 
socket,id=serial_id_serial1,path=/tmp/serial-serial1-20130415-120337-CX4dw84y,server,nowait
 \
  -device isa-serial,chardev=serial_id_serial1 \
  -chardev 
socket,id=seabioslog_id_20130415-120337-CX4dw84y,path=/tmp/seabios-20130415-120337-CX4dw84y,server,nowait
 \
  -device 
isa-debugcon,chardev=seabioslog_id_20130415-120337-CX4dw84y,iobase=0x402 \
  -device ich9-usb-uhci1,id=usb1 \
  -drive 
file='/usr/local/autotest/tests/virt/shared/data/images/rhel63-64.qcow2',if=none,id=virtio0
 \
  -device virtio-blk-pci,drive=virtio0,bootindex=1 \
  -device 
virtio-net-pci,netdev=id7t6ont,mac='9a:16:17:18:19:1a',id='idQ3SyRX' \
  -netdev tap,id=id7t6ont,vhost=on,fd=24 \
  -m 2048 \
  -smp 2,maxcpus=2,cores=1,threads=1,sockets=2 \
  -cpu 'Opteron_G3' \
  -M pc \
  -drive 
file='/usr/local/autotest/tests/virt/shared/data/isos/linux/RHEL-6.3-x86_64-DVD.iso',media=cdrom,index=2
 \
  -drive 
file='/usr/local/autotest/tests/virt/shared/data/images/rhel63-64/ks.iso',media=cdrom,index=1
 \
  -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 \
  -kernel 
'/usr/local/autotest/tests/virt/shared/data/images/rhel63-64/vmlinuz' \
  -append 'ks=cdrom nicdelay=60 console=ttyS0,115200 console=tty0' \
  -initrd 
'/usr/local/autotest/tests/virt/shared/data/images/rhel63-64/initrd.img' \
  -vnc :0 \
  -vga std \
  -rtc base=utc,clock=host,driftfix=none  \
  -boot order=cdn,once=d,menu=off  \
  -enable-kvm

  2) Connect to the monitor

  nc -U /tmp/monitor-hmp1-20130415-120337-CX4dw84y,server,nowait

  3) Unpause the VM

  [root@virtblade03 autotest]# nc -U /tmp/monitor-hmp1-20130415-120943-D6zKUQFO
  QEMU 1.4.50 monitor - type 'help' for more information
  (qemu) cont
  cont

  4) Ask for a screendump

  (qemu) screendump abc.ppm
  screendump abc.ppm

  At this point, qemu crashes.

   Program terminated with signal 11, Segmentation fault.
   #0  pixman_image_get_width (image=0x101010101010101) at pixman-image.c:834
   834 if (image->type == BITS)
   (gdb) bt
   #0  pixman_image_get_width (image=0x101010101010101) at pixman-image.c:834
   #1  0x7f0b44158374 in ppm_save (filename=0x7f0b46762a30 
"/dev/shm/scrdump-miGZom.ppm", ds=0x7f0b466b7a50, errp=0x7fff41c08260)
   at /usr/local/autotest/tmp/virt/src/qemu/hw/display/vga.c:2401
   #2  0x7f0b4410f18e in qmp_screendump (filename=0x7f0b46762a30 
"/dev/shm/scrdump-miGZom.ppm", errp=0x7fff41c08260) at ui/console.c:195
   #3  0x7f0b43ffc77a in hmp_screen_dump (mon=0x7f0b46530d80, 
qdict=) at hmp.c:1335
   #4  0x7f0b4418c889 in handle_user_command (mon=mon@entry=0x7f0b46530d80, 
cmdline=) at /usr/local/autotest/tmp/virt/src/qemu/monitor.c:4007
   #5  0x7f0b4418cc0b in monitor_command_cb (mon=0x7f0b46530d80, 
cmdline=, opaque=)
   at /usr/local/autotest/tmp/virt/src/qemu/monitor.c:4623
   #6  0x7f0b440fe69b in readline_handle_byte (rs=0x7f0b46689a30, 
ch=) at readline.c:373
   #7  0x7f0b4418c954 in monitor_read (opaque=, 
buf=, size=) at 
/usr/local/autotest/tmp/virt/src/qemu/monitor.c:4609
   #8  0x7f0b440ec029 in qemu_chr_be_write (len=, 
buf=0x7fff41c08400 "\n", s=0x7f0b46506c00) at qemu-char.c:187
   #9  tcp_chr_read (chan=, cond=, 
opaque=0x7f0b46506c00) at qemu-char.c:2519
   #10 0x7f0b43622a75 in g_main_dispatch (context=0x7f0b46506240) at 
gmain.c:2715
   #11 g_main_context_dispatch (context=context@entry=0x7f0b46506240) at 
gmain.c:3219
   #12 0x7f0b440c4c78 in glib_pollfds_poll () at main-loop.c:187
   #13 os_host_main_loop_wait (timeout=) at ma

[Qemu-devel] [Bug 1169375] [NEW] qemu.git master -> qemu segfaults during tcp migration (and other modes when using MALLOC_PERTURB_=1)

[Lucas Meneghel Rodrigues]

Public bug reported:

Relevant qemu.git master commit:

24a6e7f4d91e9ed5f8117ecb083431a23f8609a0

When trying to migrate a VM using the TCP protocol, a segfault happened:

21:45:07 INFO | Running qemu command (reformatted):
/home/lmr/Code/qemu/x86_64-softmmu/qemu-system-x86_64 \
-S \
-name 'virt-tests-vm1' \
-nodefaults \
-chardev 
socket,id=hmp_id_hmp1,path=/tmp/monitor-hmp1-20130415-214507-8fDeX7Fj,server,nowait
 \
-mon chardev=hmp_id_hmp1,mode=readline \
-chardev 
socket,id=serial_id_serial1,path=/tmp/serial-serial1-20130415-214507-8fDeX7Fj,server,nowait
 \
-device isa-serial,chardev=serial_id_serial1 \
-chardev 
socket,id=seabioslog_id_20130415-214507-8fDeX7Fj,path=/tmp/seabios-20130415-214507-8fDeX7Fj,server,nowait
 \
-device 
isa-debugcon,chardev=seabioslog_id_20130415-214507-8fDeX7Fj,iobase=0x402 \
-device ich9-usb-uhci1,id=usb1 \
-drive 
file='/home/lmr/Code/virt-test.git/shared/data/images/jeos-17-64.qcow2',if=none,id=virtio0
 \
-device virtio-blk-pci,drive=virtio0,bootindex=1 \
-device 
virtio-net-pci,netdev=idr5RNof,mac='9a:42:43:44:45:46',id='idJVlBu3' \
-netdev user,id=idr5RNof,hostfwd=tcp::5000-:22 \
-m 1024 \
-smp 2,maxcpus=2,cores=1,threads=1,sockets=2 \
-cpu 'SandyBridge' \
-M pc \
-device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 \
-vnc :1 \
-vga std \
-rtc base=utc,clock=host,driftfix=none  \
-boot order=cdn,once=c,menu=off  \
-enable-kvm \
-incoming tcp:0:5200
21:45:08 INFO | [qemu output] qemu-system-x86_64: -device 
usb-tablet,id=usb-tablet1,bus=usb1.0,port=1: Bus 'virtio-pci-bus.0' is full
21:45:08 DEBUG| VM appears to be alive with PID 2002
21:45:08 DEBUG| (monitor hmp1) Sending command 'info cpus' 
21:45:08 DEBUG| (monitor hmp1) Response to 'info cpus'
21:45:08 DEBUG| (monitor hmp1)* CPU #0: pc=0xfff0 thread_id=2004
21:45:08 DEBUG| (monitor hmp1)  CPU #1: pc=0xfff0 thread_id=2005
21:45:09 DEBUG| (monitor hmp1) Sending command 'cont' 
21:45:09 INFO | Migrating to tcp:0:5200
21:45:09 DEBUG| (monitor hmp1) Sending command 'migrate -d tcp:0:5200' 
21:45:10 WARNI| Could not find (qemu) prompt after command 'screendump 
/dev/shm/scrdump-MDE7wl.ppm'. Output so far: ''
21:45:10 WARNI| VM 'virt-tests-vm1' produced an invalid screendump
21:45:10 INFO | [qemu output] qemu: warning: error while loading state section 
id 3
21:45:10 INFO | [qemu output] load of migration failed
21:45:10 INFO | [qemu output] /bin/sh: line 1:  1867 Segmentation fault  
/home/lmr/Code/qemu/x86_64-softmmu/qemu-system-x86_64 -S -name 'virt-tests-vm1' 
-nodefaults -chardev 
socket,id=hmp_id_hmp1,path=/tmp/monitor-hmp1-20130415-214454-pGmRwNvs,server,nowait
 -mon chardev=hmp_id_hmp1,mode=readline -chardev 
socket,id=serial_id_serial1,path=/tmp/serial-serial1-20130415-214454-pGmRwNvs,server,nowait
 -device isa-serial,chardev=serial_id_serial1 -chardev 
socket,id=seabioslog_id_20130415-214454-pGmRwNvs,path=/tmp/seabios-20130415-214454-pGmRwNvs,server,nowait
 -device 
isa-debugcon,chardev=seabioslog_id_20130415-214454-pGmRwNvs,iobase=0x402 
-device ich9-usb-uhci1,id=usb1 -drive 
file='/home/lmr/Code/virt-test.git/shared/data/images/jeos-17-64.qcow2',if=none,id=virtio0
 -device virtio-blk-pci,drive=virtio0,bootindex=1 -device 
virtio-net-pci,netdev=id33wvth,mac='9a:42:43:44:45:46',id='idavPVhj' -netdev 
user,id=id33wvth,hostfwd=tcp::5001-:22 -m 1024 -smp 
2,maxcpus=2,cores=1,threads=1,so:

We've missed those problems during the last couple of weeks due to
problems in our test grid. The problem can be seen running the default
test set on virt-test. By default, virt-test does not use
MALLOC_PERTURB_=1. When using MALLOC_PERTURB_=1, pretty much all
migration modes will fail.

** 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/1169375

Title:
  qemu.git master -> qemu segfaults during tcp migration (and other
  modes when using MALLOC_PERTURB_=1)

Status in QEMU:
  New

Bug description:
  Relevant qemu.git master commit:

  24a6e7f4d91e9ed5f8117ecb083431a23f8609a0

  When trying to migrate a VM using the TCP protocol, a segfault
  happened:

  21:45:07 INFO | Running qemu command (reformatted):
  /home/lmr/Code/qemu/x86_64-softmmu/qemu-system-x86_64 \
  -S \
  -name 'virt-tests-vm1' \
  -nodefaults \
  -chardev 
socket,id=hmp_id_hmp1,path=/tmp/monitor-hmp1-20130415-214507-8fDeX7Fj,server,nowait
 \
  -mon chardev=hmp_id_hmp1,mode=readline \
  -chardev 
socket,id=serial_id_serial1,path=/tmp/serial-serial1-20130415-214507-8fDeX7Fj,server,nowait
 \
  -device isa-serial,chardev=serial_id_serial1 \
  -chardev 
socket,id=seabioslog_id_20130415-214507-8fDeX7Fj,path=/tmp/seabios-20130415-214507-8fDeX7Fj,server,nowait
 \
  -device 
isa-debugcon,chardev=seabioslog_id_20130415-214507-8fDeX7Fj,iobase=0x402 \

Re: [Qemu-devel] [BUG latest master] - qemu segfaults when issuing screendump cmd

[Lucas Meneghel Rodrigues]

On Tue, 2013-04-16 at 09:39 +0200, Gerd Hoffmann wrote:
> On 04/15/13 18:49, Lucas Meneghel Rodrigues wrote:
> > Latest qemu.git master is failing big time to pass sanity checks:
> > 
> > https://bugs.launchpad.net/qemu/+bug/1169254
> > 
> > We've had some issues with the test jobs, and finally managed to
> > stabilize the grid, so we don't have results for the last couple of
> > weeks to bisect the problem.
> 
> Can you try this?
>   git://git.kraxel.org/qemu rebase/pixman
> 
> [ I'm about to prepare a pull req, was planning
>to do it last week but got sick ... ]

Yes, in your branch, the problem is solved. Anthony came up with an even
simpler reproducer:

$ (sleep 1; echo -e 'screendump abc.ppm\nquit') | MALLOC_PERTURB_=1 
x86_64-softmmu/qemu-system-x86_64 -monitor stdio -vnc :0
QEMU 1.4.50 monitor - type 'help' for more information
(qemu) screendump abc.ppm
(qemu) quit

With current master, qemu crashes.

[lmr@thinkpad-t420s qemu-gerd]$ (sleep 1; echo -e 'screendump abc.ppm\nquit') | 
MALLOC_PERTURB_=1 x86_64-softmmu/qemu-system-x86_64 -monitor stdio -vnc :0
QEMU 1.4.50 monitor - type 'help' for more information
(qemu) screendump abc.ppm
Segmentation fault

[Qemu-devel] [Bug 1169375] Re: qemu.git master -> qemu segfaults during tcp migration (and other modes when using MALLOC_PERTURB_=1)

[Lucas Meneghel Rodrigues]

Problem fixed with this commit, recently pushed to master:

commit 7dda5dc82a776a39a7996020c188eb2a29187117
Author: Paolo Bonzini 
Date:   Tue Apr 9 17:43:43 2013 +0200

migration: initialize RAM to zero

Using qemu_memalign only leaves the RAM zero by chance, because libc
will usually use mmap to satisfy our huge requests.  But memory will
not be zero when using MALLOC_PERTURB_ with a nonzero value.  In the
case of incoming migration, this breaks a recently-introduced
invariant (commit f1c7279, migration: do not sent zero pages in
bulk stage, 2013-03-26).

To fix this, use mmap ourselves to get a well-aligned, always zero
block for the RAM.  Mmap-ed memory is easy to "trim" at the sides.

This also removes the need to do something special on valgrind
(see commit c2a8238a, Support running QEMU on Valgrind, 2011-10-31),
thus effectively reverts that patch.

Reviewed-by: Juan Quintela 
Signed-off-by: Paolo Bonzini 
Reviewed-by: Markus Armbruster 
Message-id: 136553-20153-1-git-send-email-pbonz...@redhat.com
Signed-off-by: Anthony Liguori 

I'll take the opportunity and also make MALLOC_PERTURB_=1 as default on
virt-tests. This will help to avoid such regressions in the future.

** Changed in: qemu
   Status: New => Fix Committed

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1169375

Title:
  qemu.git master -> qemu segfaults during tcp migration (and other
  modes when using MALLOC_PERTURB_=1)

Status in QEMU:
  Fix Committed

Bug description:
  Relevant qemu.git master commit:

  24a6e7f4d91e9ed5f8117ecb083431a23f8609a0

  When trying to migrate a VM using the TCP protocol, a segfault
  happened:

  21:45:07 INFO | Running qemu command (reformatted):
  /home/lmr/Code/qemu/x86_64-softmmu/qemu-system-x86_64 \
  -S \
  -name 'virt-tests-vm1' \
  -nodefaults \
  -chardev 
socket,id=hmp_id_hmp1,path=/tmp/monitor-hmp1-20130415-214507-8fDeX7Fj,server,nowait
 \
  -mon chardev=hmp_id_hmp1,mode=readline \
  -chardev 
socket,id=serial_id_serial1,path=/tmp/serial-serial1-20130415-214507-8fDeX7Fj,server,nowait
 \
  -device isa-serial,chardev=serial_id_serial1 \
  -chardev 
socket,id=seabioslog_id_20130415-214507-8fDeX7Fj,path=/tmp/seabios-20130415-214507-8fDeX7Fj,server,nowait
 \
  -device 
isa-debugcon,chardev=seabioslog_id_20130415-214507-8fDeX7Fj,iobase=0x402 \
  -device ich9-usb-uhci1,id=usb1 \
  -drive 
file='/home/lmr/Code/virt-test.git/shared/data/images/jeos-17-64.qcow2',if=none,id=virtio0
 \
  -device virtio-blk-pci,drive=virtio0,bootindex=1 \
  -device 
virtio-net-pci,netdev=idr5RNof,mac='9a:42:43:44:45:46',id='idJVlBu3' \
  -netdev user,id=idr5RNof,hostfwd=tcp::5000-:22 \
  -m 1024 \
  -smp 2,maxcpus=2,cores=1,threads=1,sockets=2 \
  -cpu 'SandyBridge' \
  -M pc \
  -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 \
  -vnc :1 \
  -vga std \
  -rtc base=utc,clock=host,driftfix=none  \
  -boot order=cdn,once=c,menu=off  \
  -enable-kvm \
  -incoming tcp:0:5200
  21:45:08 INFO | [qemu output] qemu-system-x86_64: -device 
usb-tablet,id=usb-tablet1,bus=usb1.0,port=1: Bus 'virtio-pci-bus.0' is full
  21:45:08 DEBUG| VM appears to be alive with PID 2002
  21:45:08 DEBUG| (monitor hmp1) Sending command 'info cpus' 
  21:45:08 DEBUG| (monitor hmp1) Response to 'info cpus'
  21:45:08 DEBUG| (monitor hmp1)* CPU #0: pc=0xfff0 
thread_id=2004
  21:45:08 DEBUG| (monitor hmp1)  CPU #1: pc=0xfff0 
thread_id=2005
  21:45:09 DEBUG| (monitor hmp1) Sending command 'cont' 
  21:45:09 INFO | Migrating to tcp:0:5200
  21:45:09 DEBUG| (monitor hmp1) Sending command 'migrate -d tcp:0:5200' 
  21:45:10 WARNI| Could not find (qemu) prompt after command 'screendump 
/dev/shm/scrdump-MDE7wl.ppm'. Output so far: ''
  21:45:10 WARNI| VM 'virt-tests-vm1' produced an invalid screendump
  21:45:10 INFO | [qemu output] qemu: warning: error while loading state 
section id 3
  21:45:10 INFO | [qemu output] load of migration failed
  21:45:10 INFO | [qemu output] /bin/sh: line 1:  1867 Segmentation fault  
/home/lmr/Code/qemu/x86_64-softmmu/qemu-system-x86_64 -S -name 'virt-tests-vm1' 
-nodefaults -chardev 
socket,id=hmp_id_hmp1,path=/tmp/monitor-hmp1-20130415-214454-pGmRwNvs,server,nowait
 -mon chardev=hmp_id_hmp1,mode=readline -chardev 
socket,id=serial_id_serial1,path=/tmp/serial-serial1-20130415-214454-pGmRwNvs,server,nowait
 -device isa-serial,chardev=serial_id_serial1 -chardev 
socket,id=seabioslog_id_20130415-214454-pGmRwNvs,path=/tmp/seabios-20130415-214454-pGmRwNvs,server,nowait
 -device 
isa-debugcon,chardev=seabioslog_id_20130415-214454-pGmRwNvs,iobase=0x402 
-device ich9-usb-uhci1,id=usb1 -drive 
file='/home/lmr/Code/virt-test.git/shared/data/images/jeos-17-64.qcow2',if=none,id=virtio0
 -device virtio-blk-pci,d

[Qemu-devel] [PATCH] run: Introduce --use-malloc-perturb specific qemu flag

[Lucas Meneghel Rodrigues]

Setting the environment variable MALLOC_PERTURB_ to
a non zero value [1] helps to find out some subtle
memory allocation problems, and it is being used in
our test grid. However, by default, the virt test
runner doesn't use it.

Add the new, qemu test specific --use-malloc-perturb flag
and set it to 'yes' (use the env variable) by default.
This way we're being more strict, which makes sense
in the context of a test suite. If people want to double
check the behavior of the test without the flag, just
use '--use-malloc-perturb no'.

[1] http://udrepper.livejournal.com/11429.html

Signed-off-by: Lucas Meneghel Rodrigues 
---
 run | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/run b/run
index 170f00a..dd203aa 100755
--- a/run
+++ b/run
@@ -238,6 +238,11 @@ class VirtTestRunParser(optparse.OptionParser):
 "If -c is provided and this flag is omitted, "
 "no attempt to set the qemu binaries will be made. 
"
   "Default path: %s" % qemu_bin_path))
+qemu.add_option("--use-malloc-perturb", action="store",
+dest="malloc_perturb", default="yes",
+help=("Use MALLOC_PERTURB_ env variable set to 1 "
+  "to help catch memory allocation problems on "
+  "qemu (yes or no). Default: %default"))
 qemu.add_option("--accel", action="store", dest="accel", default="kvm",
 help=("Accelerator used to run qemu (kvm or tcg). "
   "Default: kvm"))
@@ -468,6 +473,11 @@ class VirtTestApp(object):
 logging.info("Config provided, ignoring --vhost option")
 
 
+def _process_malloc_perturb(self):
+self.cartesian_parser.assign("malloc_perturb",
+ self.options.malloc_perturb)
+
+
 def _process_qemu_specific_options(self):
 """
 Calls for processing all options specific to the qemu test.
@@ -484,6 +494,7 @@ class VirtTestApp(object):
 self._process_nic_model()
 self._process_disk_buses()
 self._process_vhost()
+self._process_malloc_perturb()
 
 
 def _process_guest_os(self):
-- 
1.8.2

Re: [Qemu-devel] [BUG latest master] - qemu segfaults when issuing screendump cmd

[Lucas Meneghel Rodrigues]

On Thu, 2013-04-18 at 08:53 +0200, Gerd Hoffmann wrote:
> >> Can you try this?
> >>   git://git.kraxel.org/qemu rebase/pixman
> >>
> 
> > With current master, qemu crashes.
> 
> FYI: pull req sent, anthony merged, so it is fixed in master now.
> 
> autotest might need adaptions nevertheless, on headless configurations
> (-vga none) qemu starts throwing errors now (due to lack of a screen it
> can dump from) instead of silently doing nothing.

Oh, absolutely. An error at least is normal program operation/behavior,
so we'll adapt it. It's rather different than a segmentation fault,
which is a bug regardless of the circumstances.

Thanks, I'll verify and mark the bug as fixed.

[Qemu-devel] [Bug 1169254] Re: latest qemu.git master -> qemu-system-x86_64 crashes when issuing screendump command over monitor

[Lucas Meneghel Rodrigues]

Gerd sent a pull request that was merged, fixing the problem

top commit: 09dada400328d75daf79e3eca1e48e024fec148d

Problem is now fixed on latest qemu.git master.

** Changed in: qemu
   Status: New => Fix Committed

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1169254

Title:
  latest qemu.git master -> qemu-system-x86_64 crashes when issuing
  screendump command over monitor

Status in QEMU:
  Fix Committed

Bug description:
  Found the problem during sanity test of the 'next' branch

  git commit ID is e2ec3f976803b360c70d9ae2ba13852fa5d11665 (tag
  v1.4.0-1202-ge2ec3f9)

  For reference, kernel is upstream kvm.git

  git commit ID is 31880c37c11e28cb81c70757e38392b42e695dc6 (tag
  v3.8-12524-g31880c3)

  Steps to reproduce:

  Start qemu, reference cmd:

  MALLOC_PERTURB_=1 /usr/local/autotest/tests/virt/qemu/qemu \
  -S \
  -name 'vm1' \
  -nodefaults \
  -chardev 
socket,id=hmp_id_hmp1,path=/tmp/monitor-hmp1-20130415-120337-CX4dw84y,server,nowait
 \
  -mon chardev=hmp_id_hmp1,mode=readline \
  -chardev 
socket,id=qmp_id_qmp1,path=/tmp/monitor-qmp1-20130415-120337-CX4dw84y,server,nowait
 \
  -mon chardev=qmp_id_qmp1,mode=control \
  -chardev 
socket,id=serial_id_serial1,path=/tmp/serial-serial1-20130415-120337-CX4dw84y,server,nowait
 \
  -device isa-serial,chardev=serial_id_serial1 \
  -chardev 
socket,id=seabioslog_id_20130415-120337-CX4dw84y,path=/tmp/seabios-20130415-120337-CX4dw84y,server,nowait
 \
  -device 
isa-debugcon,chardev=seabioslog_id_20130415-120337-CX4dw84y,iobase=0x402 \
  -device ich9-usb-uhci1,id=usb1 \
  -drive 
file='/usr/local/autotest/tests/virt/shared/data/images/rhel63-64.qcow2',if=none,id=virtio0
 \
  -device virtio-blk-pci,drive=virtio0,bootindex=1 \
  -device 
virtio-net-pci,netdev=id7t6ont,mac='9a:16:17:18:19:1a',id='idQ3SyRX' \
  -netdev tap,id=id7t6ont,vhost=on,fd=24 \
  -m 2048 \
  -smp 2,maxcpus=2,cores=1,threads=1,sockets=2 \
  -cpu 'Opteron_G3' \
  -M pc \
  -drive 
file='/usr/local/autotest/tests/virt/shared/data/isos/linux/RHEL-6.3-x86_64-DVD.iso',media=cdrom,index=2
 \
  -drive 
file='/usr/local/autotest/tests/virt/shared/data/images/rhel63-64/ks.iso',media=cdrom,index=1
 \
  -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 \
  -kernel 
'/usr/local/autotest/tests/virt/shared/data/images/rhel63-64/vmlinuz' \
  -append 'ks=cdrom nicdelay=60 console=ttyS0,115200 console=tty0' \
  -initrd 
'/usr/local/autotest/tests/virt/shared/data/images/rhel63-64/initrd.img' \
  -vnc :0 \
  -vga std \
  -rtc base=utc,clock=host,driftfix=none  \
  -boot order=cdn,once=d,menu=off  \
  -enable-kvm

  2) Connect to the monitor

  nc -U /tmp/monitor-hmp1-20130415-120337-CX4dw84y,server,nowait

  3) Unpause the VM

  [root@virtblade03 autotest]# nc -U /tmp/monitor-hmp1-20130415-120943-D6zKUQFO
  QEMU 1.4.50 monitor - type 'help' for more information
  (qemu) cont
  cont

  4) Ask for a screendump

  (qemu) screendump abc.ppm
  screendump abc.ppm

  At this point, qemu crashes.

   Program terminated with signal 11, Segmentation fault.
   #0  pixman_image_get_width (image=0x101010101010101) at pixman-image.c:834
   834 if (image->type == BITS)
   (gdb) bt
   #0  pixman_image_get_width (image=0x101010101010101) at pixman-image.c:834
   #1  0x7f0b44158374 in ppm_save (filename=0x7f0b46762a30 
"/dev/shm/scrdump-miGZom.ppm", ds=0x7f0b466b7a50, errp=0x7fff41c08260)
   at /usr/local/autotest/tmp/virt/src/qemu/hw/display/vga.c:2401
   #2  0x7f0b4410f18e in qmp_screendump (filename=0x7f0b46762a30 
"/dev/shm/scrdump-miGZom.ppm", errp=0x7fff41c08260) at ui/console.c:195
   #3  0x7f0b43ffc77a in hmp_screen_dump (mon=0x7f0b46530d80, 
qdict=) at hmp.c:1335
   #4  0x7f0b4418c889 in handle_user_command (mon=mon@entry=0x7f0b46530d80, 
cmdline=) at /usr/local/autotest/tmp/virt/src/qemu/monitor.c:4007
   #5  0x7f0b4418cc0b in monitor_command_cb (mon=0x7f0b46530d80, 
cmdline=, opaque=)
   at /usr/local/autotest/tmp/virt/src/qemu/monitor.c:4623
   #6  0x7f0b440fe69b in readline_handle_byte (rs=0x7f0b46689a30, 
ch=) at readline.c:373
   #7  0x7f0b4418c954 in monitor_read (opaque=, 
buf=, size=) at 
/usr/local/autotest/tmp/virt/src/qemu/monitor.c:4609
   #8  0x7f0b440ec029 in qemu_chr_be_write (len=, 
buf=0x7fff41c08400 "\n", s=0x7f0b46506c00) at qemu-char.c:187
   #9  tcp_chr_read (chan=, cond=, 
opaque=0x7f0b46506c00) at qemu-char.c:2519
   #10 0x7f0b43622a75 in g_main_dispatch (context=0x7f0b46506240) at 
gmain.c:2715
   #11 g_main_context_dispatch (context=context@entry=0x7f0b46506240) at 
gmain.c:3219
   #12 0x7f0b440c4c78 in glib_pollfds_poll () at main-loop.c:187
   #13 os_host_main_loop_wait (timeout=) at main-loop.c:232
   #14 main_loop_wait (nonblocking=) at main-loop.c:468
   #15 0x7f0b43faab55 in main_loop () at v

Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU

[Lucas Meneghel Rodrigues]

On 12/19/2011 03:55 PM, Anthony Liguori wrote:

On 12/19/2011 11:39 AM, Avi Kivity wrote:

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.



The consensus of that future thread is that kvm-autotest needs to be
able to driver qemu-test, with longer repeat counts where appropriate.


Ack. I'm happy to help make the driver work too.

Regards,

Anthony Liguori



This is similar to kvm-unit-tests btw, that too is a standalone project,
with some glue magic in kvm-autotest. And they lived happily ever after.


I'm happy to see we already wrapped up the discussion. I'll gladly 
review the set of tests and make sure autotest can drive it. Once that 
is done, we'll execute the latest suite against the latest master branch 
daily.

Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU

[Lucas Meneghel Rodrigues]

On 12/27/2011 02:40 PM, Anthony Liguori wrote:

On 12/27/2011 09:58 AM, Avi Kivity wrote:

On 12/27/2011 05:22 PM, Anthony Liguori wrote:


The infrastructure assumes that you have a full OS available in the
guest. The tests are written in Python and make a variety of
assumptions. To my knowledge, it's not very practical to build a
busybox environment with Python embedded in it.


You could move whatever infrastructure qemu-test uses to kvm-autotest,
at which point kvm-autotest will know everything qemu-test knows. But
there's zero reason to do that, autotest is designed to drive external
tests and in fact most of the tests it supports are not in the autotest
repository.


Yes. I think having a qemu-test driver for kvm-autotest that knows
enough to invoke the qemu-tests and integrate the results in autotest
results reporting is the right thing to do.


I am happy with that too.

There's a slight inaccuracy when you've mentioned that KVM autotest 
mandates guest OS installs to perform tests. It's possible to use 
pre-installed guest images, making the time of execution of a test job 
shorter.


But anyway, your reasoning is sound. Considering that's not a lot of 
code overlap between the 2 infrastructures, as long as we can make them 
interact well, all is good. Plus, the way qemu-test is structured 
integrates well with the workflow most qemu developers are used to. In 
my point of view, it's a win-win situation, as I expect more developers 
to invest some time writing test automation.


Ideally it would be nice to have more people contributing tests to both 
qemu-test *and* kvm autotest, no doubt, but this is something we (kvm 
autotest team) still have to figure how to accomplish.

Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU

[Lucas Meneghel Rodrigues]

On 12/29/2011 05:04 PM, Peter Maydell wrote:

On 29 December 2011 18:35, Anthony Liguori  wrote:

On 12/29/2011 11:49 AM, Peter Maydell wrote:

The next obvious question is: are we going to make a serious attempt?
(For instance, in a hypothetical tests-required world, would we
tell those nice folks from Samsung "no you can't land your
Exynos patches unless you write 9000+ lines of test cases" ?


The virtio-serial test case I posted was 50 lines in qemu-test.  The
virtio-serial driver is about ~1500 LOC.  That's about 3%.


This just means it's testing only a fraction of what virtio-serial
actually implements (as you note yourself in the comments for the
test case). For serious coverage you'd also need to cover reading(!),
larger quantities of data than single lines, what happens when one end
feeds in data but the other end isn't reading, vmstate save/load,
multiple simultaneous ports, behaviour on close-and-reopen,
whether it works on bigendian targets, benchmarking to identify
possible performance regressions, etc etc. I think that by the time
you've done all that you'll be closer to 1500 lines than 50.


Agreed. There's a reason why virtio-serial testing in kvm autotest is 
2.1 k LOC for the test itself and 0.9 k LOC for the auxiliary guest 
script. Most of the scenarios you've described are covered on kvm 
autotest version.



I would expect that we at least have some sort of test that could verify
that the Exynos platform more or less worked as expected.  If that was just
booting a Linux kernel, that would be fine by me.


Yes. There's a large range between "no tests required at all" (essentially
what we have now) and "an equivalent level of device testing to what you
would carry out before sending your hardware design out to be fabbed into
silicon" (which I hope we'd all agree would be ludicrously high for QEMU);
I'm trying to establish where we're attempting to set our bar.

I agree that we'd get a lot of bang-for-the-buck out of basic automated
"boot the guest and prod it" testing that covered most of our platforms.


And that sort of automated testing can be done right now with KVM 
autotest. Granted, I never had time to make it work with ARM, but if 
people are interested, we are happily accepting patches :)

Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU

[Lucas Meneghel Rodrigues]

On 12/29/2011 12:38 PM, Dor Laor wrote:

 From the recent threads it looks to me that the 2 advantages of
qemu-test over kvm-autotest are:

1. python is not used within the guest


^ Just a (relatively small) subset of KVM autotest tests do require 
python in the guest (the ones that execute the autotest client inside 
the guest, virtio-console, and ksm overcommit), so if you don't want py 
on the guest, just execute the tests that do not require it. For 
example, we don't rely on any python for the Windows tests.



2. qemu-test is smaller and simpler

Except for the above 2, kvm autotest is superior. My main motivation to
merge qemu-test and kvm autotest is that I fear that qemu-test will be
the only requirement for committing stuff for qemu and developers will
be excused from their 'duty' by writing a 50 LOC shell script and assume
they done w/ testing. In addition to that, the 50 LOC will be too basic
and only provide value for basic functionality tests and kvm autotest
folks will need to rewrite all of the matching content and beyond.


Requiring people to writing tests for qemu-test is already a improvement 
over the current situation. It might make people more interested and 
engaged on test driven development, some of them might want to take the 
time and learn how to use and develop tests for autotest. We gotta start 
with something :)



Those above 2 advantages can be solve:

1. python is not used within the guest
- One option is just to use the same shell code in kvm autotest w/o
no python code and use the same kernel/initramfs.
- Another way is to use a plain linux distro w/ python and boot it
into single user test mode and potentially use a S4 guest snapshot
or external snapshot to shorten its boot time.
You'll get faster boot time and friendlier code.


Yes, slowly we are making autotest and the kvm tests faster by disabling 
by default some settings that make more sense to be enabled on automated 
test grids (drop memory caches, take a list of all packages installed on 
the test machine *between* tests, things like that). Hopefully it'll 
improve the experience of using it quite a lot.


Then, on the virt test side, we can find ways to cut the time to start 
the functional tests like you suggested (small, pre-installed images, 
snapshots, you name it). In any case, I believe that qemu-test is 
positive, since it lowers the barrier and gets people interested in 
writing tests. As long as we are careful and avoid overlapping features 
as much as possible, it's fine.

Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU

[Lucas Meneghel Rodrigues]

On 12/29/2011 03:02 PM, Anthony Liguori wrote:

On 12/29/2011 10:53 AM, Avi Kivity wrote:

On 12/29/2011 06:39 PM, Anthony Liguori wrote:

It might have made sense to split the kvm-testing functionality of
autotest, and have autotest drive that. We could even have called it
qemu-test.


I specifically advocated this during Lucas' KVM Forum talk and he was
strongly opposed to it.


Ok, this is a point where I have failed in communicating things.

I've watched the presentation on video just to see if my memory was not 
betraying me, and I wouldn't say I was 'strongly opposed', it's just 
that there are some practical problems, not impossible to overcome of 
course, but worth thinking.


 * We rely on a fair bit of autotest libraries/API, so by extracting 
the APIs we rely on to start a new project we'd be creating some code 
duplication, and updates/bugfixes on the autotest API wouldn't be easily 
carried on to the new project.
 * I'm not sure that this per se would fix the perceived problems with 
the tests. It'd be nearly the same code, just outside the autotest tree, 
I fail to see how that would be much better, and therefore, justify the 
work on doing this. Of course I might be wrong.



I think kvm autotest would get a lot more interest if the test cases
were pulled out of autotest, made more stand alone. They also should be
more Unix like being divided into individual executables with
independent command line options over a single do-everything
configuration file.


You have a point with regards to having the test cases more stand alone, 
but it's not as easy as one would think mainly because of the large 
amount of user configurable options that we have to pass to the tests. 
This is a place where the config file format shines, since we just have 
to override some parameters on different variants to have a test working 
among Windows and Linux guests, for example, all expressed in a concise 
way. The config files might look enormous, but they are actually pretty 
small compared with the amount of test combinations we can get out of 
it. This is nothing I'd call insurmountable as well.


If I get more feedback of people saying "Ok, this would make things 
better for me and make me more interested", then we'll go that route. 
I'm sorry if I gave the impression I was strongly opposed to your idea.

Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU

[Lucas Meneghel Rodrigues]

On 12/29/2011 10:33 PM, Anthony Liguori wrote:

So I decided to do some snooping. Here are some stats:

anthony@titi:~/git/autotest/client/tests/kvm/tests$ wc -l *.py
150 balloon_check.py
68 boot_savevm.py
190 cdrom.py
1875 cgroup.py
111 cpu_hotplug.py
170 enospc.py
71 floppy.py
72 getfd.py
89 hdparm.py
0 __init__.py
615 ksm_overcommit.py
107 migration_multi_host.py
117 migration.py
85 migration_with_file_transfer.py
43 migration_with_reboot.py
138 multi_disk.py
62 nic_bonding.py
104 nic_hotplug.py
60 nmi_watchdog.py
203 pci_hotplug.py
182 physical_resources_check.py
439 qemu_img.py
48 qemu_iotests.py
407 qmp_basic.py
389 qmp_basic_rhel6.py
54 set_link.py
67 smbios_table.py
356 stepmaker.py
247 steps.py
43 stop_continue.py
31 system_reset_bootable.py
181 timedrift.py
96 timedrift_with_migration.py
91 timedrift_with_reboot.py
103 timedrift_with_stop.py
28 unittest_kvmctl.py
121 unittest.py
90 usb.py
2174 virtio_console.py
85 vmstop.py
9562 total


There are more tests under client/virt/tests:

[lmr@freedom tests]$ wc -l *.py
25 autotest.py
   100 boot.py
42 build.py
32 clock_getres.py
   235 ethtool.py
84 file_transfer.py
53 fillup_disk.py
76 guest_s4.py
80 guest_test.py
45 image_copy.py
 0 __init__.py
   136 iofuzz.py
31 ioquit.py
40 iozone_windows.py
   127 jumbo.py
85 kdump.py
41 linux_s3.py
84 lvm.py
60 mac_change.py
46 module_probe.py
90 multicast.py
   106 netperf.py
   149 netstress_kill_guest.py
   255 nfs_corrupt.py
63 nicdriver_unload.py
39 nic_promisc.py
73 ping.py
29 pxe.py
42 shutdown.py
   147 softlockup.py
53 stress_boot.py
   164 trans_hugepage_defrag.py
   127 trans_hugepage.py
   113 trans_hugepage_swapping.py
   852 unattended_install.py
   175 vlan.py
46 watchdog.py
   136 whql_client_install.py
   275 whql_submission.py
49 yum_update.py
  4405 total

Not to mention the infrastructure libraries:

[lmr@freedom virt]$ wc -l *.py
  1351 aexpect.py
   705 base_installer.py
 9 common.py
 0 __init__.py
   195 installer.py
64 installer_unittest.py
   240 kvm_installer.py
   921 kvm_monitor.py
  1635 kvm_vm.py
   324 libvirt_monitor.py
  1271 libvirt_vm.py
   110 passfd.py
   237 ppm_utils.py
   519 rss_client.py
   527 virt_env_process.py
   124 virt_http_server.py
51 virt_passfd_setup.py
   229 virt_scheduler.py
  1401 virt_step_editor.py
   131 virt_test.py
   315 virt_test_setup.py
   813 virt_test_utils.py
  3556 virt_utils.py
   196 virt_utils_unittest.py
   224 virt_video_maker.py
  1032 virt_vm.py
 16180 total

There's a bit more outside this dir, not to mention the auxiliary data 
files. The support libraries account for roughly for the same number of 
lines of test code written, so we can say in very rough terms we have 
around 33 k of python code for kvm/libvirt tests. I agree it is more 
than an order of magnitude smaller than the qemu code base, but still it 
demands effort that has to be justified.



anthony@titi:~/git/autotest/client/tests$ git log --format="%an <%ae>"
kvm | sort -u

Amos Kong 
Chris Evich 
Cleber Rosa 
Jerry Tang 
lmr 
Lucas Meneghel Rodrigues 
Lucas Meneghel Rodrigues 
Lukas Doktor 
mbligh 
Onkar N Mahajan 
pradeep 
Qingtang Zhou 
Thomas Jarosch 
Yiqiao Pu 

Which leads me to the following conclusions:

1) No one outside of autotest developers is actually contributing tests
to kvm-autotest.


Autotest was maintained using subversion until recently, all commits 
from people outside autotest were commited by autotest developers, the 
git tree was just a mirror until recently. Grepping for Signed-off-by: 
lines will give a much better idea of the contributors:


[lmr@freedom autotest.git]$ git log client/virt | grep "Signed-off-by:" 
| sort -u

Signed-off-by: Xu He Jie 
Signed-off-by: Alon Levy 
Signed-off-by: Amos Kong 
Signed-off-by: Chen Cao 
Signed-off-by: Chris Evich 
Signed-off-by: Cleber Rosa 
Signed-off-by: Feng Yang 
Signed-off-by: Gerd Hoffmann 
Signed-off-by: Jason D. Gaston 
Signed-off-by: Jason Wang 
Signed-off-by: Jiri Zupka 
    Signed-off-by: Lucas Meneghel Rodrigues 
Signed-off-by: Lukas Doktor 
Signed-off-by: Martin Jenner 
Signed-off-by: Pradeep K Surisetty 
Signed-off-by: Pradeep Kumar Surisetty 
Signed-off-by: Qingtang Zhou 
Signed-off-by: Quentin Deldycke 
Signed-off-by: Ray Chauvin 
Signed-off-by: Satheesh Rajendran 
Signed-off-by: Suqin Huang 
Signed-off-by: Wei Yang 
Signed-off-by: Xu He Jie 
Signed-off-by: Yiqiao Pu 
Signed-off-by: Yogananth Subramanian 
Signed-off-by: Yolkfull Chow 

[lmr@freedom autotest.git]$ git log client/tests/kvm | grep 
"Signed-off-by:" | sort -u

Signed-off-by: Alon Levy 
Signed-off-by: Amos Kong 
Signed-off-by: Avi Kivity 
Signed-off-by: Bear Yang 
Signed-off-by: Cao, Chen 
Signed-off-by: Chen Cao 
Signed-off-by: Chris Evich 
 

Re: [Qemu-devel] [PATCH v5 15/15] test: add image streaming test cases

[Lucas Meneghel Rodrigues]

On 01/13/2012 02:49 PM, Stefan Hajnoczi wrote:

Hi Lucas,
The Python script below verifies the image streaming feature.  It's
built on the standard library "unittest" module, as well as QEMU's
qmp.py module.  It spawns a qemu process and creates necessary disk
image files.  The tests themselves issue QMP commands and check their
result or wait for QMP events to be raised.

I think this sort of test could be done with kvm-autotest but I don't
see much usage of cmd_qmp() in client/tests/kvm/tests/.  I'm curious
how you would approach this.  The high-level steps are:

1. Create a backing file.
2. Create a test QED image file using the backing file.
3. Issue "block_stream device=drive0" to the running VM.  This should
return no value.
4. Wait for the BLOCK_JOB_COMPLETED QMP event and check its fields -
they must contain expected values.
5. Ensure "query-block-job" does not show any active jobs anymore.
6. Use qemu-io's map command to verify that the image stays compact
and isn't bloated with actual zero bytes (this is kind of unrelated to
the rest of the test).

The other test cases share much of the same building blocks as
TestSingleDrive, so they are less interesting.

Would it be possible to look at TestSingleDrive below and give a
kvm-autotest equivalent?


Yes Stefan, sorry for the late reply. I was in FUDCon, therefore taking 
care of some Fedora related autotest stuff, but I'm putting on my todo 
list to create a KVM autotest equivalent of it.


Cheers,

Lucas

Re: [Qemu-devel] [ANNOUNCE] QEMU 0.15.0-rc1 Release

[Lucas Meneghel Rodrigues]

On 08/04/2011 12:17 PM, Stefan Hajnoczi wrote:

On Sat, Jul 30, 2011 at 1:39 AM, Anthony Liguori  wrote:

On behalf of the entire QEMU team, I'm please to announce the release of
QEMU 0.15.0-rc1.  This is the second release candidate for the 0.15.0
release.

There are numerous ways you can help participate in the 0.15.0 release.
  There is a testing coordination wiki page located at:

http://wiki.qemu.org/Planning/0.15/Testing


Hi Lucas,
Is QEMU 0.15.0-rc1 being run through KVM-Autotest?


We always test git master HEAD, so, no. I can look at testing specific 
tags or branches to help with that. The release branch/tag testing was 
just not on my radar so far.


So, I didn't take a closer look, but I assume the release work is made 
through a release branch or something?



Stefan

[Qemu-devel] qemu.git v1.0-1852-gf05f6b4 regression - Bus error, followed by core dump

[Lucas Meneghel Rodrigues]

Hi,

We've noticed the following error during Windows install when using the
latest qemu from HEAD:

04/03 01:45:42 INFO |   aexpect:0786| [qemu output] /bin/sh: line 1: 21674 Bus 
error   (core dumped) MALLOC_PERTURB_=1 
/usr/local/autotest/tests/kvm/qemu -name 'vm1' -nodefaults -vga std -monitor 
unix:'/tmp/monitor-humanmonitor1-20120403-014341-3gsf',server,nowait -qmp 
unix:'/tmp/monitor-qmpmonitor1-20120403-014341-3gsf',server,nowait -serial 
unix:'/tmp/serial-20120403-014341-3gsf',server,nowait -device 
ich9-usb-uhci1,id=usb1 -drive 
file='/tmp/kvm_autotest_root/images/win7-64-sp1.qcow2',index=0,if=virtio,cache=none
 -device virtio-net-pci,netdev=idoz6GVm,mac='9a:8e:fc:08:52:29',id='idodEJ4d' 
-netdev tap,id=idoz6GVm,fd=23 -m 2048 -smp 2 -drive 
file='/tmp/kvm_autotest_root/isos/windows/en_windows_7_ultimate_with_sp1_x64_dvd_u_677332.iso',media=cdrom,index=1
 -drive 
file='/tmp/kvm_autotest_root/isos/windows/winutils.iso',media=cdrom,index=2 
-drive file='/tmp/kvm_autotest_root/isos/virtio-win.iso',media=cdrom,index=3 
-fda '/tmp/kvm_autotest_root/images/win7-64-sp1/answer.vfd' -device 
usb-tablet,id=usb-tablet1,bus=usb1.0 -vnc :0 -boot d -enable-kvm
04/03 01:45:42 INFO |   aexpect:0786| [qemu output] (Process terminated with 
status 135)

The actual command line used is:

MALLOC_PERTURB_=1 /usr/local/autotest/tests/kvm/qemu -name 'vm1' -nodefaults 
-vga std -monitor 
unix:'/tmp/monitor-humanmonitor1-20120403-014341-3gsf',server,nowait -qmp 
unix:'/tmp/monitor-qmpmonitor1-20120403-014341-3gsf',server,nowait -serial 
unix:'/tmp/serial-20120403-014341-3gsf',server,nowait -device 
ich9-usb-uhci1,id=usb1 -drive 
file='/tmp/kvm_autotest_root/images/win7-64-sp1.qcow2',index=0,if=virtio,cache=none
 -device virtio-net-pci,netdev=idoz6GVm,mac='9a:8e:fc:08:52:29',id='idodEJ4d' 
-netdev tap,id=idoz6GVm,fd=23 -m 2048 -smp 2 -drive 
file='/tmp/kvm_autotest_root/isos/windows/en_windows_7_ultimate_with_sp1_x64_dvd_u_677332.iso',media=cdrom,index=1
 -drive 
file='/tmp/kvm_autotest_root/isos/windows/winutils.iso',media=cdrom,index=2 
-drive file='/tmp/kvm_autotest_root/isos/virtio-win.iso',media=cdrom,index=3 
-fda '/tmp/kvm_autotest_root/images/win7-64-sp1/answer.vfd' -device 
usb-tablet,id=usb-tablet1,bus=usb1.0 -vnc :0  -boot d -enable-kvm

A similar error happened during RHEL 6.2 install

04/03 01:43:55 INFO |   aexpect:0786| [qemu output] /bin/sh: line 1: 21368 Bus 
error   (core dumped) MALLOC_PERTURB_=1 
/usr/local/autotest/tests/kvm/qemu -name 'vm1' -nodefaults -vga std -monitor 
unix:'/tmp/monitor-humanmonitor1-20120403-014341-3gsf',server,nowait -qmp 
unix:'/tmp/monitor-qmpmonitor1-20120403-014341-3gsf',server,nowait -serial 
unix:'/tmp/serial-20120403-014341-3gsf',server,nowait -device 
ich9-usb-uhci1,id=usb1 -drive 
file='/tmp/kvm_autotest_root/images/rhel62-64.qcow2',index=0,if=virtio,cache=none
 -device virtio-net-pci,netdev=id9w6EMs,mac='9a:8e:fc:08:f7:80',id='idodEJ4d' 
-netdev tap,id=id9w6EMs,fd=23 -m 2048 -smp 2 -drive 
file='/tmp/kvm_autotest_root/isos/linux/RHEL-6.2-x86_64-DVD.iso',media=cdrom,index=2
 -drive 
file='/tmp/kvm_autotest_root/images/rhel62-64/ks.iso',media=cdrom,index=1 
-device usb-tablet,id=usb-tablet1,bus=usb1.0 -kernel 
'/tmp/kvm_autotest_root/images/rhel62-64/vmlinuz' -append 'ks=cdrom nicdelay=60 
console=ttyS0,115200 console=tty0' -initrd 
'/tmp/kvm_autotest_root/images/rhel62-64/initrd.img' -vnc :0 -boot d -enable-kvm
04/03 01:43:55 INFO |   aexpect:0786| [qemu output] (Process terminated with 
status 135)

MALLOC_PERTURB_=1 /usr/local/autotest/tests/kvm/qemu -name 'vm1' -nodefaults 
-vga std -monitor 
unix:'/tmp/monitor-humanmonitor1-20120403-014341-3gsf',server,nowait -qmp 
unix:'/tmp/monitor-qmpmonitor1-20120403-014341-3gsf',server,nowait -serial 
unix:'/tmp/serial-20120403-014341-3gsf',server,nowait -device 
ich9-usb-uhci1,id=usb1 -drive 
file='/tmp/kvm_autotest_root/images/rhel62-64.qcow2',index=0,if=virtio,cache=none
 -device virtio-net-pci,netdev=id9w6EMs,mac='9a:8e:fc:08:f7:80',id='idodEJ4d' 
-netdev tap,id=id9w6EMs,fd=23 -m 2048 -smp 2 -drive 
file='/tmp/kvm_autotest_root/isos/linux/RHEL-6.2-x86_64-DVD.iso',media=cdrom,index=2
 -drive 
file='/tmp/kvm_autotest_root/images/rhel62-64/ks.iso',media=cdrom,index=1 
-device usb-tablet,id=usb-tablet1,bus=usb1.0 -kernel 
'/tmp/kvm_autotest_root/images/rhel62-64/vmlinuz' -append 'ks=cdrom nicdelay=60 
console=ttyS0,115200 console=tty0' -initrd 
'/tmp/kvm_autotest_root/images/rhel62-64/initrd.img' -vnc :0  -boot d 
-enable-kvm

The relevant git commit used was:

04/03 01:41:37 DEBUG|base_utils:0077| Running '/usr/bin/git fetch -q -f -u -t 
git://git.qemu.org/qemu.git master:master'
04/03 01:41:41 INFO |   git:0153| git commit ID is 
"f05f6b4adb4db3affb0cdd17383b0a7e905e66e1" (tag v1.0-1852-gf05f6b4)

There's a 2.1 core dump file saved in our results server, if there's any 
interested in it by contributors outside Red Hat, I can ssh it to some box, as 
requested.

So, even though it might be some flag w

[Qemu-devel] [RFC] Future goals for autotest and virtualization tests

[Lucas Meneghel Rodrigues]

Hi guys. For a while we have been discussing ways to make the 
virtualization tests written on top of autotest useful for development 
level testing.


One of our main goals is to provide useful tools for the qemu community, 
since we have a good number of tests and libraries written to perform 
integration/QA testing for that tool, being successfuly used by a number 
of QA teams that work on qemu. Also, we recently provided a subset of 
that infrastructure to test libvirt, one of our virtualization projects 
of interest.


We realized that some (admittedly not very radical) changes have to be 
made on autotest itself, so we're inviting other users of autotest to 
give this a good read. This same document lives in the autotest wiki:


https://github.com/autotest/autotest/wiki/FuturePlans

Please note that splitting the virt tests from autotest is not discarded 
at the moment, and it's not incompatible with the plan outlined below.



Virt tests and autotest future goals


In order to make the autotest infrastructure, and the virt tests 
developed on top of autotest more useful for the people working on 
developing linux, virt and other platform software, as well as the QA 
teams, we are working on a number of goals, to streamline, simplify and 
make the available tools appropriate for *development level testing*.


Executing tests appropriate for *QA level testing* will continue to be 
supported, as it's one of the biggest strenghts of autotest.


The problem
---

Autotest provides as of today a local engine, used to run tests on your 
local machine (your laptop or a remote server). Currently, it runs tests 
properly wrapped and packaged under the autotest client/tests/ folder, 
using specific autotest rules.


For the virt tests that live inside autotest, we have even more rules to 
follow, causing a lot of frustration for people that are not used to how 
things are structured and how to execute and select tests.


The proposed solution
-

A solution is needed for both scenarios (virt and other general purpose 
tests). The idea is to create specialized tools can run simple tests 
without packaging, code that:


 * Knows nothing about the underlying infrastructure
 * Written in any language (shell script, c, perl, you name it)

It'll be up to the test runner to make sense of the results, provided 
that the test writer follows some simple common sense principles while 
writing the code:


 1) Make the program to return 0 on success, !=0 on failure
 2) Make the program use a test output format, mainly TAP

For simple tests, we believe that option 1) will be far more popular. 
Autotest will harness the execution of the test and put the results 
under the test results directory, with all the sysinfo collection and 
other instrumentation transparently available for the user.


At some point, the test writer might want to start the framework 
features that need to be enabled explicitly, then he/she might want to 
learn how to use the python API to do so, but it'll not be a requirement.


More about the test runner
--

The test runner for both general and virt cases should have very simple 
and minimal output:


::

Results stored in /path/to/autotest/results/default
my-full-test.py -- PASS
my-other-test.py -- PASS
look-mom-i-can-use-shell.sh -- PASS
look-mom-i-can-use-perl.pl -- FAIL
test-name-is-the-description.sh -- PASS
my-yet-another-test.sh -- SKIPPED
i-like-python.py -- PASS
whatever-test.pl -- PASS

Both will be specialized tools that use the infrastructure of
client/bin/autotest-local, but with special code to attend to the output 
spec above. They will know how to handle dependencies, and skip tests if 
needed.


Directory structure
---

This is just to give a rough idea of how we won't depend the tests to be 
in the autotest source code folder:


::

/path/to/autotest -> top level dir, that will make the autotest 
libs available

 - client/bin -> Contains the test runners and auxiliary scripts
 - client/virt/tests: Contains the virt tests that still live in 
autotest
 - client/tests/kvm/tests: Contains the qemu tests that still live 
in autotest


/any/path/test1: Contains tests for software foo
/any/path/test2: Contains tests for software bar

/any/path/images: Contains minimal guest images for virtualization 
tests


Bootstrap procedure
---

In order to comfortably use the framework features, some bootstrap steps 
will be needed, along the following lines:


::

git clone git://github.com/autotest/autotest.git /path/to/autotest
export PATH='/path/to/autotest/client/bin':$PATH
export PYTHON_PATH='/path/to/autotest':$PYTHON_PATH
export AUTOTEST_DATA='/path/to/images'

Writing tests
-

Simple tests, general case
~~

As previously mentio

Re: [Qemu-devel] [RFC] Future goals for autotest and virtualization tests

[Lucas Meneghel Rodrigues]

On 03/08/2012 10:36 AM, Anthony Liguori wrote:


Virt/qemu tests: Minimal guest images
-

In order to make development level test possible, we need the tests to
run fast.
In order to do that, a set of minimal guest images is being developed
and we
have a version for x86_64 ready and functional:

https://github.com/autotest/buildroot-autotest


I'm really not a fan of buildroot. Note that in order to ship binaries,
full source needs to be provided in order to comply with the GPL. The
FSF at least states that referring to another website for source that's
not under your control doesn't satisfy the requirements of the GPL.


We have a full clone of the buildroot repository that points out to the 
sources, if it's necessary to have a clone of all the projects needed 
host there in order to be able to publish a binary image to help people, 
then we can do it.



Just out of curiosity, did you try to use qemu-test? Is there a reason
you created something different?


I did, and it does what it proposes to. Nothing against it, but we have 
code that can do more things, that has been developed for longer time.


It's similar to qemu-jeos vs buildbot, you have written scripts to 
create an image, which happens to be precisely why buildroot was written 
more than 10 years ago and it works very well, allowing me to put things 
on the image that are not possible with qemu-jeos. If the problem is to 
point out to all sub modules as git repos, we can make that happen too, 
rather than re-writing stuff that works.


For a long time I would like to see people working on a single code 
base, because that would allow things to progress further and people 
would have even better tools to use.


By implementing the features of qemu-test in autotest we could simply 
use the qemu-test tests and use autotest rather than qemu test, and 
that's why we have done it.

Re: [Qemu-devel] [RFC] Future goals for autotest and virtualization tests

[Lucas Meneghel Rodrigues]

Before I forget, I'd like to ask you about this:

On 03/08/2012 10:36 AM, Anthony Liguori wrote:

I'm really not a fan of buildroot. Note that in order to ship binaries,
full source needs to be provided in order to comply with the GPL. The
FSF at least states that referring to another website for source that's
not under your control doesn't satisfy the requirements of the GPL.


About using buildroot, what is up with it, since it is mature and works 
well? You mentioned than providing all the sources is harder than it 
looks like, and I surely think this might be the case.


But in all my naiveness, if the problem is to ship the exact source with 
the images have been built, couldn't I just ask buildroot to fetch all 
the tarball sources (there's a function to perform source download only) 
and add them to the appropriate git branch? Granted, it sounds horribly 
inefficient space wise, but wouldn't it solve the requirements? Anyone 
can uncompress tarballs and see the source there.


I've built the images using the latest release tarballs of each project, 
such as linux, uclibc, busybox and such. I wanted something up to date 
enough (example, linux 3.2.6) but not downright git master HEAD, since 
lots of problems can creep up by doing it.

Re: [Qemu-devel] [RFC] Future goals for autotest and virtualization tests

[Lucas Meneghel Rodrigues]

On 03/08/2012 02:59 PM, Ademar Reis wrote:

Agree. For QEMU developers, libvirt should not be on the way, the
interaction should be minimal or non-existent.

That's an area which will require some work in libautotest,
because due to previous QE requirements, it now invokes libvirt
methods instead of QEMU directly for a lot of stuff. But it can
be done and is part of the plan.


Just a little correction here, we have 2 different backends, one that 
uses libvirt and another that uses qemu directly, so no issue here at all.

Re: [Qemu-devel] [RFC] Future goals for autotest and virtualization tests

[Lucas Meneghel Rodrigues]

On 03/08/2012 02:59 PM, Ademar Reis wrote:

Agree. For QEMU developers, libvirt should not be on the way, the
interaction should be minimal or non-existent.

That's an area which will require some work in libautotest,
because due to previous QE requirements, it now invokes libvirt
methods instead of QEMU directly for a lot of stuff. But it can
be done and is part of the plan.


Just a little correction here, we have 2 different backends, one that 
uses libvirt and another that uses qemu directly, so no issue here at all.

Re: [Qemu-devel] [RFC] Future goals for autotest and virtualization tests

[Lucas Meneghel Rodrigues]

On 03/08/2012 03:57 PM, Anthony Liguori wrote:

On 03/08/2012 09:19 AM, Lucas Meneghel Rodrigues wrote:

Before I forget, I'd like to ask you about this:

On 03/08/2012 10:36 AM, Anthony Liguori wrote:

I'm really not a fan of buildroot. Note that in order to ship binaries,
full source needs to be provided in order to comply with the GPL. The
FSF at least states that referring to another website for source that's
not under your control doesn't satisfy the requirements of the GPL.


About using buildroot, what is up with it, since it is mature and
works well?
You mentioned than providing all the sources is harder than it looks
like, and I
surely think this might be the case.


buildroot is a full blown distribution. But instead of distributing
binaries, it only distributes source code. Think of it like Gentoo--.

It relies on third party links to fetch said source code which means
that it's not unusual


By this definition, qemu test fetch source code from 3rd party 
repositories just as much, after all you have to fetch your linux and 
busybox code from somewhere, I assume.


at all for buildroot to straight out fail. Because

it needs a GCC that can build shared libraries, it also requires
rebuilding GCC which increases the build time even for a minimalistic
configuration.


But is this additional build time a problem? Is the person expected to 
be messing around with re-creating the minimal guest images all the time?



Having a JeOS it not meant to replace having proper guests (like Fedora
or Ubuntu). As I've said in other notes, the point of having a JeOS is
to essentially use Linux as a libOS when writing unit tests.


That is why we would have a reference binary jeos image that can be 
downloaded (although not a replacement, having a small guest makes setup 
time smaller, as well as smaller time to run the tests). If people need 
to tweak kernel, etc for some reason, I'm assuming that person would 
have their own clone of the repo and rebuild the images with the 
modification, and use that for the tests, I guess just the way you would 
do with qemu-jeos.



But in all my naiveness, if the problem is to ship the exact source
with the
images have been built, couldn't I just ask buildroot to fetch all the
tarball
sources (there's a function to perform source download only) and add
them to the
appropriate git branch?


Okay, let's say I'm a developer and I want to use a new Linux kernel to
test the new virtio-pci feature I added with buildroot. Where do I
begin? What patch do I submit?


You change the configuration file to build your linux from git rather 
than the tarball, change the linux config and type 'make'. At the end, 
you'll have a patch that can be sent and kept in another 
autotest-buildroot branch, if it's proven to be useful *for other people*.


All in all, I don't see what is the big difference between this workflow 
and qemu-jeos.

Re: [Qemu-devel] [RFC] Future goals for autotest and virtualization tests

[Lucas Meneghel Rodrigues]

On 03/08/2012 04:43 PM, Anthony Liguori wrote:

On 03/08/2012 01:34 PM, Lucas Meneghel Rodrigues wrote:

On 03/08/2012 03:57 PM, Anthony Liguori wrote:

On 03/08/2012 09:19 AM, Lucas Meneghel Rodrigues wrote:

Before I forget, I'd like to ask you about this:

On 03/08/2012 10:36 AM, Anthony Liguori wrote:

I'm really not a fan of buildroot. Note that in order to ship
binaries,
full source needs to be provided in order to comply with the GPL. The
FSF at least states that referring to another website for source
that's
not under your control doesn't satisfy the requirements of the GPL.


About using buildroot, what is up with it, since it is mature and
works well?
You mentioned than providing all the sources is harder than it looks
like, and I
surely think this might be the case.


buildroot is a full blown distribution. But instead of distributing
binaries, it only distributes source code. Think of it like Gentoo--.

It relies on third party links to fetch said source code which means
that it's not unusual


By this definition, qemu test fetch source code from 3rd party
repositories just
as much, after all you have to fetch your linux and busybox code from
somewhere,
I assume.


It uses git submodules with repositories hosted on git.qemu.org.


The linux, uclibc, gcc and and busybox repositories are nowhere to be 
seen there. Also, from .gitmodules for qemu-jeos:


[submodule "busybox"]
path = busybox
url = git://busybox.net/busybox.git
[submodule "linux"]
path = linux
url = 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

[submodule "uClibc"]
path = uClibc
url = git://uclibc.org/uClibc.git
[submodule "binutils"]
path = binutils
url = git://sources.redhat.com/git/binutils.git
[submodule "gcc"]
path = gcc
url = git://gcc.gnu.org/git/gcc.git

So still pretty much a lot of code outside the qemu.org realm.



at all for buildroot to straight out fail. Because

it needs a GCC that can build shared libraries, it also requires
rebuilding GCC which increases the build time even for a minimalistic
configuration.


But is this additional build time a problem? Is the person expected to be
messing around with re-creating the minimal guest images all the time?


I think it's common enough to want to update the guest kernel that yes,
this is something that many people need to be able to do in order for
the test cases to be effective. If it takes 24hr to rebuild the images,
that's problematic.


I'd say more like 2 hours on commodity hardware to do a full rebuild. 
Incremental rebuilds are much quicker (under 20 minutes), since gcc and 
all userspace was already built, so no need to do a full rebuild each 
time you want to update the kernel.



Having a JeOS it not meant to replace having proper guests (like Fedora
or Ubuntu). As I've said in other notes, the point of having a JeOS is
to essentially use Linux as a libOS when writing unit tests.


That is why we would have a reference binary jeos image that can be
downloaded
(although not a replacement, having a small guest makes setup time
smaller, as
well as smaller time to run the tests). If people need to tweak
kernel, etc for
some reason, I'm assuming that person would have their own clone of
the repo and
rebuild the images with the modification, and use that for the tests,
I guess
just the way you would do with qemu-jeos.


Yes, but this is a common thing. This is something that needs to be
designed for upfront for the infrastructure to be useful.


But in all my naiveness, if the problem is to ship the exact source
with the
images have been built, couldn't I just ask buildroot to fetch all the1:30
tarball
sources (there's a function to perform source download only) and add
them to the
appropriate git branch?


Okay, let's say I'm a developer and I want to use a new Linux kernel to
test the new virtio-pci feature I added with buildroot. Where do I
begin? What patch do I submit?


You change the configuration file to build your linux from git rather
than the
tarball, change the linux config and type 'make'. At the end, you'll
have a
patch that can be sent and kept in another autotest-buildroot branch,
if it's
proven to be useful *for other people*.


Except you also need to update those tarballs too that you're storing in
git, remember.

Herein lies the problem. You forgot and it's your proposal :-)


Ok, fair enough :) But still, qemu-jeos points out to external 
repositories, just as much as buildroot. It seems to me that the whole 
point about FSF requiring the source to be under your control is no 
longer valid here.

Re: [Qemu-devel] [RFC] Future goals for autotest and virtualization tests

[Lucas Meneghel Rodrigues]

On 03/08/2012 06:24 PM, Anthony Liguori wrote:


Cons:
- Lot of code will be duplicated to cover the main code paths:
writting tests will require writting/supporting considerable
ammount of code (that already exists in autotest).


Again, existence proof that this isn't true.


Case in point, the virtio test (that uses an auxiliary script to send 
data to the host). Can you tell me if both tests cover even remotely the 
same amount of functionality?


https://github.com/autotest/autotest/blob/master/client/tests/kvm/tests/virtio_console.py

https://github.com/autotest/autotest/blob/master/client/virt/scripts/virtio_console_guest.py

Here is the qemu-test version

http://git.qemu.org/?p=qemu-test.git;a=blob;f=tests/virtio-serial.sh;h=e95ae6e0b63758262919702d51a9c83bebe2fb08;hb=master

What the qemu-test version covers:
 * host starts qemu with one virtio console device backed by a file
 * guest verifies if the name of the device is correct
 * guest writes to the console device
 * host verifies if guest wrote to the virtio console

What the virtio-console covers:

 * Sends data between host and guest back and forth, validates the data 
being sent, for both small and large amounts of data, both random or 
sequential.
 * Tests write/send in blocking, polling, selecting mode, with port 
mode sync/async
 * Verifies if the maximum amount of ports was created and it's 
available in the guest

 * Tries lseek on the device
 * Verifies if concomitant access to a single port passes or fails
 * Verifies data throughput and resource utilization
 * Repeats the data transfer with live migration to see if the port 
connections survive
 * Keeps an eye on the guest OS to see if we have kernel panics, and if 
it does, it'll clean up and put the guest in a working state so other 
functionality can be checked

 * Probably something else I'm forgetting right now.

Good luck implementing that in a shell script. I'd love to see how you 
implement that amount of coverage in less lines in shell.


So, more coverage, more code. It's as simple as that. We don't write 
code just for the sake of it.



- QE will be alienated from the qemu test effort. There will be
no integration between the QE efforts and the maintenance of
the qemu developer-level tests.


I think we're a pretty friendly and open community :-) There is no
reason that QE should be "alienated" unless folks are choosing not to
participate upstream.


- You don't get the goodies from autotest (standardized system
info collection, video recording, grid support, etc).
- The new tests will work only on the master branch.


This last one is a legitimate point that I have considered myself. But I
think the value of having tests in HEAD outweigh the cost here.


3. A mix of (1) and (2): we "move" everything under qemu.git, but
keep the compatibility layer and provide a "libqemutest" for
third-parties.

Anybody writting a test that interacts with qemu will use this
library: qemu, libvirt, spice, ovirt, QE tests, etc.


I really see this all as over architecting to be honest.

Can someone explain in clear terms (without appealing to maturity,
flexibility, or any other qualitative aspect) why it takes anything more
than a few dozen shell functions to write all of the tests that are in
kvm-autotest test today?


Clearly as your requirements are different than the ones we had when the 
project was written, qemu-test doesn't need any of the stuff present 
there and you can do it all with a handful of shell script functions.


But to do cover the same things covered in autotest today with the same 
requirements, I really doubt you can do the same with the same handful 
of shell script functions. See the example about the virtio test above, 
not to mention other functionality we have with the tests, such as make 
possible to do tests run with a migration thread going on the 
background, while it's plugging/unplugging devices, running a stress 
test or ltp, or a benchmark, or measuring the time drift experienced by 
the guest.

Re: [Qemu-devel] [RFC] Future goals for autotest and virtualization tests

[Lucas Meneghel Rodrigues]

On 03/09/2012 09:13 AM, Anthony Liguori wrote:

On 03/08/2012 05:07 PM, Lucas Meneghel Rodrigues wrote:

Here is the qemu-test version

http://git.qemu.org/?p=qemu-test.git;a=blob;f=tests/virtio-serial.sh;h=e95ae6e0b63758262919702d51a9c83bebe2fb08;hb=master



So virtio-serial is an exception in autotest:

2174 virtio_console.py
1875 cgroup.py
615 ksm_overcommit.py
439 qemu_img.py
407 qmp_basic.py
389 qmp_basic_rhel6.py
356 stepmaker.py
247 steps.py

// The next largest actual test of QEMU
203 pci_hotplug.py
190 cdrom.py
182 physical_resources_check.py
181 timedrift.py
170 enospc.py
150 balloon_check.py
138 multi_disk.py
121 unittest.py
117 migration.py
111 cpu_hotplug.py
107 migration_multi_host.py
104 nic_hotplug.py
103 timedrift_with_stop.py
96 timedrift_with_migration.py
...

So picking virtio-serial as your comparison point is not really
representative of kvm-autotest but at any rate...


We have a bunch of high level test functions in 
client/virt/virt_test_utils.py that contain some commonly used test 
functions such as migration and running autotest tests on vms, and other 
functions, that allow us to reuse those functions on the tests and save 
code, but we can reasonably assume that it doesn't change the order of 
magnitude of the actual qemu tests in size, so point taken.


You also have a point in the respect that a lot of the large tests are 
more linux-qemu integration tests, name cpuflags, cgroups, ksm_overcommit.


The point you tried to make and I replied to was 'qemu-test tests are 
all smaller than the equivalent kvm autotest tests'. Well, sure they 
tend to be, but in pretty much all cases more code means more 
functionality being covered, and making sure the same test works on 
RHEL5, RHEL6, upstream, on an Ubuntu, Fedora, RHEL or even Windows guests.


It is indeed a bit nerve wrecking to hear that all you can do with the 
stuff you have been working on the last 3 years can be done better with 
a dozen of shell script functions. It's similar to say that we just like 
to throw lines at a text editor just for the fun of it. I am sure you 
didn't mean it but that is how it sounded, and that's why I'd like to 
assure that the code there *does stuff*. It's just that this extra stuff 
is potentially not interesting to the goal of doing developer level 
regression testing of qemu alone.

Re: [Qemu-devel] [RFC] Future goals for autotest and virtualization tests

[Lucas Meneghel Rodrigues]

On 03/09/2012 11:13 AM, Anthony Liguori wrote:

It is indeed a bit nerve wrecking to hear that all you can do with the
stuff you
have been working on the last 3 years can be done better with a dozen
of shell
script functions. It's similar to say that we just like to throw lines
at a text
editor just for the fun of it. I am sure you didn't mean it but that
is how it
sounded, and that's why I'd like to assure that the code there *does
stuff*.


Look at how this discussion started. We've been discussing testing on
qemu-devel at excruciating length and detail and have finally come to
something of a consensus. AFAIK, no one from autotest has participated
in those discussions which is fair as I'm sure ya'll don't read
qemu-devel religiously.


All right, point taken.


Then we see this note that more or less declares, this is how QEMU
should do all of its testing. What reaction did you really expect there
to be? :-)


It was an attempt to offer what we have rather than dictating how QEMU 
should do all its testing:


"""
One of our main goals is to provide useful tools for the qemu community,
since we have a good number of tests and libraries written to perform
integration/QA testing for that tool, being successfuly used by a number
of QA teams that work on qemu.
"""

I re-read the first message I sent, and certainly did not find where we 
declare that this is the way QEMU should do its testing.


If you judge that there's nothing interesting there for qemu, I'm fine 
with it. That all said, certainly I did not expect your repeated 
attempts to show that you can do it all better with a couple of shell 
script lines, oh boy, I did not.

Re: [Qemu-devel] KVM call agenda for June 21

[Lucas Meneghel Rodrigues]

On Tue, 2011-06-21 at 16:56 +0300, Avi Kivity wrote:
> On 06/21/2011 04:50 PM, Anthony Liguori wrote:
> > On 06/21/2011 06:28 AM, Avi Kivity wrote:
> >> On 06/20/2011 10:42 AM, Juan Quintela wrote:
> >>> Please send in any agenda items you are interested in covering.
> >>>
> >>
> >>
> >> https://bugzilla.redhat.com/show_bug.cgi?id=689672 - Guests do not start
> >> after upgrading qemu to 0.13
> >>
> >> Seems like our backward compatibility plan isn't working. How do we
> >> address it? How do we test it?
> >
> > f13 is ancient, no?
> 
> Yes, a year old.
> 
> Furthermore, Justin tells me it carries a lot downstream patches.
> 
> >
> > I'm not sure what this particular issue is, but is this doing -M pc-0.12?
> >
> 
> It has its own machine type.  So this report may not indicate any 
> problem with upstream.
> 
> Still, I feel we have a potential problem here.  We identify 
> guest-visible attributes just by review; we're sure to miss something 
> here and there.  Unlike ordinary bugs, compatibility problems only show 
> up later and are much harder to fix.
> 
> Second, we don't do any tests in this area that I'm aware of.  Lucas, 
> what would it take (thanks, you're most kind) to test multiple qemus in 
> a single run?

I have thought about it, people have asked about this in the past.
Here's my implementation idea:

1) Turn qemu to be a configurable option very much like images, cdroms,
nics, etc, such as:

qemu_binary_upstream = '/path/1'
qemu_binary_rhel6 = '/path/2'
...
qemu_binary_n = '/path/n'

So people in need of testing multiple qemus can set them and have them
all track down by autotest

2) Add support in the build test for building multiple user spaces

3) Make qemu_binary to be a VM param. This way if we need to change the
userspace a given VM uses, just update the params and start the vm
again. Noticing different params, the VM will be restarted using the
alternate userspace. 

I will start to work on this right now. It'll probably take a couple of
weeks for a first patchset, but it's high time we get this implemented,
since there are several uses for it.

> We can have a script that runs lspci -vvv, x86info, and 
> other interesting stuff and compare the results, and also system tests 
> that boot a guest on multiple qemus (with the same -M and different -M) 
> and see if things work.
> 
> We can probably continue on email, I don't see a real need for a call 
> for this topic.
> 

Re: [Qemu-devel] [PATCH 0/4] add "make check"

[Lucas Meneghel Rodrigues]

On 10/25/2011 01:03 PM, Eduardo Habkost wrote:

On Tue, Oct 25, 2011 at 03:27:35PM +0200, Gerd Hoffmann wrote:
[...]

A while ago I played with some simple IDE tests. It basically was a
small x86 kernel with an empty image that sends IDE commands and prints
some results, and a script that invokes the guest and checks whether the
test has passed or failed.


That reminds me that I've started toying with running tests inside a
guest too.  Stopped working on it a while back due to other priorities.
  Attached what I have so far.


So at first I started with my own multiboot kernel and copied over some
parts of kvm-unittest's libc. Clearly not the best idea once it's more
than a couple of lines, so at some point I took the code and integrated
with my real kvm-unittests repository.

Now I don't have to duplicate code any more, but at the same time
there's no chance that a 'make check' in an upstream qemu tree could run
this. Tests for other devices will have exactly the same problem.

Any suggestions on how to go forward with this kind of tests? Should
this go into qemu or into kvm-unittests? Or should kvm-unittests be
merged into the qemu tree? Or is the approach completely wrong?


I think we should have some framework to run tests inside the guest in
the qemu source tree.  I'm not sure kvm-unittests is the right tool for
the job though.  It is quite low-level and mainly targets the kvm bits
inside the linux kernel.  Testing -- for example -- usb device emulation
would pretty much require writing a usb stack for kvm-unitests ...


We have a framework to run tests inside a fully-installed guest, that's
KVM-Autotest. But maybe it's too much for the kind of tests you need, I
don't know. There are different "levels" of testing, with different
reequirements, and we need to have good tools for all levels.

Just trying to enumerate the kind of tests somebody may need:

A) Simple unit tests for internal qemu C functions
- 'make check' can run them, using either libcheck or gtest.
B) Functional tests that tests actual virtualization/emulation, but only
of some specific subsystems, not using a fully-featured qemu process.
- We don't have anything like that, today, right? I am not sure we
  need it.
C) Functional tests that just need to run a small binary with no OS
installed in the guest, but running a fully-feature qemu process.
- The tests in the 'tests' directory do this, right? kvm-unittests
  does this, right?
D) Functional tests that need a minimal OS installed, with, e.g., at
least a Linux kernel and a shell.
- This is what Gerd's patch below does, right? Also, KVM-Autotest can
  be used for this.


Yes, it can. There's instrumentation to get ssh sessions, serial 
sessions, execute monitor commands... Only need to specify the path to a 
pre-installed minimal guest, skip install tests and have the bare 
minimal subset of tests needed. If only a small subset of tests are run 
with a minimal image, a kvm autotest job is quick to run and suitable 
for development use. I've looked at Gerd's initial patch to add an 
initramfs for such lightweight testing, and the init ramdisk generation 
could be implemented in autotest.


However...

Problem today is that KVM autotest is considered to be hard to approach 
and integrate with qemu developer's workflow. I won't argue it's not, so 
I'm admitting failure here. We've been juggling to keep it stable for 
the regular, full blown QE case, with expanding test and targets 
coverage (see libvirt test), and yet trying to make it better documented 
and sufficiently easy to approach to do simpler ad hoc testing. I wish 
it was easier to accomplish the later, though.


So, an in-tree solution for D) like the one Gerd started to work on 
seems better, as it won't generate frustration from folks having to 
learn kvm autotest, which will ultimately lead to them ignoring the effort.



E) Functional tests that need a full OS installed and configured.
- Today we use KVM-Autotest for this.


Does the above model look correct/complete, or is there some case I
missed?




cheers,
   Gerd



 From 096f68ea08c3c4baf1bbdc549b257a67ecc87e25 Mon Sep 17 00:00:00 2001
From: Gerd Hoffmann
Date: Tue, 13 Sep 2011 17:38:37 +0200
Subject: [PATCH] initramfs test framework

Signed-off-by: Gerd Hoffmann
---
  initramfs/.gitignore |3 +
  initramfs/10-qemu-udev.rules |5 +
  initramfs/Makefile   |   36 +++
  initramfs/README |   44 
  initramfs/init.c |  225 ++
  initramfs/initramfs-boot |   32 ++
  initramfs/initramfs-create   |  111 +
  initramfs/test-ehci  |3 +
  initramfs/test-ehci.good |8 ++
  initramfs/test-hello.c   |7 ++
  initramfs/test-hello.good|1 +
  initramfs/test-uhci  |3 +
  initramfs/test-uhci.good |3 +
  13 files changed, 481 insertions(+), 0 deletions(-)
  create mo

[Qemu-devel] qemu/qemu-kvm floppy regression brought by 212ec7baa28cc9d819234fed1541fc1423cfe3d8

[Lucas Meneghel Rodrigues]

Hi folks:

We've captured a regression with floppy disk on recent qemu (and 
qemu-kvm, after a code merge). We bisected it to be caused by:


commit 212ec7baa28cc9d819234fed1541fc1423cfe3d8
Author: Richard Henderson 
Date:   Mon Aug 15 15:08:45 2011 -0700

fdc: Convert to isa_register_portio_list

Signed-off-by: Richard Henderson 
Signed-off-by: Avi Kivity 

Since this commit, the guest doesn't see a floppy disk attached to it 
anymore, blocking kvm autotest ability to install windows guests 
automatically. This is a big deal for kvm autotest (ruins our automated 
regression jobs), so please take a look at it.


Cheers,

Lucas and Cleber

Re: [Qemu-devel] qemu/qemu-kvm floppy regression brought by 212ec7baa28cc9d819234fed1541fc1423cfe3d8

[Lucas Meneghel Rodrigues]

On 10/26/2011 01:47 PM, Kevin Wolf wrote:

Am 26.10.2011 16:41, schrieb Lucas Meneghel Rodrigues:

Hi folks:

We've captured a regression with floppy disk on recent qemu (and
qemu-kvm, after a code merge). We bisected it to be caused by:

commit 212ec7baa28cc9d819234fed1541fc1423cfe3d8
Author: Richard Henderson
Date:   Mon Aug 15 15:08:45 2011 -0700

  fdc: Convert to isa_register_portio_list

  Signed-off-by: Richard Henderson
  Signed-off-by: Avi Kivity

Since this commit, the guest doesn't see a floppy disk attached to it
anymore, blocking kvm autotest ability to install windows guests
automatically. This is a big deal for kvm autotest (ruins our automated
regression jobs), so please take a look at it.


Can you please try again with the latest block branch? I think there is
a patch queued that will fix it.


Kevin, I did try with HEAD of your repo:

git://repo.or.cz/qemu/kevin.git

[lmr@freedom qemu-kwolf]$ git branch -r
  origin/HEAD -> origin/master
  origin/blkqueue
  origin/blkqueue-v1
  origin/block
  origin/coroutine
  origin/coroutine-block
  origin/coroutine-devel
  origin/devel
  origin/ehci
  origin/for-anthony
  origin/for-stable-0.14
  origin/inplace-conversion
  origin/master

With this repo, master branch, the problem persists. With the block 
branch, the problem persists.


Now, with the blkqueue branch the problem is resolved. Cleber had the 
same results booting a FreeDOS floppy. So the fix is indeed in blkqueue.


Oh, you might want to check the blkqueue branch, it does have quite a 
bunch of set but unused variables, which will cause compilation errors 
unless --disable-werror is passed to the configure script.


Please merge the fixes with qemu master as soon as you can, we are 
probably leave windows installs from the upstream daily jobs until the 
fixes get to master.


Thanks,

Lucas

[Qemu-devel] [Bug 318824] Re: DHCP/NAT: Vista fails to get IP from DHCP engine

[Lucas Meneghel Rodrigues]

** Changed in: qemu
   Status: Incomplete => Invalid

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/318824

Title:
  DHCP/NAT: Vista fails to get IP from DHCP engine

Status in QEMU:
  Invalid

Bug description:
  
  Problem: When I use userspace networking - i.e. Qemu NAT engine with DHCP -
  Vista 32-bit VM guest fails to recognize it.

  The only way for Vista VM to work is to manually set IP address:
  IP: 10.0.2.2
  Gateway: 10.0.2.15
  DNS: 10.0.2.3

  This problem does not happen with Windows XP VM.

  ./qemu -hda WindowsVista-32-mypc.qcow2 -m 512 -snapshot -name
  Vista-32-mypc

  btw: NAT itself works - after IPs are manually configured. Emulated NIC is
  Realtek RTL8139. Same problem also exists with Intel E1000 NIC.

  -Alexey, 19.1.2009.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/318824/+subscriptions

[Qemu-devel] [Bug 588955] Re: qemu segfaults when trying to install winvista64 sp2 64 bit on VM

[Lucas Meneghel Rodrigues]

This bug was opened a long time ago, and probably is no longer valid,
hence, closing it as invalid.

** Changed in: qemu
   Status: New => Invalid

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/588955

Title:
  qemu segfaults when trying to install winvista64 sp2 64 bit on VM

Status in QEMU:
  Invalid

Bug description:
  When trying to install windows vista sp2 64bit on a KVM VM, we get
  consistently a segfault.

  Version of qemu affected: Commit hash for
  git://git.savannah.nongnu.org/qemu.git is
  d9b73e47a3d596c5b33802597ec5bd91ef3348e2 (no tag found)

  Backtrace:

  [root@virtlab7 qemu]# gdb 
/usr/local/autotest/tests/kvm/build/bin/qemu-system-x86_64 -c ../core
  GNU gdb (GDB) Red Hat Enterprise Linux (7.1-24.el6)
  Copyright (C) 2010 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
  and "show warranty" for details.
  This GDB was configured as "x86_64-redhat-linux-gnu".
  For bug reporting instructions, please see:
  ...
  Reading symbols from 
/usr/local/autotest/tests/kvm/build/bin/qemu-system-x86_64...done.

  warning: core file may not match specified executable file.
  [New Thread 12852]
  [New Thread 12898]
  Missing separate debuginfo for
  Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install 
/usr/lib/debug/.build-id/da/38811550a55156d7072260d3b89fc8aeb79abf
  Reading symbols from /lib64/librt-2.12.so...Reading symbols from 
/usr/lib/debug/lib64/librt-2.12.so.debug...done.
  done.
  Loaded symbols for /lib64/librt-2.12.so
  Reading symbols from /lib64/libpthread-2.12.so...Reading symbols from 
/usr/lib/debug/lib64/libpthread-2.12.so.debug...done.
  done.
  Loaded symbols for /lib64/libpthread-2.12.so
  Reading symbols from /lib64/libutil-2.12.so...Reading symbols from 
/usr/lib/debug/lib64/libutil-2.12.so.debug...done.
  done.
  Loaded symbols for /lib64/libutil-2.12.so
  Reading symbols from /lib64/libncurses.so.5...(no debugging symbols 
found)...done.
  Loaded symbols for /lib64/libncurses.so.5
  Reading symbols from /usr/lib64/libsasl2.so.2...(no debugging symbols 
found)...done.
  Loaded symbols for /usr/lib64/libsasl2.so.2
  Reading symbols from /usr/lib64/libSDL-1.2.so.0...(no debugging symbols 
found)...done.
  Loaded symbols for /usr/lib64/libSDL-1.2.so.0
  Reading symbols from /usr/lib64/libX11.so.6...(no debugging symbols 
found)...done.
  Loaded symbols for /usr/lib64/libX11.so.6
  Reading symbols from /lib64/libm-2.12.so...Reading symbols from 
/usr/lib/debug/lib64/libm-2.12.so.debug...done.
  done.
  Loaded symbols for /lib64/libm-2.12.so
  Reading symbols from /lib64/libz.so.1...(no debugging symbols found)...done.
  Loaded symbols for /lib64/libz.so.1
  Reading symbols from /lib64/libc-2.12.so...Reading symbols from 
/usr/lib/debug/lib64/libc-2.12.so.debug...done.
  done.
  Loaded symbols for /lib64/libc-2.12.so
  Reading symbols from /lib64/libtinfo.so.5...(no debugging symbols 
found)...done.
  Loaded symbols for /lib64/libtinfo.so.5
  Reading symbols from /lib64/ld-2.12.so...Reading symbols from 
/usr/lib/debug/lib64/ld-2.12.so.debug...done.
  done.
  Loaded symbols for /lib64/ld-2.12.so
  Reading symbols from /lib64/libdl-2.12.so...Reading symbols from 
/usr/lib/debug/lib64/libdl-2.12.so.debug...done.
  done.
  Loaded symbols for /lib64/libdl-2.12.so
  Reading symbols from /lib64/libresolv-2.12.so...Reading symbols from 
/usr/lib/debug/lib64/libresolv-2.12.so.debug...done.
  done.
  Loaded symbols for /lib64/libresolv-2.12.so
  Reading symbols from /lib64/libcrypt-2.12.so...Reading symbols from 
/usr/lib/debug/lib64/libcrypt-2.12.so.debug...done.
  done.
  Loaded symbols for /lib64/libcrypt-2.12.so
  Reading symbols from /usr/lib64/libxcb.so.1...(no debugging symbols 
found)...done.
  Loaded symbols for /usr/lib64/libxcb.so.1
  Reading symbols from /lib64/libfreebl3.so...(no debugging symbols 
found)...done.
  Loaded symbols for /lib64/libfreebl3.so
  Reading symbols from /usr/lib64/libXau.so.6...(no debugging symbols 
found)...done.
  Loaded symbols for /usr/lib64/libXau.so.6
  Reading symbols from /usr/lib64/sasl2/libcrammd5.so...(no debugging symbols 
found)...done.
  Loaded symbols for /usr/lib64/sasl2/libcrammd5.so
  Reading symbols from /usr/lib64/sasl2/libsasldb.so...(no debugging symbols 
found)...done.
  Loaded symbols for /usr/lib64/sasl2/libsasldb.so
  Reading symbols from /lib64/libdb-4.7.so...(no debugging symbols 
found)...done.
  Loaded symbols for /lib64/libdb-4.7.so
  Reading symbols from /usr/lib64/sasl2/liblogin.so...(no debugging symbols 
found)...done.
  Loaded symbols for /usr/lib64/sasl2/liblogin.so
  Reading symbols from /usr/lib64/sasl2/libplain.so...(no debugging symbols 
found)...done.
  Lo

Re: [Qemu-devel] qemu/qemu-kvm floppy regression brought by 212ec7baa28cc9d819234fed1541fc1423cfe3d8

[Lucas Meneghel Rodrigues]

On 10/27/2011 05:17 AM, Stefan Hajnoczi wrote:

On Wed, Oct 26, 2011 at 03:19:17PM -0200, Lucas Meneghel Rodrigues wrote:

On 10/26/2011 01:47 PM, Kevin Wolf wrote:

Am 26.10.2011 16:41, schrieb Lucas Meneghel Rodrigues:

Hi folks:

We've captured a regression with floppy disk on recent qemu (and
qemu-kvm, after a code merge). We bisected it to be caused by:

commit 212ec7baa28cc9d819234fed1541fc1423cfe3d8
Author: Richard Henderson
Date:   Mon Aug 15 15:08:45 2011 -0700

  fdc: Convert to isa_register_portio_list

  Signed-off-by: Richard Henderson
  Signed-off-by: Avi Kivity

Since this commit, the guest doesn't see a floppy disk attached to it
anymore, blocking kvm autotest ability to install windows guests
automatically. This is a big deal for kvm autotest (ruins our automated
regression jobs), so please take a look at it.


Can you please try again with the latest block branch? I think there is
a patch queued that will fix it.


Kevin, I did try with HEAD of your repo:

git://repo.or.cz/qemu/kevin.git

[lmr@freedom qemu-kwolf]$ git branch -r
   origin/HEAD ->  origin/master
   origin/blkqueue
   origin/blkqueue-v1
   origin/block
   origin/coroutine
   origin/coroutine-block
   origin/coroutine-devel
   origin/devel
   origin/ehci
   origin/for-anthony
   origin/for-stable-0.14
   origin/inplace-conversion
   origin/master

With this repo, master branch, the problem persists. With the block
branch, the problem persists.

Now, with the blkqueue branch the problem is resolved. Cleber had
the same results booting a FreeDOS floppy. So the fix is indeed in
blkqueue.

Oh, you might want to check the blkqueue branch, it does have quite
a bunch of set but unused variables, which will cause compilation
errors unless --disable-werror is passed to the configure script.


I think blkqueue is an older development branch of the "block queue"
feature that Kevin was working on.  It is not Kevin's block tree (see
his "block" branch).


So no, the block branch does not resolve the floppy access problem.

Well, considering the tests of the stable set I'm running against qemu 
right now, this is not the biggest of our problems... I'm verifying qemu 
is segfaulting on nearly every prolonged attempt of doing migration... 
I'm about to write an email about it.


Thanks Stefan!

Re: [Qemu-devel] qemu/qemu-kvm floppy regression brought by 212ec7baa28cc9d819234fed1541fc1423cfe3d8

[Lucas Meneghel Rodrigues]

On Thu 27 Oct 2011 11:17:48 PM BRST, Zhi Yong Wu wrote:

On Fri, Oct 28, 2011 at 2:57 AM, Lucas Meneghel Rodrigues
  wrote:

On 10/27/2011 05:17 AM, Stefan Hajnoczi wrote:


On Wed, Oct 26, 2011 at 03:19:17PM -0200, Lucas Meneghel Rodrigues wrote:


On 10/26/2011 01:47 PM, Kevin Wolf wrote:


Am 26.10.2011 16:41, schrieb Lucas Meneghel Rodrigues:


Hi folks:

We've captured a regression with floppy disk on recent qemu (and
qemu-kvm, after a code merge). We bisected it to be caused by:

commit 212ec7baa28cc9d819234fed1541fc1423cfe3d8
Author: Richard Henderson
Date:   Mon Aug 15 15:08:45 2011 -0700

  fdc: Convert to isa_register_portio_list

  Signed-off-by: Richard Henderson
  Signed-off-by: Avi Kivity

Since this commit, the guest doesn't see a floppy disk attached to it
anymore, blocking kvm autotest ability to install windows guests
automatically. This is a big deal for kvm autotest (ruins our automated
regression jobs), so please take a look at it.


Can you please try again with the latest block branch? I think there is
a patch queued that will fix it.


Kevin, I did try with HEAD of your repo:

git://repo.or.cz/qemu/kevin.git

[lmr@freedom qemu-kwolf]$ git branch -r
   origin/HEAD ->origin/master
   origin/blkqueue
   origin/blkqueue-v1
   origin/block
   origin/coroutine
   origin/coroutine-block
   origin/coroutine-devel
   origin/devel
   origin/ehci
   origin/for-anthony
   origin/for-stable-0.14
   origin/inplace-conversion
   origin/master

With this repo, master branch, the problem persists. With the block
branch, the problem persists.

Now, with the blkqueue branch the problem is resolved. Cleber had
the same results booting a FreeDOS floppy. So the fix is indeed in
blkqueue.

Oh, you might want to check the blkqueue branch, it does have quite
a bunch of set but unused variables, which will cause compilation
errors unless --disable-werror is passed to the configure script.


I think blkqueue is an older development branch of the "block queue"
feature that Kevin was working on.  It is not Kevin's block tree (see
his "block" branch).


So no, the block branch does not resolve the floppy access problem.

Well, considering the tests of the stable set I'm running against qemu right
now, this is not the biggest of our problems... I'm verifying qemu is
segfaulting on nearly every prolonged attempt of doing migration... I'm
about to write an email about it.

What is the OS of your guest? fedora16 or RHEL6? I would like recently
to use floppy device in guest.


Fedora 15.

Re: [Qemu-devel] qemu/qemu-kvm floppy regression brought by 212ec7baa28cc9d819234fed1541fc1423cfe3d8

[Lucas Meneghel Rodrigues]

On 10/27/2011 11:17 PM, Zhi Yong Wu wrote:

On Fri, Oct 28, 2011 at 2:57 AM, Lucas Meneghel Rodrigues
  wrote:

On 10/27/2011 05:17 AM, Stefan Hajnoczi wrote:


On Wed, Oct 26, 2011 at 03:19:17PM -0200, Lucas Meneghel Rodrigues wrote:


On 10/26/2011 01:47 PM, Kevin Wolf wrote:


Am 26.10.2011 16:41, schrieb Lucas Meneghel Rodrigues:


Hi folks:

We've captured a regression with floppy disk on recent qemu (and
qemu-kvm, after a code merge). We bisected it to be caused by:

commit 212ec7baa28cc9d819234fed1541fc1423cfe3d8
Author: Richard Henderson
Date:   Mon Aug 15 15:08:45 2011 -0700

  fdc: Convert to isa_register_portio_list

  Signed-off-by: Richard Henderson
  Signed-off-by: Avi Kivity

Since this commit, the guest doesn't see a floppy disk attached to it
anymore, blocking kvm autotest ability to install windows guests
automatically. This is a big deal for kvm autotest (ruins our automated
regression jobs), so please take a look at it.


Can you please try again with the latest block branch? I think there is
a patch queued that will fix it.


Kevin, I did try with HEAD of your repo:

git://repo.or.cz/qemu/kevin.git

[lmr@freedom qemu-kwolf]$ git branch -r
   origin/HEAD ->origin/master
   origin/blkqueue
   origin/blkqueue-v1
   origin/block
   origin/coroutine
   origin/coroutine-block
   origin/coroutine-devel
   origin/devel
   origin/ehci
   origin/for-anthony
   origin/for-stable-0.14
   origin/inplace-conversion
   origin/master

With this repo, master branch, the problem persists. With the block
branch, the problem persists.

Now, with the blkqueue branch the problem is resolved. Cleber had
the same results booting a FreeDOS floppy. So the fix is indeed in
blkqueue.

Oh, you might want to check the blkqueue branch, it does have quite
a bunch of set but unused variables, which will cause compilation
errors unless --disable-werror is passed to the configure script.


I think blkqueue is an older development branch of the "block queue"
feature that Kevin was working on.  It is not Kevin's block tree (see
his "block" branch).


So no, the block branch does not resolve the floppy access problem.

Well, considering the tests of the stable set I'm running against qemu right
now, this is not the biggest of our problems... I'm verifying qemu is
segfaulting on nearly every prolonged attempt of doing migration... I'm
about to write an email about it.

What is the OS of your guest? fedora16 or RHEL6? I would like recently
to use floppy device in guest.


Ok, correcting my answer, it was Windows 7 SP1. For some reason, I read 
'host' instead of guest. I had a long day when I wrote the 1st reply.


It's been a while that we've verified that the linux floppy driver is 
quite unstable. In general linux + floppy devices on a guest tends to 
crash the guest kernel, and that's why in kvm autotest we moved from 
floppy devices to cdroms to hold the kickstart file. The fact you 
managed to get things working under F14 means you are lucky, and that 
particular floppy driver bug does not happen under F14's kernel. We 
never had such a kernel crash problem with any of the Windows's kernels.


So if I were you, I would *not* use a floppy with a linux guest. Well, 
unless you want to debug the floppy driver bug and fix this on upstream 
linux once for all, so future versions of linux won't have this problem.

[Qemu-devel] [Qemu test report] Autotest | Job ID: 1997 "Upstream qemu.git sanity 10-30-2011 00:05:01" | Status: 1 Completed | Success Rate: 53.85 %

[Lucas Meneghel Rodrigues]

Hi folks, sending this to QEMU devel to inform the current problems we 
are able to reproduce on the current master branch.


So, qemu.git is presenting problems as of latest master. None of the 
problems mentioned is happening on qemu-kvm.git.


 Original Message 
Subject: Autotest | Job ID: 1997 "Upstream qemu.git sanity 10-30-2011 
00:05:01" | Status: 1 Completed | Success Rate: 53.85 %

Date: Sun, 30 Oct 2011 09:50:58 -0400
From: kvm-autot...@redhat.com
To: l...@redhat.com, cr...@redhat.com

Job ID: 1997
Job name: Upstream qemu.git sanity 10-30-2011 00:05:01
Summary: Host: virtlab208.virt.bos.redhat.com Status: Completed
Status: 1 Completed
Execution time (HH:MM:SS): 05:44:38
User tests executed: 26
User tests passed: 14
User tests failed: 12
User tests success rate: 53.85 %
Failures:
Test Name 
 Status  Reason 



kvm.qemu-git.virtio_blk.smp2.virtio_net.Win7.64.sp1.unattended_install.cdrom 
FAILTimeout elapsed while waiting for install to finish[context: 
waiting for installation to finish] 



^ Here, the windows install timeout happened due to the floppy 
regression introduced by 212ec7baa28cc9d819234fed1541fc1423cfe3d8. We 
did try Kevin's patches and they did not fix the issue.


kvm.qemu-git.virtio_blk.smp2.virtio_net.RHEL.6.1.x86_64.migrate.tcp 
 FAILUnhandled LoginError: Client said 'connection refused' 
(output: 'ssh: connect to host 192.168.122.129 port 22: Connection 
refused\n')[context: logging into 'vm1']
kvm.qemu-git.virtio_blk.smp2.virtio_net.RHEL.6.1.x86_64.reboot 
 FAILUnhandled LoginError: Client said 'connection refused' 
(output: 'ssh: connect to host 192.168.122.25 port 22: Connection 
refused\n')[context: logging into 'vm1']
kvm.qemu-git.virtio_blk.smp2.virtio_net.RHEL.6.1.x86_64.migrate.unix 
 FAILUnhandled LoginError: Client said 'connection refused' 
(output: 'ssh: connect to host 192.168.122.3 port 22: Connection 
refused\n')[context: logging into 'vm1']
kvm.qemu-git.virtio_blk.smp2.virtio_net.RHEL.6.1.x86_64.migrate.exec 
 FAILUnhandled MonitorSocketError: Could not send monitor 
command 'info migrate'([Errno 32] Broken pipe)[context: 
migrating 'vm1']


^ All of those failures happened due to qemu segfaults during the 
migration process. I believe Luiz had a patch to possibly fix this 
migration issue, so copying him.


The segfaults generated core dumps, which we would be happy to scp to a 
public box, if someone is interested in them.


Cheers,

Lucas

[Qemu-devel] [qemu-kvm unittest regression] Re: Autotest | Job ID: 2011 "Upstream qemu-kvm.git sanity 11-01-2011 00:04:02" | Status: 1 Completed | Success Rate: 94.74 %

[Lucas Meneghel Rodrigues]

On 11/01/2011 12:17 PM, kvm-autotest wrote:

Job ID: 2011
Job name: Upstream qemu-kvm.git sanity 11-01-2011 00:04:02
Summary: Host: Status: Completed
Status: 1 Completed
Execution time (HH:MM:SS): 01:17:02
User tests executed: 19
User tests passed: 18
User tests failed: 1
User tests success rate: 94.74 %
Failures:
Test Name  Status Reason
kvm.qemu-kvm-git.unittests FAIL   Unit tests failed: emulator


Hi Marcelo, Avi:

We've seen emulator unittest failures during the last couple of jobs of 
qemu-kvm.git userspace + kvm.git kernel. Relevant hashes for the last 
failure seen:


11/01 09:33:59 INFO |virt_utils:0501| Commit hash for 
git://github.com/avikivity/kvm.git is 
b796a09c5d808f4013f27ad45953db604dac18fd (tag v3.1-rc4-10168-gb796a09)


11/01 09:50:57 DEBUG|virt_utils:2587| Git repo qemu_kvm uri: 
git://github.com/avikivity/qemu.git
11/01 09:51:52 INFO |virt_utils:2531| Commit hash for qemu_kvm is 
7879db7e9c09b92d9af1c143fbe2cc212ec89e4b (no tag found)


Cheers,

Lucas

Re: [Qemu-devel] qemu/qemu-kvm floppy regression brought by 212ec7baa28cc9d819234fed1541fc1423cfe3d8

[Lucas Meneghel Rodrigues]

On 11/02/2011 05:48 AM, Zhi Yong Wu wrote:

On Wed, Oct 26, 2011 at 10:41 PM, Lucas Meneghel Rodrigues
  wrote:

Hi folks:

We've captured a regression with floppy disk on recent qemu (and qemu-kvm,
after a code merge). We bisected it to be caused by:

commit 212ec7baa28cc9d819234fed1541fc1423cfe3d8
Author: Richard Henderson
Date:   Mon Aug 15 15:08:45 2011 -0700

fdc: Convert to isa_register_portio_list

Signed-off-by: Richard Henderson
Signed-off-by: Avi Kivity

Since this commit, the guest doesn't see a floppy disk attached to it
anymore, blocking kvm autotest ability to install windows guests
automatically. This is a big deal for kvm autotest (ruins our automated
regression jobs), so please take a look at it.

Just i tried the latest qemu.git upstream, it can work for floppy now.
I can see the floppy drive on guest and the file in it saved by me.

My qemu.git/HEAD is

commit e072ea2fd8fdceef64159b9596d3c15ce01bea91
Author: Anthony Liguori
Date:   Tue Nov 1 19:37:01 2011 -0500

 Bump version to 1.0-rc0

 Look out 1.0, here we come!

 Signed-off-by: Anthony Liguori



Ok, I have triggered some jobs and will look during the morning whether 
this is working for us as well.

[Qemu-devel] [1.0 release work] Fix regressions found on recent KVM autotest qemu master 'sanity' jobs

[Lucas Meneghel Rodrigues]

Hi guys,

As we understand that qemu is approaching 1.0, we think it's a good idea 
to share the issues we have been seeing on recent qemu.git sanity jobs:


1) Some condition is consistently making a RHEL 6.1 linux guest not able 
to bring up the network interface, causing login failures for all linux 
guest tests. This very same guest install works perfectly on qemu-kvm, 
RHEL 5 and RHEL 6.


2) The floppy regression problem which was reported some days ago on 
this mailing list still happens, Kevin did post a patch that resolves it


diff --git a/hw/dma.c b/hw/dma.c
index 8a7302a..1d3b6f1 100644
--- a/hw/dma.c
+++ b/hw/dma.c
@@ -358,6 +358,13 @@ static void DMA_run (void)
 struct dma_cont *d;
 int icont, ichan;
 int rearm = 0;
+static int running = 0;
+
+if (running) {
+goto out;
+} else {
+running = 1;
+}

 d = dma_controllers;

@@ -374,6 +381,8 @@ static void DMA_run (void)
 }
 }

+out:
+running = 0;
 if (rearm)
 qemu_bh_schedule_idle(dma_bh);
 }

But still wasn't integrated upstream. As I understand, there are doubts 
whether this is a proper fix. Works with qemu-kvm.git. RHEL 5 and RHEL 6.


3) With Kevin's patch applied, windows install goes on until the first 
reboot. When it gets there, it gets stuck on the BIOS screen. The bios 
being used is the bin shipped on qemu.git's repo. So the install does 
not complete. Works with qemu-kvm.git, RHEL 5 and RHEL 6.


Those were the issues found on our 'sanity' job, which is the closest to 
a smoke test we have with KVM autotest. It simply installs one stable 
and recent linux guest, boot, simple migration, reboot, shutdown, rinse 
and repeat with the latest windows guest available. All guests use 
virtio disks and virtio network cards. It has 100% PASS rate, or very 
close to it for the other branches mentioned.


So qemu.git current state is not good, and those bugs need some work 
before 1.0 is out.


Please feel free to approach myself and Cleber on irc or email, as we 
can give you the details we have available, in case you need them.


Lucas

Re: [Qemu-devel] [1.0 release work] Fix regressions found on recent KVM autotest qemu master 'sanity' jobs

[Lucas Meneghel Rodrigues]

On Fri 04 Nov 2011 02:50:53 PM BRST, Kevin Wolf wrote:

Am 04.11.2011 17:40, schrieb Lucas Meneghel Rodrigues:

2) The floppy regression problem which was reported some days ago on
this mailing list still happens, Kevin did post a patch that resolves it

[...]

But still wasn't integrated upstream. As I understand, there are doubts
whether this is a proper fix. Works with qemu-kvm.git. RHEL 5 and RHEL 6.


The first patch was buggy (even though it seemed to do the trick in most
cases), but I do have a new version queued for my next pull request.

In case you like to test it before it gets merged, this is the new version:

diff --git a/hw/dma.c b/hw/dma.c
index 8a7302a..0a9322d 100644
--- a/hw/dma.c
+++ b/hw/dma.c
@@ -358,6 +358,14 @@ static void DMA_run (void)
  struct dma_cont *d;
  int icont, ichan;
  int rearm = 0;
+static int running = 0;
+
+if (running) {
+rearm = 1;
+goto out;
+} else {
+running = 1;
+}

  d = dma_controllers;

@@ -374,6 +382,8 @@ static void DMA_run (void)
  }
  }

+running = 0;
+out:
  if (rearm)
  qemu_bh_schedule_idle(dma_bh);
  }

Kevin


Ok, we'll put it on our off tree patch stash for the next upstream jobs 
[1], thanks. We still have the bios problem to finally get a working 
windows install, I hope people might look into this.


[1] Well, currently this is the only patch on our 'stash', we only 
resort to external patches on blockers like this one.

Re: [Qemu-devel] [1.0 release work] Fix regressions found on recent KVM autotest qemu master 'sanity' jobs

[Lucas Meneghel Rodrigues]

On Fri 04 Nov 2011 02:56:30 PM BRST, Anthony Liguori wrote:

On 11/04/2011 11:40 AM, Lucas Meneghel Rodrigues wrote:

Hi guys,

As we understand that qemu is approaching 1.0, we think it's a good 
idea to

share the issues we have been seeing on recent qemu.git sanity jobs:

1) Some condition is consistently making a RHEL 6.1 linux guest not 
able to
bring up the network interface, causing login failures for all linux 
guest
tests. This very same guest install works perfectly on qemu-kvm, RHEL 
5 and RHEL 6.


Can you file a bug report with specific information about how the 
guest is being launched? Specifically, what NIC are we talking about? 
Do other types of guests work?


Ok, I will. Just FYI, it's a virtio nic. As on sanity jobs we only test 
RHEL 6.1 64 bit and Windows 7 SP1 64 bit, and Windows is blocked due to 
the other bug mentioned, I still have no idea whether other guests do 
work.

Re: [Qemu-devel] [1.0 release work] Fix regressions found on recent KVM autotest qemu master 'sanity' jobs

[Lucas Meneghel Rodrigues]

On 11/04/2011 02:56 PM, Anthony Liguori wrote:

On 11/04/2011 11:40 AM, Lucas Meneghel Rodrigues wrote:

Hi guys,

As we understand that qemu is approaching 1.0, we think it's a good
idea to
share the issues we have been seeing on recent qemu.git sanity jobs:

1) Some condition is consistently making a RHEL 6.1 linux guest not
able to
bring up the network interface, causing login failures for all linux
guest
tests. This very same guest install works perfectly on qemu-kvm, RHEL
5 and RHEL 6.


Can you file a bug report with specific information about how the guest
is being launched? Specifically, what NIC are we talking about? Do other
types of guests work?


https://bugs.launchpad.net/qemu/+bug/886255

I believe relevant info is there. Command lines, screenshots, kernel 
versions, qemu commit hashes... If you need something else, let me know.



Regards,

Anthony Liguori

[Qemu-devel] [Bug 886255] Re: Qemu master branch - RHEL 6.1 guest failing to start network

[Lucas Meneghel Rodrigues]

** Attachment added: "screenshot showing nw initialization failure"
   
https://bugs.launchpad.net/bugs/886255/+attachment/2585413/+files/vm1_2011-11-04_00-45-19.jpg

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/886255

Title:
  Qemu master branch - RHEL 6.1 guest failing to start network

Status in QEMU:
  New

Bug description:
  Guest: RHEL 6.1 64 bit DVD

  Kernel: Latest Fedora, also reproduces with Avi's kvm.git kernel based
  on 3.1: 2.6.40.6-0.fc15.x86_64

  qemu version:

  11/04 00:25:30 DEBUG|virt_utils:2587| Git repo qemu uri: 
git://git.qemu.org/qemu.git
  11/04 00:25:30 DEBUG|virt_utils:2590| Git repo qemu branch: master
  11/04 00:25:30 DEBUG|virt_utils:3189| Configure options for git_repo_qemu: 
['--target-list=x86_64-softmmu']
  11/04 00:25:30 DEBUG|virt_utils:2496| Initializing new git repo at 
/usr/local/autotest/tests/kvm/src/qemu for receiving git repo 11/04 00:25:30 
INFO |virt_utils:2505| Fetching git [REP 'git://git.qemu.org/qemu.git' BRANCH 
'master'] -> /usr/local/autotest/tests/kvm/src/qemu
  11/04 00:25:30 DEBUG|base_utils:0074| Running 'git fetch -q -f -u -t 
git://git.qemu.org/qemu.git master:master'
  11/04 00:34:41 INFO |virt_utils:2531| Commit hash for qemu is 
932eacc158c064935c7bab920c88a93a629e1ca4 (no tag found)

  On guest boot screenshots (one of them attached), you can see the
  message

  "Bringing up interface eth0: Device eth0 does not seem to be present,
  delaying initialization"

  Network card info
  11/04 00:44:55 DEBUG| virt_test:0041| bridge = virbr0
  11/04 00:44:55 DEBUG| virt_test:0041| nic_mode = tap
  11/04 00:44:55 DEBUG| virt_test:0041| nic_model = virtio

  Commented excerpt of the test log:

  11/04 00:44:57 INFO |kvm_vm:0790| Running qemu command:
  /usr/local/autotest/tests/kvm/qemu -name 'vm1' -nodefaults -vga std -monitor 
unix:'/tmp/monitor-humanmonitor1-2004-003602-LPJY',server,nowait -qmp 
unix:'/tmp/monitor-qmpmonitor1-2004-003602-LPJY',server,nowait -serial 
unix:'/tmp/serial-2004-003602-LPJY',server,nowait -drive 
file='/tmp/kvm_autotest_root/images/rhel6.1-64.qcow2',index=0,if=virtio,cache=none
 -device virtio-net-pci,netdev=id3HQgQx,mac='9a:16:a5:3c:05:25',id='id0AfUVE' 
-netdev tap,id=id3HQgQx,fd=23 -m 2048 -smp 2 -vnc :0  -enable-kvm
  11/04 00:44:59 DEBUG|kvm_monito:0624| (monitor qmpmonitor1) Sending command 
'qmp_capabilities'
  11/04 00:44:59 DEBUG|kvm_vm:0851| VM appears to be alive with PID 9827
  11/04 00:44:59 DEBUG|virt_env_p:0318| Starting screendump thread
  11/04 00:44:59 DEBUG|   virt_vm:0654| Attempting to log into 'vm1' (timeout 
720s)

  ... here it starts booting ...

  11/04 00:44:59 DEBUG|   virt_vm:0660| Cannot find IP address for MAC address 
9a:16:a5:3c:05:25
  11/04 00:45:01 DEBUG|   virt_vm:0660| Cannot find IP address for MAC address 
9a:16:a5:3c:05:25
  11/04 00:45:03 DEBUG|   virt_vm:0660| Cannot find IP address for MAC address 
9a:16:a5:3c:05:25
  11/04 00:45:05 DEBUG|   virt_vm:0660| Cannot find IP address for MAC address 
9a:16:a5:3c:05:25
  11/04 00:45:07 DEBUG|   virt_vm:0660| Cannot find IP address for MAC address 
9a:16:a5:3c:05:25
  11/04 00:45:09 DEBUG|   virt_vm:0660| Cannot find IP address for MAC address 
9a:16:a5:3c:05:25
  11/04 00:45:11 DEBUG|   virt_vm:0660| Cannot find IP address for MAC address 
9a:16:a5:3c:05:25
  11/04 00:45:13 DEBUG|   virt_vm:0660| Cannot find IP address for MAC address 
9a:16:a5:3c:05:25
  11/04 00:45:15 DEBUG|   virt_vm:0660| Cannot find IP address for MAC address 
9a:16:a5:3c:05:25
  11/04 00:45:17 DEBUG|   virt_vm:0660| Cannot find IP address for MAC address 
9a:16:a5:3c:05:25
  11/04 00:45:19 DEBUG|   virt_vm:0660| Cannot find IP address for MAC address 
9a:16:a5:3c:05:25
  11/04 00:45:21 DEBUG|   virt_vm:0660| Cannot find IP address for MAC address 
9a:16:a5:3c:05:25
  11/04 00:45:23 DEBUG|   virt_vm:0660| Cannot find IP address for MAC address 
9a:16:a5:3c:05:25

  ... here it gets an IP from the DHCP server ...

  11/04 00:45:24 DEBUG|virt_env_p:0438| (address cache) Adding cache
  entry: 9a:16:a5:3c:05:25 ---> 192.168.122.195

  ... ok, let's try to login ...

  11/04 00:45:25 DEBUG|virt_utils:0710| Trying to login with command
  'ssh -o UserKnownHostsFile=/dev/null -o
  PreferredAuthentications=password -p 22 root@192.168.122.195'

  ... ouch, not possible to login ...

  11/04 00:45:25 DEBUG|   virt_vm:0660| Client said 'connection refused'
  (output: 'ssh: connect to host 192.168.122.195 port 22: Connection
  refused\n')

  ... message above repeats until ...

  11/04 00:56:59 ERROR| virt_test:0095| Test failed: LoginError: Client said 
'connection refused'(output: 'ssh: connect to host 192.168.122.195 port 22: 
Connection refused\n')
  11/04 00:56:59 DEBUG|virt_env_p:0147| Postprocessing VM 'vm1'
  11/04 00:56:59 DEBUG|virt_env_p:0166| Param 'kill_vm' specified, killing VM
  11/04 00:56:59 DEBUG|kvm_vm:0885| Destroying VM

[Qemu-devel] [Bug 886255] [NEW] Qemu master branch - RHEL 6.1 guest failing to start network

[Lucas Meneghel Rodrigues]

Public bug reported:

Guest: RHEL 6.1 64 bit DVD

Kernel: Latest Fedora, also reproduces with Avi's kvm.git kernel based
on 3.1: 2.6.40.6-0.fc15.x86_64

qemu version:

11/04 00:25:30 DEBUG|virt_utils:2587| Git repo qemu uri: 
git://git.qemu.org/qemu.git
11/04 00:25:30 DEBUG|virt_utils:2590| Git repo qemu branch: master
11/04 00:25:30 DEBUG|virt_utils:3189| Configure options for git_repo_qemu: 
['--target-list=x86_64-softmmu']
11/04 00:25:30 DEBUG|virt_utils:2496| Initializing new git repo at 
/usr/local/autotest/tests/kvm/src/qemu for receiving git repo 11/04 00:25:30 
INFO |virt_utils:2505| Fetching git [REP 'git://git.qemu.org/qemu.git' BRANCH 
'master'] -> /usr/local/autotest/tests/kvm/src/qemu
11/04 00:25:30 DEBUG|base_utils:0074| Running 'git fetch -q -f -u -t 
git://git.qemu.org/qemu.git master:master'
11/04 00:34:41 INFO |virt_utils:2531| Commit hash for qemu is 
932eacc158c064935c7bab920c88a93a629e1ca4 (no tag found)

On guest boot screenshots (one of them attached), you can see the
message

"Bringing up interface eth0: Device eth0 does not seem to be present,
delaying initialization"

Network card info
11/04 00:44:55 DEBUG| virt_test:0041| bridge = virbr0
11/04 00:44:55 DEBUG| virt_test:0041| nic_mode = tap
11/04 00:44:55 DEBUG| virt_test:0041| nic_model = virtio

Commented excerpt of the test log:

11/04 00:44:57 INFO |kvm_vm:0790| Running qemu command:
/usr/local/autotest/tests/kvm/qemu -name 'vm1' -nodefaults -vga std -monitor 
unix:'/tmp/monitor-humanmonitor1-2004-003602-LPJY',server,nowait -qmp 
unix:'/tmp/monitor-qmpmonitor1-2004-003602-LPJY',server,nowait -serial 
unix:'/tmp/serial-2004-003602-LPJY',server,nowait -drive 
file='/tmp/kvm_autotest_root/images/rhel6.1-64.qcow2',index=0,if=virtio,cache=none
 -device virtio-net-pci,netdev=id3HQgQx,mac='9a:16:a5:3c:05:25',id='id0AfUVE' 
-netdev tap,id=id3HQgQx,fd=23 -m 2048 -smp 2 -vnc :0  -enable-kvm
11/04 00:44:59 DEBUG|kvm_monito:0624| (monitor qmpmonitor1) Sending command 
'qmp_capabilities'
11/04 00:44:59 DEBUG|kvm_vm:0851| VM appears to be alive with PID 9827
11/04 00:44:59 DEBUG|virt_env_p:0318| Starting screendump thread
11/04 00:44:59 DEBUG|   virt_vm:0654| Attempting to log into 'vm1' (timeout 
720s)

... here it starts booting ...

11/04 00:44:59 DEBUG|   virt_vm:0660| Cannot find IP address for MAC address 
9a:16:a5:3c:05:25
11/04 00:45:01 DEBUG|   virt_vm:0660| Cannot find IP address for MAC address 
9a:16:a5:3c:05:25
11/04 00:45:03 DEBUG|   virt_vm:0660| Cannot find IP address for MAC address 
9a:16:a5:3c:05:25
11/04 00:45:05 DEBUG|   virt_vm:0660| Cannot find IP address for MAC address 
9a:16:a5:3c:05:25
11/04 00:45:07 DEBUG|   virt_vm:0660| Cannot find IP address for MAC address 
9a:16:a5:3c:05:25
11/04 00:45:09 DEBUG|   virt_vm:0660| Cannot find IP address for MAC address 
9a:16:a5:3c:05:25
11/04 00:45:11 DEBUG|   virt_vm:0660| Cannot find IP address for MAC address 
9a:16:a5:3c:05:25
11/04 00:45:13 DEBUG|   virt_vm:0660| Cannot find IP address for MAC address 
9a:16:a5:3c:05:25
11/04 00:45:15 DEBUG|   virt_vm:0660| Cannot find IP address for MAC address 
9a:16:a5:3c:05:25
11/04 00:45:17 DEBUG|   virt_vm:0660| Cannot find IP address for MAC address 
9a:16:a5:3c:05:25
11/04 00:45:19 DEBUG|   virt_vm:0660| Cannot find IP address for MAC address 
9a:16:a5:3c:05:25
11/04 00:45:21 DEBUG|   virt_vm:0660| Cannot find IP address for MAC address 
9a:16:a5:3c:05:25
11/04 00:45:23 DEBUG|   virt_vm:0660| Cannot find IP address for MAC address 
9a:16:a5:3c:05:25

... here it gets an IP from the DHCP server ...

11/04 00:45:24 DEBUG|virt_env_p:0438| (address cache) Adding cache
entry: 9a:16:a5:3c:05:25 ---> 192.168.122.195

... ok, let's try to login ...

11/04 00:45:25 DEBUG|virt_utils:0710| Trying to login with command 'ssh
-o UserKnownHostsFile=/dev/null -o PreferredAuthentications=password -p
22 root@192.168.122.195'

... ouch, not possible to login ...

11/04 00:45:25 DEBUG|   virt_vm:0660| Client said 'connection refused'
(output: 'ssh: connect to host 192.168.122.195 port 22: Connection
refused\n')

... message above repeats until ...

11/04 00:56:59 ERROR| virt_test:0095| Test failed: LoginError: Client said 
'connection refused'(output: 'ssh: connect to host 192.168.122.195 port 22: 
Connection refused\n')
11/04 00:56:59 DEBUG|virt_env_p:0147| Postprocessing VM 'vm1'
11/04 00:56:59 DEBUG|virt_env_p:0166| Param 'kill_vm' specified, killing VM
11/04 00:56:59 DEBUG|kvm_vm:0885| Destroying VM with PID 9827
11/04 00:56:59 DEBUG|kvm_vm:0889| Trying to shutdown VM with shell command
11/04 00:56:59 DEBUG|virt_utils:0710| Trying to login with command 'ssh -o 
UserKnownHostsFile=/dev/null -o PreferredAuthentications=password -p 22 
root@192.168.122.195'
11/04 00:56:59 DEBUG|kvm_vm:0893| Client said 'connection refused'
(output: 'ssh: connect to host 192.168.122.195 port 22: Connection refused\n')
11/04 00:56:59 DEBUG|kvm_vm:0908| Trying to kill VM with monitor command
11/04 00:56:59 INFO | 

[Qemu-devel] [Bug 886255] Re: Qemu master branch - RHEL 6.1 guest failing to start network

[Lucas Meneghel Rodrigues]

We are currently investigating the failure. One of our suspects is that
on kvm autotest, each new qemu process instance might have a new NIC mac
address, and that might be triggering some condition in qemu in
conjunction to the guest init scripts.

It is important to note that this problem does not affect qemu-kvm.git,
or RHEL based branches for that matter.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/886255

Title:
  Qemu master branch - RHEL 6.1 guest failing to start network

Status in QEMU:
  New

Bug description:
  Guest: RHEL 6.1 64 bit DVD

  Kernel: Latest Fedora, also reproduces with Avi's kvm.git kernel based
  on 3.1: 2.6.40.6-0.fc15.x86_64

  qemu version:

  11/04 00:25:30 DEBUG|virt_utils:2587| Git repo qemu uri: 
git://git.qemu.org/qemu.git
  11/04 00:25:30 DEBUG|virt_utils:2590| Git repo qemu branch: master
  11/04 00:25:30 DEBUG|virt_utils:3189| Configure options for git_repo_qemu: 
['--target-list=x86_64-softmmu']
  11/04 00:25:30 DEBUG|virt_utils:2496| Initializing new git repo at 
/usr/local/autotest/tests/kvm/src/qemu for receiving git repo 11/04 00:25:30 
INFO |virt_utils:2505| Fetching git [REP 'git://git.qemu.org/qemu.git' BRANCH 
'master'] -> /usr/local/autotest/tests/kvm/src/qemu
  11/04 00:25:30 DEBUG|base_utils:0074| Running 'git fetch -q -f -u -t 
git://git.qemu.org/qemu.git master:master'
  11/04 00:34:41 INFO |virt_utils:2531| Commit hash for qemu is 
932eacc158c064935c7bab920c88a93a629e1ca4 (no tag found)

  On guest boot screenshots (one of them attached), you can see the
  message

  "Bringing up interface eth0: Device eth0 does not seem to be present,
  delaying initialization"

  Network card info
  11/04 00:44:55 DEBUG| virt_test:0041| bridge = virbr0
  11/04 00:44:55 DEBUG| virt_test:0041| nic_mode = tap
  11/04 00:44:55 DEBUG| virt_test:0041| nic_model = virtio

  Commented excerpt of the test log:

  11/04 00:44:57 INFO |kvm_vm:0790| Running qemu command:
  /usr/local/autotest/tests/kvm/qemu -name 'vm1' -nodefaults -vga std -monitor 
unix:'/tmp/monitor-humanmonitor1-2004-003602-LPJY',server,nowait -qmp 
unix:'/tmp/monitor-qmpmonitor1-2004-003602-LPJY',server,nowait -serial 
unix:'/tmp/serial-2004-003602-LPJY',server,nowait -drive 
file='/tmp/kvm_autotest_root/images/rhel6.1-64.qcow2',index=0,if=virtio,cache=none
 -device virtio-net-pci,netdev=id3HQgQx,mac='9a:16:a5:3c:05:25',id='id0AfUVE' 
-netdev tap,id=id3HQgQx,fd=23 -m 2048 -smp 2 -vnc :0  -enable-kvm
  11/04 00:44:59 DEBUG|kvm_monito:0624| (monitor qmpmonitor1) Sending command 
'qmp_capabilities'
  11/04 00:44:59 DEBUG|kvm_vm:0851| VM appears to be alive with PID 9827
  11/04 00:44:59 DEBUG|virt_env_p:0318| Starting screendump thread
  11/04 00:44:59 DEBUG|   virt_vm:0654| Attempting to log into 'vm1' (timeout 
720s)

  ... here it starts booting ...

  11/04 00:44:59 DEBUG|   virt_vm:0660| Cannot find IP address for MAC address 
9a:16:a5:3c:05:25
  11/04 00:45:01 DEBUG|   virt_vm:0660| Cannot find IP address for MAC address 
9a:16:a5:3c:05:25
  11/04 00:45:03 DEBUG|   virt_vm:0660| Cannot find IP address for MAC address 
9a:16:a5:3c:05:25
  11/04 00:45:05 DEBUG|   virt_vm:0660| Cannot find IP address for MAC address 
9a:16:a5:3c:05:25
  11/04 00:45:07 DEBUG|   virt_vm:0660| Cannot find IP address for MAC address 
9a:16:a5:3c:05:25
  11/04 00:45:09 DEBUG|   virt_vm:0660| Cannot find IP address for MAC address 
9a:16:a5:3c:05:25
  11/04 00:45:11 DEBUG|   virt_vm:0660| Cannot find IP address for MAC address 
9a:16:a5:3c:05:25
  11/04 00:45:13 DEBUG|   virt_vm:0660| Cannot find IP address for MAC address 
9a:16:a5:3c:05:25
  11/04 00:45:15 DEBUG|   virt_vm:0660| Cannot find IP address for MAC address 
9a:16:a5:3c:05:25
  11/04 00:45:17 DEBUG|   virt_vm:0660| Cannot find IP address for MAC address 
9a:16:a5:3c:05:25
  11/04 00:45:19 DEBUG|   virt_vm:0660| Cannot find IP address for MAC address 
9a:16:a5:3c:05:25
  11/04 00:45:21 DEBUG|   virt_vm:0660| Cannot find IP address for MAC address 
9a:16:a5:3c:05:25
  11/04 00:45:23 DEBUG|   virt_vm:0660| Cannot find IP address for MAC address 
9a:16:a5:3c:05:25

  ... here it gets an IP from the DHCP server ...

  11/04 00:45:24 DEBUG|virt_env_p:0438| (address cache) Adding cache
  entry: 9a:16:a5:3c:05:25 ---> 192.168.122.195

  ... ok, let's try to login ...

  11/04 00:45:25 DEBUG|virt_utils:0710| Trying to login with command
  'ssh -o UserKnownHostsFile=/dev/null -o
  PreferredAuthentications=password -p 22 root@192.168.122.195'

  ... ouch, not possible to login ...

  11/04 00:45:25 DEBUG|   virt_vm:0660| Client said 'connection refused'
  (output: 'ssh: connect to host 192.168.122.195 port 22: Connection
  refused\n')

  ... message above repeats until ...

  11/04 00:56:59 ERROR| virt_test:0095| Test failed: LoginError: Client said 
'connection refused'(output: 'ssh: connect to host 192.168.122.195 port 22: 
Connection refused\n')