Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

2012-03-15 Thread Wen Congyang
At 03/15/2012 02:46 AM, Eric Northup Wrote:
> On Wed, Mar 14, 2012 at 6:25 AM, Gleb Natapov  wrote:
> 
>> On Wed, Mar 14, 2012 at 03:16:05PM +0200, Avi Kivity wrote:
>>> On 03/14/2012 03:14 PM, Gleb Natapov wrote:
 On Wed, Mar 14, 2012 at 03:07:46PM +0200, Avi Kivity wrote:
> On 03/14/2012 01:11 PM, Wen Congyang wrote:
>>>
>>> I don't think we want to use the driver.  Instead, have a small
>> piece of
>>> code that resets the device and pushes out a string (the panic
>> message?)
>>> without any interrupts etc.
>>>
>>> It's still going to be less reliable than a hypercall, I agree.
>>
>> Do you still want to use complicated and less reliable way?
>
> Are you willing to try it out and see how complicated it really is?
>
> While it's more complicated, it's also more flexible.  You can
> communicate the panic message, whether the guest is attempting a
>> kdump
> and its own recovery or whether it wants the host to do it, etc., you
> can communicate less severe failures like oopses.
>
 hypercall can take arguments to achieve the same.
>>>
>>> It has to be designed in advance; and every time we notice something's
>>> missing we have to update the host kernel.
>>>
>>
>> We and in the designed stage now. Not to late to design something flexible
>> :) Panic hypercall can take GPA of a buffer where host puts panic info
>> as a parameter.  This buffer can be read by QEMU and passed to management.
>>
> 
> If a host kernel change is in the works, I think it might be cleanest to
> have the host kernel export a new kind of VCPU exit for unhandled-by-KVM
> hypercalls.  Then usermode can respond to the hypercall as appropriate.
>  This would permit adding or changing future hypercalls without host kernel
> changes.
> 
> "Guest panic" is almost the definition of not-a-fast-path, and so what's
> the reason to handle it in the host kernel.
> 
> Punting to user-space wouldn't be a magic bullet for getting good
> interfaces designed, but in my opinion it is a better place to be doing
> them.
> 

Do you mean that: the guest execute vmcall instruction, and the host kernel
exits to userspace. The userspace will deal with the vmexit?

Thanks
Wen Congyang



[Qemu-devel] [PATCH V2 0/3] Exynos: i2c, gpio and touchscreen support for NURI board

2012-03-15 Thread Igor Mitsyanko
This patchset adds Exynos4210 i2c and GPIO implementation along with Atmel MXT 
touchscreen
which is used for NURI board emulation.

v1->v2
- QOM-related patches are droped (they have already been accepted);
- Added indendations for second and subsequent lines of multiple-line macro 
definitions;
- Weird big spaces after .field members of VMStateDescriptions are replaced 
with single space;
- maxtouch.c is not ARM target specific from now on.

Igor Mitsyanko (3):
  exynos4210: add Exynos4210 i2c implementation
  exynos4210: add exynos4210 GPIO implementation
  hw: add Atmel maxtouch touchscreen implementation

 Makefile.objs   |1 +
 Makefile.target |1 +
 default-configs/arm-softmmu.mak |1 +
 hw/exynos4210.c |   72 +++
 hw/exynos4210.h |   67 +++
 hw/exynos4210_gpio.c| 1117 +++
 hw/exynos4210_i2c.c |  469 
 hw/exynos4_boards.c |   13 +-
 hw/maxtouch.c   | 1079 +
 9 files changed, 2816 insertions(+), 4 deletions(-)
 create mode 100644 hw/exynos4210_gpio.c
 create mode 100644 hw/exynos4210_i2c.c
 create mode 100644 hw/maxtouch.c

-- 
1.7.4.1




[Qemu-devel] [PATCH V2 1/3] exynos4210: add Exynos4210 i2c implementation

2012-03-15 Thread Igor Mitsyanko
Create 9 exynos4210 i2c interfaces.

Signed-off-by: Igor Mitsyanko 
---
 Makefile.target |1 +
 hw/exynos4210.c |   26 +++
 hw/exynos4210.h |3 +
 hw/exynos4210_i2c.c |  469 +++
 4 files changed, 499 insertions(+), 0 deletions(-)
 create mode 100644 hw/exynos4210_i2c.c

diff --git a/Makefile.target b/Makefile.target
index eb25941..5e8a1d4 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -357,6 +357,7 @@ obj-arm-y += realview_gic.o realview.o arm_sysctl.o 
arm11mpcore.o a9mpcore.o
 obj-arm-y += exynos4210_gic.o exynos4210_combiner.o exynos4210.o
 obj-arm-y += exynos4_boards.o exynos4210_uart.o exynos4210_pwm.o
 obj-arm-y += exynos4210_pmu.o exynos4210_mct.o exynos4210_fimd.o
+obj-arm-y += exynos4210_i2c.o
 obj-arm-y += arm_l2x0.o
 obj-arm-y += arm_mptimer.o a15mpcore.o
 obj-arm-y += armv7m.o armv7m_nvic.o stellaris.o pl022.o stellaris_enet.o
diff --git a/hw/exynos4210.c b/hw/exynos4210.c
index f904370..464f157 100644
--- a/hw/exynos4210.c
+++ b/hw/exynos4210.c
@@ -35,6 +35,13 @@
 /* MCT */
 #define EXYNOS4210_MCT_BASE_ADDR   0x1005
 
+/* I2C */
+#define EXYNOS4210_I2C_SHIFT   0x0001
+#define EXYNOS4210_I2C_BASE_ADDR   0x1386
+/* Interrupt Group of External Interrupt Combiner for I2C */
+#define EXYNOS4210_I2C_INTG27
+#define EXYNOS4210_HDMI_INTG   16
+
 /* UART's definitions */
 #define EXYNOS4210_UART0_BASE_ADDR 0x1380
 #define EXYNOS4210_UART1_BASE_ADDR 0x1381
@@ -242,6 +249,25 @@ Exynos4210State *exynos4210_init(MemoryRegion *system_mem,
 s->irq_table[exynos4210_get_irq(35, 3)]);
 sysbus_mmio_map(busdev, 0, EXYNOS4210_MCT_BASE_ADDR);
 
+/*** I2C ***/
+for (n = 0; n < EXYNOS4210_I2C_NUMBER; n++) {
+uint32_t addr = EXYNOS4210_I2C_BASE_ADDR + EXYNOS4210_I2C_SHIFT * n;
+qemu_irq i2c_irq;
+
+if (n < 8) {
+i2c_irq = s->irq_table[exynos4210_get_irq(EXYNOS4210_I2C_INTG, n)];
+} else {
+i2c_irq = s->irq_table[exynos4210_get_irq(EXYNOS4210_HDMI_INTG, 
1)];
+}
+
+dev = qdev_create(NULL, "exynos4210.i2c");
+qdev_init_nofail(dev);
+busdev = sysbus_from_qdev(dev);
+sysbus_connect_irq(busdev, 0, i2c_irq);
+sysbus_mmio_map(busdev, 0, addr);
+s->i2c_if[n] = (i2c_bus *)qdev_get_child_bus(dev, "i2c");
+}
+
 /*** UARTs ***/
 exynos4210_uart_create(EXYNOS4210_UART0_BASE_ADDR,
EXYNOS4210_UART0_FIFO_SIZE, 0, NULL,
diff --git a/hw/exynos4210.h b/hw/exynos4210.h
index c112e03..1205fb5 100644
--- a/hw/exynos4210.h
+++ b/hw/exynos4210.h
@@ -74,6 +74,8 @@
 #define EXYNOS4210_EXT_GIC_NIRQ (160-32)
 #define EXYNOS4210_INT_GIC_NIRQ 64
 
+#define EXYNOS4210_I2C_NUMBER   9
+
 typedef struct Exynos4210Irq {
 qemu_irq int_combiner_irq[EXYNOS4210_MAX_INT_COMBINER_IN_IRQ];
 qemu_irq ext_combiner_irq[EXYNOS4210_MAX_EXT_COMBINER_IN_IRQ];
@@ -95,6 +97,7 @@ typedef struct Exynos4210State {
 MemoryRegion dram1_mem;
 MemoryRegion boot_secondary;
 MemoryRegion bootreg_mem;
+i2c_bus *i2c_if[EXYNOS4210_I2C_NUMBER];
 } Exynos4210State;
 
 Exynos4210State *exynos4210_init(MemoryRegion *system_mem,
diff --git a/hw/exynos4210_i2c.c b/hw/exynos4210_i2c.c
new file mode 100644
index 000..42f770d
--- /dev/null
+++ b/hw/exynos4210_i2c.c
@@ -0,0 +1,469 @@
+/*
+ *  Exynos4210 I2C Bus Serial Interface Emulation
+ *
+ *  Copyright (C) 2012 Samsung Electronics Co Ltd.
+ *Maksim Kozlov, 
+ *Igor Mitsyanko, 
+ *
+ *  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 "qemu-timer.h"
+#include "sysbus.h"
+#include "i2c.h"
+
+#ifndef EXYNOS4_I2C_DEBUG
+#define EXYNOS4_I2C_DEBUG 0
+#endif
+
+#define TYPE_EXYNOS4_I2C  "exynos4210.i2c"
+#define TYPE_EXYNOS4_I2C_SLAVE"exynos4210.i2c-slave"
+#define EXYNOS4_I2C(obj)  \
+OBJECT_CHECK(Exynos4210I2CState, (obj), TYPE_EXYNOS4_I2C)
+#define EXYNOS4_I2C_SLAVE(obj)\
+OBJECT_CHECK(Exynos4210I2CSlave, (obj), TYPE_EXYNOS4_I2C_SLAVE)
+
+/* Exynos4210 I2C memory map */
+#define EXYNOS4_I2C_MEM_SIZE  0x14
+#define I2CCON_ADDR   0x00  /* control register */
+#define I2CSTAT_ADDR  0x04  /* control/status register */
+#define I2CA

[Qemu-devel] [PATCH V2 3/3] hw: add Atmel maxtouch touchscreen implementation

2012-03-15 Thread Igor Mitsyanko
And use it for exynos4210 NURI board emulation

Signed-off-by: Igor Mitsyanko 
---
 Makefile.objs   |1 +
 default-configs/arm-softmmu.mak |1 +
 hw/exynos4_boards.c |   11 +-
 hw/maxtouch.c   | 1079 +++
 4 files changed, 1089 insertions(+), 3 deletions(-)
 create mode 100644 hw/maxtouch.c

diff --git a/Makefile.objs b/Makefile.objs
index 226b01d..0171957 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -248,6 +248,7 @@ hw-obj-$(CONFIG_SMARTCARD) += usb/dev-smartcard-reader.o 
ccid-card-passthru.o
 hw-obj-$(CONFIG_SMARTCARD_NSS) += ccid-card-emulated.o
 hw-obj-$(CONFIG_USB_REDIR) += usb/redirect.o
 hw-obj-$(CONFIG_I8259) += i8259_common.o i8259.o
+hw-obj-$(CONFIG_MAXTOUCH) += maxtouch.o
 
 # PPC devices
 hw-obj-$(CONFIG_PREP_PCI) += prep_pci.o
diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index e542b4f..7666748 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -27,3 +27,4 @@ CONFIG_SMC91C111=y
 CONFIG_DS1338=y
 CONFIG_PFLASH_CFI01=y
 CONFIG_PFLASH_CFI02=y
+CONFIG_MAXTOUCH=y
diff --git a/hw/exynos4_boards.c b/hw/exynos4_boards.c
index b438361..f851026 100644
--- a/hw/exynos4_boards.c
+++ b/hw/exynos4_boards.c
@@ -28,6 +28,7 @@
 #include "exec-memory.h"
 #include "exynos4210.h"
 #include "boards.h"
+#include "i2c.h"
 
 #undef DEBUG
 
@@ -44,6 +45,7 @@
 #endif
 
 #define SMDK_LAN9118_BASE_ADDR  0x0500
+#define MAXTOUCH_TS_I2C_ADDR0x4a
 
 typedef enum Exynos4BoardType {
 EXYNOS4_BOARD_NURI,
@@ -134,9 +136,12 @@ static void nuri_init(ram_addr_t ram_size,
 const char *kernel_filename, const char *kernel_cmdline,
 const char *initrd_filename, const char *cpu_model)
 {
-exynos4_boards_init_common(kernel_filename, kernel_cmdline,
-initrd_filename, EXYNOS4_BOARD_NURI);
-
+Exynos4210State *cpu = exynos4_boards_init_common(kernel_filename,
+kernel_cmdline, initrd_filename, EXYNOS4_BOARD_NURI);
+DeviceState *dev =
+i2c_create_slave(cpu->i2c_if[3], "maxtouch.var0", 
MAXTOUCH_TS_I2C_ADDR);
+qdev_connect_gpio_out(dev, 0, qdev_get_gpio_in(cpu->gpio2x,
+EXYNOS4210_GPIO2X_LINE(GPX0, 4)));
 arm_load_kernel(first_cpu, &exynos4_board_binfo);
 }
 
diff --git a/hw/maxtouch.c b/hw/maxtouch.c
new file mode 100644
index 000..0c37d30
--- /dev/null
+++ b/hw/maxtouch.c
@@ -0,0 +1,1079 @@
+/*
+ *  Atmel maXTouch touchscreen emulation
+ *
+ *  Copyright (c) 2012 Samsung Electronics Co., Ltd. All rights reserved.
+ *Igor Mitsyanko  
+ *
+ *  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 "i2c.h"
+#include "console.h"
+
+#ifndef MXT_DEBUG
+#define MXT_DEBUG 0
+#endif
+
+/* Fifo length must be a power of 2 */
+#define MXT_MESSAGE_FIFO_LEN  16
+/* Maxtouch supports up to 10 concurrent touches, but we emulate 3 since common
+ * PC mouse has only 3 buttons. Exact meaning of each touch (each mouse button
+ * press) is defined by target userspace application only */
+#define MXT_NUM_OF_TOUCHES3
+#define MXT_CRC_POLY  0x80001B
+#define MXT_CRC_SIZE  3
+/* Maximum value of x and y coordinate in QEMU mouse event callback */
+#define MXT_QEMU_MAX_COORD0x7FFF
+
+/* Each maXTouch device consists of a certain number of subdevices (objects)
+ * with code names like T5, T6, T9, e.t.c. Each object implements only a 
portion
+ * of maXTouch functionality. For example, touch detection is performed
+ * by T9 object, but information about touch state changes is generated (and 
can
+ * be read) only in T5 object.
+ * Various variants of maXTouch can have different set of objects placed at
+ * different addresses within maXtouch address space. Composition of objects
+ * is described by mandatory Object Table which starts at address 0x7.
+ * Length of object table (i.e. number of objects) of this exact variant of
+ * maXTouch can be read from address 0x6 */
+#define MXT_OBJTBL_ENTRY_LEN  6
+/* Offsets within one object table entry */
+/* Object type code */
+#define MXT_OBJTBL_TYPE   0x0
+/* Start address of object registers within maxTouch address space */
+#define MXT_OBJTBL_START_LSB  0x1
+#define MXT_OBJTBL_START_MSB   

[Qemu-devel] [PATCH V2 2/3] exynos4210: add exynos4210 GPIO implementation

2012-03-15 Thread Igor Mitsyanko
Now that we have GPIO emulation for exynos4210 SoC we can use it to
properly hook up IRQ line to lan9215 controller on SMDK board.

Signed-off-by: Igor Mitsyanko 
---
 Makefile.target  |2 +-
 hw/exynos4210.c  |   46 ++
 hw/exynos4210.h  |   64 +++
 hw/exynos4210_gpio.c | 1117 ++
 hw/exynos4_boards.c  |2 +-
 5 files changed, 1229 insertions(+), 2 deletions(-)
 create mode 100644 hw/exynos4210_gpio.c

diff --git a/Makefile.target b/Makefile.target
index 5e8a1d4..aab4ec6 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -357,7 +357,7 @@ obj-arm-y += realview_gic.o realview.o arm_sysctl.o 
arm11mpcore.o a9mpcore.o
 obj-arm-y += exynos4210_gic.o exynos4210_combiner.o exynos4210.o
 obj-arm-y += exynos4_boards.o exynos4210_uart.o exynos4210_pwm.o
 obj-arm-y += exynos4210_pmu.o exynos4210_mct.o exynos4210_fimd.o
-obj-arm-y += exynos4210_i2c.o
+obj-arm-y += exynos4210_i2c.o exynos4210_gpio.o
 obj-arm-y += arm_l2x0.o
 obj-arm-y += arm_mptimer.o a15mpcore.o
 obj-arm-y += armv7m.o armv7m_nvic.o stellaris.o pl022.o stellaris_enet.o
diff --git a/hw/exynos4210.c b/hw/exynos4210.c
index 464f157..d81fc3d 100644
--- a/hw/exynos4210.c
+++ b/hw/exynos4210.c
@@ -35,6 +35,12 @@
 /* MCT */
 #define EXYNOS4210_MCT_BASE_ADDR   0x1005
 
+/* GPIO */
+#define EXYNOS4210_GPIO1_BASE_ADDR 0x1140
+#define EXYNOS4210_GPIO2_BASE_ADDR 0x1100
+#define EXYNOS4210_GPIO2X_BASE_ADDR0x11000C00
+#define EXYNOS4210_GPIO3_BASE_ADDR 0x0386
+
 /* I2C */
 #define EXYNOS4210_I2C_SHIFT   0x0001
 #define EXYNOS4210_I2C_BASE_ADDR   0x1386
@@ -249,6 +255,46 @@ Exynos4210State *exynos4210_init(MemoryRegion *system_mem,
 s->irq_table[exynos4210_get_irq(35, 3)]);
 sysbus_mmio_map(busdev, 0, EXYNOS4210_MCT_BASE_ADDR);
 
+/* GPIO */
+s->gpio1 = qdev_create(NULL, "exynos4210.gpio1");
+qdev_init_nofail(s->gpio1);
+busdev = sysbus_from_qdev(s->gpio1);
+sysbus_connect_irq(busdev, 0, s->irq_table[exynos4210_get_irq(24, 1)]);
+sysbus_mmio_map(busdev, 0, EXYNOS4210_GPIO1_BASE_ADDR);
+
+s->gpio2 = qdev_create(NULL, "exynos4210.gpio2");
+qdev_init_nofail(s->gpio2);
+busdev = sysbus_from_qdev(s->gpio2);
+sysbus_connect_irq(busdev, 0, s->irq_table[exynos4210_get_irq(24, 0)]);
+sysbus_mmio_map(busdev, 0, EXYNOS4210_GPIO2_BASE_ADDR);
+
+s->gpio2x = qdev_create(NULL, "exynos4210.gpio2x");
+qdev_init_nofail(s->gpio2x);
+busdev = sysbus_from_qdev(s->gpio2x);
+sysbus_connect_irq(busdev, 0, s->irq_table[exynos4210_get_irq(40, 0)]);
+sysbus_connect_irq(busdev, 1, s->irq_table[exynos4210_get_irq(41, 0)]);
+sysbus_connect_irq(busdev, 2, s->irq_table[exynos4210_get_irq(42, 0)]);
+sysbus_connect_irq(busdev, 3, s->irq_table[exynos4210_get_irq(43, 0)]);
+sysbus_connect_irq(busdev, 4, s->irq_table[exynos4210_get_irq(37, 0)]);
+sysbus_connect_irq(busdev, 5, s->irq_table[exynos4210_get_irq(37, 1)]);
+sysbus_connect_irq(busdev, 6, s->irq_table[exynos4210_get_irq(37, 2)]);
+sysbus_connect_irq(busdev, 7, s->irq_table[exynos4210_get_irq(37, 3)]);
+sysbus_connect_irq(busdev, 8, s->irq_table[exynos4210_get_irq(38, 0)]);
+sysbus_connect_irq(busdev, 9, s->irq_table[exynos4210_get_irq(38, 1)]);
+sysbus_connect_irq(busdev, 10, s->irq_table[exynos4210_get_irq(38, 2)]);
+sysbus_connect_irq(busdev, 11, s->irq_table[exynos4210_get_irq(38, 3)]);
+sysbus_connect_irq(busdev, 12, s->irq_table[exynos4210_get_irq(38, 4)]);
+sysbus_connect_irq(busdev, 13, s->irq_table[exynos4210_get_irq(38, 5)]);
+sysbus_connect_irq(busdev, 14, s->irq_table[exynos4210_get_irq(38, 6)]);
+sysbus_connect_irq(busdev, 15, s->irq_table[exynos4210_get_irq(38, 7)]);
+sysbus_connect_irq(busdev, 16, s->irq_table[exynos4210_get_irq(39, 0)]);
+sysbus_mmio_map(busdev, 0, EXYNOS4210_GPIO2X_BASE_ADDR);
+
+s->gpio3 = qdev_create(NULL, "exynos4210.gpio3");
+qdev_init_nofail(s->gpio3);
+busdev = sysbus_from_qdev(s->gpio3);
+sysbus_mmio_map(busdev, 0, EXYNOS4210_GPIO3_BASE_ADDR);
+
 /*** I2C ***/
 for (n = 0; n < EXYNOS4210_I2C_NUMBER; n++) {
 uint32_t addr = EXYNOS4210_I2C_BASE_ADDR + EXYNOS4210_I2C_SHIFT * n;
diff --git a/hw/exynos4210.h b/hw/exynos4210.h
index 1205fb5..98b2dbd 100644
--- a/hw/exynos4210.h
+++ b/hw/exynos4210.h
@@ -76,6 +76,69 @@
 
 #define EXYNOS4210_I2C_NUMBER   9
 
+/*
+ * Exynos4210 general purpose input/output (GPIO)
+ */
+
+/* GPIO part 1 port group numbers */
+#define EXYNOS4210_GPIO1_GPA0   0
+#define EXYNOS4210_GPIO1_GPA1   1
+#define EXYNOS4210_GPIO1_GPB2
+#define EXYNOS4210_GPIO1_GPC0   3
+#define EXYNOS4210_GPIO1_GPC1   4
+#define EXYNOS4210_GPIO1_GPD0   5
+#define EXYNOS4210_GPIO1_GPD1   6
+#define EXYNOS4210_GPIO1_GPE0   7
+#define EXYNOS4210_GPIO1_GPE1   8
+#define EXYNOS4210_GPIO1_GPE2  

Re: [Qemu-devel] [PATCH v2] Man page: Add -global description

2012-03-15 Thread Markus Armbruster
Anthony Liguori  writes:

> Just while we're here, I'll be posting the following shortly:
>
> commit 82aff428155d469ab705294486cc26cb34947999
> Author: Anthony Liguori 
> Date:   Fri Dec 23 11:30:45 2011 -0600
>
> qdev: don't allow globals to be set by bus name
>
> This is technically a compatibility breaker.  However:
>
> 1) libvirt does not rely on this (it always uses the driver name)
>
> 2) This behavior isn't actually documented anywhere (the docs just say 
> driver).
>
> 3) I suspect there are less than three people on earth that even know this is
>possible (minus the people reading this message).
>
> So I think we can safely break it :-)

Go right ahead.  We shouldn't tie ourselves up in knots over
undocumented behavior, unless there's clear evidence of use.



[Qemu-devel] [Bug 938431] Re: Reproducible crash in slirp_remque (qemu 1.0.1)

2012-03-15 Thread Jan Kiszka
> Thread 1 (Thread 0xb63d36e0 (LWP 32412)):
> #0 0xb7679517 in slirp_remque (a=0xb9119cf0) at slirp/misc.c:39
> element = 0xb9119cf0
> #1 0xb7677489 in if_start (slirp=0xb87a6eb8) at slirp/if.c:189
> now = 118754910412798
> requeued = 0
> ifm = 0xb9119cf0
> ifqt = 0x0

"requeued" is no longer present in qemu.git. And
217bfb445b54db618a30f3a39170bebd9fd9dbf2 actually predates the important
fixes by a lot of commits. It has to be
3e7ecd976b06fc9054a34bda093a70efae99588b or newer.

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

Title:
  Reproducible crash in slirp_remque (qemu 1.0.1)

Status in QEMU:
  New

Bug description:
  Heya

  I've been testing some automated data conversion scripts with qemu
  1.0.1. They work fine with qemu-kvm 0.15.1, but on qemu 1.0.1 (from
  the website, built from source using gcc 4.6.1, i686 host), when the
  script runs qemu I see qemu crash in slirp_remque a few seconds after
  it's launched. This crash is consistent and reproducible.

  The qemu guest is SCO OpenServer 5.0.5. I'm using it for some data
  conversion from a legacy application. qemu is launched "-display none
  -monitor stdio" and controlled from a Python script that then connects
  to the VM over usermode port forwards to ftp data to/from the VM and
  send commands over telnet.

  qemu is launched fine with the following command:

  /usr/local/qemu/bin/qemu-system-i386 -display none -vga cirrus -M pc
  -no-acpi -no-hpet -monitor stdio -net
  
user,net=10.0.2.0/24,host=10.0.2.2,dns=10.0.2.3,hostfwd=tcp:127.0.0.1:-10.0.2.1:22,hostfwd=tcp:127.0.0.1:2323-10.0.2.1:23,hostfwd=tcp:127.0.0.1:2121-10.0.2.1:21,hostfwd=tcp:127.0.0.1:2020-10.0.2.1:20
  -net nic,model=pcnet -drive
  file=sco/sco.qcow2,format=qcow2,cache=unsafe,snapshot=on -drive
  file=sco/booksys.qcow2,format=qcow2,cache=unsafe,snapshot=on -snapshot
  > qemu-log

  and images:

  $ for f in *.qcow2; do qemu-img info $f; echo; done
  image: booksys-blank-compressed.qcow2
  file format: qcow2
  virtual size: 4.0G (4294967296 bytes)
  disk size: 696K
  cluster_size: 65536

  image: booksys.qcow2
  file format: qcow2
  virtual size: 4.0G (4294967296 bytes)
  disk size: 140K
  cluster_size: 65536
  backing file: booksys-blank-compressed.qcow2 (actual path: 
booksys-blank-compressed.qcow2)

  image: sco-base-compressed.qcow2
  file format: qcow2
  virtual size: 512M (536870912 bytes)
  disk size: 142M
  cluster_size: 65536

  image: sco.qcow2
  file format: qcow2
  virtual size: 512M (536870912 bytes)
  disk size: 140K
  cluster_size: 65536
  backing file: sco-base-compressed.qcow2 (actual path: 
sco-base-compressed.qcow2)


  
  The VM guest begins booting fine, and nothing of interest appears in the 
monitor log:

  QEMU 1.0,1 monitor - type 'help' for more information
  (qemu)

  After a few seconds the controlling scripts begins trying to ftp into
  the guest over the user-mode port forward on port 2121, and it's at
  this point that qemu crashes with the following backtrace:

  Program received signal SIGSEGV, Segmentation fault.
  [Switching to Thread 0xb63e46e0 (LWP 25453)]
  0xb768753b in slirp_remque (a=0xb90ee408) at slirp/misc.c:39
  39  ((struct quehead *)(element->qh_rlink))->qh_link = element->qh_link;
  (gdb) bt
  #0  0xb768753b in slirp_remque (a=0xb90ee408) at slirp/misc.c:39
  #1  0xb76854ad in if_start (slirp=0xb879beb0) at slirp/if.c:189
  #2  0xb76853b3 in if_output (so=0xb8eb1380, ifm=0xb90eea60) at slirp/if.c:138
  #3  0xb7686bb5 in ip_output (so=0xb8eb1380, m0=0xb90eea60)
  at slirp/ip_output.c:84
  #4  0xb768f59c in tcp_output (tp=0xb906fd48) at slirp/tcp_output.c:456
  #5  0xb7691b9b in tcp_timers (tp=0xb906fd48, timer=0) at slirp/tcp_timer.c:242
  #6  0xb76918d4 in tcp_slowtimo (slirp=0xb879beb0) at slirp/tcp_timer.c:88
  #7  0xb768965a in slirp_select_poll (readfds=0xbf9e3dcc, writefds=0xbf9e3e4c, 
  xfds=0xbf9e3ecc, select_error=0) at slirp/slirp.c:433
  #8  0xb763e2a0 in main_loop_wait (nonblocking=0) at main-loop.c:465
  #9  0xb7633042 in main_loop () at /home/craig/build/qemu-1.0.1/vl.c:1481
  #10 0xb76388a0 in main (argc=20, argv=0xbf9e42d4, envp=0xbf9e4328)
  at /home/craig/build/qemu-1.0.1/vl.c:3485

  (gdb) frame 0
  #0  0xb768753b in slirp_remque (a=0xb90ee408) at slirp/misc.c:39
  39  ((struct quehead *)(element->qh_rlink))->qh_link = element->qh_link;

  A more detailed backtrace, as supplied by "thread apply all bt full",
  follows at the end of this post.

  In case it matters, stdout is redirected to a logfile and stdin is
  attached to the Python script, which hasn't yet written anything to
  the stdin pipe.

  I'll happily post the script, but isn't much good without the OS image
  which is about 150MB and can't be legally redistributed. I'm happy to
  test patches, though, or try anything that's suggested.

  Host info and full backtrace follows:


  $

Re: [Qemu-devel] buildbot failure in qemu on default_s390

2012-03-15 Thread Alexander Graf

On 15.03.2012, at 01:11, Michael Roth  wrote:

> On Thu, Mar 15, 2012 at 01:01:04AM +0100, Andreas Färber wrote:
>> Am 15.03.2012 01:16, schrieb q...@buildbot.b1-systems.de:
>>> The Buildbot has detected a new failure on builder default_s390 while 
>>> building qemu.
>>> Full details are available at:
>>> http://buildbot.b1-systems.de/qemu/builders/default_s390/builds/190
>>> 
>>> Buildbot URL: http://buildbot.b1-systems.de/qemu/
>>> 
>>> Buildslave for this Build: qemu-s390.opensuse.org
>>> 
>>> Build Reason: The Nightly scheduler named 'nightly_default' triggered this 
>>> build
>>> Build Source Stamp: [branch master] HEAD
>>> Blamelist: 
>>> 
>>> BUILD FAILED: failed compile
>> 
>> Sorry...
>> 
>>  CClm32-softmmu/arch_init.o
>> In file included from /home/build/qemu/default_s390/build/qemu-common.h:123,
>> from /home/build/qemu/default_s390/build/monitor.h:4,
>> from /home/build/qemu/default_s390/build/arch_init.c:32:
>> /home/build/qemu/default_s390/build/target-lm32/cpu.h:185: error:
>> redefinition of typedef 'CPULM32State'
>> /home/build/qemu/default_s390/build/target-lm32/cpu.h:31: error:
>> previous declaration of 'CPULM32State' was here
>> make[1]: *** [arch_init.o] Error 1
>> make: *** [subdir-lm32-softmmu] Error 2
>> 
>> My GCC handles the following code fine:
>> 
>> typedef struct CPULM32State CPULM32State;
>> 
>> typedef struct CPULM32State {
>>// ...
>> } CPULM32State;
>> 
>> Solutions would be to
>> a) drop the second typedef,
>> b) use struct CPULM32State,
>> c) move the function using it to after the second typedef.
> 
> I vote for a)

Same here.

Alex




Re: [Qemu-devel] [PATCH v2] Man page: Add -global description

2012-03-15 Thread Miroslav Rezanina
- Original Message -
> From: "Peter Maydell" 
> To: "Miroslav Rezanina" 
> Cc: qemu-devel@nongnu.org
> Sent: Wednesday, March 14, 2012 7:21:30 PM
> Subject: Re: [Qemu-devel] [PATCH v2] Man page: Add -global description
>
> On 14 March 2012 08:53, Miroslav Rezanina 
> wrote:
> > --- a/qemu-options.hx
> > +++ b/qemu-options.hx
> > @@ -292,9 +292,13 @@ DEF("global", HAS_ARG, QEMU_OPTION_global,
> >     "                set a global default for a driver property\n",
> >     QEMU_ARCH_ALL)
> >  STEXI
> > -@item -global
> > +@item -global @var{driver}.@var{property}=@var{value}
>
> We seem to use @var{prop}, not @var{property}, elsewhere in the docs.
>
You're right, I reused naming from DEF part...both has to be updated.

> >  @findex -global
> > -TODO
> > +Set default value of @var{driver}'s @var{property} to @var{value},
> > e.g.:
> > +
> > +@example
> > +qemu -global ide-drive.physical_block_size=4096 -drive
> > file=file,if=ide,index=0
> > +@end example
> >  ETEXI
>
> This is missing any motivation for why you would want to actually
> use this option. How about:
>
> "In particular, you can use this to set driver properties for devices
> which
> are created automatically by the machine model. (To create a device
> which is
> not created automatically and set properties on it, use -device.)"
>
> ?
>
> That's still not great, but I think it helps a little.
>

Yeah, more use case should be stated but I do not think man page is good
place for extensive user motivation.

> (ideally if -device/-global are the new standard interface we should
> have a
> section explaining the general concepts and syntax and then
> documentation of
> how to do specific things like networking via -device, and relegate
> all the
> 'legacy' options to a section clearly marked as 'legacy' with
> pointers back
> to the new ways of doing the same thing. That would be a much bigger
> job,
> though.)
>

Agree, man page is really behind the code. However, I think documenting new
interfaces should be done first to agree on them and their usage. After new
way is known extracting old interface as legacy stuff would be easier.

> -- PMM
>


Anyway, I will resend this patch with updates you recommended.

Mirek



[Qemu-devel] [PATCH 0/2] Style and bug on linux-user/signal.c

2012-03-15 Thread Alex Barcelo
I tried to send a trivial patch and a v2, but I did it horribly wrong
and seems that have not yet been updated. I thought that maybe
it was a good moment to do things "betterly".

The bug is really a typo, because everywhere there is the same
0 comparison. But each comparison is different one from another, so
the style is quite messed up and the typo becomes non-trivial to
understand.

The first patch is a style patch which makes everything check the
conditions the same way. The second patch corrects a "== 0" that
was missing on an if condition, to be like every other condition.

I sent two "[TRIVIAL]" to the lists that are irrelevant with this
patch. They are:
"sas_ss_flags bug for powerpc"
(v2) "Bad zero comparison for sas_ss_flags on powerpc"

Alex Barcelo (2):
  linux-user: Homogeneity on sas_ss_flags checks (signal)
  linux-user: Bug on a zero comparation with sas_ss_flags

 linux-user/signal.c |   46 ++
 1 files changed, 26 insertions(+), 20 deletions(-)

-- 
1.7.5.4




[Qemu-devel] [PATCH 2/2] linux-user: Bug on a zero comparation with sas_ss_flags

2012-03-15 Thread Alex Barcelo
All sas_ss_flags' 0 check is the same across every architecture.
But in PPC there was a bug and it was checked the other way round.

It seems a typo and is not architecture dependant, is a POSIX
standard and the QEMU way of checking it.

Now the signal.c and its sas_ss_flags check should be coherent and
correct across archs.

Signed-off-by: Alex Barcelo 
---
 linux-user/signal.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/linux-user/signal.c b/linux-user/signal.c
index d1a2671..d159ada 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -4122,7 +4122,7 @@ static target_ulong get_sigframe(struct target_sigaction 
*ka,
 oldsp = env->gpr[1];
 
 if ((ka->sa_flags & TARGET_SA_ONSTACK) &&
-(sas_ss_flags(oldsp))) {
+(sas_ss_flags(oldsp) == 0)) {
 oldsp = (target_sigaltstack_used.ss_sp
  + target_sigaltstack_used.ss_size);
 }
-- 
1.7.5.4




[Qemu-devel] [PATCH 1/2] linux-user: Homogeneity on sas_ss_flags checks (signal)

2012-03-15 Thread Alex Barcelo
Each architecture does the same comparation, but it is hard
(at least was hard for me) to see, because of the fancy way
of doing a simple 0 comparation.

This patch simply tries to assure signal.c code coherence.

Signed-off-by: Alex Barcelo 
---
 linux-user/signal.c |   44 +---
 1 files changed, 25 insertions(+), 19 deletions(-)

diff --git a/linux-user/signal.c b/linux-user/signal.c
index fca51e2..d1a2671 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -804,19 +804,21 @@ get_sigframe(struct target_sigaction *ka, CPUX86State 
*env, size_t frame_size)
/* Default to using normal stack */
esp = env->regs[R_ESP];
/* This is the X/Open sanctioned signal stack switching.  */
-if (ka->sa_flags & TARGET_SA_ONSTACK) {
-if (sas_ss_flags(esp) == 0)
-esp = target_sigaltstack_used.ss_sp + 
target_sigaltstack_used.ss_size;
+if (ka->sa_flags & TARGET_SA_ONSTACK) {
+if (sas_ss_flags(esp) == 0) {
+esp = (target_sigaltstack_used.ss_sp
+   + target_sigaltstack_used.ss_size);
 }
-
-   /* This is the legacy signal stack switching. */
-   else
+} else {
+/* This is the legacy signal stack switching. */
 if ((env->segs[R_SS].selector & 0x) != __USER_DS &&
 !(ka->sa_flags & TARGET_SA_RESTORER) &&
 ka->sa_restorer) {
 esp = (unsigned long) ka->sa_restorer;
-   }
-return (esp - frame_size) & -8ul;
+}
+}
+
+return (esp - frame_size) & -8ul;
 }
 
 /* compare linux/arch/i386/kernel/signal.c:setup_frame() */
@@ -1248,8 +1250,10 @@ get_sigframe(struct target_sigaction *ka, CPUARMState 
*regs, int framesize)
/*
 * This is the X/Open sanctioned signal stack switching.
 */
-   if ((ka->sa_flags & TARGET_SA_ONSTACK) && !sas_ss_flags(sp))
-sp = target_sigaltstack_used.ss_sp + 
target_sigaltstack_used.ss_size;
+if ((ka->sa_flags & TARGET_SA_ONSTACK) &&
+(sas_ss_flags(sp) == 0)) {
+sp = target_sigaltstack_used.ss_sp + target_sigaltstack_used.ss_size;
+}
/*
 * ATPCS B01 mandates 8-byte alignment
 */
@@ -2710,7 +2714,8 @@ get_sigframe(struct target_sigaction *ka, CPUMIPSState 
*regs, size_t frame_size)
 sp -= 32;
 
 /* This is the X/Open sanctioned signal stack switching.  */
-if ((ka->sa_flags & TARGET_SA_ONSTACK) && (sas_ss_flags (sp) == 0)) {
+if ((ka->sa_flags & TARGET_SA_ONSTACK) &&
+(sas_ss_flags(sp) == 0)) {
 sp = target_sigaltstack_used.ss_sp + target_sigaltstack_used.ss_size;
 }
 
@@ -2969,7 +2974,8 @@ struct target_rt_sigframe
 static abi_ulong get_sigframe(struct target_sigaction *ka,
  unsigned long sp, size_t frame_size)
 {
-if ((ka->sa_flags & TARGET_SA_ONSTACK) && (sas_ss_flags(sp) == 0)) {
+if ((ka->sa_flags & TARGET_SA_ONSTACK) &&
+(sas_ss_flags(sp) == 0)) {
 sp = target_sigaltstack_used.ss_sp + target_sigaltstack_used.ss_size;
 }
 
@@ -3698,11 +3704,9 @@ get_sigframe(struct target_sigaction *ka, CPUS390XState 
*env, size_t frame_size)
 sp = env->regs[15];
 
 /* This is the X/Open sanctioned signal stack switching.  */
-if (ka->sa_flags & TARGET_SA_ONSTACK) {
-if (!sas_ss_flags(sp)) {
-sp = target_sigaltstack_used.ss_sp +
- target_sigaltstack_used.ss_size;
-}
+if ((ka->sa_flags & TARGET_SA_ONSTACK) &&
+(sas_ss_flags(sp) == 0) {
+sp = target_sigaltstack_used.ss_sp + target_sigaltstack_used.ss_size;
 }
 
 /* This is the legacy signal stack switching. */
@@ -4668,7 +4672,8 @@ get_sigframe(struct target_sigaction *ka, CPUM68KState 
*regs,
 sp = regs->aregs[7];
 
 /* This is the X/Open sanctioned signal stack switching.  */
-if ((ka->sa_flags & TARGET_SA_ONSTACK) && (sas_ss_flags (sp) == 0)) {
+if ((ka->sa_flags & TARGET_SA_ONSTACK) &&
+(sas_ss_flags(sp) == 0)) {
 sp = target_sigaltstack_used.ss_sp + target_sigaltstack_used.ss_size;
 }
 
@@ -5046,7 +5051,8 @@ static inline abi_ulong get_sigframe(struct 
target_sigaction *sa,
 abi_ulong sp = env->ir[IR_SP];
 
 /* This is the X/Open sanctioned signal stack switching.  */
-if ((sa->sa_flags & TARGET_SA_ONSTACK) != 0 && !sas_ss_flags(sp)) {
+if ((sa->sa_flags & TARGET_SA_ONSTACK) &&
+(sas_ss_flags(sp) == 0)) {
 sp = target_sigaltstack_used.ss_sp + target_sigaltstack_used.ss_size;
 }
 return (sp - framesize) & -32;
-- 
1.7.5.4




Re: [Qemu-devel] [RFC] qemu-iotest only for Linux?

2012-03-15 Thread Stefan Hajnoczi
On Wed, Mar 14, 2012 at 11:04:24PM +0100, Stefan Weil wrote:
> What's the reason for "_supported_os Linux" in each test?
> Because of this statement, the tests only run on Linux today,
> although they could also run on BSD, w32 and other operating
> systems (maybe small fixes are needed).
> 
> I don't think that adding every possible OS to each test
> would be a good solution. Can we remove this OS dependency
> completely?

In many cases the _supported_os was probably copy-pasted when creating
new tests.  However, we can be pretty sure that the tests haven't all
been run on anything other than Linux and maybe Windows recently.

I think we can support other host OSes but we should combine this with
adding "make check" and maybe "make check-block" to the buildbot - that
way we'll be notified if the tests break.  There are Linux, Solaris, and
OpenBSD buildslaves.

Stefan




[Qemu-devel] [PATCH 0/5] VMWare PVSCSI paravirtual device implementation

2012-03-15 Thread Dmitry Fleytman
Below is the implementation of VMWare PVSCSI device and
command line parameters to configure vendor name and product name
for SCSI storage are implemented.
Latter is needed to make PVSCSI storage devices look exactly as 
on VMWare hypervisors.

With this and VMWARE3 patches V2V migration problem for VMWare
images should be solved relatively easy.

PVSCSI implementation is based on Paolo Bonzini code sumbitted
some time ago but never applied.
See commit messages and file headers for details.

Implementation supports of all the device features.
Code was tested on different OSes:
Fedora 15
Ubuntu 10.4
Centos 6.2
Windows 2008R2
Windows 2008 64bit
Windows 2008 32bit
Windows 2003 64bit
Windows 2003 32bit

Dmitry Fleytman (5):
  Utility function strpadcpy() added
  Vendor name and product name parameters for SCSI devices Options
"vendor_name" and "product_name" added for SCSI disks.
  Header with various utility functions shared by VMWARE SCSI and
network devices
  PVCSI paravirtualized device implementation
  PVSCSI paravirtualized device integration Bus type "pvscsi"
added.

 Makefile.objs  |1 +
 blockdev.c |   12 +-
 blockdev.h |   16 +-
 cutils.c   |   13 +
 default-configs/pci.mak|1 +
 docs/specs/pvscsi-spec.txt |   92 
 hw/pc.c|5 +
 hw/pci-hotplug.c   |7 +-
 hw/pci.h   |1 +
 hw/pvscsi.c| 1242 
 hw/pvscsi.h|  442 
 hw/scsi-bus.c  |   14 +-
 hw/scsi-disk.c |   51 ++-
 hw/scsi.h  |1 +
 hw/vmware_utils.h  |  122 +
 qemu-common.h  |1 +
 16 files changed, 1997 insertions(+), 24 deletions(-)
 create mode 100644 docs/specs/pvscsi-spec.txt
 create mode 100644 hw/pvscsi.c
 create mode 100644 hw/pvscsi.h
 create mode 100644 hw/vmware_utils.h

-- 
1.7.7.6




[Qemu-devel] [PATCH 1/5] Utility function strpadcpy() added

2012-03-15 Thread Dmitry Fleytman
Signed-off-by: Dmitry Fleytman 
Signed-off-by: Yan Vugenfirer 
---
 cutils.c  |   13 +
 qemu-common.h |1 +
 2 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/cutils.c b/cutils.c
index af308cd..0df7fdf 100644
--- a/cutils.c
+++ b/cutils.c
@@ -27,6 +27,19 @@
 
 #include "qemu_socket.h"
 
+void strpadcpy(char *buf, int buf_size, const char *str, char pad)
+{
+int i;
+int has_src_data = TRUE;
+
+for (i = 0; i < buf_size; i++) {
+if ((has_src_data) && (0 == str[i])) {
+has_src_data = FALSE;
+}
+  buf[i] = has_src_data ? str[i] : pad;
+}
+}
+
 void pstrcpy(char *buf, int buf_size, const char *str)
 {
 int c;
diff --git a/qemu-common.h b/qemu-common.h
index b0fdf5c..fdd3d17 100644
--- a/qemu-common.h
+++ b/qemu-common.h
@@ -134,6 +134,7 @@ int qemu_timedate_diff(struct tm *tm);
 
 /* cutils.c */
 void pstrcpy(char *buf, int buf_size, const char *str);
+void strpadcpy(char *buf, int buf_size, const char *str, char pad);
 char *pstrcat(char *buf, int buf_size, const char *s);
 int strstart(const char *str, const char *val, const char **ptr);
 int stristart(const char *str, const char *val, const char **ptr);
-- 
1.7.7.6




[Qemu-devel] [PATCH 5/5] PVSCSI paravirtualized device integration Bus type "pvscsi" added.

2012-03-15 Thread Dmitry Fleytman
Sample command line for pvscsi-based disk is:
-drive file=image.raw,if=none,cache=off,id=pvscsi1 \
-device pvscsi,id=pvscsi -device scsi-disk,drive=pvscsi1,bus=pvscsi.0 \

Signed-off-by: Dmitry Fleytman 
Signed-off-by: Yan Vugenfirer 
---
 Makefile.objs   |1 +
 blockdev.c  |   12 
 blockdev.h  |   10 +-
 default-configs/pci.mak |1 +
 hw/pc.c |5 +
 hw/pci-hotplug.c|7 ++-
 hw/pci.h|1 +
 hw/scsi-bus.c   |   14 --
 hw/scsi.h   |1 +
 9 files changed, 44 insertions(+), 8 deletions(-)

diff --git a/Makefile.objs b/Makefile.objs
index 226b01d..bf0a351 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -304,6 +304,7 @@ hw-obj-$(CONFIG_AHCI) += ide/ich.o
 
 # SCSI layer
 hw-obj-$(CONFIG_LSI_SCSI_PCI) += lsi53c895a.o
+hw-obj-$(CONFIG_PVSCSI_SCSI_PCI) += pvscsi.o
 hw-obj-$(CONFIG_ESP) += esp.o
 
 hw-obj-y += dma-helpers.o sysbus.o isa-bus.o
diff --git a/blockdev.c b/blockdev.c
index 1a500b8..41e8efd 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -32,6 +32,7 @@ static const char *const if_name[IF_COUNT] = {
 [IF_SD] = "sd",
 [IF_VIRTIO] = "virtio",
 [IF_XEN] = "xen",
+[IF_PVSCSI] = "pvscsi",
 };
 
 static const int if_max_devs[IF_COUNT] = {
@@ -433,7 +434,8 @@ DriveInfo *drive_init(QemuOpts *opts, int default_to_scsi)
 
 on_write_error = BLOCK_ERR_STOP_ENOSPC;
 if ((buf = qemu_opt_get(opts, "werror")) != NULL) {
-if (type != IF_IDE && type != IF_SCSI && type != IF_VIRTIO && type != 
IF_NONE) {
+if (type != IF_IDE && type != IF_SCSI && type != IF_VIRTIO &&
+type != IF_PVSCSI && type != IF_NONE) {
 error_report("werror is not supported by this bus type");
 return NULL;
 }
@@ -446,7 +448,8 @@ DriveInfo *drive_init(QemuOpts *opts, int default_to_scsi)
 
 on_read_error = BLOCK_ERR_REPORT;
 if ((buf = qemu_opt_get(opts, "rerror")) != NULL) {
-if (type != IF_IDE && type != IF_VIRTIO && type != IF_SCSI && type != 
IF_NONE) {
+if (type != IF_IDE && type != IF_VIRTIO && type != IF_SCSI &&
+type != IF_PVSCSI && type != IF_NONE) {
 error_report("rerror is not supported by this bus type");
 return NULL;
 }
@@ -516,7 +519,7 @@ DriveInfo *drive_init(QemuOpts *opts, int default_to_scsi)
 } else {
 /* no id supplied -> create one */
 dinfo->id = g_malloc0(32);
-if (type == IF_IDE || type == IF_SCSI)
+if (type == IF_IDE || type == IF_SCSI || type == IF_PVSCSI)
 mediastr = (media == MEDIA_CDROM) ? "-cd" : "-hd";
 if (max_devs)
 snprintf(dinfo->id, 32, "%s%i%s%i",
@@ -545,6 +548,7 @@ DriveInfo *drive_init(QemuOpts *opts, int default_to_scsi)
 case IF_IDE:
 case IF_SCSI:
 case IF_XEN:
+case IF_PVSCSI:
 case IF_NONE:
 switch(media) {
case MEDIA_DISK:
@@ -596,7 +600,7 @@ DriveInfo *drive_init(QemuOpts *opts, int default_to_scsi)
 ro = 1;
 } else if (ro == 1) {
 if (type != IF_SCSI && type != IF_VIRTIO && type != IF_FLOPPY &&
-type != IF_NONE && type != IF_PFLASH) {
+type != IF_PVSCSI && type != IF_NONE && type != IF_PFLASH) {
 error_report("readonly not supported by this bus type");
 goto err;
 }
diff --git a/blockdev.h b/blockdev.h
index 1813c53..7c531aa 100644
--- a/blockdev.h
+++ b/blockdev.h
@@ -24,7 +24,15 @@ void blockdev_auto_del(BlockDriverState *bs);
 typedef enum {
 IF_DEFAULT = -1,/* for use with drive_add() only */
 IF_NONE,
-IF_IDE, IF_SCSI, IF_FLOPPY, IF_PFLASH, IF_MTD, IF_SD, IF_VIRTIO, IF_XEN,
+IF_IDE,
+IF_SCSI,
+IF_FLOPPY,
+IF_PFLASH,
+IF_MTD,
+IF_SD,
+IF_VIRTIO,
+IF_XEN,
+IF_PVSCSI,
 IF_COUNT
 } BlockInterfaceType;
 
diff --git a/default-configs/pci.mak b/default-configs/pci.mak
index 21e4ccf..c203bf8 100644
--- a/default-configs/pci.mak
+++ b/default-configs/pci.mak
@@ -11,6 +11,7 @@ CONFIG_EEPRO100_PCI=y
 CONFIG_PCNET_PCI=y
 CONFIG_PCNET_COMMON=y
 CONFIG_LSI_SCSI_PCI=y
+CONFIG_PVSCSI_SCSI_PCI=y
 CONFIG_RTL8139_PCI=y
 CONFIG_E1000_PCI=y
 CONFIG_IDE_CORE=y
diff --git a/hw/pc.c b/hw/pc.c
index 83a1b5b..2140a25 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -1175,4 +1175,9 @@ void pc_pci_device_init(PCIBus *pci_bus)
 for (bus = 0; bus <= max_bus; bus++) {
 pci_create_simple(pci_bus, -1, "lsi53c895a");
 }
+
+max_bus = drive_get_max_bus(IF_PVSCSI);
+for (bus = 0; bus <= max_bus; bus++) {
+pci_create_simple(pci_bus, -1, "pvscsi");
+}
 }
diff --git a/hw/pci-hotplug.c b/hw/pci-hotplug.c
index 5c6307f..672b2d7 100644
--- a/hw/pci-hotplug.c
+++ b/hw/pci-hotplug.c
@@ -114,6 +114,7 @@ int pci_drive_hot_add(Monitor *mon, const QDict *qdict,
 
 switch (type) {
 case IF_SCSI:
+case IF_PVSCSI:
 if (pci_read_devaddr(mon, pci_addr, &dom, &pci_bus, &

[Qemu-devel] [PATCH 3/5] Header with various utility functions shared by VMWARE SCSI and network devices

2012-03-15 Thread Dmitry Fleytman
Signed-off-by: Dmitry Fleytman 
Signed-off-by: Yan Vugenfirer 
---
 hw/vmware_utils.h |  122 +
 1 files changed, 122 insertions(+), 0 deletions(-)
 create mode 100644 hw/vmware_utils.h

diff --git a/hw/vmware_utils.h b/hw/vmware_utils.h
new file mode 100644
index 000..a86e691
--- /dev/null
+++ b/hw/vmware_utils.h
@@ -0,0 +1,122 @@
+/*
+ * QEMU VMWARE paravirtual devices - auxiliary code
+ *
+ * Copyright (c) 2012 Ravello Systems LTD (http://ravellosystems.com)
+ *
+ * Developed by Daynix Computing LTD (http://www.daynix.com)
+ *
+ * Authors:
+ * Dmitry Fleytman 
+ * Yan Vugenfirer 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#ifndef VMWARE_UTILS_H
+#define VMWARE_UTILS_H
+
+/* Shared memory access functions with byte swap support */
+static inline void
+vmw_shmem_read(target_phys_addr_t addr, void *buf, int len)
+{
+DSHPRINTF("SHMEM r: %" PRIx64 ", len: %d to %p", addr, len, buf);
+cpu_physical_memory_read(addr, buf, len);
+}
+
+static inline void
+vmw_shmem_write(target_phys_addr_t addr, void *buf, int len)
+{
+DSHPRINTF("SHMEM w: %" PRIx64 ", len: %d to %p", addr, len, buf);
+cpu_physical_memory_write(addr, buf, len);
+}
+
+static inline void
+vmw_shmem_rw(target_phys_addr_t addr, void *buf, int len, int is_write)
+{
+DSHPRINTF("SHMEM r/w: %" PRIx64 ", len: %d (to %p), is write: %d",
+  addr, len, buf, is_write);
+
+cpu_physical_memory_rw(addr, buf, len, is_write);
+}
+
+static inline void
+vmw_shmem_set(target_phys_addr_t addr, uint8 val, int len)
+{
+int i;
+DSHPRINTF("SHMEM set: %" PRIx64 ", len: %d (value 0x%X)", addr, len, val);
+
+for (i = 0; i < len; i++) {
+cpu_physical_memory_write(addr + i, &val, 1);
+}
+}
+
+static inline uint32_t
+vmw_shmem_ld8(target_phys_addr_t addr)
+{
+uint8_t res = ldub_phys(addr);
+DSHPRINTF("SHMEM load8: %" PRIx64 " (value 0x%X)", addr, res);
+return res;
+}
+
+static inline void
+vmw_shmem_st8(target_phys_addr_t addr, uint8_t value)
+{
+DSHPRINTF("SHMEM store8: %" PRIx64 " (value 0x%X)", addr, value);
+stb_phys(addr, value);
+}
+
+static inline uint32_t
+vmw_shmem_ld16(target_phys_addr_t addr)
+{
+uint16_t res = lduw_le_phys(addr);
+DSHPRINTF("SHMEM load16: %" PRIx64 " (value 0x%X)", addr, res);
+return res;
+}
+
+static inline void
+vmw_shmem_st16(target_phys_addr_t addr, uint16_t value)
+{
+DSHPRINTF("SHMEM store16: %" PRIx64 " (value 0x%X)", addr, value);
+stw_le_phys(addr, value);
+}
+
+static inline uint32_t
+vmw_shmem_ld32(target_phys_addr_t addr)
+{
+uint32_t res = ldl_le_phys(addr);
+DSHPRINTF("SHMEM load32: %" PRIx64 " (value 0x%X)", addr, res);
+return res;
+}
+
+static inline void
+vmw_shmem_st32(target_phys_addr_t addr, uint32_t value)
+{
+DSHPRINTF("SHMEM store32: %" PRIx64 " (value 0x%X)", addr, value);
+stl_le_phys(addr, value);
+}
+
+static inline uint64_t
+vmw_shmem_ld64(target_phys_addr_t addr)
+{
+uint64_t res = ldq_le_phys(addr);
+DSHPRINTF("SHMEM load64: %" PRIx64 " (value %" PRIx64 ")", addr, res);
+return res;
+}
+
+static inline void
+vmw_shmem_st64(target_phys_addr_t addr, uint64_t value)
+{
+DSHPRINTF("SHMEM store64: %" PRIx64 " (value %" PRIx64 ")", addr, value);
+stq_le_phys(addr, value);
+}
+
+/* MACROS for simplification of operations on array-style registers */
+#define IS_MULTIREG_ADDR(addr, base, cnt, regsize) \
+(((addr) >= (base)) && ((addr) < (base) + (cnt) * (regsize)))
+
+#define MULTIREG_IDX_BY_ADDR(addr, base, regsize)  \
+(((addr) - (base)) / (regsize))
+
+#endif
-- 
1.7.7.6




[Qemu-devel] [PATCH 2/5] Vendor name and product name parameters for SCSI devices Options "vendor_name" and "product_name" added for SCSI disks.

2012-03-15 Thread Dmitry Fleytman
Sample command line is:

-drive file=image.raw,if=none,cache=off,id=scsi1 \
-device lsi,id=scsi -device 
scsi-disk,drive=scsi1,bus=scsi.0,product_name="VENDOR SCSI 
DISK",vendor_name="[VENDOR]" \

Signed-off-by: Dmitry Fleytman 
Signed-off-by: Yan Vugenfirer 
---
 blockdev.h |6 +-
 hw/scsi-disk.c |   51 ---
 2 files changed, 41 insertions(+), 16 deletions(-)

diff --git a/blockdev.h b/blockdev.h
index 260e16b..1813c53 100644
--- a/blockdev.h
+++ b/blockdev.h
@@ -17,7 +17,9 @@
 void blockdev_mark_auto_del(BlockDriverState *bs);
 void blockdev_auto_del(BlockDriverState *bs);
 
-#define BLOCK_SERIAL_STRLEN 20
+#define BLOCK_SERIAL_STRLEN  20
+#define BLOCK_VENDOR_STRLEN  8
+#define BLOCK_PRODUCT_STRLEN 16
 
 typedef enum {
 IF_DEFAULT = -1,/* for use with drive_add() only */
@@ -37,6 +39,8 @@ struct DriveInfo {
 int media_cd;
 QemuOpts *opts;
 char serial[BLOCK_SERIAL_STRLEN + 1];
+char vname[BLOCK_VENDOR_STRLEN + 1];
+char pname[BLOCK_PRODUCT_STRLEN + 1];
 QTAILQ_ENTRY(DriveInfo) next;
 int refcount;
 };
diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
index add399e..0a12ea2 100644
--- a/hw/scsi-disk.c
+++ b/hw/scsi-disk.c
@@ -70,6 +70,8 @@ struct SCSIDiskState
 QEMUBH *bh;
 char *version;
 char *serial;
+char *vname;
+char *pname;
 bool tray_open;
 bool tray_locked;
 };
@@ -566,12 +568,23 @@ static int scsi_disk_emulate_inquiry(SCSIRequest *req, 
uint8_t *outbuf)
 
 outbuf[0] = s->qdev.type & 0x1f;
 outbuf[1] = s->removable ? 0x80 : 0;
-if (s->qdev.type == TYPE_ROM) {
-memcpy(&outbuf[16], "QEMU CD-ROM ", 16);
+
+if (NULL != s->pname) {
+strpadcpy((char *) &outbuf[16], 16, s->pname, ' ');
 } else {
-memcpy(&outbuf[16], "QEMU HARDDISK   ", 16);
+if (s->qdev.type == TYPE_ROM) {
+memcpy(&outbuf[16], "QEMU CD-ROM ", 16);
+} else {
+memcpy(&outbuf[16], "QEMU HARDDISK   ", 16);
+}
 }
-memcpy(&outbuf[8], "QEMU", 8);
+
+if (NULL != s->vname) {
+strpadcpy((char *) &outbuf[8], 8, s->vname, ' ');
+} else {
+memcpy(&outbuf[8], "QEMU", 8);
+}
+
 memset(&outbuf[32], 0, 4);
 memcpy(&outbuf[32], s->version, MIN(4, strlen(s->version)));
 /*
@@ -1585,14 +1598,19 @@ static int scsi_initfn(SCSIDevice *dev)
 return -1;
 }
 
-if (!s->serial) {
-/* try to fall back to value set with legacy -drive serial=... */
-dinfo = drive_get_by_blockdev(s->qdev.conf.bs);
-if (*dinfo->serial) {
-s->serial = g_strdup(dinfo->serial);
-}
-}
+dinfo = drive_get_by_blockdev(s->qdev.conf.bs);
 
+/* when no value given try to fall back to */
+/* value set with legacy -drive serial=... */
+if ((!s->serial) && (*dinfo->serial)) {
+s->serial = g_strdup(dinfo->serial);
+}
+if ((!s->vname) && (*dinfo->vname)) {
+s->vname = g_strdup(dinfo->vname);
+}
+if ((!s->pname) && (*dinfo->pname)) {
+s->pname = g_strdup(dinfo->pname);
+}
 if (!s->version) {
 s->version = g_strdup(QEMU_VERSION);
 }
@@ -1788,10 +1806,13 @@ static SCSIRequest *scsi_block_new_request(SCSIDevice 
*d, uint32_t tag,
 }
 #endif
 
-#define DEFINE_SCSI_DISK_PROPERTIES()   \
-DEFINE_BLOCK_PROPERTIES(SCSIDiskState, qdev.conf),  \
-DEFINE_PROP_STRING("ver",  SCSIDiskState, version), \
-DEFINE_PROP_STRING("serial",  SCSIDiskState, serial)
+#define DEFINE_SCSI_DISK_PROPERTIES() \
+DEFINE_BLOCK_PROPERTIES(SCSIDiskState, qdev.conf),\
+DEFINE_PROP_STRING("ver",  SCSIDiskState, version),   \
+DEFINE_PROP_STRING("serial",  SCSIDiskState, serial), \
+DEFINE_PROP_STRING("vendor_name",  SCSIDiskState, vname), \
+DEFINE_PROP_STRING("product_name",  SCSIDiskState, pname)
+
 
 static Property scsi_hd_properties[] = {
 DEFINE_SCSI_DISK_PROPERTIES(),
-- 
1.7.7.6




[Qemu-devel] Adding "make check" to the QEMU buildbot

2012-03-15 Thread Stefan Hajnoczi
QEMU has grown a number of sanity tests that can be run using "make
check".  They are fast and do not require many resources.

Is it possible to add "make check" after the build?

We may have to deal with some failures in the beginning - either due to
buildslave environment or legitimate broken platforms.  But I think we
can get all green pretty easily.

Stefan




Re: [Qemu-devel] [PATCH 1/2] .gitignore update

2012-03-15 Thread Stefan Hajnoczi
On Thu, Mar 08, 2012 at 12:09:40PM +1100, David Gibson wrote:
> This adds a few previously missing generated files to .gitignore: the
> qemu-bridge-helper binary, and the linuxboot and multiboot images from
> pc-bios/optionrom.
> 
> Signed-off-by: David Gibson 
> ---
>  .gitignore   |1 +
>  pc-bios/optionrom/.gitignore |5 +
>  2 files changed, 6 insertions(+), 0 deletions(-)
>  create mode 100644 pc-bios/optionrom/.gitignore

Only taking Patch 1, since Patch 2 seems to be covered by a
yet-to-be-merged patch on the list.

Thanks, applied to the trivial patches tree:
https://github.com/stefanha/qemu/commits/trivial-patches

Stefan



Re: [Qemu-devel] [RFC] qemu-iotest only for Linux?

2012-03-15 Thread Christoph Hellwig
On Thu, Mar 15, 2012 at 07:59:20AM +, Stefan Hajnoczi wrote:
> On Wed, Mar 14, 2012 at 11:04:24PM +0100, Stefan Weil wrote:
> > What's the reason for "_supported_os Linux" in each test?
> > Because of this statement, the tests only run on Linux today,
> > although they could also run on BSD, w32 and other operating
> > systems (maybe small fixes are needed).
> > 
> > I don't think that adding every possible OS to each test
> > would be a good solution. Can we remove this OS dependency
> > completely?
> 
> In many cases the _supported_os was probably copy-pasted when creating
> new tests.  However, we can be pretty sure that the tests haven't all
> been run on anything other than Linux and maybe Windows recently.

Yes.

> I think we can support other host OSes but we should combine this with
> adding "make check" and maybe "make check-block" to the buildbot - that
> way we'll be notified if the tests break.  There are Linux, Solaris, and
> OpenBSD buildslaves.

For now please add the Oses it actually works as documentation, once
we have a good overview we can add classes like "generic" or "posix"



Re: [Qemu-devel] buildbot failure in qemu on default_s390

2012-03-15 Thread Andreas Färber
Am 15.03.2012 09:32, schrieb Alexander Graf:
> 
> On 15.03.2012, at 01:11, Michael Roth  wrote:
> 
>> On Thu, Mar 15, 2012 at 01:01:04AM +0100, Andreas Färber wrote:
>>> My GCC handles the following code fine:
>>>
>>> typedef struct CPULM32State CPULM32State;
>>>
>>> typedef struct CPULM32State {
>>>// ...
>>> } CPULM32State;
>>>
>>> Solutions would be to
>>> a) drop the second typedef,
>>> b) use struct CPULM32State,
>>> c) move the function using it to after the second typedef.
>>
>> I vote for a)
> 
> Same here.

Long fixed. :) Wait, you haven't actually been sleeping at night this
once? ;)

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



Re: [Qemu-devel] [Qemu-trivial] [PATCH] ioapic: fix build with DEBUG_IOAPIC

2012-03-15 Thread Stefan Hajnoczi
On Thu, Mar 08, 2012 at 10:05:22AM +0800, Jason Wang wrote:
> ioapic.c:198: error: format ‘%08x’ expects type ‘unsigned int’, but argument 
> 3 has type ‘uint64_t’
> 
> Signed-off-by: Jason Wang 
> ---
>  hw/ioapic.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/hw/ioapic.c b/hw/ioapic.c
> index 3fee011..2b0e6e9 100644
> --- a/hw/ioapic.c
> +++ b/hw/ioapic.c
> @@ -195,7 +195,7 @@ ioapic_mem_write(void *opaque, target_phys_addr_t addr, 
> uint64_t val,
>  if (size != 4) {
>  break;
>  }
> -DPRINTF("write: %08x = %08x\n", s->ioregsel, val);
> +DPRINTF("write: %08x = %lx\n", s->ioregsel, val);

Please use PRIx64 since the argument is uint64_t.  On a 32-bit host the
%lx format string will be wrong and the compiler may issue a warning.

Stefan



Re: [Qemu-devel] [PATCH v2] vnc: Fix packed boolean struct members

2012-03-15 Thread Stefan Hajnoczi
On Thu, Mar 08, 2012 at 10:58:06PM +0100, Stefan Weil wrote:
> This patch fixes warnings reported by splint:
> 
> For variables which are packed in a single bit, a signed data type
> like 'int' does not make much sense.
> 
> There is no obvious reason why the two values should be packed,
> so I removed the packing and changed the data type to bool
> because both are used as boolean values.
> 
> v2:
> 
> Some versions of gcc complain after this modification,
> for example gcc (Debian 4.4.5-8) 4.4.5):
> 
> ui/vnc-auth-sasl.c: In function ‘vnc_sasl_client_cleanup’:
> ui/vnc-auth-sasl.c:34: error: suggest parentheses around assignment used as 
> truth value
> 
> Obviously, the compiler does not like code which does
> bool = unsigned = bool = 0
> 
> Splitting that code in three statements works.
> 
> Cc: Anthony Liguori 
> Signed-off-by: Stefan Weil 
> ---
>  ui/vnc-auth-sasl.c |4 +++-
>  ui/vnc-auth-sasl.h |4 ++--
>  2 files changed, 5 insertions(+), 3 deletions(-)

Thanks, applied to the trivial patches tree:
https://github.com/stefanha/qemu/commits/trivial-patches

Stefan



Re: [Qemu-devel] [PATCH v3 0/7] RTC: New logic to emulate RTC

2012-03-15 Thread Paolo Bonzini
Il 15/03/2012 01:06, Zhang, Yang Z ha scritto:
> You are right. Actually, the v4 is ready and it uses the same logic
> with v2. Since I have other high priority task in hand, I don't test
> v4 too much. So i plan to delay it for a while and hope v3 can be
> accepted before v4 is ready. If you really doesn't like the v3, I
> will pay more effort in v4 and will send out it ASAP. :)

Thanks, that would be great!

Paolo



Re: [Qemu-devel] [RFC PATCH 06/17] block: use bdrv_{co, aio}_discard for write_zeroes operations

2012-03-15 Thread Paolo Bonzini
Il 15/03/2012 01:42, Richard Laager ha scritto:
>> > It is worse in that we do not want the hardware parameters exposed to the
>> > guest to change behind the scenes, except if you change the machine type
>> > or if you use the default unversioned type.
> You're saying that discard_granularity and discard_zeros_data need to be
> properties of the machine type? If you start with that as a requirement,
> I can see why you want to always report discard_granularity=512 &
> discard_zeros_data=1. But that design has many downsides. I'm not
> convinced that discard_granularity and discard_zeros_data need to be
> properties of the machine type. Why do you feel that's necessary? What's
> the harm in those properties changing across QEMU startups (i.e. guest
> boots)?

Changing across guest boots is a minor problem, but changing across
migration must be avoided at all costs.

BTW, after this discussion I think we can instead report
discard_granularity = 512 and discard_zeroes_data=0 and get most of the
benefit, at least on file-backed storage.

Paolo



Re: [Qemu-devel] [Qemu-trivial] do_spice_init error on Ubuntu11.10

2012-03-15 Thread Stefan Hajnoczi
On Thu, Mar 08, 2012 at 11:29:48AM +0800, suyi wang wrote:
> Hi all:

Hi Suyi,
qemu-trivial is a mailing list for QEMU patches, questions should be
directed at the regular QEMU mailing list.  I have CCed qemu-devel and
libvirt-list so your question will go to the QEMU and libvirt
communities.

Are you sure your libvirt configuration allows the QEMU process to
access /dev/shm?  You may have SELinux enabled.

Stefan

> I tried kvm on my ubuntu  with the libvirt.xml file as follows:
>
>instance-0011 name>
>2097152
>
>hvm
>
>
>
>
>
>1
>
>
>
>
>
>file='/opt/stack/nova/nova/../
> /instances/instance-0011/disk'/>
>
>
>
>
> 
> - Ignored:
>file='/opt/stack/nova/nova/..//instances/instance-0011/disk.local'/>
>
>
> 
>
>
>
>filter="nova-instance-instance-0011-02163e44a1dd">
>
>
>
>
> 
>
>
>path='/opt/stack/nova/nova/..//instances/instance-0011/console.log'/>
>
>
> 
>
>
>
>
> 
>
>
>
>
> 
> 
>listen='0.0.0.0'/>
> 
>
>
> 
>So it works well.
> 
>Howerver, I want change the remote access method by spice, I simply
> changed
>the libvirt.xml as follows:
>
>instance-0011
>2097152
>
>hvm
>
>
>
>
>
>1
>
>
>
>
>
>file='/opt/stack/nova/nova/..//instances/instance-0011/disk'/>
>
>
>
>
>file='/opt/stack/nova/nova/..//instances/instance-0011/disk.local'/>
>
>
> 
>
>
>
>filter="nova-instance-instance-0011-02163e44a1dd">
>
>
>
>
> 
>
>
>path='/opt/stack/nova/nova/..//instances/instance-0011/console.log'/>
>
>
> 
>
>
>
>
> 
>
>
>
>
> 
> 
>listen='0.0.0.0'/>
> 
>
>
> 
>As you can see, I just change  autoport='yes'
>keymap='en-us' listen='0.0.0.0'/> to autoport='yes' keymap='en-us' listen='0.0.0.0'/>   ,   But it called the
>error as follows:
> 
>libvirtError: internal error Process exited while reading console log
>output: char device redirected to /dev/pts/12
>TRACE: do_spice_init: starting 0.8.1
>TRACE: do_spice_init: statistics shm_open failed, Permission denied"
> 
> 
> Then I also  tried "ls -ld /dev/shm"   ,  yes, it is already  777.
> then my problem remained:
> libvirtError: internal error Process exited while reading console log
>output: char device redirected to /dev/pts/12
>TRACE: do_spice_init: starting 0.8.1
>TRACE: do_spice_init: statistics shm_open failed, Permission denied"
> 
> 
>I wish someone can give me some help! Thanks!
> 
> -- 
> Yours.
> suyi



Re: [Qemu-devel] [PATCH RFC v4 03/20] target-arm: Embed CPUARMState in QOM ARMCPU

2012-03-15 Thread Paolo Bonzini
Il 14/03/2012 23:30, Andreas Färber ha scritto:
>> As usual I don't like "legacy". :)
> 
> Well, it refers to "former CPUState of which some or many fields are
> going to be extracted". I wouldn't want to write it into documentation
> as such.
> " * @env: CPUARMState" is not telling either.
> Better wordings anyone?
> 
>>  A more interesting distinction is
>> between state that is relevant to the emulation, and state that is
>> relevant to the main loop or the machine.  The former is reinitialized
>> after reset and can remain in CPUFooState.  The latter is not
>> reinitialized after reset, can move to QOM, and in most cases that's
>> what we access when we use CPUArchState.
> 
> Actually I was planning on keeping CPU*State only for TCG fields.

@env: CPUARMState structure (only TCG fields should remain there)

> Whether a field is reset or not should be determined by the reset
> callback, not by a semi-magic memset() up to a certain field name.
> That's especially problematic for cp15.

True.  My idea was to leave all resettable fields in CPUARMState, and
move the others in ARMCPU.  This is consistent with "machine state" in
CPUARMState and "machine settings + main-loop state" in ARMCPU.
However, it may make little sense to you.  If so, ignore me. :)

>> Also, I understand that the conversion is not fully mechanical, but
>> perhaps it can be made "more" mechanical than this?  Splitting this
>> patch in two would be nice, but I can't say I read it fully.
> 
> Hm, this patch has been around since v1 and so far nobody requested a
> particular split... it would be possible to move init and reset code in
> separate patches if deemed necessary? Peter?

No problem, now that you posted conversion of everything.

Paolo



Re: [Qemu-devel] [PATCH 5/5] PVSCSI paravirtualized device integration Bus type "pvscsi" added.

2012-03-15 Thread Paolo Bonzini
Il 15/03/2012 10:02, Dmitry Fleytman ha scritto:
> Sample command line for pvscsi-based disk is:
> -drive file=image.raw,if=none,cache=off,id=pvscsi1 \
> -device pvscsi,id=pvscsi -device scsi-disk,drive=pvscsi1,bus=pvscsi.0 \
> 
> Signed-off-by: Dmitry Fleytman 
> Signed-off-by: Yan Vugenfirer 
> ---
>  Makefile.objs   |1 +
>  blockdev.c  |   12 
>  blockdev.h  |   10 +-
>  default-configs/pci.mak |1 +
>  hw/pc.c |5 +
>  hw/pci-hotplug.c|7 ++-
>  hw/pci.h|1 +
>  hw/scsi-bus.c   |   14 --
>  hw/scsi.h   |1 +
>  9 files changed, 44 insertions(+), 8 deletions(-)
> 
> diff --git a/Makefile.objs b/Makefile.objs
> index 226b01d..bf0a351 100644
> --- a/Makefile.objs
> +++ b/Makefile.objs
> @@ -304,6 +304,7 @@ hw-obj-$(CONFIG_AHCI) += ide/ich.o
>  
>  # SCSI layer
>  hw-obj-$(CONFIG_LSI_SCSI_PCI) += lsi53c895a.o
> +hw-obj-$(CONFIG_PVSCSI_SCSI_PCI) += pvscsi.o
>  hw-obj-$(CONFIG_ESP) += esp.o
>  
>  hw-obj-y += dma-helpers.o sysbus.o isa-bus.o
> diff --git a/blockdev.c b/blockdev.c
> index 1a500b8..41e8efd 100644
> --- a/blockdev.c
> +++ b/blockdev.c
> @@ -32,6 +32,7 @@ static const char *const if_name[IF_COUNT] = {
>  [IF_SD] = "sd",
>  [IF_VIRTIO] = "virtio",
>  [IF_XEN] = "xen",
> +[IF_PVSCSI] = "pvscsi",
>  };
>  
>  static const int if_max_devs[IF_COUNT] = {
> @@ -433,7 +434,8 @@ DriveInfo *drive_init(QemuOpts *opts, int default_to_scsi)
>  
>  on_write_error = BLOCK_ERR_STOP_ENOSPC;
>  if ((buf = qemu_opt_get(opts, "werror")) != NULL) {
> -if (type != IF_IDE && type != IF_SCSI && type != IF_VIRTIO && type 
> != IF_NONE) {
> +if (type != IF_IDE && type != IF_SCSI && type != IF_VIRTIO &&
> +type != IF_PVSCSI && type != IF_NONE) {
>  error_report("werror is not supported by this bus type");
>  return NULL;
>  }
> @@ -446,7 +448,8 @@ DriveInfo *drive_init(QemuOpts *opts, int default_to_scsi)
>  
>  on_read_error = BLOCK_ERR_REPORT;
>  if ((buf = qemu_opt_get(opts, "rerror")) != NULL) {
> -if (type != IF_IDE && type != IF_VIRTIO && type != IF_SCSI && type 
> != IF_NONE) {
> +if (type != IF_IDE && type != IF_VIRTIO && type != IF_SCSI &&
> +type != IF_PVSCSI && type != IF_NONE) {
>  error_report("rerror is not supported by this bus type");
>  return NULL;
>  }
> @@ -516,7 +519,7 @@ DriveInfo *drive_init(QemuOpts *opts, int default_to_scsi)
>  } else {
>  /* no id supplied -> create one */
>  dinfo->id = g_malloc0(32);
> -if (type == IF_IDE || type == IF_SCSI)
> +if (type == IF_IDE || type == IF_SCSI || type == IF_PVSCSI)
>  mediastr = (media == MEDIA_CDROM) ? "-cd" : "-hd";
>  if (max_devs)
>  snprintf(dinfo->id, 32, "%s%i%s%i",
> @@ -545,6 +548,7 @@ DriveInfo *drive_init(QemuOpts *opts, int default_to_scsi)
>  case IF_IDE:
>  case IF_SCSI:
>  case IF_XEN:
> +case IF_PVSCSI:
>  case IF_NONE:
>  switch(media) {
>   case MEDIA_DISK:
> @@ -596,7 +600,7 @@ DriveInfo *drive_init(QemuOpts *opts, int default_to_scsi)
>  ro = 1;
>  } else if (ro == 1) {
>  if (type != IF_SCSI && type != IF_VIRTIO && type != IF_FLOPPY &&
> -type != IF_NONE && type != IF_PFLASH) {
> +type != IF_PVSCSI && type != IF_NONE && type != IF_PFLASH) {
>  error_report("readonly not supported by this bus type");
>  goto err;
>  }
> diff --git a/blockdev.h b/blockdev.h
> index 1813c53..7c531aa 100644
> --- a/blockdev.h
> +++ b/blockdev.h
> @@ -24,7 +24,15 @@ void blockdev_auto_del(BlockDriverState *bs);
>  typedef enum {
>  IF_DEFAULT = -1,/* for use with drive_add() only */
>  IF_NONE,
> -IF_IDE, IF_SCSI, IF_FLOPPY, IF_PFLASH, IF_MTD, IF_SD, IF_VIRTIO, IF_XEN,
> +IF_IDE,
> +IF_SCSI,
> +IF_FLOPPY,
> +IF_PFLASH,
> +IF_MTD,
> +IF_SD,
> +IF_VIRTIO,
> +IF_XEN,
> +IF_PVSCSI,
>  IF_COUNT
>  } BlockInterfaceType;
>  
> diff --git a/default-configs/pci.mak b/default-configs/pci.mak
> index 21e4ccf..c203bf8 100644
> --- a/default-configs/pci.mak
> +++ b/default-configs/pci.mak
> @@ -11,6 +11,7 @@ CONFIG_EEPRO100_PCI=y
>  CONFIG_PCNET_PCI=y
>  CONFIG_PCNET_COMMON=y
>  CONFIG_LSI_SCSI_PCI=y
> +CONFIG_PVSCSI_SCSI_PCI=y
>  CONFIG_RTL8139_PCI=y
>  CONFIG_E1000_PCI=y
>  CONFIG_IDE_CORE=y
> diff --git a/hw/pc.c b/hw/pc.c
> index 83a1b5b..2140a25 100644
> --- a/hw/pc.c
> +++ b/hw/pc.c
> @@ -1175,4 +1175,9 @@ void pc_pci_device_init(PCIBus *pci_bus)
>  for (bus = 0; bus <= max_bus; bus++) {
>  pci_create_simple(pci_bus, -1, "lsi53c895a");
>  }
> +
> +max_bus = drive_get_max_bus(IF_PVSCSI);
> +for (bus = 0; bus <= max_bus; bus++) {
> +pci_create_simple(pci_bus, -1, "pvscsi");
> +}
>  }
> dif

Re: [Qemu-devel] [Qemu-trivial] [PATCH] Remove type field in ModuleEntry as it's not used.

2012-03-15 Thread Stefan Hajnoczi
On Wed, Mar 07, 2012 at 11:36:43PM +0800, Chen Yufei wrote:
> Signed-off-by: Chen Yufei 
> ---
>  module.c |1 -
>  1 files changed, 0 insertions(+), 1 deletions(-)

Thanks, applied to the trivial patches tree:
https://github.com/stefanha/qemu/commits/trivial-patches

Stefan



Re: [Qemu-devel] [PATCH V2 3/3] hw: add Atmel maxtouch touchscreen implementation

2012-03-15 Thread Andreas Färber
Am 15.03.2012 08:35, schrieb Igor Mitsyanko:
> And use it for exynos4210 NURI board emulation
> 
> Signed-off-by: Igor Mitsyanko 

Thanks for moving this to libhw. Looks okay, not knowing I2C or the
device and assuming you've tested it; some nitpicks below.

> diff --git a/hw/exynos4_boards.c b/hw/exynos4_boards.c
> index b438361..f851026 100644
> --- a/hw/exynos4_boards.c
> +++ b/hw/exynos4_boards.c

> @@ -134,9 +136,12 @@ static void nuri_init(ram_addr_t ram_size,
>  const char *kernel_filename, const char *kernel_cmdline,
>  const char *initrd_filename, const char *cpu_model)
>  {
> -exynos4_boards_init_common(kernel_filename, kernel_cmdline,
> -initrd_filename, EXYNOS4_BOARD_NURI);
> -
> +Exynos4210State *cpu = exynos4_boards_init_common(kernel_filename,
> +kernel_cmdline, initrd_filename, EXYNOS4_BOARD_NURI);

I'd advise against using "cpu" for what looks like board or SoC state to
avoid confusion. "cpu" is going to be used for CPUState instances, i.e.
one day: ARMCPU *cpu = cpu_arm_init("cortex-a9");

I'd suggest s (generically for state) here.

> +DeviceState *dev =
> +i2c_create_slave(cpu->i2c_if[3], "maxtouch.var0", 
> MAXTOUCH_TS_I2C_ADDR);
> +qdev_connect_gpio_out(dev, 0, qdev_get_gpio_in(cpu->gpio2x,
> +EXYNOS4210_GPIO2X_LINE(GPX0, 4)));
>  arm_load_kernel(first_cpu, &exynos4_board_binfo);
>  }
>  
> diff --git a/hw/maxtouch.c b/hw/maxtouch.c
> new file mode 100644
> index 000..0c37d30
> --- /dev/null
> +++ b/hw/maxtouch.c
> @@ -0,0 +1,1079 @@
> +/*
> + *  Atmel maXTouch touchscreen emulation
> + *
> + *  Copyright (c) 2012 Samsung Electronics Co., Ltd. All rights reserved.

It's been remarked that "All rights reserved." conflicts with the GPL's
copyleft. Please drop that sentence if you can.

> + *Igor Mitsyanko  
> + *
> + *  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 .
> + *
> + */

> +/* Object types */
> +enum {
> +MXT_GEN_MESSAGE_T5 = 0,  MXT_GEN_COMMAND_T6,
> +MXT_GEN_POWER_T7,MXT_GEN_ACQUIRE_T8,
> +MXT_TOUCH_MULTI_T9,  MXT_TOUCH_KEYARRAY_T15,
> +MXT_SPT_COMMSCONFIG_T18, MXT_SPT_GPIOPWM_T19,
> +MXT_PROCI_GRIPFACE_T20,  MXT_PROCG_NOISE_T22,
> +MXT_TOUCH_PROXIMITY_T23, MXT_PROCI_ONETOUCH_T24,
> +MXT_SPT_SELFTEST_T25,MXT_PROCI_TWOTOUCH_T27,
> +MXT_SPT_CTECONFIG_T28,   MXT_DEBUG_DIAGNOSTIC_T37,
> +MXT_NUM_OF_OBJECT_TYPES
> +};

Personally I find it easier to read a mostly monotonically increasing
enum (or array below) when it's not in two columns. Was this copied from
some Linux header as is so that we wouldn't want to reformat it to allow
for easy updates, or was this a design choice of yours?

> +#define TYPE_MAXTOUCH   "maxtouch"
> +#define MXT(obj)\
> +OBJECT_CHECK(MXTState, (obj), TYPE_MAXTOUCH)
> +#define MXT_CLASS(klass)\
> +OBJECT_CLASS_CHECK(MXTClass, (klass), TYPE_MAXTOUCH)
> +#define MXT_GET_CLASS(obj)  \
> +OBJECT_GET_CLASS(MXTClass, (obj), TYPE_MAXTOUCH)

> +static const uint8_t mxt_variant0_info[MXT_INFO_SIZE] = {
> +[MXT_FAMILY_ID] = 0x80,
> +[MXT_VARIANT_ID] = 0x0,
> +[MXT_VERSION] = 0x1,
> +[MXT_BUILD] = 0x1,
> +[MXT_MATRIX_X_SIZE] = 16,
> +[MXT_MATRIX_Y_SIZE] = 14,
> +[MXT_OBJ_NUM] = sizeof(mxt_variant0_objlist) / sizeof(ObjConfig),

We have an ARRAY_SIZE() macro for this.

> +};

> +static const uint8_t mxt_variant1_info[MXT_INFO_SIZE] = {
> +[MXT_FAMILY_ID] = 0x80,
> +[MXT_VARIANT_ID] = 0x1,
> +[MXT_VERSION] = 0x1,
> +[MXT_BUILD] = 0x1,
> +[MXT_MATRIX_X_SIZE] = 16,
> +[MXT_MATRIX_Y_SIZE] = 14,
> +[MXT_OBJ_NUM] = sizeof(mxt_variant1_objlist) / sizeof(ObjConfig),

Dito.

> +};
> +
> +static const MXTVariantInfo mxt_variants_info_array[] = {
> +{
> +.name = TYPE_MXT_VARIANT0,
> +.mxt_variant_info = mxt_variant0_info,
> +.mxt_variant_obj_list = mxt_variant0_objlist
> +},
> +{
> +.name = TYPE_MXT_VARIANT1,
> +.mxt_variant_info = mxt_variant1_info,
> +.mxt_variant_obj_list = mxt_variant1_objlist
> +}
> +};
> +
> +#define MXT_NUM_OF_VARIANTS \
> +(sizeof(mxt_variants_info_array) / sizeof(MXTVariantInfo))

Dito.

> +#if MXT_DEBUG
> +#define DPRINT(fmt, args...)   \
> +do {fprintf(stderr, "QEMU MXT: "fmt, ## args); } while (0)

Re: [Qemu-devel] [PATCH 1/5] Utility function strpadcpy() added

2012-03-15 Thread Paolo Bonzini
Il 15/03/2012 10:02, Dmitry Fleytman ha scritto:
> Signed-off-by: Dmitry Fleytman 
> Signed-off-by: Yan Vugenfirer 
> ---
>  cutils.c  |   13 +
>  qemu-common.h |1 +
>  2 files changed, 14 insertions(+), 0 deletions(-)
> 
> diff --git a/cutils.c b/cutils.c
> index af308cd..0df7fdf 100644
> --- a/cutils.c
> +++ b/cutils.c
> @@ -27,6 +27,19 @@
>  
>  #include "qemu_socket.h"
>  
> +void strpadcpy(char *buf, int buf_size, const char *str, char pad)
> +{
> +int i;
> +int has_src_data = TRUE;
> +
> +for (i = 0; i < buf_size; i++) {
> +if ((has_src_data) && (0 == str[i])) {
> +has_src_data = FALSE;
> +}
> +  buf[i] = has_src_data ? str[i] : pad;
> +}

No parentheses around simple if conditions, this is not Pascal. :)  But
since you're at it, why not the simpler:

int len = qemu_strnlen(str, buf_size);
memcpy(buf, str, len);
memset(buf + len, pad, buf_size - len);

> +}
> +
>  void pstrcpy(char *buf, int buf_size, const char *str)
>  {
>  int c;
> diff --git a/qemu-common.h b/qemu-common.h
> index b0fdf5c..fdd3d17 100644
> --- a/qemu-common.h
> +++ b/qemu-common.h
> @@ -134,6 +134,7 @@ int qemu_timedate_diff(struct tm *tm);
>  
>  /* cutils.c */
>  void pstrcpy(char *buf, int buf_size, const char *str);
> +void strpadcpy(char *buf, int buf_size, const char *str, char pad);
>  char *pstrcat(char *buf, int buf_size, const char *s);
>  int strstart(const char *str, const char *val, const char **ptr);
>  int stristart(const char *str, const char *val, const char **ptr);




Re: [Qemu-devel] [PATCH] kvmvapic: align start address as well as size

2012-03-15 Thread Avi Kivity
On 03/14/2012 10:33 PM, Anthony Liguori wrote:
> On 03/06/2012 09:50 AM, Avi Kivity wrote:
>> The kvmvapic code remaps a section of ROM as RAM to allow the guest to
>> maintain state there.  It is careful to align the section size to a page
>> boundary, to avoid creating subpages, but neglects to do the same for
>> the start address.  These leads to an assert later on when the memory
>> core tries to create a page which is half RAM and half ROM.
>>
>> Fix by aligning the start address to a page boundary.
>>
>> This can be triggered by running qemu-system-x86_64 -enable-kvm -vga
>> none.
>>
>> Signed-off-by: Avi Kivity
>
> Tested-by: Anthony Liguori 
>
> Are you going to do a PULL request or do you want me to apply directly?

I forgot all about it, sorry.

-- 
error compiling committee.c: too many arguments to function




Re: [Qemu-devel] [PATCH 2/5] Vendor name and product name parameters for SCSI devices Options "vendor_name" and "product_name" added for SCSI disks.

2012-03-15 Thread Paolo Bonzini
Il 15/03/2012 10:02, Dmitry Fleytman ha scritto:
> Sample command line is:
> 
> -drive file=image.raw,if=none,cache=off,id=scsi1 \
> -device lsi,id=scsi -device 
> scsi-disk,drive=scsi1,bus=scsi.0,product_name="VENDOR SCSI 
> DISK",vendor_name="[VENDOR]" \
> 
> Signed-off-by: Dmitry Fleytman 
> Signed-off-by: Yan Vugenfirer 
> ---
>  blockdev.h |6 +-
>  hw/scsi-disk.c |   51 ---
>  2 files changed, 41 insertions(+), 16 deletions(-)
> 
> diff --git a/blockdev.h b/blockdev.h
> index 260e16b..1813c53 100644
> --- a/blockdev.h
> +++ b/blockdev.h
> @@ -17,7 +17,9 @@
>  void blockdev_mark_auto_del(BlockDriverState *bs);
>  void blockdev_auto_del(BlockDriverState *bs);
>  
> -#define BLOCK_SERIAL_STRLEN 20
> +#define BLOCK_SERIAL_STRLEN  20
> +#define BLOCK_VENDOR_STRLEN  8
> +#define BLOCK_PRODUCT_STRLEN 16
>  
>  typedef enum {
>  IF_DEFAULT = -1,/* for use with drive_add() only */
> @@ -37,6 +39,8 @@ struct DriveInfo {
>  int media_cd;
>  QemuOpts *opts;
>  char serial[BLOCK_SERIAL_STRLEN + 1];
> +char vname[BLOCK_VENDOR_STRLEN + 1];
> +char pname[BLOCK_PRODUCT_STRLEN + 1];
>  QTAILQ_ENTRY(DriveInfo) next;
>  int refcount;
>  };

Unused.

> diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
> index add399e..0a12ea2 100644
> --- a/hw/scsi-disk.c
> +++ b/hw/scsi-disk.c
> @@ -70,6 +70,8 @@ struct SCSIDiskState
>  QEMUBH *bh;
>  char *version;
>  char *serial;
> +char *vname;
> +char *pname;
>  bool tray_open;
>  bool tray_locked;
>  };
> @@ -566,12 +568,23 @@ static int scsi_disk_emulate_inquiry(SCSIRequest *req, 
> uint8_t *outbuf)
>  
>  outbuf[0] = s->qdev.type & 0x1f;
>  outbuf[1] = s->removable ? 0x80 : 0;
> -if (s->qdev.type == TYPE_ROM) {
> -memcpy(&outbuf[16], "QEMU CD-ROM ", 16);
> +
> +if (NULL != s->pname) {
> +strpadcpy((char *) &outbuf[16], 16, s->pname, ' ');
>  } else {
> -memcpy(&outbuf[16], "QEMU HARDDISK   ", 16);
> +if (s->qdev.type == TYPE_ROM) {
> +memcpy(&outbuf[16], "QEMU CD-ROM ", 16);
> +} else {
> +memcpy(&outbuf[16], "QEMU HARDDISK   ", 16);
> +}
>  }
> -memcpy(&outbuf[8], "QEMU", 8);
> +
> +if (NULL != s->vname) {
> +strpadcpy((char *) &outbuf[8], 8, s->vname, ' ');
> +} else {
> +memcpy(&outbuf[8], "QEMU", 8);
> +}
> +
>  memset(&outbuf[32], 0, 4);
>  memcpy(&outbuf[32], s->version, MIN(4, strlen(s->version)));
>  /*
> @@ -1585,14 +1598,19 @@ static int scsi_initfn(SCSIDevice *dev)
>  return -1;
>  }
>  
> -if (!s->serial) {
> -/* try to fall back to value set with legacy -drive serial=... */
> -dinfo = drive_get_by_blockdev(s->qdev.conf.bs);
> -if (*dinfo->serial) {
> -s->serial = g_strdup(dinfo->serial);
> -}
> -}
> +dinfo = drive_get_by_blockdev(s->qdev.conf.bs);
>  
> +/* when no value given try to fall back to */
> +/* value set with legacy -drive serial=... */
> +if ((!s->serial) && (*dinfo->serial)) {
> +s->serial = g_strdup(dinfo->serial);
> +}

No need to change the way the serial is handled, because you don't need
dinfo for vname/pname.

> +if ((!s->vname) && (*dinfo->vname)) {
> +s->vname = g_strdup(dinfo->vname);
> +}
> +if ((!s->pname) && (*dinfo->pname)) {
> +s->pname = g_strdup(dinfo->pname);
> +}

(Also, no parentheses around simple conditions).

>  if (!s->version) {
>  s->version = g_strdup(QEMU_VERSION);
>  }
> @@ -1788,10 +1806,13 @@ static SCSIRequest *scsi_block_new_request(SCSIDevice 
> *d, uint32_t tag,
>  }
>  #endif
>  
> -#define DEFINE_SCSI_DISK_PROPERTIES()   \
> -DEFINE_BLOCK_PROPERTIES(SCSIDiskState, qdev.conf),  \
> -DEFINE_PROP_STRING("ver",  SCSIDiskState, version), \
> -DEFINE_PROP_STRING("serial",  SCSIDiskState, serial)
> +#define DEFINE_SCSI_DISK_PROPERTIES() \
> +DEFINE_BLOCK_PROPERTIES(SCSIDiskState, qdev.conf),\
> +DEFINE_PROP_STRING("ver",  SCSIDiskState, version),   \
> +DEFINE_PROP_STRING("serial",  SCSIDiskState, serial), \
> +DEFINE_PROP_STRING("vendor_name",  SCSIDiskState, vname), \
> +DEFINE_PROP_STRING("product_name",  SCSIDiskState, pname)
> +
>  
>  static Property scsi_hd_properties[] = {
>  DEFINE_SCSI_DISK_PROPERTIES(),

Paolo



Re: [Qemu-devel] [PATCH 3/5] Header with various utility functions shared by VMWARE SCSI and network devices

2012-03-15 Thread Paolo Bonzini
Il 15/03/2012 10:02, Dmitry Fleytman ha scritto:
> Signed-off-by: Dmitry Fleytman 
> Signed-off-by: Yan Vugenfirer 
> ---
>  hw/vmware_utils.h |  122 
> +
>  1 files changed, 122 insertions(+), 0 deletions(-)
>  create mode 100644 hw/vmware_utils.h
> 
> diff --git a/hw/vmware_utils.h b/hw/vmware_utils.h
> new file mode 100644
> index 000..a86e691
> --- /dev/null
> +++ b/hw/vmware_utils.h
> @@ -0,0 +1,122 @@
> +/*
> + * QEMU VMWARE paravirtual devices - auxiliary code
> + *
> + * Copyright (c) 2012 Ravello Systems LTD (http://ravellosystems.com)
> + *
> + * Developed by Daynix Computing LTD (http://www.daynix.com)
> + *
> + * Authors:
> + * Dmitry Fleytman 
> + * Yan Vugenfirer 
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2 or later.
> + * See the COPYING file in the top-level directory.
> + *
> + */
> +
> +#ifndef VMWARE_UTILS_H
> +#define VMWARE_UTILS_H
> +
> +/* Shared memory access functions with byte swap support */
> +static inline void
> +vmw_shmem_read(target_phys_addr_t addr, void *buf, int len)
> +{
> +DSHPRINTF("SHMEM r: %" PRIx64 ", len: %d to %p", addr, len, buf);

Please add an #ifndef DSHPRINTF that defines it to nothing.

> +cpu_physical_memory_read(addr, buf, len);
> +}
> +
> +static inline void
> +vmw_shmem_write(target_phys_addr_t addr, void *buf, int len)
> +{
> +DSHPRINTF("SHMEM w: %" PRIx64 ", len: %d to %p", addr, len, buf);
> +cpu_physical_memory_write(addr, buf, len);
> +}
> +
> +static inline void
> +vmw_shmem_rw(target_phys_addr_t addr, void *buf, int len, int is_write)
> +{
> +DSHPRINTF("SHMEM r/w: %" PRIx64 ", len: %d (to %p), is write: %d",
> +  addr, len, buf, is_write);
> +
> +cpu_physical_memory_rw(addr, buf, len, is_write);
> +}
> +
> +static inline void
> +vmw_shmem_set(target_phys_addr_t addr, uint8 val, int len)
> +{
> +int i;
> +DSHPRINTF("SHMEM set: %" PRIx64 ", len: %d (value 0x%X)", addr, len, 
> val);
> +
> +for (i = 0; i < len; i++) {
> +cpu_physical_memory_write(addr + i, &val, 1);
> +}
> +}
> +
> +static inline uint32_t
> +vmw_shmem_ld8(target_phys_addr_t addr)
> +{
> +uint8_t res = ldub_phys(addr);
> +DSHPRINTF("SHMEM load8: %" PRIx64 " (value 0x%X)", addr, res);
> +return res;
> +}
> +
> +static inline void
> +vmw_shmem_st8(target_phys_addr_t addr, uint8_t value)
> +{
> +DSHPRINTF("SHMEM store8: %" PRIx64 " (value 0x%X)", addr, value);
> +stb_phys(addr, value);
> +}
> +
> +static inline uint32_t
> +vmw_shmem_ld16(target_phys_addr_t addr)
> +{
> +uint16_t res = lduw_le_phys(addr);
> +DSHPRINTF("SHMEM load16: %" PRIx64 " (value 0x%X)", addr, res);
> +return res;
> +}
> +
> +static inline void
> +vmw_shmem_st16(target_phys_addr_t addr, uint16_t value)
> +{
> +DSHPRINTF("SHMEM store16: %" PRIx64 " (value 0x%X)", addr, value);
> +stw_le_phys(addr, value);
> +}
> +
> +static inline uint32_t
> +vmw_shmem_ld32(target_phys_addr_t addr)
> +{
> +uint32_t res = ldl_le_phys(addr);
> +DSHPRINTF("SHMEM load32: %" PRIx64 " (value 0x%X)", addr, res);
> +return res;
> +}
> +
> +static inline void
> +vmw_shmem_st32(target_phys_addr_t addr, uint32_t value)
> +{
> +DSHPRINTF("SHMEM store32: %" PRIx64 " (value 0x%X)", addr, value);
> +stl_le_phys(addr, value);
> +}
> +
> +static inline uint64_t
> +vmw_shmem_ld64(target_phys_addr_t addr)
> +{
> +uint64_t res = ldq_le_phys(addr);
> +DSHPRINTF("SHMEM load64: %" PRIx64 " (value %" PRIx64 ")", addr, res);
> +return res;
> +}
> +
> +static inline void
> +vmw_shmem_st64(target_phys_addr_t addr, uint64_t value)
> +{
> +DSHPRINTF("SHMEM store64: %" PRIx64 " (value %" PRIx64 ")", addr, value);
> +stq_le_phys(addr, value);
> +}
> +
> +/* MACROS for simplification of operations on array-style registers */
> +#define IS_MULTIREG_ADDR(addr, base, cnt, regsize) \
> +(((addr) >= (base)) && ((addr) < (base) + (cnt) * (regsize)))
> +
> +#define MULTIREG_IDX_BY_ADDR(addr, base, regsize)  \
> +(((addr) - (base)) / (regsize))
> +
> +#endif

Otherwise looks good.

Paolo



Re: [Qemu-devel] [PATCH 0/1] Fix large memory chunks allocation with tcg_malloc

2012-03-15 Thread Kirill Batuzov
Ping?
Somebody please review this patch...

And whom should I Cc in case of changes to tcg/ ? File MAINTAINERS lists
only qemu-devel for this subsystem.

On Fri, 2 Mar 2012, Kirill Batuzov wrote:

> Currently large memory chunk allocation with tcg_malloc is broken.  An attempt
> to allocate such chunk when pool_current field of TCGContext is not NULL will
> result in circular links in list of memory pools:
> 
> p = new pool;
> s->pool_current->next = p;
> p->next = s->pool_current;
> (in tcg_malloc_internal)
> 
> Later p became a current pool, and current pool became next pool.  Next
> tcg_malloc will switch current pool to next pool ('previous' current pool)
> and will start allocating memory from it's beginning.  But some memory in
> the beginning of this pool was already allocated and will be used twice
> for different arrays.
> 
> At the end of this cover letter there is a patch that demonstrates the
> problem.  It breaks current trunk on the first translation block containing
> labels.
> 
> Large memory pools can not be reused by memory allocator for big allocations
> and an attempt to reuse them for small allocations may result in an infinite
> increase of memory consumption during run time.  Memory consumption would
> increase every time a new large chunk of memory is allocated.  If code
> allocates such chunk on every translation block (like patch at the end of this
> letter do) then memory consumption would increase with every new block
> translated.
> 
> My fix for the problems mentioned above is in the second e-mail.  I moved 
> large
> memory pools to a separate list and free them on pool_reset.
> 
> By the way: is there any particular reason for labels array in TCGContex to be
> allocated dynamically?  It has constant size and is allocated unconditionally
> for each translation block.
> 
> Kirill Batuzov (1):
>   Fix large memory chunks allocation with tcg_malloc.
> 
>  tcg/tcg.c |   14 +-
>  tcg/tcg.h |2 +-
>  2 files changed, 10 insertions(+), 6 deletions(-)
> 
> ---
> diff --git a/tcg/tcg.c b/tcg/tcg.c
> index 351a0a3..6dd54e6 100644
> --- a/tcg/tcg.c
> +++ b/tcg/tcg.c
> @@ -265,6 +265,8 @@ void tcg_set_frame(TCGContext *s, int reg,
>  s->frame_reg = reg;
>  }
>  
> +uint8_t *p;
> +
>  void tcg_func_start(TCGContext *s)
>  {
>  int i;
> @@ -273,6 +275,7 @@ void tcg_func_start(TCGContext *s)
>  for(i = 0; i < (TCG_TYPE_COUNT * 2); i++)
>  s->first_free_temp[i] = -1;
>  s->labels = tcg_malloc(sizeof(TCGLabel) * TCG_MAX_LABELS);
> +p = tcg_malloc(TCG_POOL_CHUNK_SIZE + 1);
>  s->nb_labels = 0;
>  s->current_frame_offset = s->frame_start;
> 



Re: [Qemu-devel] [PATCH] ds1338: Add missing break statement

2012-03-15 Thread Stefan Hajnoczi
On Sat, Feb 25, 2012 at 02:50:25PM +0100, Stefan Weil wrote:
> Without the break statement, case 5 sets month and year from the same
> data. This does not look correct.
> 
> The missing break was reported by splint.
> 
> Signed-off-by: Stefan Weil 
> ---
>  hw/ds1338.c |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)

Sorry, looks like I missed a couple of your patches in my inbox.

Thanks, applied to the trivial patches tree:
https://github.com/stefanha/qemu/commits/trivial-patches

Stefan



Re: [Qemu-devel] [PULL] QOM CPUState v5 - conflict resolution info

2012-03-15 Thread Andreas Färber
Am 15.03.2012 01:49, schrieb Anthony Liguori:
> On 03/14/2012 04:42 PM, Andreas Färber wrote:
>> Hello Anthony,
>>
>> Please pull the second QOM CPU series,
>> which frees the identifiers cpu_reset and CPUState and introduces
>> TYPE_CPU.
>>
>> Cc: Anthony Liguori
>>
>> The following changes since commit
>> 418ba9e5d6849ef2e8512d8853628ce4bf37937a:
>>
>>qom: Introduce object_class_get_list() (2012-03-14 15:30:39 -0500)
>>
>> are available in the git repository at:
>>git://repo.or.cz/qemu/afaerber.git [qom-cpu.v5]
> 
> Pulled.  Thanks.

Thanks.

A note to everyone who's now getting compilation errors for CPUState for
their patches or on local branches:

The meaning of CPUState was changed in this series: It used to be a
#define pointing to struct CPU${arch}State, it is now a typedef for a
QOM struct.

* If your code is target-specific, use CPU${arch}State.
  These structs will remain for TCG.

* Otherwise if it's code for multiple targets, use CPUArchState alias.
  That's considered deprecated and will be dropped in favor of CPUState.

"We apologize for the inconvenience,"

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



[Qemu-devel] pci-assign can not work

2012-03-15 Thread Wen Congyang
Hi all

When I use pci-assign, I meet the following error:

Failed to assign irq for "hostdev0": Input/output error
Perhaps you are assigning a device that shares an IRQ with another device?

Is it a bug or I miss something?

I use libvirt to start the guest, and the user/group is root/root(not 
qemu/qemu).

If I use the default qemu(provided in RHEL6.2), the guest can be started.

Thanks
Wen Congyang



Re: [Qemu-devel] [PATCH V2 3/3] hw: add Atmel maxtouch touchscreen implementation

2012-03-15 Thread Dmitry Solodkiy
Dear Andreas, 

  "All rights reserved" was added by accident and going to be removed on next
update of all our patches.

Thanks,
 Dmitry Solodkiy,
     Emulator/Kernel PL, Mobile Group,
     Moscow R&D center, Samsung Electronics


-Original Message-
From: Andreas Färber [mailto:afaer...@suse.de] 
Sent: Thursday, March 15, 2012 1:48 PM
To: Igor Mitsyanko
Cc: qemu-devel@nongnu.org; peter.mayd...@linaro.org; e.voevo...@samsung.com;
kyungmin.p...@samsung.com; d.solod...@samsung.com; m.koz...@samsung.com
Subject: Re: [Qemu-devel] [PATCH V2 3/3] hw: add Atmel maxtouch touchscreen
implementation

Am 15.03.2012 08:35, schrieb Igor Mitsyanko:
> And use it for exynos4210 NURI board emulation
> 
> Signed-off-by: Igor Mitsyanko 

Thanks for moving this to libhw. Looks okay, not knowing I2C or the device and
assuming you've tested it; some nitpicks below.

> diff --git a/hw/exynos4_boards.c b/hw/exynos4_boards.c index 
> b438361..f851026 100644
> --- a/hw/exynos4_boards.c
> +++ b/hw/exynos4_boards.c

> @@ -134,9 +136,12 @@ static void nuri_init(ram_addr_t ram_size,
>  const char *kernel_filename, const char *kernel_cmdline,
>  const char *initrd_filename, const char *cpu_model)  {
> -exynos4_boards_init_common(kernel_filename, kernel_cmdline,
> -initrd_filename, EXYNOS4_BOARD_NURI);
> -
> +Exynos4210State *cpu = exynos4_boards_init_common(kernel_filename,
> +kernel_cmdline, initrd_filename, EXYNOS4_BOARD_NURI);

I'd advise against using "cpu" for what looks like board or SoC state to avoid
confusion. "cpu" is going to be used for CPUState instances, i.e.
one day: ARMCPU *cpu = cpu_arm_init("cortex-a9");

I'd suggest s (generically for state) here.

> +DeviceState *dev =
> +i2c_create_slave(cpu->i2c_if[3], "maxtouch.var0",
MAXTOUCH_TS_I2C_ADDR);
> +qdev_connect_gpio_out(dev, 0, qdev_get_gpio_in(cpu->gpio2x,
> +EXYNOS4210_GPIO2X_LINE(GPX0, 4)));
>  arm_load_kernel(first_cpu, &exynos4_board_binfo);  }
>  
> diff --git a/hw/maxtouch.c b/hw/maxtouch.c new file mode 100644 index 
> 000..0c37d30
> --- /dev/null
> +++ b/hw/maxtouch.c
> @@ -0,0 +1,1079 @@
> +/*
> + *  Atmel maXTouch touchscreen emulation
> + *
> + *  Copyright (c) 2012 Samsung Electronics Co., Ltd. All rights reserved.

It's been remarked that "All rights reserved." conflicts with the GPL's
copyleft. Please drop that sentence if you can.

> + *Igor Mitsyanko  
> + *
> + *  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 .
> + *
> + */

> +/* Object types */
> +enum {
> +MXT_GEN_MESSAGE_T5 = 0,  MXT_GEN_COMMAND_T6,
> +MXT_GEN_POWER_T7,MXT_GEN_ACQUIRE_T8,
> +MXT_TOUCH_MULTI_T9,  MXT_TOUCH_KEYARRAY_T15,
> +MXT_SPT_COMMSCONFIG_T18, MXT_SPT_GPIOPWM_T19,
> +MXT_PROCI_GRIPFACE_T20,  MXT_PROCG_NOISE_T22,
> +MXT_TOUCH_PROXIMITY_T23, MXT_PROCI_ONETOUCH_T24,
> +MXT_SPT_SELFTEST_T25,MXT_PROCI_TWOTOUCH_T27,
> +MXT_SPT_CTECONFIG_T28,   MXT_DEBUG_DIAGNOSTIC_T37,
> +MXT_NUM_OF_OBJECT_TYPES
> +};

Personally I find it easier to read a mostly monotonically increasing enum (or
array below) when it's not in two columns. Was this copied from some Linux
header as is so that we wouldn't want to reformat it to allow for easy updates,
or was this a design choice of yours?

> +#define TYPE_MAXTOUCH   "maxtouch"
> +#define MXT(obj)\
> +OBJECT_CHECK(MXTState, (obj), TYPE_MAXTOUCH)
> +#define MXT_CLASS(klass)\
> +OBJECT_CLASS_CHECK(MXTClass, (klass), TYPE_MAXTOUCH)
> +#define MXT_GET_CLASS(obj)  \
> +OBJECT_GET_CLASS(MXTClass, (obj), TYPE_MAXTOUCH)

> +static const uint8_t mxt_variant0_info[MXT_INFO_SIZE] = {
> +[MXT_FAMILY_ID] = 0x80,
> +[MXT_VARIANT_ID] = 0x0,
> +[MXT_VERSION] = 0x1,
> +[MXT_BUILD] = 0x1,
> +[MXT_MATRIX_X_SIZE] = 16,
> +[MXT_MATRIX_Y_SIZE] = 14,
> +[MXT_OBJ_NUM] = sizeof(mxt_variant0_objlist) / sizeof(ObjConfig),

We have an ARRAY_SIZE() macro for this.

> +};

> +static const uint8_t mxt_variant1_info[MXT_INFO_SIZE] = {
> +[MXT_FAMILY_ID] = 0x80,
> +[MXT_VARIANT_ID] = 0x1,
> +[MXT_VERSION] = 0x1,
> +[MXT_BUILD] = 0x1,
> +[MXT_MATRIX_X_SIZE] = 16,
> +[MXT_MATRIX_Y_SIZE] = 14,
> +[MXT_OBJ_NUM] = sizeof(mxt_variant1_objlist) / sizeof(ObjConfig),

Dito.

> +};
> +
> 

Re: [Qemu-devel] [PATCH] monitor: Remove unused bool field 'qapi' in mon_cmd_t struct

2012-03-15 Thread Stefan Hajnoczi
On Mon, Mar 12, 2012 at 02:13:57PM -0400, Jeff Cody wrote:
> Some minor code cleanup: the 'qapi' bool field in mon_cmd_t is
> unused, and can be removed.
> 
> Signed-off-by: Jeff Cody 
> ---
>  monitor.c |1 -
>  1 files changed, 0 insertions(+), 1 deletions(-)

Thanks, applied to the trivial patches tree:
https://github.com/stefanha/qemu/commits/trivial-patches

Stefan



Re: [Qemu-devel] [PATCH V2 1/3] exynos4210: add Exynos4210 i2c implementation

2012-03-15 Thread Andreas Färber
Am 15.03.2012 08:35, schrieb Igor Mitsyanko:
> Create 9 exynos4210 i2c interfaces.
> 
> Signed-off-by: Igor Mitsyanko 

Reviewed-by: Andreas Färber 

for the non-technical aspects. One remark below.

> diff --git a/hw/exynos4210_i2c.c b/hw/exynos4210_i2c.c
> new file mode 100644
> index 000..42f770d
> --- /dev/null
> +++ b/hw/exynos4210_i2c.c

> +enum {
> +idle,
> +start_bit_received,
> +sending_data,
> +receiving_data
> +};

Usually our enum values are uppercase, not sure if that's a rule.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

2012-03-15 Thread Gleb Natapov
On Wed, Mar 14, 2012 at 11:46:08AM -0700, Eric Northup wrote:
> On Wed, Mar 14, 2012 at 6:25 AM, Gleb Natapov  wrote:
> 
> > On Wed, Mar 14, 2012 at 03:16:05PM +0200, Avi Kivity wrote:
> > > On 03/14/2012 03:14 PM, Gleb Natapov wrote:
> > > > On Wed, Mar 14, 2012 at 03:07:46PM +0200, Avi Kivity wrote:
> > > > > On 03/14/2012 01:11 PM, Wen Congyang wrote:
> > > > > > >
> > > > > > > I don't think we want to use the driver.  Instead, have a small
> > piece of
> > > > > > > code that resets the device and pushes out a string (the panic
> > message?)
> > > > > > > without any interrupts etc.
> > > > > > >
> > > > > > > It's still going to be less reliable than a hypercall, I agree.
> > > > > >
> > > > > > Do you still want to use complicated and less reliable way?
> > > > >
> > > > > Are you willing to try it out and see how complicated it really is?
> > > > >
> > > > > While it's more complicated, it's also more flexible.  You can
> > > > > communicate the panic message, whether the guest is attempting a
> > kdump
> > > > > and its own recovery or whether it wants the host to do it, etc., you
> > > > > can communicate less severe failures like oopses.
> > > > >
> > > > hypercall can take arguments to achieve the same.
> > >
> > > It has to be designed in advance; and every time we notice something's
> > > missing we have to update the host kernel.
> > >
> >
> > We and in the designed stage now. Not to late to design something flexible
> > :) Panic hypercall can take GPA of a buffer where host puts panic info
> > as a parameter.  This buffer can be read by QEMU and passed to management.
> >
> 
> If a host kernel change is in the works, I think it might be cleanest to
> have the host kernel export a new kind of VCPU exit for unhandled-by-KVM
> hypercalls.  Then usermode can respond to the hypercall as appropriate.
>  This would permit adding or changing future hypercalls without host kernel
> changes.
> 
There was such vm exit (KVM_EXIT_HYPERCALL), but it was deemed to be a
bad idea.

> "Guest panic" is almost the definition of not-a-fast-path, and so what's
> the reason to handle it in the host kernel.
The only "handling" that kernel does is maps hypercall to panic exit.

> 
> Punting to user-space wouldn't be a magic bullet for getting good
> interfaces designed, but in my opinion it is a better place to be doing
> them.

--
Gleb.



Re: [Qemu-devel] [PATCH V2 3/3] hw: add Atmel maxtouch touchscreen implementation

2012-03-15 Thread Igor Mitsyanko

On 03/15/2012 01:48 PM, Andreas Färber wrote:


Am 15.03.2012 08:35, schrieb Igor Mitsyanko:

And use it for exynos4210 NURI board emulation

Signed-off-by: Igor Mitsyanko


Thanks for moving this to libhw. Looks okay, not knowing I2C or the
device and assuming you've tested it; some nitpicks below.


diff --git a/hw/exynos4_boards.c b/hw/exynos4_boards.c
index b438361..f851026 100644
--- a/hw/exynos4_boards.c
+++ b/hw/exynos4_boards.c



@@ -134,9 +136,12 @@ static void nuri_init(ram_addr_t ram_size,
  const char *kernel_filename, const char *kernel_cmdline,
  const char *initrd_filename, const char *cpu_model)
  {
-exynos4_boards_init_common(kernel_filename, kernel_cmdline,
-initrd_filename, EXYNOS4_BOARD_NURI);
-
+Exynos4210State *cpu = exynos4_boards_init_common(kernel_filename,
+kernel_cmdline, initrd_filename, EXYNOS4_BOARD_NURI);


I'd advise against using "cpu" for what looks like board or SoC state to
avoid confusion. "cpu" is going to be used for CPUState instances, i.e.
one day: ARMCPU *cpu = cpu_arm_init("cortex-a9");

I'd suggest s (generically for state) here.


Right, and also we already use s in SMDK board init function.



+DeviceState *dev =
+i2c_create_slave(cpu->i2c_if[3], "maxtouch.var0", 
MAXTOUCH_TS_I2C_ADDR);
+qdev_connect_gpio_out(dev, 0, qdev_get_gpio_in(cpu->gpio2x,
+EXYNOS4210_GPIO2X_LINE(GPX0, 4)));
  arm_load_kernel(first_cpu,&exynos4_board_binfo);
  }

diff --git a/hw/maxtouch.c b/hw/maxtouch.c
new file mode 100644
index 000..0c37d30
--- /dev/null
+++ b/hw/maxtouch.c
@@ -0,0 +1,1079 @@
+/*
+ *  Atmel maXTouch touchscreen emulation
+ *
+ *  Copyright (c) 2012 Samsung Electronics Co., Ltd. All rights reserved.


It's been remarked that "All rights reserved." conflicts with the GPL's
copyleft. Please drop that sentence if you can.


Ok


+ *Igor Mitsyanko
+ *
+ *  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.
+ *
+ */



+/* Object types */
+enum {
+MXT_GEN_MESSAGE_T5 = 0,  MXT_GEN_COMMAND_T6,
+MXT_GEN_POWER_T7,MXT_GEN_ACQUIRE_T8,
+MXT_TOUCH_MULTI_T9,  MXT_TOUCH_KEYARRAY_T15,
+MXT_SPT_COMMSCONFIG_T18, MXT_SPT_GPIOPWM_T19,
+MXT_PROCI_GRIPFACE_T20,  MXT_PROCG_NOISE_T22,
+MXT_TOUCH_PROXIMITY_T23, MXT_PROCI_ONETOUCH_T24,
+MXT_SPT_SELFTEST_T25,MXT_PROCI_TWOTOUCH_T27,
+MXT_SPT_CTECONFIG_T28,   MXT_DEBUG_DIAGNOSTIC_T37,
+MXT_NUM_OF_OBJECT_TYPES
+};


Personally I find it easier to read a mostly monotonically increasing
enum (or array below) when it's not in two columns. Was this copied from
some Linux header as is so that we wouldn't want to reformat it to allow
for easy updates, or was this a design choice of yours?


It was my attempt to reduce amount of time needed to scroll this file 
down, I don't mind reformatting it to one column.



+#define TYPE_MAXTOUCH   "maxtouch"
+#define MXT(obj)\
+OBJECT_CHECK(MXTState, (obj), TYPE_MAXTOUCH)
+#define MXT_CLASS(klass)\
+OBJECT_CLASS_CHECK(MXTClass, (klass), TYPE_MAXTOUCH)
+#define MXT_GET_CLASS(obj)  \
+OBJECT_GET_CLASS(MXTClass, (obj), TYPE_MAXTOUCH)



+static const uint8_t mxt_variant0_info[MXT_INFO_SIZE] = {
+[MXT_FAMILY_ID] = 0x80,
+[MXT_VARIANT_ID] = 0x0,
+[MXT_VERSION] = 0x1,
+[MXT_BUILD] = 0x1,
+[MXT_MATRIX_X_SIZE] = 16,
+[MXT_MATRIX_Y_SIZE] = 14,
+[MXT_OBJ_NUM] = sizeof(mxt_variant0_objlist) / sizeof(ObjConfig),


We have an ARRAY_SIZE() macro for this.


OK


+};



+static const uint8_t mxt_variant1_info[MXT_INFO_SIZE] = {
+[MXT_FAMILY_ID] = 0x80,
+[MXT_VARIANT_ID] = 0x1,
+[MXT_VERSION] = 0x1,
+[MXT_BUILD] = 0x1,
+[MXT_MATRIX_X_SIZE] = 16,
+[MXT_MATRIX_Y_SIZE] = 14,
+[MXT_OBJ_NUM] = sizeof(mxt_variant1_objlist) / sizeof(ObjConfig),


Dito.


+};
+
+static const MXTVariantInfo mxt_variants_info_array[] = {
+{
+.name = TYPE_MXT_VARIANT0,
+.mxt_variant_info = mxt_variant0_info,
+.mxt_variant_obj_list = mxt_variant0_objlist
+},
+{
+.name = TYPE_MXT_VARIANT1,
+.mxt_variant_info = mxt_variant1_info,
+.mxt_variant_obj_list = mxt_variant1_objlist
+}
+};
+
+#define MXT_NUM_OF_VARIANTS \
+(sizeof(mxt_variants_info_array) / sizeof(MXTVariantInfo))


Dito.


+#if MXT_DEBUG
+#define DPRINT(fmt, args...)   \
+do 

Re: [Qemu-devel] [PATCH 1/2] cleanup obsolete typedef

2012-03-15 Thread Stefan Hajnoczi
On Tue, Mar 13, 2012 at 01:28:47PM -0500, Mark Langsdorf wrote:
> From: Joshua Housh 
> 
> There are no users of i2c_slave.
> 
> Signed-off-by: Joshua Housh 
> Signed-off-by: Mark Langsdorf 
> ---
>  qemu-common.h |1 -
>  1 files changed, 0 insertions(+), 1 deletions(-)

Thanks, applied to the trivial patches tree:
https://github.com/stefanha/qemu/commits/trivial-patches

Stefan



Re: [Qemu-devel] [PATCH V2 2/3] exynos4210: add exynos4210 GPIO implementation

2012-03-15 Thread Andreas Färber
Am 15.03.2012 08:35, schrieb Igor Mitsyanko:
> Now that we have GPIO emulation for exynos4210 SoC we can use it to
> properly hook up IRQ line to lan9215 controller on SMDK board.
> 
> Signed-off-by: Igor Mitsyanko 

The patches for .instance_size were applied now, so the TypeInfos look
okay, although a bit confusing at first. ;) Same for .class_size but
type_initialize() seems to handle that correctly.

Reviewed-by: Andreas Färber 

All static TypeInfos could be made const for a v3.

Series looks plausible; Peter should take a second, closer look though.
Probably best to wait for more comments before resending minor fixes.

Thanks,

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



Re: [Qemu-devel] [PATCH v3 0/3] qxl trace events

2012-03-15 Thread Stefan Hajnoczi
On Wed, Mar 14, 2012 at 1:09 PM, Alon Levy  wrote:
> Changes from v2:
>  split 6+ trace points to X + X_rest (leave qid as first argument in both) 
> (Stefan)
>  (cleanup as requested by Gerd)
>  no trace event for pipe write failure, left dprint there anyway.
>  indentation in a separate patch
>  qxl-render.c: qxl_render prefix
>  spice-display.c: qemu_spice functions trace names prefixed with qemu_spice
>
> Changes from v1:
>  add qid prefix to all tracepoints (except vga update which makes no sense)
>  rename to ring where suggested (Gerd)
>  add some trace points to spice-display
>  drop enter/exit in favor of a single command (Gerd)
>  some sorting of the trace event list
>
> Alon Levy (3):
>  qxl: switch qxl.c to trace-events
>  qxl/qxl_render.c: add trace events
>  qxl: init_pipe_signaling: exit on failure
>
>  hw/qxl-render.c    |   13 ++---
>  hw/qxl.c           |  160 
> ++--
>  trace-events       |   69 ++
>  ui/spice-display.c |   13 -
>  4 files changed, 163 insertions(+), 92 deletions(-)

Thanks Alon,

Reviewed-by: Stefan Hajnoczi 



[Qemu-devel] Illumos/SmarOS support

2012-03-15 Thread Lee Essen
Resend from different email -- not sure what happened to my first 2 attempts!

Hi,

I've been working on getting the mainline qemu tree working on SmartOS (illumos), the current qemu support seems to be a branch of qemu-kvm and we've been having some problems getting spice working, so moving to the main qemu tree seemed sensible.

Anyway, couple of questions…

1. Are you happy to accept patches that enable this?   
	- There are a few build related things that don't work … assumption of sh being bash, missing -64 argument to dtrace etc. 
	- There are also some dtrace language problems with tracetool (no support for bool, and self being reserved.) 
	- More fundamentally some object linking issues with dtrace which I'll need some help to find the best way to resolve.
	- Specific #ifdef CONFIG_SOLARIS/__sun__ stuff to support differences
	- ultimately the support for vnic's … but I haven't even looked at that yet.

	The current state is that it's working ok for Windows guests, and non-KVM for Linux, but kvm & linux seems to fail, hence question number 2.

2. The last thing that happens when I try to boot linux with kvm enabled is some apic mmio accesses, then it stops at a hlt instruction and never gets going again. Is there something I can enable to help debug this? Or has anyone else seen similar behaviour? I've run out of places to look.

Many thanks,

Lee.

Re: [Qemu-devel] [PATCH] coroutine-gthread.c: Avoid threading APIs deprecated in GLib 2.31

2012-03-15 Thread Stefan Hajnoczi
On Sat, Mar 3, 2012 at 2:52 PM, Peter Maydell  wrote:
> The GLib threading APIs were revamped in GLib 2.31 and a number
> of the old interfaces were deprecated, which means they provoke
> compilation warnings (errors if -Werror) now. Add support for the
> new interfaces while retaining the old ones so we can still compile
> on older versions of GLib too.
>
> Signed-off-by: Peter Maydell 
> ---
> In particular, this fixes compilation failure on ARM hosts running
> Ubuntu Precise. Seems kinda ugly to me, suggestions for improvement
> welcomed.

It's ugly but it won't cause larger scale problems, so we should
probably pick this up.

I was wondering if this is a legitimate case to override warnings -
because the new library probably still supports the deprecated
functions.  But eventually we need to bite the bullet and convert the
code.

Stefan



Re: [Qemu-devel] Virtio_PCI device driver code

2012-03-15 Thread Stefan Hajnoczi
On Wed, Mar 14, 2012 at 1:38 PM, Abhinav Pundir
 wrote:
> Hello all I am very much new to the world of KVM and Qemu.
> I am trying to make a communication possible between the Guest and the Host.
> I have studied how Virtio works but I am still confused how exactly the flow
> will work.
> The front end drivers will communicate to the back end driver by invoking a
> kick function, but which back end driver will be involved in that.
> Also how the back end driver present in the Hypervisor will pass this
> information to the emulated device running in  Qemu.
> I am trying to use virtio_pci.c and some suitable modification, so that the
> back end driver can take that information and that information will
> be available to the Hypervisor.
>
> It will be very useful if somebody can provide me the working code of the
> virtio_pci with all the dependencies in the separate directory, so that I
> will be able to insert that module and the equivalent back-end driver code
> running in the Hypervisor.

Please explain what you are trying to achieve.  Coding a custom virtio
device may not be the best solution - it depends on the specific use
case.

Stefan



Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

2012-03-15 Thread Jan Kiszka
On 2012-03-15 11:39, Gleb Natapov wrote:
> On Wed, Mar 14, 2012 at 11:46:08AM -0700, Eric Northup wrote:
>> On Wed, Mar 14, 2012 at 6:25 AM, Gleb Natapov  wrote:
>>
>>> On Wed, Mar 14, 2012 at 03:16:05PM +0200, Avi Kivity wrote:
 On 03/14/2012 03:14 PM, Gleb Natapov wrote:
> On Wed, Mar 14, 2012 at 03:07:46PM +0200, Avi Kivity wrote:
>> On 03/14/2012 01:11 PM, Wen Congyang wrote:

 I don't think we want to use the driver.  Instead, have a small
>>> piece of
 code that resets the device and pushes out a string (the panic
>>> message?)
 without any interrupts etc.

 It's still going to be less reliable than a hypercall, I agree.
>>>
>>> Do you still want to use complicated and less reliable way?
>>
>> Are you willing to try it out and see how complicated it really is?
>>
>> While it's more complicated, it's also more flexible.  You can
>> communicate the panic message, whether the guest is attempting a
>>> kdump
>> and its own recovery or whether it wants the host to do it, etc., you
>> can communicate less severe failures like oopses.
>>
> hypercall can take arguments to achieve the same.

 It has to be designed in advance; and every time we notice something's
 missing we have to update the host kernel.

>>>
>>> We and in the designed stage now. Not to late to design something flexible
>>> :) Panic hypercall can take GPA of a buffer where host puts panic info
>>> as a parameter.  This buffer can be read by QEMU and passed to management.
>>>
>>
>> If a host kernel change is in the works, I think it might be cleanest to
>> have the host kernel export a new kind of VCPU exit for unhandled-by-KVM
>> hypercalls.  Then usermode can respond to the hypercall as appropriate.
>>  This would permit adding or changing future hypercalls without host kernel
>> changes.
>>
> There was such vm exit (KVM_EXIT_HYPERCALL), but it was deemed to be a
> bad idea.

BTW, this would help a lot in emulating hypercalls of other hypervisors
(or of KVM's VAPIC in the absence of in-kernel irqchip - I had to jump
through hoops therefore) in user space. Not all those hypercall handlers
actually have to reside in the KVM module.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux



Re: [Qemu-devel] [PATCH 0/2] Style and bug on linux-user/signal.c

2012-03-15 Thread Stefan Hajnoczi
On Thu, Mar 15, 2012 at 8:52 AM, Alex Barcelo  wrote:
> I tried to send a trivial patch and a v2, but I did it horribly wrong
> and seems that have not yet been updated. I thought that maybe
> it was a good moment to do things "betterly".

Alex Graf mentioned he'd apply it to ppc-next, I have CCed him but he
may have limited connectivity because I think he's away at the moment.
 Perhaps Riku can review and merge it.

Stefan



Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

2012-03-15 Thread Avi Kivity
On 03/15/2012 01:25 PM, Jan Kiszka wrote:
> >>
> > There was such vm exit (KVM_EXIT_HYPERCALL), but it was deemed to be a
> > bad idea.
>
> BTW, this would help a lot in emulating hypercalls of other hypervisors
> (or of KVM's VAPIC in the absence of in-kernel irqchip - I had to jump
> through hoops therefore) in user space. Not all those hypercall handlers
> actually have to reside in the KVM module.
>

That is true.  On the other hand the hypercall ABI might go to pieces if
there was no central implementation.

-- 
error compiling committee.c: too many arguments to function




Re: [Qemu-devel] [PATCH 0/2] Style and bug on linux-user/signal.c

2012-03-15 Thread Alexander Graf

On 15.03.2012, at 12:41, Stefan Hajnoczi wrote:

> On Thu, Mar 15, 2012 at 8:52 AM, Alex Barcelo  wrote:
>> I tried to send a trivial patch and a v2, but I did it horribly wrong
>> and seems that have not yet been updated. I thought that maybe
>> it was a good moment to do things "betterly".
> 
> Alex Graf mentioned he'd apply it to ppc-next, I have CCed him but he
> may have limited connectivity because I think he's away at the moment.
> Perhaps Riku can review and merge it.

No, I'm still around until Monday and today is pull request day! Hooray! So 
after long times of anxious waiting, we will finally have lots of fun ppc stuff 
in the tree again ;).


Alex




Re: [Qemu-devel] [PATCH 0/5] VMWare PVSCSI paravirtual device implementation

2012-03-15 Thread Stefan Hajnoczi
On Thu, Mar 15, 2012 at 9:02 AM, Dmitry Fleytman
 wrote:
> Below is the implementation of VMWare PVSCSI device and
> command line parameters to configure vendor name and product name
> for SCSI storage are implemented.
> Latter is needed to make PVSCSI storage devices look exactly as
> on VMWare hypervisors.
>
> With this and VMWARE3 patches V2V migration problem for VMWare
> images should be solved relatively easy.

What is the V2V strategy?

Supporting these devices is fine if we have a way to convert guests to
use virtio.  But if the plan is to keep the guests on VMware pv
devices, then that will split the development effort on support and
optimizing I/O devices.  All the performance work going into
virtio-net (vhost-net), virtio-blk, and possibly virtio-scsi isn't
easy to duplicate for VMware pv devices.  Also, we cannot extend
VMware devices easily while retaining compatibility.

I'm for supporting these devices, but we really need another step to
move migrated guests onto virtio - otherwise users will be
disappointed with KVM's support/performance.  Can you explain a bit
how you want these devices to be used?

Stefan



Re: [Qemu-devel] [PATCH 0/2] Style and bug on linux-user/signal.c

2012-03-15 Thread Alex Barcelo
Thanks and sorry! I forgot to add a CC when doing the git send-email.

And I thought that I saw some pulls to PPC, so I assumed that the
patch was incomplete (I didn't prepare it very well), and thought that
better to do a style patch next to it. And comment it better.

On Thu, Mar 15, 2012 at 12:47, Alexander Graf  wrote:
>
> On 15.03.2012, at 12:41, Stefan Hajnoczi wrote:
>
>> On Thu, Mar 15, 2012 at 8:52 AM, Alex Barcelo  wrote:
>>> I tried to send a trivial patch and a v2, but I did it horribly wrong
>>> and seems that have not yet been updated. I thought that maybe
>>> it was a good moment to do things "betterly".
>>
>> Alex Graf mentioned he'd apply it to ppc-next, I have CCed him but he
>> may have limited connectivity because I think he's away at the moment.
>> Perhaps Riku can review and merge it.
>
> No, I'm still around until Monday and today is pull request day! Hooray! So 
> after long times of anxious waiting, we will finally have lots of fun ppc 
> stuff in the tree again ;).
>
>
> Alex
>



Re: [Qemu-devel] [PATCH 0/5] VMWare PVSCSI paravirtual device implementation

2012-03-15 Thread Daniel P. Berrange
On Thu, Mar 15, 2012 at 11:47:29AM +, Stefan Hajnoczi wrote:
> On Thu, Mar 15, 2012 at 9:02 AM, Dmitry Fleytman
>  wrote:
> > Below is the implementation of VMWare PVSCSI device and
> > command line parameters to configure vendor name and product name
> > for SCSI storage are implemented.
> > Latter is needed to make PVSCSI storage devices look exactly as
> > on VMWare hypervisors.
> >
> > With this and VMWARE3 patches V2V migration problem for VMWare
> > images should be solved relatively easy.
> 
> What is the V2V strategy?
> 
> Supporting these devices is fine if we have a way to convert guests to
> use virtio.  But if the plan is to keep the guests on VMware pv
> devices, then that will split the development effort on support and
> optimizing I/O devices.  All the performance work going into
> virtio-net (vhost-net), virtio-blk, and possibly virtio-scsi isn't
> easy to duplicate for VMware pv devices.  Also, we cannot extend
> VMware devices easily while retaining compatibility.
> 
> I'm for supporting these devices, but we really need another step to
> move migrated guests onto virtio - otherwise users will be
> disappointed with KVM's support/performance.  Can you explain a bit
> how you want these devices to be used?

FWIW, there is a v2v tool that is able to update guest images to
port them from VMware to KVM, which covers changing the drivers,
but also a bunch of other things

  http://libguestfs.org/virt-v2v/


I can still see value in natively supporting the VMWare PV devices
though, since it could facilitate people who just want to try out
pre-built appliance images which were designed only to use those
devices.

Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|



Re: [Qemu-devel] [PATCH 0/5] VMWare PVSCSI paravirtual device implementation

2012-03-15 Thread Paolo Bonzini
Il 15/03/2012 12:47, Stefan Hajnoczi ha scritto:
> What is the V2V strategy?
> 
> Supporting these devices is fine if we have a way to convert guests to
> use virtio.  But if the plan is to keep the guests on VMware pv
> devices, then that will split the development effort on support and
> optimizing I/O devices.  All the performance work going into
> virtio-net (vhost-net), virtio-blk, and possibly virtio-scsi isn't
> easy to duplicate for VMware pv devices.  Also, we cannot extend
> VMware devices easily while retaining compatibility.

virtio-scsi and vmware-pvscsi should be equivalent in terms of
performance.  Of course vhost-scsi would be another story.

I think supporting these devices is good anyway as long as they are
expected to perform decently but not necessarily as well as virtio.
After all we do support both vmware-vga and qxl.

> I'm for supporting these devices, but we really need another step to
> move migrated guests onto virtio - otherwise users will be
> disappointed with KVM's support/performance.  Can you explain a bit
> how you want these devices to be used?

I'm curious about this too.

Paolo



Re: [Qemu-devel] Illumos/SmarOS support

2012-03-15 Thread Stefan Hajnoczi
On Thu, Mar 15, 2012 at 11:19 AM, Lee Essen  wrote:
> I've been working on getting the mainline qemu tree working on SmartOS
> (illumos), the current qemu support seems to be a branch of qemu-kvm and
> we've been having some problems getting spice working, so moving to the main
> qemu tree seemed sensible.

qemu-kvm.git is a fork of qemu.git.  qemu-kvm.git periodically pulls
in qemu.git updates, but patches are also sent back to mainline
qemu.git so the delta between the two has been decreasing.  Perhaps
the two can merge soon.

> Anyway, couple of questions…
>
> 1. Are you happy to accept patches that enable this?
>   - There are a few build related things that don't work … assumption of 
> sh
> being bash, missing -64 argument to dtrace etc.

Sounds good, but have you checked the Joyent qemu-kvm Illumos port to
see what fixes they already have?

https://github.com/joyent/illumos-kvm-cmd

>   - There are also some dtrace language problems with tracetool (no 
> support
> for bool, and self being reserved.)

If there is a reserved keyword then we need to update ./trace-events
to avoid using it, and we need to add a check to scripts/tracetool so
that it refuses such trace event definitions.  There was discussion
about reserved keywords recently here:
http://patchwork.ozlabs.org/patch/146054/

>   - More fundamentally some object linking issues with dtrace which I'll 
> need
> some help to find the best way to resolve.

I think Joyent has already done this, they said they use QEMU tracing
with DTrace as the backend.

>   - Specific #ifdef CONFIG_SOLARIS/__sun__ stuff to support differences
>   - ultimately the support for vnic's … but I haven't even looked at that
> yet.
>
>   The current state is that it's working ok for Windows guests, and 
> non-KVM
> for Linux, but kvm & linux seems to fail, hence question number 2.
>
> 2. The last thing that happens when I try to boot linux with kvm enabled is
> some apic mmio accesses, then it stops at a hlt instruction and never gets
> going again. Is there something I can enable to help debug this? Or has
> anyone else seen similar behaviour? I've run out of places to look.

So you are using qemu.git/master with the IllumOS KVM port?

I think what you are trying to do makes sense - IllumOS as a host OS
and QEMU platform should be actively involved in the upstream QEMU
community.  But you may want to first check the Joyent port to see
what can easily be upstreamed and also try talking with them if you
haven't already.  I'm not sure why things aren't being pushed upstream
but perhaps the process can be started.

Stefan



Re: [Qemu-devel] [PATCH 2/7] Convert pc cpu to qdev

2012-03-15 Thread Gleb Natapov
On Wed, Mar 14, 2012 at 08:55:08PM +0100, Vasilis Liaskovitis wrote:
> On Wed, Mar 14, 2012 at 05:23:24PM +0200, Gleb Natapov wrote:
> > On Wed, Mar 14, 2012 at 02:49:59PM +0100, Vasilis Liaskovitis wrote:
> > > Hi,
> > > 
> > > 
> > On a different note, are your going to continue working on your memory hot 
> > plug series?
> > I am going to look at it now.
> 
> The memory hotplug patch from September has several issues (e.g. unplug/memory
> free isn't really performed at the qemu level) and is outdated (qemu-kvm-0.15
> and seabios-0.6.1 timeframe). 
> I 've continued working on it against master/new memory API and I will 
> resubmit
> for comments.
> 
Thanks, I've commented on your previous submission. When do you expect
to send update patches?

--
Gleb.



[Qemu-devel] [PATCH 4/4] block: track dirty flag status in qed

2012-03-15 Thread Dong Xu Wang
From: Dong Xu Wang 


Signed-off-by: Dong Xu Wang 
---
 block/qed.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/block/qed.c b/block/qed.c
index a041d31..44b72aa 100644
--- a/block/qed.c
+++ b/block/qed.c
@@ -1441,6 +1441,7 @@ static int bdrv_qed_get_info(BlockDriverState *bs, 
BlockDriverInfo *bdi)
 
 memset(bdi, 0, sizeof(*bdi));
 bdi->cluster_size = s->header.cluster_size;
+bdi->is_dirty = s->header.features & QED_F_NEED_CHECK;
 return 0;
 }
 
-- 
1.7.5.4




[Qemu-devel] [PATCH 01/16] Bad zero comparison for sas_ss_flags on powerpc

2012-03-15 Thread Alexander Graf
From: Alex Barcelo 

All architectures work the same way, and all check for sas_ss_flags ==
0. The powerpc lines are wrong, and do the check the other way round
(it's a qemu internal check, which is done wrong only for this
architecture, it's more a typo than a bug). It's NOT ppc specific,
it's POSIX standard (sigaltstack) and qemu internal.

I have a test source that I will send in a follow-up (it's longer than
I would have wished, I'm sure that a better test case can be written
if needed)

Signed-off-by: Alex Barcelo 
Signed-off-by: Alexander Graf 
---
 linux-user/signal.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/linux-user/signal.c b/linux-user/signal.c
index fca51e2..b1e139d 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -4118,7 +4118,7 @@ static target_ulong get_sigframe(struct target_sigaction 
*ka,
 oldsp = env->gpr[1];
 
 if ((ka->sa_flags & TARGET_SA_ONSTACK) &&
-(sas_ss_flags(oldsp))) {
+(sas_ss_flags(oldsp) == 0)) {
 oldsp = (target_sigaltstack_used.ss_sp
  + target_sigaltstack_used.ss_size);
 }
-- 
1.6.0.2




[Qemu-devel] [PATCH 12/16] ppc: Correctly define POWERPC_INSNS2_DEFAULT

2012-03-15 Thread Alexander Graf
From: Meador Inge 

'POWERPC_INSNS2_DEFAULT' was defined incorrectly which was causing the
opcode table creation code to erroneously register 'eieio' and 'mbar'
for the "default" processor:

   ** ERROR: opcode 1a already assigned in opcode table 16
   *** ERROR: unable to insert opcode [1f-16-1a]
   *** ERROR initializing PowerPC instruction 0x1f 0x16 0x1a

Signed-off-by: Meador Inge 
Signed-off-by: Alexander Graf 
---
 target-ppc/translate_init.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index 5a958b9..367eefa 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -6718,7 +6718,7 @@ static void init_proc_620 (CPUPPCState *env)
 #if defined (TARGET_PPC64) && 0 // XXX: TODO
 #define CPU_POWERPC_DEFAULTCPU_POWERPC_PPC64
 #define POWERPC_INSNS_DEFAULT  POWERPC_INSNS_PPC64
-#define POWERPC_INSNS2_DEFAULT POWERPC_INSNS_PPC64
+#define POWERPC_INSNS2_DEFAULT POWERPC_INSNS2_PPC64
 #define POWERPC_MSRM_DEFAULT   POWERPC_MSRM_PPC64
 #define POWERPC_MMU_DEFAULTPOWERPC_MMU_PPC64
 #define POWERPC_EXCP_DEFAULT   POWERPC_EXCP_PPC64
@@ -6730,7 +6730,7 @@ static void init_proc_620 (CPUPPCState *env)
 #else
 #define CPU_POWERPC_DEFAULTCPU_POWERPC_PPC32
 #define POWERPC_INSNS_DEFAULT  POWERPC_INSNS_PPC32
-#define POWERPC_INSNS2_DEFAULT POWERPC_INSNS_PPC32
+#define POWERPC_INSNS2_DEFAULT POWERPC_INSNS2_PPC32
 #define POWERPC_MSRM_DEFAULT   POWERPC_MSRM_PPC32
 #define POWERPC_MMU_DEFAULTPOWERPC_MMU_PPC32
 #define POWERPC_EXCP_DEFAULT   POWERPC_EXCP_PPC32
-- 
1.6.0.2




[Qemu-devel] [PATCH 05/16] PPC64: Add support for ldbrx and stdbrx instructions

2012-03-15 Thread Alexander Graf
From: Thomas Huth 

These instructions for loading and storing byte-swapped 64-bit values have
been introduced in PowerISA 2.06.

Signed-off-by: Thomas Huth 
Signed-off-by: David Gibson 
Signed-off-by: Alexander Graf 
---
 target-ppc/cpu.h|4 ++-
 target-ppc/translate.c  |   52 +++---
 target-ppc/translate_init.c |2 +-
 3 files changed, 47 insertions(+), 11 deletions(-)

diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
index ad09cbe..ca6f1cb 100644
--- a/target-ppc/cpu.h
+++ b/target-ppc/cpu.h
@@ -1918,8 +1918,10 @@ enum {
 PPC2_DFP   = 0x0004ULL,
 /* Embedded.Processor Control*/
 PPC2_PRCNTL= 0x0008ULL,
+/* Byte-reversed, indexed, double-word load and store*/
+PPC2_DBRX  = 0x0010ULL,
 
-#define PPC_TCG_INSNS2 (PPC2_BOOKE206 | PPC2_PRCNTL)
+#define PPC_TCG_INSNS2 (PPC2_BOOKE206 | PPC2_PRCNTL | PPC2_DBRX)
 };
 
 /*/
diff --git a/target-ppc/translate.c b/target-ppc/translate.c
index 3ec59a7..4722a09 100644
--- a/target-ppc/translate.c
+++ b/target-ppc/translate.c
@@ -2650,7 +2650,7 @@ static void glue(gen_, name##ux)(DisasContext *ctx)
 tcg_temp_free(EA);\
 }
 
-#define GEN_LDX(name, ldop, opc2, opc3, type) \
+#define GEN_LDX_E(name, ldop, opc2, opc3, type, type2)\
 static void glue(gen_, name##x)(DisasContext *ctx)\
 { \
 TCGv EA;  \
@@ -2660,6 +2660,8 @@ static void glue(gen_, name##x)(DisasContext *ctx)
\
 gen_qemu_##ldop(ctx, cpu_gpr[rD(ctx->opcode)], EA);   \
 tcg_temp_free(EA);\
 }
+#define GEN_LDX(name, ldop, opc2, opc3, type) \
+GEN_LDX_E(name, ldop, opc2, opc3, type, PPC_NONE)
 
 #define GEN_LDS(name, ldop, op, type) \
 GEN_LD(name, ldop, op | 0x20, type);  \
@@ -2793,8 +2795,8 @@ static void glue(gen_, name##ux)(DisasContext *ctx)
 tcg_temp_free(EA);\
 }
 
-#define GEN_STX(name, stop, opc2, opc3, type) \
-static void glue(gen_, name##x)(DisasContext *ctx) 
   \
+#define GEN_STX_E(name, stop, opc2, opc3, type, type2)\
+static void glue(gen_, name##x)(DisasContext *ctx)\
 { \
 TCGv EA;  \
 gen_set_access_type(ctx, ACCESS_INT); \
@@ -2803,6 +2805,8 @@ static void glue(gen_, name##x)(DisasContext *ctx)
 gen_qemu_##stop(ctx, cpu_gpr[rS(ctx->opcode)], EA);   \
 tcg_temp_free(EA);\
 }
+#define GEN_STX(name, stop, opc2, opc3, type) \
+GEN_STX_E(name, stop, opc2, opc3, type, PPC_NONE)
 
 #define GEN_STS(name, stop, op, type) \
 GEN_ST(name, stop, op | 0x20, type);  \
@@ -2891,6 +2895,18 @@ static inline void gen_qemu_ld32ur(DisasContext *ctx, 
TCGv arg1, TCGv arg2)
 }
 GEN_LDX(lwbr, ld32ur, 0x16, 0x10, PPC_INTEGER);
 
+#if defined(TARGET_PPC64)
+/* ldbrx */
+static inline void gen_qemu_ld64ur(DisasContext *ctx, TCGv arg1, TCGv arg2)
+{
+tcg_gen_qemu_ld64(arg1, arg2, ctx->mem_idx);
+if (likely(!ctx->le_mode)) {
+tcg_gen_bswap64_tl(arg1, arg1);
+}
+}
+GEN_LDX_E(ldbr, ld64ur, 0x14, 0x10, PPC_NONE, PPC2_DBRX);
+#endif  /* TARGET_PPC64 */
+
 /* sthbrx */
 static inline void gen_qemu_st16r(DisasContext *ctx, TCGv arg1, TCGv arg2)
 {
@@ -2921,6 +2937,22 @@ static inline void gen_qemu_st32r(DisasContext *ctx, 
TCGv arg1, TCGv arg2)
 }
 GEN_STX(stwbr, st32r, 0x16, 0x14, PPC_INTEGER);
 
+#if defined(TARGET_PPC64)
+/* stdbrx */
+static inline void gen_qemu_st64r(DisasContext *ctx, TCGv arg1, TCGv arg2)
+{
+if (likely(!ctx->le_mode)) {
+TCGv t0 = tcg_temp_new();
+tcg_gen_bswap64_tl(t0, arg1);
+tcg_gen_qemu_st64(t0, arg2, ctx->mem_idx);
+tcg_temp_free(t0);
+} else {
+tcg_gen_qemu_st64(arg1, arg2, ctx->mem_idx);
+}
+}
+GEN_STX_E(stdbr, st64r, 0x14, 0x14, PPC_NONE, PPC2_DBRX);
+#endif  /* TARGET_PPC64 */
+
 /***Integer load and store multiple***/
 
 /* lmw */
@@ -8818,7 +8850,7 @@ GE

[Qemu-devel] [PATCH 03/16] ppc: Add missing 'static' to spin_rw_ops

2012-03-15 Thread Alexander Graf
From: Stefan Weil 

spin_rw_ops is only used in hw/ppce500_spin.c.

Signed-off-by: Stefan Weil 
Acked-by: Andreas Färber 
Signed-off-by: Alexander Graf 
---
 hw/ppce500_spin.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/hw/ppce500_spin.c b/hw/ppce500_spin.c
index 268f5fd..960b7b0 100644
--- a/hw/ppce500_spin.c
+++ b/hw/ppce500_spin.c
@@ -182,7 +182,7 @@ static uint64_t spin_read(void *opaque, target_phys_addr_t 
addr, unsigned len)
 }
 }
 
-const MemoryRegionOps spin_rw_ops = {
+static const MemoryRegionOps spin_rw_ops = {
 .read = spin_read,
 .write = spin_write,
 .endianness = DEVICE_BIG_ENDIAN,
-- 
1.6.0.2




Re: [Qemu-devel] Illumos/SmarOS support

2012-03-15 Thread Andreas Färber
Hi,

Am 15.03.2012 12:19, schrieb Lee Essen:
> I've been working on getting the mainline qemu tree working on SmartOS 
> (illumos), the current qemu support seems to be a branch of qemu-kvm and 
> we've been having some problems getting spice working, so moving to the main 
> qemu tree seemed sensible.
> 
> Anyway, couple of questions…
> 
> 1. Are you happy to accept patches that enable this?

In the past I've kept QEMU running on OpenSolaris. Avi had one
outstanding patch to fix C99 compilation, and I have some to start
tackling builds without --disable-guest-agent on OpenIndiana in a local
queue that I need to revisit. Never tested our DTrace support so far.

But sure, host support patches for qemu.git are welcome.

See http://wiki.qemu.org/Contribute/StartHere for info on expected style
and workflows. Please cc me on patches.

Andreas



Re: [Qemu-devel] [PATCH 0/5] VMWare PVSCSI paravirtual device implementation

2012-03-15 Thread Avi Kivity
On 03/15/2012 01:47 PM, Stefan Hajnoczi wrote:
> On Thu, Mar 15, 2012 at 9:02 AM, Dmitry Fleytman
>  wrote:
> > Below is the implementation of VMWare PVSCSI device and
> > command line parameters to configure vendor name and product name
> > for SCSI storage are implemented.
> > Latter is needed to make PVSCSI storage devices look exactly as
> > on VMWare hypervisors.
> >
> > With this and VMWARE3 patches V2V migration problem for VMWare
> > images should be solved relatively easy.
>
> What is the V2V strategy?
>
> Supporting these devices is fine if we have a way to convert guests to
> use virtio.  But if the plan is to keep the guests on VMware pv
> devices, then that will split the development effort on support and
> optimizing I/O devices.  All the performance work going into
> virtio-net (vhost-net), virtio-blk, and possibly virtio-scsi isn't
> easy to duplicate for VMware pv devices.  Also, we cannot extend
> VMware devices easily while retaining compatibility.
>

Note, it's possible to hook vmxnet to vhost-net:

 - process the vmxnet ring in qemu
 - translate it into a virtio ring in offguest memory (placing virtio
headers in offguest memory as well)
 - fire off vhost-net
 - etc.

So there are still extra context switches, but we can still get some of
the benefits of vhost-net.

-- 
error compiling committee.c: too many arguments to function




Re: [Qemu-devel] [PATCH] coroutine-gthread.c: Avoid threading APIs deprecated in GLib 2.31

2012-03-15 Thread Andreas Färber
Am 14.03.2012 15:50, schrieb Peter Maydell:
> Ping?
> 
> On 3 March 2012 14:52, Peter Maydell  wrote:
>> The GLib threading APIs were revamped in GLib 2.31 and a number
>> of the old interfaces were deprecated, which means they provoke
>> compilation warnings (errors if -Werror) now. Add support for the
>> new interfaces while retaining the old ones so we can still compile
>> on older versions of GLib too.
>>
>> Signed-off-by: Peter Maydell 
>> ---
>> In particular, this fixes compilation failure on ARM hosts running
>> Ubuntu Precise. Seems kinda ugly to me, suggestions for improvement
>> welcomed.

Appeared okay to me.

/-F

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



Re: [Qemu-devel] Illumos/SmarOS support

2012-03-15 Thread lee . essen
On 15/03/2012 11:56, Stefan Hajnoczi wrote:

  Anyway, couple of questions…

1. Are you happy to accept patches that enable this?
	- There are a few build related things that don't work … assumption of sh
being bash, missing -64 argument to dtrace etc.

  Sounds good, but have you checked the Joyent qemu-kvm Illumos port to
see what fixes they already have?

https://github.com/joyent/illumos-kvm-cmd Yes, they have solved the same problems .. however the build mechanism seems to be sufficiently different that things need to be done slightly differently for qemu.git.These aren't complex changes and amount to generally only a couple of lines.The illumos-kvm-cmd tree seems to be only updated to address joyent live-image build requirements, and hasn't really moved in about 7 months. I've been posting profusely on the smartos mailing list and they also don't seem that concerned about this work.However, there are a few of us that would like to get spice up and running and the illumos fork doesn't seem like a sensible place to start when they are so far behind.They have said that they will incorporate the spice work once it's complete, so I'm pretty confident that we can push them to the main qemu tree at that point.	
	- More fundamentally some object linking issues with dtrace which I'll need
some help to find the best way to resolve.
I think Joyent has already done this, they said they use QEMU tracing
with DTrace as the backend.
 Yes they have, but again the build mechanism has changed quite significantly.The basic issue here is that dtrace on Illumos seems to need all objects to be provided to it when you create the dtrace provider object, I'm guessing it uses the objects to work out which probes to actually include ... if you don't provide any objects you get an output object with none of the symbols you need in it.So for each binary created you need to do something like...dtrace -o -dtrace.o -G -s  ... then include the specific -drace.o when linking the main binary.
So you are using qemu.git/master with the IllumOS KVM port?

I think what you are trying to do makes sense - IllumOS as a host OS
and QEMU platform should be actively involved in the upstream QEMU
community.  But you may want to first check the Joyent port to see
what can easily be upstreamed and also try talking with them if you
haven't already.  I'm not sure why things aren't being pushed upstream
but perhaps the process can be started.
 Yes, and (other than my Linux issue) it's working well.The changes needed to get it working are pretty minimal, most of them are #ifdef's around KVM_CAP's that are assumed to be defined (at least in some of the code.)The specific code changes boil down to:- a different mechanism for creating a vcpu filehandle (which is cloned from /dev/kvm rather than the return code of KVM_CREATE_VCPU) - some of the kvm ioctls using different filehandles.- the requirement to lock guest memory- a KVM_EXIT_INTR case with ret=0 from the ioctl (exernal interrupt)... which amounts to probably less than 50 lines of changes, and again the code structure is pretty different to their port, so I think it's easier to apply new rather than push upstream.I would have thought that applying this (minimal) stuff to the qemu.git tree and using that for illumos would remove the need for a specific joyent version, and hence be a good thing.The joyent guys are very focused (understandably) on their specific needs, however if someone else is prepared to do the work they do seem pretty willing to adopt it.Regards,Lee.


Re: [Qemu-devel] [PATCH 1/4 v3] block: add image fragmentation statistics to qemu-img

2012-03-15 Thread Stefan Hajnoczi
On Thu, Mar 15, 2012 at 08:13:31PM +0800, Dong Xu Wang wrote:
> From: Dong Xu Wang 
> 
> Discussion can be found at:
> http://patchwork.ozlabs.org/patch/128730/
> 
> This patch add image fragmentation statistics while using qemu-img check.
> 
> Signed-off-by: Dong Xu Wang 
> ---
>  block.h|7 +++
>  qemu-img.c |9 -
>  2 files changed, 15 insertions(+), 1 deletions(-)

A minor comment that doesn't require resending:

Please avoid introducing whitespace or reformatting changes in a patch
that makes other code changes.  Patch 1 changes whitespace in a place
that is not touched by the rest of your patch, so that change is not
essential and it's best to leave it out.

Reviewed-by: Stefan Hajnoczi 




[Qemu-devel] [PATCH 2/4 v3] block: image fragmentation statistics for qed

2012-03-15 Thread Dong Xu Wang
From: Dong Xu Wang 


Signed-off-by: Dong Xu Wang 
---
 block/qed-check.c |9 +
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/block/qed-check.c b/block/qed-check.c
index e4a49ce..94327ff 100644
--- a/block/qed-check.c
+++ b/block/qed-check.c
@@ -68,6 +68,7 @@ static unsigned int qed_check_l2_table(QEDCheck *check, 
QEDTable *table)
 {
 BDRVQEDState *s = check->s;
 unsigned int i, num_invalid = 0;
+uint64_t last_offset = 0;
 
 for (i = 0; i < s->table_nelems; i++) {
 uint64_t offset = table->offsets[i];
@@ -76,6 +77,11 @@ static unsigned int qed_check_l2_table(QEDCheck *check, 
QEDTable *table)
 qed_offset_is_zero_cluster(offset)) {
 continue;
 }
+check->result->bfi.allocated_clusters++;
+if (last_offset && (last_offset + s->header.cluster_size != offset)) {
+check->result->bfi.fragmented_clusters++;
+}
+last_offset = offset;
 
 /* Detect invalid cluster offset */
 if (!qed_check_cluster_offset(s, offset)) {
@@ -200,6 +206,9 @@ int qed_check(BDRVQEDState *s, BdrvCheckResult *result, 
bool fix)
 check.used_clusters = g_malloc0(((check.nclusters + 31) / 32) *
sizeof(check.used_clusters[0]));
 
+check.result->bfi.total_clusters =
+(s->header.image_size + s->header.cluster_size - 1) /
+s->header.cluster_size;
 ret = qed_check_l1_table(&check, s->l1_table);
 if (ret == 0) {
 /* Only check for leaks if entire image was scanned successfully */
-- 
1.7.5.4




[Qemu-devel] [PATCH 1/4 v3] block: add image fragmentation statistics to qemu-img

2012-03-15 Thread Dong Xu Wang
From: Dong Xu Wang 

Discussion can be found at:
http://patchwork.ozlabs.org/patch/128730/

This patch add image fragmentation statistics while using qemu-img check.

Signed-off-by: Dong Xu Wang 
---
 block.h|7 +++
 qemu-img.c |9 -
 2 files changed, 15 insertions(+), 1 deletions(-)

diff --git a/block.h b/block.h
index 415bb17..32e1e58 100644
--- a/block.h
+++ b/block.h
@@ -17,6 +17,12 @@ typedef struct BlockDriverInfo {
 int64_t vm_state_offset;
 } BlockDriverInfo;
 
+typedef struct BlockFragInfo {
+uint64_t allocated_clusters;
+uint64_t total_clusters;
+uint64_t fragmented_clusters;
+} BlockFragInfo;
+
 typedef struct QEMUSnapshotInfo {
 char id_str[128]; /* unique snapshot id */
 /* the following fields are informative. They are not needed for
@@ -175,6 +181,7 @@ typedef struct BdrvCheckResult {
 int corruptions;
 int leaks;
 int check_errors;
+BlockFragInfo bfi;
 } BdrvCheckResult;
 
 int bdrv_check(BlockDriverState *bs, BdrvCheckResult *res);
diff --git a/qemu-img.c b/qemu-img.c
index 0e48b35..4de48ba 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -428,6 +428,13 @@ static int img_check(int argc, char **argv)
 }
 }
 
+if (result.bfi.total_clusters != 0 && result.bfi.allocated_clusters != 0) {
+printf("%" PRId64 "/%" PRId64 "= %0.2f%% allocated, %0.2f%% 
fragmented\n",
+result.bfi.allocated_clusters, result.bfi.total_clusters,
+result.bfi.allocated_clusters * 100.0 / result.bfi.total_clusters,
+result.bfi.fragmented_clusters * 100.0 / 
result.bfi.allocated_clusters);
+}
+
 bdrv_delete(bs);
 
 if (ret < 0 || result.check_errors) {
@@ -716,7 +723,7 @@ static int img_convert(int argc, char **argv)
 ret = -1;
 goto out;
 }
-
+
 qemu_progress_init(progress, 2.0);
 qemu_progress_print(0, 100);
 
-- 
1.7.5.4




[Qemu-devel] [PATCH 3/4 v3] block: add dirty flag status to qemu-img

2012-03-15 Thread Dong Xu Wang
From: Dong Xu Wang 

Some block drivers can verify their image files are clean or not. So we can show
it while using "qemu-img info".

Signed-off-by: Dong Xu Wang 
---
 block.h|1 +
 qemu-img.c |3 +++
 2 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/block.h b/block.h
index 32e1e58..12219d0 100644
--- a/block.h
+++ b/block.h
@@ -15,6 +15,7 @@ typedef struct BlockDriverInfo {
 int cluster_size;
 /* offset at which the VM state can be saved (0 if not possible) */
 int64_t vm_state_offset;
+bool is_dirty;
 } BlockDriverInfo;
 
 typedef struct BlockFragInfo {
diff --git a/qemu-img.c b/qemu-img.c
index 4de48ba..6a61ca8 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -1132,6 +1132,9 @@ static int img_info(int argc, char **argv)
 if (bdi.cluster_size != 0) {
 printf("cluster_size: %d\n", bdi.cluster_size);
 }
+if (bdi.is_dirty) {
+printf("cleanly shut down: no\n");
+}
 }
 bdrv_get_backing_filename(bs, backing_filename, sizeof(backing_filename));
 if (backing_filename[0] != '\0') {
-- 
1.7.5.4




[Qemu-devel] [PATCH] vga: disable default VGA if appropriate -device is used

2012-03-15 Thread Paolo Bonzini
This is a partial revert of commits a369da5 (vga: improve VGA logic,
committed 2012-01-22) and c5bd4f3 (vga: fix -nodefaults -device VGA,
2012-01-24) which broke command-line option parsing in different ways.

Since commit a369da5 it has become impossible to specify a VGA device
entirely with QemuOpts-enabled options, i.e. without needing an explicit
"-vga none".

In addition, until commit c5bd4f3 -nodefaults would not disable the device
you specified with the legacy "-vga" option, independent of the order.
Since commit c5bd4f3 QEMU -nodefaults will override a previous -vga
option.

I did not reintroduce machine->no_vga.  Boards can simply ignore the
vga_interface_type variable, and most will indeed do so.

Cc: Blue Swirl 
Signed-off-by: Paolo Bonzini 
---
 vl.c |   25 -
 1 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/vl.c b/vl.c
index 65f11f2..fd394c8 100644
--- a/vl.c
+++ b/vl.c
@@ -272,6 +272,7 @@ static int default_monitor = 1;
 static int default_floppy = 1;
 static int default_cdrom = 1;
 static int default_sdcard = 1;
+static int default_vga = 1;
 
 static struct {
 const char *driver;
@@ -287,6 +288,12 @@ static struct {
 { .driver = "virtio-serial-pci",.flag = &default_virtcon   },
 { .driver = "virtio-serial-s390",   .flag = &default_virtcon   },
 { .driver = "virtio-serial",.flag = &default_virtcon   },
+{ .driver = "VGA",  .flag = &default_vga   },
+{ .driver = "isa-vga",  .flag = &default_vga   },
+{ .driver = "cirrus-vga",   .flag = &default_vga   },
+{ .driver = "isa-cirrus-vga",   .flag = &default_vga   },
+{ .driver = "vmware-svga",  .flag = &default_vga   },
+{ .driver = "qxl-vga",  .flag = &default_vga   },
 };
 
 static void res_free(void)
@@ -2269,7 +2276,7 @@ int main(int argc, char **argv, char **envp)
 const char *loadvm = NULL;
 QEMUMachine *machine;
 const char *cpu_model;
-const char *vga_model = NULL;
+const char *vga_model = "none";
 const char *pid_file = NULL;
 const char *incoming = NULL;
 #ifdef CONFIG_VNC
@@ -2699,6 +2706,7 @@ int main(int argc, char **argv, char **envp)
 break;
 case QEMU_OPTION_vga:
 vga_model = optarg;
+default_vga = 0;
 break;
 case QEMU_OPTION_g:
 {
@@ -3107,7 +3115,7 @@ int main(int argc, char **argv, char **envp)
 default_floppy = 0;
 default_cdrom = 0;
 default_sdcard = 0;
-vga_model = "none";
+default_vga = 0;
 break;
 case QEMU_OPTION_xen_domid:
 if (!(xen_available())) {
@@ -3468,14 +3476,13 @@ int main(int argc, char **argv, char **envp)
 
 module_call_init(MODULE_INIT_QOM);
 
-/* must be after qdev registration but before machine init */
-if (vga_model) {
-select_vgahw(vga_model);
-} else if (cirrus_vga_available()) {
-select_vgahw("cirrus");
-} else {
-select_vgahw("none");
+/* This must be after qdev registration but before machine init.
+ * If no default VGA is requested, the default is "none".
+ */
+if (default_vga && cirrus_vga_available()) {
+vga_model = "cirrus";
 }
+select_vgahw(vga_model);
 
 if (qemu_opts_foreach(qemu_find_opts("device"), device_help_func, NULL, 0) 
!= 0)
 exit(0);
-- 
1.7.7.6




Re: [Qemu-devel] Illumos/SmarOS support

2012-03-15 Thread Stefan Hajnoczi
On Thu, Mar 15, 2012 at 12:39 PM,   wrote:
>> On 15/03/2012 11:56, Stefan Hajnoczi wrote:
>> I think what you are trying to do makes sense - IllumOS as a host OS
>> and QEMU platform should be actively involved in the upstream QEMU
>> community.  But you may want to first check the Joyent port to see
>> what can easily be upstreamed and also try talking with them if you
>> haven't already.  I'm not sure why things aren't being pushed upstream
>> but perhaps the process can be started.
>
>
> Yes, and (other than my Linux issue) it's working well.
>
> The changes needed to get it working are pretty minimal, most of them are
> #ifdef's around KVM_CAP's that are assumed to be defined (at least in some
> of the code.)
>
> The specific code changes boil down to:
> - a different mechanism for creating a vcpu filehandle (which is cloned from
> /dev/kvm rather than the return code of KVM_CREATE_VCPU)
> - some of the kvm ioctls using different filehandles.
> - the requirement to lock guest memory
> - a KVM_EXIT_INTR case with ret=0 from the ioctl (exernal interrupt)
>
> ... which amounts to probably less than 50 lines of changes, and again the
> code structure is pretty different to their port, so I think it's easier to
> apply new rather than push upstream.
>
> I would have thought that applying this (minimal) stuff to the qemu.git tree
> and using that for illumos would remove the need for a specific joyent
> version, and hence be a good thing.
>
> The joyent guys are very focused (understandably) on their specific needs,
> however if someone else is prepared to do the work they do seem pretty
> willing to adopt it.

Okay, that's important because doing a porting/upstreaming effort like
this also has a big human or political element.  If they are
supportive then it's more likely everyone involved will end up with a
qemu.git tree they like and can use.

My main concern with the KVM functionality is that Joyent is leading
the kernel side and you are leading the upstream qemu.git side - this
means there needs to be collaboration.  Perhaps you can CC your
qemu-devel patches to an illumos/joyent mailing list so that it's
always clear where you're headed.  That way, folks experienced with
the IllumOS KVM kernel interface can review and give advice.  The
scenario to avoid would be for upstream qemu.git to have IllumOS
support merged but it breaks because the KVM kernel side goes in a
different direction.

Anway, your plan to get patches upstream sounds good to me.

Stefan



[Qemu-devel] [PATCH 02/16] PPC: 405: Fix ppc405ep initialization

2012-03-15 Thread Alexander Graf
When trying to run a ppc405 guest, it segfaults quite quickly, trying to
access timers that weren't initialized. Initialize them properly instead.

Reported-by: Andreas Faerber 
Signed-off-by: Alexander Graf 
---
 hw/ppc405_uc.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/hw/ppc405_uc.c b/hw/ppc405_uc.c
index 6f8342e..89e5013 100644
--- a/hw/ppc405_uc.c
+++ b/hw/ppc405_uc.c
@@ -2471,6 +2471,8 @@ CPUPPCState *ppc405ep_init(MemoryRegion 
*address_space_mem,
 ppc4xx_pob_init(env);
 /* OBP arbitrer */
 ppc4xx_opba_init(0xef600600);
+/* Initialize timers */
+ppc_booke_timers_init(env, sysclk, 0);
 /* Universal interrupt controller */
 irqs = g_malloc0(sizeof(qemu_irq) * PPCUIC_OUTPUT_NB);
 irqs[PPCUIC_OUTPUT_INT] =
-- 
1.6.0.2




[Qemu-devel] [PATCH 3/4 v3] block: add dirty flag status to qemu-img

2012-03-15 Thread Dong Xu Wang
From: Dong Xu Wang 

Some block drivers can verify their image files are clean or not. So we can show
it while using "qemu-img info".

Signed-off-by: Dong Xu Wang 
---
 block.h|1 +
 qemu-img.c |3 +++
 2 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/block.h b/block.h
index 32e1e58..12219d0 100644
--- a/block.h
+++ b/block.h
@@ -15,6 +15,7 @@ typedef struct BlockDriverInfo {
 int cluster_size;
 /* offset at which the VM state can be saved (0 if not possible) */
 int64_t vm_state_offset;
+bool is_dirty;
 } BlockDriverInfo;
 
 typedef struct BlockFragInfo {
diff --git a/qemu-img.c b/qemu-img.c
index 4de48ba..6a61ca8 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -1132,6 +1132,9 @@ static int img_info(int argc, char **argv)
 if (bdi.cluster_size != 0) {
 printf("cluster_size: %d\n", bdi.cluster_size);
 }
+if (bdi.is_dirty) {
+printf("cleanly shut down: no\n");
+}
 }
 bdrv_get_backing_filename(bs, backing_filename, sizeof(backing_filename));
 if (backing_filename[0] != '\0') {
-- 
1.7.5.4




Re: [Qemu-devel] Illumos/SmarOS support

2012-03-15 Thread Andreas Färber
Something went wrong with your reply... While it contains a quote it
does not reference the mail you replied to, that way messages get lost
among the constant chatter on qemu-devel.

Am 15.03.2012 13:39, schrieb lee.es...@me.com:
> On 15/03/2012 11:56, Stefan Hajnoczi wrote:
>>> Anyway, couple of questions…
>>>
>>> 1. Are you happy to accept patches that enable this?
>>> - There are a few build related things that don't work … assumption of 
>>> sh
>>> being bash, missing -64 argument to dtrace etc.
>> Sounds good, but have you checked the Joyent qemu-kvm Illumos port to
>> see what fixes they already have?
>>
>> https://github.com/joyent/illumos-kvm-cmd
>  
> Yes, they have solved the same problems .. however the build mechanism
> seems to be sufficiently different that things need to be done slightly
> differently for qemu.git.
> 
> These aren't complex changes and amount to generally only a couple of lines.
> 
> The illumos-kvm-cmd tree seems to be only updated to address joyent
> live-image build requirements, and hasn't really moved in about 7
> months. I've been posting profusely on the smartos mailing list and they
> also don't seem that concerned about this work.

At FOSDEM, I talked to a Bryant from illumos who wanted to forward my
business card to their KVM/QEMU guys re upstreaming, but I haven't heard
back from anyone so far.

> So for each binary created you need to do something like...
> 
> dtrace -o -dtrace.o -G -s 
> 
> 
> ... then include the specific -drace.o when linking the main
> binary.

Same as on Solaris 10. There was some alternative trick to "glom"
objects together to avoid linking in that extra object, don't remember
exactly. Hopefully there's an archive of the old Sun blogs somewhere.


Concerning KVM, there was some resentment on the Red Hat side againt the
SmartOS KVM port due to the legal issue of whether GPL'ed KVM may be
combined with CDDL. But that is independent of currently broken QEMU
host support in userland.

Andreas



[Qemu-devel] [PATCH 09/16] PPC: Add PIR register to POWER7 CPU

2012-03-15 Thread Alexander Graf
From: Nathan Whitehorn 

The POWER7 emulation is missing the Processor Identification Register,
mandatory in recent POWER CPUs, that is required for SMP on at least
some operating systems (e.g. FreeBSD) to function properly. This patch
copies the existing PIR code from the other CPUs that implement it.

Signed-off-by: Nathan Whitehorn 
Signed-off-by: Alexander Graf 
---
 target-ppc/translate_init.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index c707959..5a958b9 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -6588,6 +6588,11 @@ static void init_proc_POWER7 (CPUPPCState *env)
 gen_spr_7xx(env);
 /* Time base */
 gen_tbl(env);
+/* Processor identification */
+spr_register(env, SPR_PIR, "PIR",
+ SPR_NOACCESS, SPR_NOACCESS,
+ &spr_read_generic, &spr_write_pir,
+ 0x);
 #if !defined(CONFIG_USER_ONLY)
 /* PURR & SPURR: Hack - treat these as aliases for the TB for now */
 spr_register(env, SPR_PURR,   "PURR",
-- 
1.6.0.2




[Qemu-devel] [PATCH 1/4 v3] block: add image fragmentation statistics to qemu-img

2012-03-15 Thread Dong Xu Wang
From: Dong Xu Wang 

Discussion can be found at:
http://patchwork.ozlabs.org/patch/128730/

This patch add image fragmentation statistics while using qemu-img check.

Signed-off-by: Dong Xu Wang 
---
 block.h|7 +++
 qemu-img.c |9 -
 2 files changed, 15 insertions(+), 1 deletions(-)

diff --git a/block.h b/block.h
index 415bb17..32e1e58 100644
--- a/block.h
+++ b/block.h
@@ -17,6 +17,12 @@ typedef struct BlockDriverInfo {
 int64_t vm_state_offset;
 } BlockDriverInfo;
 
+typedef struct BlockFragInfo {
+uint64_t allocated_clusters;
+uint64_t total_clusters;
+uint64_t fragmented_clusters;
+} BlockFragInfo;
+
 typedef struct QEMUSnapshotInfo {
 char id_str[128]; /* unique snapshot id */
 /* the following fields are informative. They are not needed for
@@ -175,6 +181,7 @@ typedef struct BdrvCheckResult {
 int corruptions;
 int leaks;
 int check_errors;
+BlockFragInfo bfi;
 } BdrvCheckResult;
 
 int bdrv_check(BlockDriverState *bs, BdrvCheckResult *res);
diff --git a/qemu-img.c b/qemu-img.c
index 0e48b35..4de48ba 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -428,6 +428,13 @@ static int img_check(int argc, char **argv)
 }
 }
 
+if (result.bfi.total_clusters != 0 && result.bfi.allocated_clusters != 0) {
+printf("%" PRId64 "/%" PRId64 "= %0.2f%% allocated, %0.2f%% 
fragmented\n",
+result.bfi.allocated_clusters, result.bfi.total_clusters,
+result.bfi.allocated_clusters * 100.0 / result.bfi.total_clusters,
+result.bfi.fragmented_clusters * 100.0 / 
result.bfi.allocated_clusters);
+}
+
 bdrv_delete(bs);
 
 if (ret < 0 || result.check_errors) {
@@ -716,7 +723,7 @@ static int img_convert(int argc, char **argv)
 ret = -1;
 goto out;
 }
-
+
 qemu_progress_init(progress, 2.0);
 qemu_progress_print(0, 100);
 
-- 
1.7.5.4




Re: [Qemu-devel] [PATCH] kvmvapic: align start address as well as size

2012-03-15 Thread Anthony Liguori

On 03/15/2012 04:55 AM, Avi Kivity wrote:

On 03/14/2012 10:33 PM, Anthony Liguori wrote:

On 03/06/2012 09:50 AM, Avi Kivity wrote:

The kvmvapic code remaps a section of ROM as RAM to allow the guest to
maintain state there.  It is careful to align the section size to a page
boundary, to avoid creating subpages, but neglects to do the same for
the start address.  These leads to an assert later on when the memory
core tries to create a page which is half RAM and half ROM.

Fix by aligning the start address to a page boundary.

This can be triggered by running qemu-system-x86_64 -enable-kvm -vga
none.

Signed-off-by: Avi Kivity


Tested-by: Anthony Liguori

Are you going to do a PULL request or do you want me to apply directly?


I forgot all about it, sorry.


No worries.  I actually caught the bug in the original pull request but do to a 
bug in qemu-test, when I tried to bisect, things got weird and I mistakenly 
thought the real problem had been introduced earlier.


Regards,

Anthony Liguori








[Qemu-devel] [PATCH 13/16] kvm: Comparison with ioctl number macros needs to be unsigned

2012-03-15 Thread Alexander Graf
From: David Gibson 

In kvm-all.c we store an ioctl cmd number in the irqchip_inject_ioctl field
of KVMState, which has type 'int'.  This seems to make sense since the
ioctl() man page says that the cmd parameter has type int.

However, the kernel treats ioctl numbers as unsigned - sys_ioctl() takes an
unsigned int, and the macros which generate ioctl numbers expand to
unsigned expressions.  Furthermore, some ioctls (IOC_READ ioctls on x86
and IOC_WRITE ioctls on powerpc) have bit 31 set, and so would be negative
if interpreted as an int. This has the surprising and compile-breaking
consequence that in kvm_irqchip_set_irq() where we do:
return (s->irqchip_inject_ioctl == KVM_IRQ_LINE) ? 1 : event.status;
We will get a "comparison is always false due to limited range of data
type" warning from gcc if KVM_IRQ_LINE is one of the bit-31-set ioctls,
which it is on powerpc.

So, despite the fact that the man page and posix say ioctl numbers are
signed, they're actually unsigned.  The kernel uses unsigned, the glibc
header uses unsigned long, and FreeBSD, NetBSD and OSX also use unsigned
long ioctl numbers in the code.

Therefore, this patch changes the variable to be unsigned, fixing the
compile.

Signed-off-by: David Gibson 
Signed-off-by: Alexander Graf 
---
 kvm-all.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/kvm-all.c b/kvm-all.c
index 42e5e23..ba2cee1 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -79,7 +79,10 @@ struct KVMState
 int pit_state2;
 int xsave, xcrs;
 int many_ioeventfds;
-int irqchip_inject_ioctl;
+/* The man page (and posix) say ioctl numbers are signed int, but
+ * they're not.  Linux, glibc and *BSD all treat ioctl numbers as
+ * unsigned, and treating them as signed here can break things */
+unsigned irqchip_inject_ioctl;
 #ifdef KVM_CAP_IRQ_ROUTING
 struct kvm_irq_routing *irq_routes;
 int nr_allocated_irq_routes;
-- 
1.6.0.2




[Qemu-devel] [Bug 918791] Re: qemu-kvm dies when using vmvga driver and unity in the guest

2012-03-15 Thread Jamie Strandboge
Serge, thanks for your work on this. I can confirm that I can run unity-
2d on 11.04 without crashing qemu. Thanks! :)

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

Title:
  qemu-kvm dies when using vmvga driver and unity in the guest

Status in QEMU:
  New
Status in “qemu-kvm” package in Ubuntu:
  Fix Released
Status in “xserver-xorg-video-vmware” package in Ubuntu:
  Confirmed
Status in “qemu-kvm” source package in Precise:
  Fix Released
Status in “xserver-xorg-video-vmware” source package in Precise:
  Confirmed

Bug description:
  12.04's qemu-kvm has been unstable for me and Marc Deslauriers and I
  figured out it has something to do with the interaction of qemu-kvm,
  unity and the vmvga driver. This is a regression over qemu-kvm in
  11.10.

  TEST CASE:
  1. start a VM that uses unity (eg, 11.04, 11.10 or 12.04). My tests use 
unity-2d on an amd64 host and amd64 guests
  2. on 11.04 and 11.10, open empathy via the messaging indicator and click 
'Chat'. On 12.04, open empathy via the messaging indicator and click 'Chat', 
close the empathy wizard, move the empathy window over the unity luancher (so 
it autohides), then do 'ctrl+alt+t' to open a terminal

  When the launcher tries to auto(un)hide, qemu-kvm dies with this:
  [10574.958149] do_general_protection: 132 callbacks suppressed
  [10574.958154] kvm[13192] general protection ip:7fab9680ea0f sp:74440148 
error:0 in qemu-system-x86_64[7fab966c4000+2c9000]

  Relevant libvirt xml:
  


  

  If I change to using 'cirrus', then qemu-kvm no longer crashes. Eg:
  



  

  The workaround is therefore to use the cirrus driver instead of vmvga,
  however being able to kill qemu-kvm in this manner is not ideal. Also,
  unfortunately unity-2d does not run with with cirrus driver under
  11.04, so the security and SRU teams are unable to properly test
  updates in GUI applications under unity when using the current 12.04
  qemu-kvm.

  I tried to report this via apport, but apport complained about a CRC
  error, so I could not.

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



[Qemu-devel] [PATCH 10/16] PPC: Fix large page support in TCG

2012-03-15 Thread Alexander Graf
From: Nathan Whitehorn 

Fix large page support in TCG. The old code would overwrite the large page
table entry with the fake 4 KB one generated here whenever the ref/change bits
were updated, causing it to point to the wrong area of memory.

Signed-off-by: Nathan Whitehorn 
Acked-by: David Gibson 
[agraf: fix whitespace, braces]
Signed-off-by: Alexander Graf 
---
 target-ppc/helper.c |   12 ++--
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/target-ppc/helper.c b/target-ppc/helper.c
index bd711b6..39dcc27 100644
--- a/target-ppc/helper.c
+++ b/target-ppc/helper.c
@@ -591,12 +591,6 @@ static inline int _find_pte(CPUPPCState *env, mmu_ctx_t 
*ctx, int is_64b, int h,
 pte1 = ldq_phys(env->htab_base + pteg_off + (i * 16) + 8);
 }
 
-/* We have a TLB that saves 4K pages, so let's
- * split a huge page to 4k chunks */
-if (target_page_bits != TARGET_PAGE_BITS)
-pte1 |= (ctx->eaddr & (( 1 << target_page_bits ) - 1))
-& TARGET_PAGE_MASK;
-
 r = pte64_check(ctx, pte0, pte1, h, rw, type);
 LOG_MMU("Load pte from " TARGET_FMT_lx " => " TARGET_FMT_lx " "
 TARGET_FMT_lx " %d %d %d " TARGET_FMT_lx "\n",
@@ -672,6 +666,12 @@ static inline int _find_pte(CPUPPCState *env, mmu_ctx_t 
*ctx, int is_64b, int h,
 }
 }
 
+/* We have a TLB that saves 4K pages, so let's
+ * split a huge page to 4k chunks */
+if (target_page_bits != TARGET_PAGE_BITS) {
+ctx->raddr |= (ctx->eaddr & ((1 << target_page_bits) - 1))
+  & TARGET_PAGE_MASK;
+}
 return ret;
 }
 
-- 
1.6.0.2




[Qemu-devel] [PATCH 07/16] pseries: Remove unused constant from PCI code

2012-03-15 Thread Alexander Graf
From: David Gibson 

The 'bars' constant array was used in experimental device allocation code
which is no longer necessary now that we always run the SLOF firmware.
This patch removes the now redundant variable.

Signed-off-by: Alexey Kardashevskiy 
Signed-off-by: David Gibson 
Signed-off-by: Alexander Graf 
---
 hw/spapr_pci.c |7 ---
 1 files changed, 0 insertions(+), 7 deletions(-)

diff --git a/hw/spapr_pci.c b/hw/spapr_pci.c
index 374dcf8..3d5e50a 100644
--- a/hw/spapr_pci.c
+++ b/hw/spapr_pci.c
@@ -32,13 +32,6 @@
 
 #include "hw/pci_internals.h"
 
-static const uint32_t bars[] = {
-PCI_BASE_ADDRESS_0, PCI_BASE_ADDRESS_1,
-PCI_BASE_ADDRESS_2, PCI_BASE_ADDRESS_3,
-PCI_BASE_ADDRESS_4, PCI_BASE_ADDRESS_5
-/*, PCI_ROM_ADDRESS*/
-};
-
 static PCIDevice *find_dev(sPAPREnvironment *spapr,
uint64_t buid, uint32_t config_addr)
 {
-- 
1.6.0.2




[Qemu-devel] [PATCH 04/16] pseries: Don't try to munmap() a malloc()ed TCE table

2012-03-15 Thread Alexander Graf
From: David Gibson 

For the pseries machine, TCE (IOMMU) tables can either be directly
malloc()ed in qemu or, when running on a KVM which supports it, mmap()ed
from a KVM ioctl.  The latter option is used when available, because it
allows the (frequent bottlenext) H_PUT_TCE hypercall to be KVM accelerated.
However, even when KVM is persent, TCE acceleration is not always possible.
Only KVM HV supports this ioctl(), not KVM PR, or the kernel could run out
of contiguous memory to allocate the new table.  In this case we need to
fall back on the malloc()ed table.

When a device is removed, and we need to remove the TCE table, we need to
either munmap() or free() the table as appropriate for how it was
allocated.  The code is supposed to do that, but we buggily fail to
initialize the tcet->fd variable in the malloc() case, which is used as a
flag to determine which is the right choice.

This patch fixes the bug, and cleans up error messages relating to this
path while we're at it.

Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: David Gibson 
Signed-off-by: Alexander Graf 
---
 target-ppc/kvm.c |   12 ++--
 1 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index aeb3de9..724f4c7 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -843,12 +843,18 @@ void *kvmppc_create_spapr_tce(uint32_t liobn, uint32_t 
window_size, int *pfd)
 int fd;
 void *table;
 
+/* Must set fd to -1 so we don't try to munmap when called for
+ * destroying the table, which the upper layers -will- do
+ */
+*pfd = -1;
 if (!cap_spapr_tce) {
 return NULL;
 }
 
 fd = kvm_vm_ioctl(kvm_state, KVM_CREATE_SPAPR_TCE, &args);
 if (fd < 0) {
+fprintf(stderr, "KVM: Failed to create TCE table for liobn 0x%x\n",
+liobn);
 return NULL;
 }
 
@@ -857,6 +863,8 @@ void *kvmppc_create_spapr_tce(uint32_t liobn, uint32_t 
window_size, int *pfd)
 
 table = mmap(NULL, len, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
 if (table == MAP_FAILED) {
+fprintf(stderr, "KVM: Failed to map TCE table for liobn 0x%x\n",
+liobn);
 close(fd);
 return NULL;
 }
@@ -876,8 +884,8 @@ int kvmppc_remove_spapr_tce(void *table, int fd, uint32_t 
window_size)
 len = (window_size / SPAPR_VIO_TCE_PAGE_SIZE)*sizeof(VIOsPAPR_RTCE);
 if ((munmap(table, len) < 0) ||
 (close(fd) < 0)) {
-fprintf(stderr, "KVM: Unexpected error removing KVM SPAPR TCE "
-"table: %s", strerror(errno));
+fprintf(stderr, "KVM: Unexpected error removing TCE table: %s",
+strerror(errno));
 /* Leak the table */
 }
 
-- 
1.6.0.2




[Qemu-devel] [PULL 00/16] ppc patch queue 2012-03-15

2012-03-15 Thread Alexander Graf
Hi Blue / Aurelien,

This is my current patch queue for ppc. Please pull.

Alex


The following changes since commit ae7d54d489540b49b7c13a7df7ddc220588a2ced:
  Andreas Färber (1):
target-lm32/microblaze: Drop second CPU{LM32, MB}State typedef

are available in the git repository at:

  git://repo.or.cz/qemu/agraf.git ppc-for-upstream

Alex Barcelo (1):
  Bad zero comparison for sas_ss_flags on powerpc

Alexander Graf (3):
  PPC: 405: Fix ppc405ep initialization
  PPC: KVM: Synchronize regs on CPU dump
  PPC: Fix openpic with relative memregions

Alexey Kardashevskiy (1):
  pseries: Remove PCI device from PCI host bridge code

David Gibson (6):
  pseries: Don't try to munmap() a malloc()ed TCE table
  pseries: Update SLOF firmware image
  pseries: Remove unused constant from PCI code
  pseries: Add support for level interrupts to XICS
  kvm: Comparison with ioctl number macros needs to be unsigned
  pseries: Configure PCI bridge using properties

Meador Inge (1):
  ppc: Correctly define POWERPC_INSNS2_DEFAULT

Nathan Whitehorn (2):
  PPC: Add PIR register to POWER7 CPU
  PPC: Fix large page support in TCG

Stefan Weil (1):
  ppc: Add missing 'static' to spin_rw_ops

Thomas Huth (1):
  PPC64: Add support for ldbrx and stdbrx instructions

 hw/openpic.c|   12 +--
 hw/ppc405_uc.c  |2 +
 hw/ppce500_spin.c   |2 +-
 hw/spapr.c  |5 +-
 hw/spapr.h  |   13 +++-
 hw/spapr_pci.c  |  193 ---
 hw/spapr_pci.h  |4 +-
 hw/spapr_vio.c  |2 +-
 hw/xics.c   |  125 +---
 hw/xics.h   |8 ++-
 kvm-all.c   |5 +-
 linux-user/signal.c |2 +-
 pc-bios/README  |2 +-
 pc-bios/slof.bin|  Bin 869584 -> 880496 bytes
 roms/SLOF   |2 +-
 target-ppc/cpu.h|4 +-
 target-ppc/helper.c |   12 ++--
 target-ppc/kvm.c|   12 ++-
 target-ppc/translate.c  |   54 ++--
 target-ppc/translate_init.c |   11 ++-
 20 files changed, 294 insertions(+), 176 deletions(-)



[Qemu-devel] [Bug 883136] Re: qemu on ARM hosts aborts on startup because makecontext() always fails

2012-03-15 Thread Peter Maydell
** Changed in: qemu-linaro
   Status: Fix Committed => Fix Released

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

Title:
  qemu on ARM hosts aborts on startup because makecontext() always fails

Status in QEMU:
  Fix Committed
Status in Linaro QEMU:
  Fix Released

Bug description:
  qemu has recently grown a coroutines implementation. There are two
  versions, one using the makecontext/setcontext/swapcontext functions
  from ucontext.h, and one falling back to implementing coroutines as
  separate glib threads. configure chooses the former if the platform
  has a makecontext().

  Unfortunately ARM eglibc provides a makecontext() which always fails
  ENOSYS, which means the configure check passes but when qemu starts it
  abort()s.

  The best fix for this is probably going to involve making the
  coroutine implementation runtime-selectable.

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



[Qemu-devel] [PATCH 2/4 v3] block: image fragmentation statistics for qed

2012-03-15 Thread Dong Xu Wang
From: Dong Xu Wang 


Signed-off-by: Dong Xu Wang 
---
 block/qed-check.c |9 +
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/block/qed-check.c b/block/qed-check.c
index e4a49ce..94327ff 100644
--- a/block/qed-check.c
+++ b/block/qed-check.c
@@ -68,6 +68,7 @@ static unsigned int qed_check_l2_table(QEDCheck *check, 
QEDTable *table)
 {
 BDRVQEDState *s = check->s;
 unsigned int i, num_invalid = 0;
+uint64_t last_offset = 0;
 
 for (i = 0; i < s->table_nelems; i++) {
 uint64_t offset = table->offsets[i];
@@ -76,6 +77,11 @@ static unsigned int qed_check_l2_table(QEDCheck *check, 
QEDTable *table)
 qed_offset_is_zero_cluster(offset)) {
 continue;
 }
+check->result->bfi.allocated_clusters++;
+if (last_offset && (last_offset + s->header.cluster_size != offset)) {
+check->result->bfi.fragmented_clusters++;
+}
+last_offset = offset;
 
 /* Detect invalid cluster offset */
 if (!qed_check_cluster_offset(s, offset)) {
@@ -200,6 +206,9 @@ int qed_check(BDRVQEDState *s, BdrvCheckResult *result, 
bool fix)
 check.used_clusters = g_malloc0(((check.nclusters + 31) / 32) *
sizeof(check.used_clusters[0]));
 
+check.result->bfi.total_clusters =
+(s->header.image_size + s->header.cluster_size - 1) /
+s->header.cluster_size;
 ret = qed_check_l1_table(&check, s->l1_table);
 if (ret == 0) {
 /* Only check for leaks if entire image was scanned successfully */
-- 
1.7.5.4




[Qemu-devel] [PATCH 16/16] PPC: Fix openpic with relative memregions

2012-03-15 Thread Alexander Graf
After commit 5312bd8b3152 we got memory region relative offsets into our mmio
callbacks instead of page boundary based offsets.

This broke the OpenPIC emulation which expected offsets to be on page boundary
and substracted its region offset manually.

This patch gets rid of that manual substraction and lets the memory api do its
magic instead.

Signed-off-by: Alexander Graf 
---
 hw/openpic.c |   12 ++--
 1 files changed, 2 insertions(+), 10 deletions(-)

diff --git a/hw/openpic.c b/hw/openpic.c
index 280b7a9..58ef871 100644
--- a/hw/openpic.c
+++ b/hw/openpic.c
@@ -713,7 +713,7 @@ static void openpic_timer_write (void *opaque, uint32_t 
addr, uint32_t val)
 DPRINTF("%s: addr %08x <= %08x\n", __func__, addr, val);
 if (addr & 0xF)
 return;
-addr -= 0x1100;
+addr -= 0x10;
 addr &= 0x;
 idx = (addr & 0xFFF0) >> 6;
 addr = addr & 0x30;
@@ -746,7 +746,7 @@ static uint32_t openpic_timer_read (void *opaque, uint32_t 
addr)
 retval = 0x;
 if (addr & 0xF)
 return retval;
-addr -= 0x1100;
+addr -= 0x10;
 addr &= 0x;
 idx = (addr & 0xFFF0) >> 6;
 addr = addr & 0x30;
@@ -1361,7 +1361,6 @@ static void mpic_src_ext_write (void *opaque, 
target_phys_addr_t addr,
 if (addr & 0xF)
 return;
 
-addr -= MPIC_EXT_REG_START & (OPENPIC_PAGE_SIZE - 1);
 if (addr < MPIC_EXT_REG_SIZE) {
 idx += (addr & 0xFFF0) >> 5;
 if (addr & 0x10) {
@@ -1385,7 +1384,6 @@ static uint32_t mpic_src_ext_read (void *opaque, 
target_phys_addr_t addr)
 if (addr & 0xF)
 return retval;
 
-addr -= MPIC_EXT_REG_START & (OPENPIC_PAGE_SIZE - 1);
 if (addr < MPIC_EXT_REG_SIZE) {
 idx += (addr & 0xFFF0) >> 5;
 if (addr & 0x10) {
@@ -1411,7 +1409,6 @@ static void mpic_src_int_write (void *opaque, 
target_phys_addr_t addr,
 if (addr & 0xF)
 return;
 
-addr -= MPIC_INT_REG_START & (OPENPIC_PAGE_SIZE - 1);
 if (addr < MPIC_INT_REG_SIZE) {
 idx += (addr & 0xFFF0) >> 5;
 if (addr & 0x10) {
@@ -1435,7 +1432,6 @@ static uint32_t mpic_src_int_read (void *opaque, 
target_phys_addr_t addr)
 if (addr & 0xF)
 return retval;
 
-addr -= MPIC_INT_REG_START & (OPENPIC_PAGE_SIZE - 1);
 if (addr < MPIC_INT_REG_SIZE) {
 idx += (addr & 0xFFF0) >> 5;
 if (addr & 0x10) {
@@ -1461,7 +1457,6 @@ static void mpic_src_msg_write (void *opaque, 
target_phys_addr_t addr,
 if (addr & 0xF)
 return;
 
-addr -= MPIC_MSG_REG_START & (OPENPIC_PAGE_SIZE - 1);
 if (addr < MPIC_MSG_REG_SIZE) {
 idx += (addr & 0xFFF0) >> 5;
 if (addr & 0x10) {
@@ -1485,7 +1480,6 @@ static uint32_t mpic_src_msg_read (void *opaque, 
target_phys_addr_t addr)
 if (addr & 0xF)
 return retval;
 
-addr -= MPIC_MSG_REG_START & (OPENPIC_PAGE_SIZE - 1);
 if (addr < MPIC_MSG_REG_SIZE) {
 idx += (addr & 0xFFF0) >> 5;
 if (addr & 0x10) {
@@ -1511,7 +1505,6 @@ static void mpic_src_msi_write (void *opaque, 
target_phys_addr_t addr,
 if (addr & 0xF)
 return;
 
-addr -= MPIC_MSI_REG_START & (OPENPIC_PAGE_SIZE - 1);
 if (addr < MPIC_MSI_REG_SIZE) {
 idx += (addr & 0xFFF0) >> 5;
 if (addr & 0x10) {
@@ -1534,7 +1527,6 @@ static uint32_t mpic_src_msi_read (void *opaque, 
target_phys_addr_t addr)
 if (addr & 0xF)
 return retval;
 
-addr -= MPIC_MSI_REG_START & (OPENPIC_PAGE_SIZE - 1);
 if (addr < MPIC_MSI_REG_SIZE) {
 idx += (addr & 0xFFF0) >> 5;
 if (addr & 0x10) {
-- 
1.6.0.2




[Qemu-devel] [PATCH 6/9] libqtest: add IRQ intercept commands

2012-03-15 Thread Anthony Liguori
From: Paolo Bonzini 

Signed-off-by: Paolo Bonzini 
Signed-off-by: Anthony Liguori 
---
 tests/libqtest.c |   12 
 tests/libqtest.h |6 ++
 2 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/tests/libqtest.c b/tests/libqtest.c
index dd07b07..1d1b06e 100644
--- a/tests/libqtest.c
+++ b/tests/libqtest.c
@@ -235,6 +235,18 @@ bool qtest_get_irq(QTestState *s, int num)
 return s->irq_level[num];
 }
 
+void qtest_irq_intercept_out(QTestState *s, const char *qom_path)
+{
+qtest_sendf(s, "irq_intercept_out %s\n", qom_path);
+qtest_rsp(s, 0);
+}
+
+void qtest_irq_intercept_in(QTestState *s, const char *qom_path)
+{
+qtest_sendf(s, "irq_intercept_in %s\n", qom_path);
+qtest_rsp(s, 0);
+}
+
 static void qtest_out(QTestState *s, const char *cmd, uint16_t addr, uint32_t 
value)
 {
 qtest_sendf(s, "%s 0x%x 0x%x\n", cmd, addr, value);
diff --git a/tests/libqtest.h b/tests/libqtest.h
index dd82926..b5ca04e 100644
--- a/tests/libqtest.h
+++ b/tests/libqtest.h
@@ -26,6 +26,10 @@ void qtest_quit(QTestState *s);
 
 bool qtest_get_irq(QTestState *s, int num);
 
+void qtest_irq_intercept_in(QTestState *s, const char *string);
+
+void qtest_irq_intercept_out(QTestState *s, const char *string);
+
 void qtest_outb(QTestState *s, uint16_t addr, uint8_t value);
 
 void qtest_outw(QTestState *s, uint16_t addr, uint16_t value);
@@ -51,6 +55,8 @@ void qtest_add_func(const char *str, void (*fn));
 )
 
 #define get_irq(num) qtest_get_irq(global_qtest, (num))
+#define irq_intercept_in(num) qtest_irq_intercept_in(global_qtest, (num))
+#define irq_intercept_out(num) qtest_irq_intercept_out(global_qtest, (num))
 #define outb(addr, val) qtest_outb(global_qtest, (addr), (val))
 #define outw(addr, val) qtest_outw(global_qtest, (addr), (val))
 #define outl(addr, val) qtest_outl(global_qtest, (addr), (val))
-- 
1.7.5.4




[Qemu-devel] [PATCH 4/9] make: add check targets based on gtester (v2)

2012-03-15 Thread Anthony Liguori
This will run all tests through gtester.  The main targets are:

$ make check

Which will run each unit test and:

$ make check-report.html

Which will generate a nice HTML report of the test status.

Signed-off-by: Anthony Liguori 
Signed-off-by: Paolo Bonzini 
---
v1 -> v2
 - fix Makefile (Paolo)
 - add stubs to work around bug in recent gtester (Paolo)

gtester-cat: work around recent bug

merge into check command
---
 scripts/gtester-cat |   37 +
 tests/Makefile  |   64 +++---
 2 files changed, 97 insertions(+), 4 deletions(-)
 create mode 100755 scripts/gtester-cat

diff --git a/scripts/gtester-cat b/scripts/gtester-cat
new file mode 100755
index 000..de57e63
--- /dev/null
+++ b/scripts/gtester-cat
@@ -0,0 +1,37 @@
+#!/bin/sh
+#
+# Copyright IBM, Corp. 2012
+#
+# Authors:
+#  Anthony Liguori 
+#
+# This work is licensed under the terms of the GNU GPLv2 or later.
+# See the COPYING file in the top-level directory.
+
+cat <
+
+ 
+  qemu
+  0.0
+  rev
+  
+EOF
+
+for file in "$@"; do
+first="yes"
+cat $file | while read LINE; do
+   if test "$first" = "yes"; then
+   first="no"
+   continue
+   fi
+   if test "$LINE" = "" -o "$LINE" = ""; then
+   continue
+   fi
+   echo $LINE
+done
+done
+
+cat<
+EOF
diff --git a/tests/Makefile b/tests/Makefile
index 9d7cfb3..254c06d 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -11,7 +11,13 @@ CHECKS += test-qmp-input-visitor$(EXESUF)
 CHECKS += test-qmp-output-visitor$(EXESUF)
 CHECKS += test-string-input-visitor$(EXESUF)
 CHECKS += test-string-output-visitor$(EXESUF)
-CHECKS += $(SRC_PATH)/tests/qemu-iotests-quick.sh
+
+TEST_SCRIPTS = $(SRC_PATH)/tests/qemu-iotests-quick.sh
+
+
+HW_TESTS=
+
+TARGETS=$(patsubst %-softmmu,%, $(filter %-softmmu,$(TARGET_DIRS)))
 
 check-qint.o check-qstring.o check-qdict.o check-qlist.o check-qfloat.o 
check-qjson.o test-coroutine.o: $(GENERATED_HEADERS)
 
@@ -59,8 +65,58 @@ tests/rtc-test: tests/rtc-test.o tests/libqtest.o
 
 .PHONY: check check-block
 
-check: $(CHECKS)
-   $(call quiet-command, gtester $(CHECKS), "  CHECK")
-
 check-block:
$(call quiet-command, $(SHELL) $(SRC_PATH)/tests/check-block.sh , "  
CHECK")
+
+check-help:
+   @echo "Regression targets:"
+   @echo
+   @echo " make checkRun all tests"
+   @echo " make check-qtest  Run qtest tests"
+   @echo " make check-unit   Run qobject tests"
+   @echo " make check-block  Run block tests"
+   @echo " make check-report.htmlGenerates an HTML test report"
+   @echo
+   @echo "Please note that HTML reports do not regenerate if the unit 
tests"
+   @echo "has not changed."
+   @echo
+   @echo "The variable SPEED can be set to control the gtester speed 
setting"
+
+.SECONDARY:
+
+SPEED ?= quick
+
+# Reports
+check-report-qtest-%.log: $(HW_TESTS)
+   $(call quiet-command,QTEST_QEMU_BINARY=`basename $@ .log | cut -f4 
-d-`-softmmu/qemu-system-`basename $@ .log | cut -f4 -d-` \
+ gtester -k -q -o $@ -m=$(SPEED) $(HW_TESTS),"  TEST   $^ (`basename 
$@ .log | cut -f4 -d-`)")
+
+check-report-unit.log: $(CHECKS)
+   $(call quiet-command,gtester -k -q -m=$(SPEED) -o $@ $^, "  TEST   $^")
+
+check-report.log: check-report-unit.log $(patsubst %,check-report-qtest-%.log, 
$(TARGETS))
+   $(call quiet-command,$(SRC_PATH)/scripts/gtester-cat $^ > $@, "  GEN
$@")
+
+check-report.html: check-report.log
+   $(call quiet-command,gtester-report $< > $@, "  GEN$@")
+
+# Check tests
+
+check-qtest-%: $(HW_TESTS)
+   @for test in $^; do \
+   arch=`echo $@ | cut -f3- -d-`; \
+   echo "Running '$$test' with qemu-system-$$arch..."; \
+   $(SRC_PATH)/scripts/qtest $$arch-softmmu/qemu-system-$$arch $$test 
|| exit $$?; \
+   done
+
+check-qtest: $(patsubst %,check-qtest-%, $(TARGETS))
+
+check-unit: $(addprefix $(shell pwd)/, $(CHECKS)) $(TEST_SCRIPTS)
+   @for test in $^; do \
+   echo "Running '$$test'..."; \
+   $$test || exit $?; \
+   done
+
+check: check-unit check-qtest
+
+.PHONY: check-help check-qtest check-unit check
-- 
1.7.5.4




[Qemu-devel] [PATCH 2/9] qtest: add test framework (v3)

2012-03-15 Thread Anthony Liguori
The idea behind qtest is pretty simple.  Instead of executing a CPU via TCG or
KVM, rely on an external process to send events to the device model that the CPU
would normally generate.

qtest presents itself as an accelerator.  In addition, a new option is added to
establish a qtest server (-qtest) that takes a character device.  This is what
allows the external process to send CPU events to the device model.

qtest uses a simple line based protocol to send the events.  Documentation of
that protocol is in qtest.c.

I considered reusing the monitor for this job.  Adding interrupts would be a bit
difficult.  In addition, logging would also be difficult.

qtest has extensive logging support.  All protocol commands are logged with
time stamps using a new command line option (-qtest-log).  Logging is important
since ultimately, this is a feature for debugging.

Signed-off-by: Anthony Liguori 
Signed-off-by: Paolo Bonzini 
---
v1 -> v2
 - always send a response (Paolo)
 - enable echo (Paolo)
 - do not use TCG CPU threads (Paolo)

v2 -> v3
 - no need for synthetic interupt controller (Paolo)
---
 Makefile.objs   |2 +
 cpu-exec.c  |1 +
 cpus.c  |   62 +-
 qemu-options.hx |8 ++
 qtest.c |  354 +++
 qtest.h |   35 ++
 vl.c|8 ++
 7 files changed, 467 insertions(+), 3 deletions(-)
 create mode 100644 qtest.c
 create mode 100644 qtest.h

diff --git a/Makefile.objs b/Makefile.objs
index 226b01d..e9842b0 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -322,6 +322,8 @@ hw-obj-$(CONFIG_DP8393X) += dp8393x.o
 hw-obj-$(CONFIG_DS1225Y) += ds1225y.o
 hw-obj-$(CONFIG_MIPSNET) += mipsnet.o
 
+hw-obj-y += qtest.o
+
 # Sound
 sound-obj-y =
 sound-obj-$(CONFIG_SB16) += sb16.o
diff --git a/cpu-exec.c b/cpu-exec.c
index bd5791f..d8354b8 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -21,6 +21,7 @@
 #include "disas.h"
 #include "tcg.h"
 #include "qemu-barrier.h"
+#include "qtest.h"
 
 int tb_invalidated_flag;
 
diff --git a/cpus.c b/cpus.c
index 25ba621..010047e 100644
--- a/cpus.c
+++ b/cpus.c
@@ -741,6 +741,48 @@ static void *qemu_kvm_cpu_thread_fn(void *arg)
 return NULL;
 }
 
+static void *qemu_dummy_cpu_thread_fn(void *arg)
+{
+#ifdef _WIN32
+fprintf(stderr, "qtest is not supported under Windows\n");
+exit(1);
+#else
+CPUArchState *env = arg;
+sigset_t waitset;
+int r;
+
+qemu_mutex_lock_iothread();
+qemu_thread_get_self(env->thread);
+env->thread_id = qemu_get_thread_id();
+
+sigemptyset(&waitset);
+sigaddset(&waitset, SIG_IPI);
+
+/* signal CPU creation */
+env->created = 1;
+qemu_cond_signal(&qemu_cpu_cond);
+
+cpu_single_env = env;
+while (1) {
+cpu_single_env = NULL;
+qemu_mutex_unlock_iothread();
+do {
+int sig;
+r = sigwait(&waitset, &sig);
+} while (r == -1 && (errno == EAGAIN || errno == EINTR));
+if (r == -1) {
+perror("sigwait");
+exit(1);
+}
+qemu_mutex_lock_iothread();
+cpu_single_env = env;
+qemu_wait_io_event_common(env);
+}
+
+return NULL; 
+#endif
+}
+
 static void tcg_exec_all(void);
 
 static void *qemu_tcg_cpu_thread_fn(void *arg)
@@ -803,7 +845,7 @@ void qemu_cpu_kick(void *_env)
 CPUArchState *env = _env;
 
 qemu_cond_broadcast(env->halt_cond);
-if (kvm_enabled() && !env->thread_kicked) {
+if (!tcg_enabled() && !env->thread_kicked) {
 qemu_cpu_kick_thread(env);
 env->thread_kicked = true;
 }
@@ -832,7 +874,7 @@ int qemu_cpu_is_self(void *_env)
 
 void qemu_mutex_lock_iothread(void)
 {
-if (kvm_enabled()) {
+if (!tcg_enabled()) {
 qemu_mutex_lock(&qemu_global_mutex);
 } else {
 iothread_requesting_mutex = true;
@@ -947,6 +989,18 @@ static void qemu_kvm_start_vcpu(CPUArchState *env)
 }
 }
 
+static void qemu_dummy_start_vcpu(CPUArchState *env)
+{
+env->thread = g_malloc0(sizeof(QemuThread));
+env->halt_cond = g_malloc0(sizeof(QemuCond));
+qemu_cond_init(env->halt_cond);
+qemu_thread_create(env->thread, qemu_dummy_cpu_thread_fn, env,
+   QEMU_THREAD_JOINABLE);
+while (env->created == 0) {
+qemu_cond_wait(&qemu_cpu_cond, &qemu_global_mutex);
+}
+}
+
 void qemu_init_vcpu(void *_env)
 {
 CPUArchState *env = _env;
@@ -956,8 +1010,10 @@ void qemu_init_vcpu(void *_env)
 env->stopped = 1;
 if (kvm_enabled()) {
 qemu_kvm_start_vcpu(env);
-} else {
+} else if (tcg_enabled()) {
 qemu_tcg_init_vcpu(env);
+} else {
+qemu_dummy_start_vcpu(env);
 }
 }
 
diff --git a/qemu-options.hx b/qemu-options.hx
index daefce3..dae3407 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -2707,6 +2707,14 @@ the @var{simple} tracing backend.
 @end table
 ETEXI
 
+DEF("qtest", HAS_ARG, QEMU_OPTION_qtest,
+"-qtest CHR  specify tracing options\n",
+QEMU_A

[Qemu-devel] [PATCH 11/16] pseries: Add support for level interrupts to XICS

2012-03-15 Thread Alexander Graf
From: David Gibson 

The pseries "xics" interrupt controller, like most interrupt
controllers can support both message (i.e. edge sensitive) interrupts
and level sensitive interrupts, but it needs to know which are which.

When I implemented the xics emulation for qemu, the only devices we
supported were the PAPR virtual IO devices.  These devices only use
message interrupts, so they were the only ones I implemented in xics.

Since then, however, we have added support for PCI devices, which use
level sensitive interrupts.  It turns out the message interrupt logic
still actually works most of the time for these, but there are
circumstances where we can lost interrupts due to the incorrect
interrupt logic.

This patch, therefore, implements the correct xics level-sensitive
interrupt logic.  The type of the interrupt is set when a device
allocates a new xics interrupt.

Signed-off-by: David Gibson 
Signed-off-by: Alexander Graf 
---
 hw/spapr.c |5 +-
 hw/spapr.h |   13 +-
 hw/spapr_pci.c |2 +-
 hw/spapr_vio.c |2 +-
 hw/xics.c  |  125 +--
 hw/xics.h  |8 +++-
 6 files changed, 117 insertions(+), 38 deletions(-)

diff --git a/hw/spapr.c b/hw/spapr.c
index 3719e0e..bfaf260 100644
--- a/hw/spapr.c
+++ b/hw/spapr.c
@@ -83,7 +83,8 @@
 
 sPAPREnvironment *spapr;
 
-qemu_irq spapr_allocate_irq(uint32_t hint, uint32_t *irq_num)
+qemu_irq spapr_allocate_irq(uint32_t hint, uint32_t *irq_num,
+enum xics_irq_type type)
 {
 uint32_t irq;
 qemu_irq qirq;
@@ -95,7 +96,7 @@ qemu_irq spapr_allocate_irq(uint32_t hint, uint32_t *irq_num)
 irq = spapr->next_irq++;
 }
 
-qirq = xics_find_qirq(spapr->icp, irq);
+qirq = xics_assign_irq(spapr->icp, irq, type);
 if (!qirq) {
 return NULL;
 }
diff --git a/hw/spapr.h b/hw/spapr.h
index a41641f..11160b0 100644
--- a/hw/spapr.h
+++ b/hw/spapr.h
@@ -286,7 +286,18 @@ void spapr_register_hypercall(target_ulong opcode, 
spapr_hcall_fn fn);
 target_ulong spapr_hypercall(CPUPPCState *env, target_ulong opcode,
  target_ulong *args);
 
-qemu_irq spapr_allocate_irq(uint32_t hint, uint32_t *irq_num);
+qemu_irq spapr_allocate_irq(uint32_t hint, uint32_t *irq_num,
+enum xics_irq_type type);
+
+static inline qemu_irq spapr_allocate_msi(uint32_t hint, uint32_t *irq_num)
+{
+return spapr_allocate_irq(hint, irq_num, XICS_MSI);
+}
+
+static inline qemu_irq spapr_allocate_lsi(uint32_t hint, uint32_t *irq_num)
+{
+return spapr_allocate_irq(hint, irq_num, XICS_LSI);
+}
 
 static inline uint32_t rtas_ld(target_ulong phys, int n)
 {
diff --git a/hw/spapr_pci.c b/hw/spapr_pci.c
index c06afac..233250f 100644
--- a/hw/spapr_pci.c
+++ b/hw/spapr_pci.c
@@ -190,7 +190,7 @@ static int spapr_phb_init(SysBusDevice *s)
 qemu_irq qirq;
 uint32_t num;
 
-qirq = spapr_allocate_irq(0, &num);
+qirq = spapr_allocate_lsi(0, &num);
 if (!qirq) {
 return -1;
 }
diff --git a/hw/spapr_vio.c b/hw/spapr_vio.c
index 2fb3cee..dbf5a90 100644
--- a/hw/spapr_vio.c
+++ b/hw/spapr_vio.c
@@ -670,7 +670,7 @@ static int spapr_vio_busdev_init(DeviceState *qdev)
 dev->qdev.id = id;
 }
 
-dev->qirq = spapr_allocate_irq(dev->vio_irq_num, &dev->vio_irq_num);
+dev->qirq = spapr_allocate_msi(dev->vio_irq_num, &dev->vio_irq_num);
 if (!dev->qirq) {
 return -1;
 }
diff --git a/hw/xics.c b/hw/xics.c
index f7963f3..668a0d6 100644
--- a/hw/xics.c
+++ b/hw/xics.c
@@ -132,9 +132,9 @@ static void icp_eoi(struct icp_state *icp, int server, 
uint32_t xirr)
 {
 struct icp_server_state *ss = icp->ss + server;
 
-ics_eoi(icp->ics, xirr & XISR_MASK);
 /* Send EOI -> ICS */
 ss->xirr = (ss->xirr & ~CPPR_MASK) | (xirr & CPPR_MASK);
+ics_eoi(icp->ics, xirr & XISR_MASK);
 if (!XISR(ss)) {
 icp_resend(icp, server);
 }
@@ -165,8 +165,9 @@ struct ics_irq_state {
 int server;
 uint8_t priority;
 uint8_t saved_priority;
-/* int pending:1; */
-/* int presented:1; */
+enum xics_irq_type type;
+int asserted:1;
+int sent:1;
 int rejected:1;
 int masked_pending:1;
 };
@@ -185,9 +186,32 @@ static int ics_valid_irq(struct ics_state *ics, uint32_t 
nr)
 && (nr < (ics->offset + ics->nr_irqs));
 }
 
-static void ics_set_irq_msi(void *opaque, int srcno, int val)
+static void resend_msi(struct ics_state *ics, int srcno)
+{
+struct ics_irq_state *irq = ics->irqs + srcno;
+
+/* FIXME: filter by server#? */
+if (irq->rejected) {
+irq->rejected = 0;
+if (irq->priority != 0xff) {
+icp_irq(ics->icp, irq->server, srcno + ics->offset,
+irq->priority);
+}
+}
+}
+
+static void resend_lsi(struct ics_state *ics, int srcno)
+{
+struct ics_irq_state *irq = ics->irqs + srcno;
+
+if ((irq->priority != 0xff) && irq->asserted &

[Qemu-devel] [PATCH 0/9] qtest: a testing framework for devices (v3)

2012-03-15 Thread Anthony Liguori
Hi,

This is a combination of Paolo's qtest series and my original qtest series.

qtest provides a way to write tests against specific devices using the host
environment to interact with guests.

This also includes a patch from Stefan Weil that he asked me to include in this
series.




[Qemu-devel] [PATCH 8/9] qtest: add rtc-test test-case (v3)

2012-03-15 Thread Anthony Liguori
Signed-off-by: Anthony Liguori 
Signed-off-by: Paolo Bonzini 
---
v1 -> v2
 - fix set_alarm_time (Paolo)

v2 -> v3
 - merge IRQ intercept support (Paolo)
---
 tests/Makefile   |2 +-
 tests/rtc-test.c |  268 ++
 2 files changed, 269 insertions(+), 1 deletions(-)
 create mode 100644 tests/rtc-test.c

diff --git a/tests/Makefile b/tests/Makefile
index 254c06d..8c83207 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -15,7 +15,7 @@ CHECKS += test-string-output-visitor$(EXESUF)
 TEST_SCRIPTS = $(SRC_PATH)/tests/qemu-iotests-quick.sh
 
 
-HW_TESTS=
+HW_TESTS=tests/rtc-test
 
 TARGETS=$(patsubst %-softmmu,%, $(filter %-softmmu,$(TARGET_DIRS)))
 
diff --git a/tests/rtc-test.c b/tests/rtc-test.c
new file mode 100644
index 000..8280f45
--- /dev/null
+++ b/tests/rtc-test.c
@@ -0,0 +1,268 @@
+/*
+ * QTest
+ *
+ * Copyright IBM, Corp. 2012
+ *
+ * Authors:
+ *  Anthony Liguori   
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+#include "libqtest.h"
+#include "hw/mc146818rtc_regs.h"
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static uint8_t base = 0x70;
+
+static int bcd2dec(int value)
+{
+return (((value >> 4) & 0x0F) * 10) + (value & 0x0F);
+}
+
+static int dec2bcd(int value)
+{
+return ((value / 10) << 4) | (value % 10);
+}
+
+static uint8_t cmos_read(uint8_t reg)
+{
+outb(base + 0, reg);
+return inb(base + 1);
+}
+
+static void cmos_write(uint8_t reg, uint8_t val)
+{
+outb(base + 0, reg);
+outb(base + 1, val);
+}
+
+static int tm_cmp(struct tm *lhs, struct tm *rhs)
+{
+time_t a, b;
+struct tm d1, d2;
+
+memcpy(&d1, lhs, sizeof(d1));
+memcpy(&d2, rhs, sizeof(d2));
+
+a = mktime(&d1);
+b = mktime(&d2);
+
+if (a < b) {
+return -1;
+} else if (a > b) {
+return 1;
+}
+
+return 0;
+}
+
+#if 0
+static void print_tm(struct tm *tm)
+{
+printf("%04d-%02d-%02d %02d:%02d:%02d\n",
+   tm->tm_year + 1900, tm->tm_mon + 1, tm->tm_mday, 
+   tm->tm_hour, tm->tm_min, tm->tm_sec, tm->tm_gmtoff);
+}
+#endif
+
+static void cmos_get_date_time(struct tm *date)
+{
+int base_year = 2000, hour_offset;
+int sec, min, hour, mday, mon, year;
+time_t ts;
+struct tm dummy;
+
+sec = cmos_read(RTC_SECONDS);
+min = cmos_read(RTC_MINUTES);
+hour = cmos_read(RTC_HOURS);
+mday = cmos_read(RTC_DAY_OF_MONTH);
+mon = cmos_read(RTC_MONTH);
+year = cmos_read(RTC_YEAR);
+
+if ((cmos_read(RTC_REG_B) & REG_B_DM) == 0) {
+sec = bcd2dec(sec);
+min = bcd2dec(min);
+hour = bcd2dec(hour);
+mday = bcd2dec(mday);
+mon = bcd2dec(mon);
+year = bcd2dec(year);
+hour_offset = 80;
+} else {
+hour_offset = 0x80;
+}
+
+if ((cmos_read(0x0B) & REG_B_24H) == 0) {
+if (hour >= hour_offset) {
+hour -= hour_offset;
+hour += 12;
+}
+}
+
+ts = time(NULL);
+localtime_r(&ts, &dummy);
+
+date->tm_isdst = dummy.tm_isdst;
+date->tm_sec = sec;
+date->tm_min = min;
+date->tm_hour = hour;
+date->tm_mday = mday;
+date->tm_mon = mon - 1;
+date->tm_year = base_year + year - 1900;
+date->tm_gmtoff = 0;
+
+ts = mktime(date);
+}
+
+static void check_time(int wiggle)
+{
+struct tm start, date[4], end;
+struct tm *datep;
+time_t ts;
+
+/*
+ * This check assumes a few things.  First, we cannot guarantee that we get
+ * a consistent reading from the wall clock because we may hit an edge of
+ * the clock while reading.  To work around this, we read four clock 
readings
+ * such that at least two of them should match.  We need to assume that one
+ * reading is corrupt so we need four readings to ensure that we have at
+ * least two consecutive identical readings
+ *
+ * It's also possible that we'll cross an edge reading the host clock so
+ * simply check to make sure that the clock reading is within the period of
+ * when we expect it to be.
+ */
+
+ts = time(NULL);
+gmtime_r(&ts, &start);
+
+cmos_get_date_time(&date[0]);
+cmos_get_date_time(&date[1]);
+cmos_get_date_time(&date[2]);
+cmos_get_date_time(&date[3]);
+
+ts = time(NULL);
+gmtime_r(&ts, &end);
+
+if (tm_cmp(&date[0], &date[1]) == 0) {
+datep = &date[0];
+} else if (tm_cmp(&date[1], &date[2]) == 0) {
+datep = &date[1];
+} else if (tm_cmp(&date[2], &date[3]) == 0) {
+datep = &date[2];
+} else {
+g_assert_not_reached();
+}
+
+if (!(tm_cmp(&start, datep) <= 0 && tm_cmp(datep, &end) <= 0)) {
+time_t t, s;
+
+start.tm_isdst = datep->tm_isdst;
+
+t = mktime(datep);
+s = mktime(&start);
+if (t < s) {
+g_test_message("RTC is %ld second(s) behind wall-clock\n", (s - 
t));
+  

Re: [Qemu-devel] Debug single program in QEMU

2012-03-15 Thread Yue Chen
But it is hard to localize a specific program instead of lots of logs.
On Mar 15, 2012 4:14 AM, "陳韋任"  wrote:

> On Thu, Mar 15, 2012 at 01:26:44PM +0700, Mulyadi Santosa wrote:
> > On Thu, Mar 15, 2012 at 09:12, Yue Chen  wrote:
> > > Hi!~
> > >
> > > Now I'd like to see what the micro-ops (intermediate operations
> generated by
> > > TCG) of a single Linux or Windows program, any approach to do this
> under
> > > QEMU? Thanks.
> >
> > are you referring to you Qemu system emulation or Qemu user mode?
>
>  Does that matter? I think "-d op" should be enough, right?
>
> Regards,
> chenwj
>
> --
> Wei-Ren Chen (陳韋任)
> Computer Systems Lab, Institute of Information Science,
> Academia Sinica, Taiwan (R.O.C.)
> Tel:886-2-2788-3799 #1667
> Homepage: http://people.cs.nctu.edu.tw/~chenwj
>


[Qemu-devel] [PATCH 15/16] pseries: Configure PCI bridge using properties

2012-03-15 Thread Alexander Graf
From: David Gibson 

Currently, the function spapr_create_phb() uses its parameters to
initialize the correct memory windows for the new PCI Host Bridge
(PHB).  This is not the way things are supposed to be done with qdevs,
and means you can't create extra PHBs easily using -device.

Since pSeries machines can and do have many PHBs with various
configurations, this is a real limitation, not just a theoretical.
This patch, therefore, alters the PHB initialization code to use qdev
properties to set these parameters of the new bridge, moving most of
the code from spapr_create_phb() to spapr_phb_init().

While we're at it, we change the naming of each PCI bus and its
associated memory regions to be less arbitrary and make it easier to
relate the guest and qemu views of memory to each other.

Signed-off-by: Alexey Kardashevskiy 
Signed-off-by: David Gibson 
Reviewed-by: Andreas Färber 
Signed-off-by: Alexander Graf 
---
 hw/spapr_pci.c |  166 +++-
 hw/spapr_pci.h |4 +-
 2 files changed, 94 insertions(+), 76 deletions(-)

diff --git a/hw/spapr_pci.c b/hw/spapr_pci.c
index 233250f..e7ef551 100644
--- a/hw/spapr_pci.c
+++ b/hw/spapr_pci.c
@@ -180,49 +180,6 @@ static void pci_spapr_set_irq(void *opaque, int irq_num, 
int level)
 qemu_set_irq(phb->lsi_table[irq_num].qirq, level);
 }
 
-static int spapr_phb_init(SysBusDevice *s)
-{
-sPAPRPHBState *phb = FROM_SYSBUS(sPAPRPHBState, s);
-int i;
-
-/* Initialize the LSI table */
-for (i = 0; i < SPAPR_PCI_NUM_LSI; i++) {
-qemu_irq qirq;
-uint32_t num;
-
-qirq = spapr_allocate_lsi(0, &num);
-if (!qirq) {
-return -1;
-}
-
-phb->lsi_table[i].dt_irq = num;
-phb->lsi_table[i].qirq = qirq;
-}
-
-return 0;
-}
-
-static void spapr_phb_class_init(ObjectClass *klass, void *data)
-{
-SysBusDeviceClass *sdc = SYS_BUS_DEVICE_CLASS(klass);
-
-sdc->init = spapr_phb_init;
-}
-
-static TypeInfo spapr_phb_info = {
-.name  = "spapr-pci-host-bridge",
-.parent= TYPE_SYS_BUS_DEVICE,
-.instance_size = sizeof(sPAPRPHBState),
-.class_init= spapr_phb_class_init,
-};
-
-static void spapr_register_types(void)
-{
-type_register_static(&spapr_phb_info);
-}
-
-type_init(spapr_register_types)
-
 static uint64_t spapr_io_read(void *opaque, target_phys_addr_t addr,
   unsigned size)
 {
@@ -260,35 +217,29 @@ static const MemoryRegionOps spapr_io_ops = {
 .write = spapr_io_write
 };
 
-void spapr_create_phb(sPAPREnvironment *spapr,
-  const char *busname, uint64_t buid,
-  uint64_t mem_win_addr, uint64_t mem_win_size,
-  uint64_t io_win_addr)
+/*
+ * PHB PCI device
+ */
+static int spapr_phb_init(SysBusDevice *s)
 {
-DeviceState *dev;
-SysBusDevice *s;
-sPAPRPHBState *phb;
+sPAPRPHBState *phb = FROM_SYSBUS(sPAPRPHBState, s);
+char *namebuf;
+int i;
 PCIBus *bus;
-char namebuf[strlen(busname)+11];
 
-dev = qdev_create(NULL, "spapr-pci-host-bridge");
-qdev_init_nofail(dev);
-s = sysbus_from_qdev(dev);
-phb = FROM_SYSBUS(sPAPRPHBState, s);
+phb->dtbusname = g_strdup_printf("pci@%" PRIx64, phb->buid);
+namebuf = alloca(strlen(phb->dtbusname) + 32);
 
-phb->mem_win_addr = mem_win_addr;
-
-sprintf(namebuf, "%s-mem", busname);
+/* Initialize memory regions */
+sprintf(namebuf, "%s.mmio", phb->dtbusname);
 memory_region_init(&phb->memspace, namebuf, INT64_MAX);
 
-sprintf(namebuf, "%s-memwindow", busname);
+sprintf(namebuf, "%s.mmio-alias", phb->dtbusname);
 memory_region_init_alias(&phb->memwindow, namebuf, &phb->memspace,
- SPAPR_PCI_MEM_WIN_BUS_OFFSET, mem_win_size);
-memory_region_add_subregion(get_system_memory(), mem_win_addr,
+ SPAPR_PCI_MEM_WIN_BUS_OFFSET, phb->mem_win_size);
+memory_region_add_subregion(get_system_memory(), phb->mem_win_addr,
 &phb->memwindow);
 
-phb->io_win_addr = io_win_addr;
-
 /* On ppc, we only have MMIO no specific IO space from the CPU
  * perspective.  In theory we ought to be able to embed the PCI IO
  * memory region direction in the system memory space.  However,
@@ -297,33 +248,92 @@ void spapr_create_phb(sPAPREnvironment *spapr,
  * system io address space.  This hack to bounce things via
  * system_io works around the problem until all the users of
  * old_portion are updated */
-sprintf(namebuf, "%s-io", busname);
+sprintf(namebuf, "%s.io", phb->dtbusname);
 memory_region_init(&phb->iospace, namebuf, SPAPR_PCI_IO_WIN_SIZE);
 /* FIXME: fix to support multiple PHBs */
 memory_region_add_subregion(get_system_io(), 0, &phb->iospace);
 
-sprintf(namebuf, "%s-iowindow", busname);
+sprintf(namebuf, "%s.io-alias", phb->dtbusname);
 memory_region_init_io(&

[Qemu-devel] [PATCH 08/16] pseries: Remove PCI device from PCI host bridge code

2012-03-15 Thread Alexander Graf
From: Alexey Kardashevskiy 

The sPAPR PCI code defines a PCI device "spapr-pci-host-bridge-pci" which
is never used.  This came over from the earlier bridge driver we used as
a template.  Some other bridges appear on their own PCI bus as a device,
but that is not true of pSeries bridges, which are pure host to PCI with
no visible presence on the PCI side.

Signed-off-by: Alexey Kardashevskiy 
Signed-off-by: David Gibson 
Signed-off-by: Alexander Graf 
---
 hw/spapr_pci.c |   20 
 1 files changed, 0 insertions(+), 20 deletions(-)

diff --git a/hw/spapr_pci.c b/hw/spapr_pci.c
index 3d5e50a..c06afac 100644
--- a/hw/spapr_pci.c
+++ b/hw/spapr_pci.c
@@ -202,25 +202,6 @@ static int spapr_phb_init(SysBusDevice *s)
 return 0;
 }
 
-static int spapr_main_pci_host_init(PCIDevice *d)
-{
-return 0;
-}
-
-static void spapr_main_pci_host_class_init(ObjectClass *klass, void *data)
-{
-PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
-
-k->init = spapr_main_pci_host_init;
-}
-
-static TypeInfo spapr_main_pci_host_info = {
-.name  = "spapr-pci-host-bridge-pci",
-.parent= TYPE_PCI_DEVICE,
-.instance_size = sizeof(PCIDevice),
-.class_init= spapr_main_pci_host_class_init,
-};
-
 static void spapr_phb_class_init(ObjectClass *klass, void *data)
 {
 SysBusDeviceClass *sdc = SYS_BUS_DEVICE_CLASS(klass);
@@ -238,7 +219,6 @@ static TypeInfo spapr_phb_info = {
 static void spapr_register_types(void)
 {
 type_register_static(&spapr_phb_info);
-type_register_static(&spapr_main_pci_host_info);
 }
 
 type_init(spapr_register_types)
-- 
1.6.0.2




[Qemu-devel] [PATCH 7/9] rtc: split out macros into a header file and use in test case

2012-03-15 Thread Anthony Liguori
Signed-off-by: Anthony Liguori 
---
 hw/mc146818rtc.c  |   33 --
 hw/mc146818rtc.h  |3 +-
 hw/mc146818rtc_regs.h |   62 +
 3 files changed, 63 insertions(+), 35 deletions(-)
 create mode 100644 hw/mc146818rtc_regs.h

diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
index 2b59c36..9c64e0a 100644
--- a/hw/mc146818rtc.c
+++ b/hw/mc146818rtc.c
@@ -47,39 +47,6 @@
 
 #define RTC_REINJECT_ON_ACK_COUNT 20
 
-#define RTC_SECONDS 0
-#define RTC_SECONDS_ALARM   1
-#define RTC_MINUTES 2
-#define RTC_MINUTES_ALARM   3
-#define RTC_HOURS   4
-#define RTC_HOURS_ALARM 5
-#define RTC_ALARM_DONT_CARE0xC0
-
-#define RTC_DAY_OF_WEEK 6
-#define RTC_DAY_OF_MONTH7
-#define RTC_MONTH   8
-#define RTC_YEAR9
-
-#define RTC_REG_A   10
-#define RTC_REG_B   11
-#define RTC_REG_C   12
-#define RTC_REG_D   13
-
-#define REG_A_UIP 0x80
-
-#define REG_B_SET  0x80
-#define REG_B_PIE  0x40
-#define REG_B_AIE  0x20
-#define REG_B_UIE  0x10
-#define REG_B_SQWE 0x08
-#define REG_B_DM   0x04
-#define REG_B_24H  0x02
-
-#define REG_C_UF   0x10
-#define REG_C_IRQF 0x80
-#define REG_C_PF   0x40
-#define REG_C_AF   0x20
-
 typedef struct RTCState {
 ISADevice dev;
 MemoryRegion io;
diff --git a/hw/mc146818rtc.h b/hw/mc146818rtc.h
index f119930..f286b6a 100644
--- a/hw/mc146818rtc.h
+++ b/hw/mc146818rtc.h
@@ -2,8 +2,7 @@
 #define MC146818RTC_H
 
 #include "isa.h"
-
-#define RTC_ISA_IRQ 8
+#include "mc146818rtc_regs.h"
 
 ISADevice *rtc_init(ISABus *bus, int base_year, qemu_irq intercept_irq);
 void rtc_set_memory(ISADevice *dev, int addr, int val);
diff --git a/hw/mc146818rtc_regs.h b/hw/mc146818rtc_regs.h
new file mode 100644
index 000..3ab3770
--- /dev/null
+++ b/hw/mc146818rtc_regs.h
@@ -0,0 +1,62 @@
+/*
+ * QEMU MC146818 RTC emulation
+ *
+ * Copyright (c) 2003-2004 Fabrice Bellard
+ *
+ * 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.
+ */
+#ifndef RTC_REGS_H
+#define RTC_REGS_H
+
+#define RTC_ISA_IRQ 8
+
+#define RTC_SECONDS 0
+#define RTC_SECONDS_ALARM   1
+#define RTC_MINUTES 2
+#define RTC_MINUTES_ALARM   3
+#define RTC_HOURS   4
+#define RTC_HOURS_ALARM 5
+#define RTC_ALARM_DONT_CARE0xC0
+
+#define RTC_DAY_OF_WEEK 6
+#define RTC_DAY_OF_MONTH7
+#define RTC_MONTH   8
+#define RTC_YEAR9
+
+#define RTC_REG_A   10
+#define RTC_REG_B   11
+#define RTC_REG_C   12
+#define RTC_REG_D   13
+
+#define REG_A_UIP 0x80
+
+#define REG_B_SET  0x80
+#define REG_B_PIE  0x40
+#define REG_B_AIE  0x20
+#define REG_B_UIE  0x10
+#define REG_B_SQWE 0x08
+#define REG_B_DM   0x04
+#define REG_B_24H  0x02
+
+#define REG_C_UF   0x10
+#define REG_C_IRQF 0x80
+#define REG_C_PF   0x40
+#define REG_C_AF   0x20
+
+#endif
-- 
1.7.5.4




  1   2   3   >