Re: [Qemu-devel] [PATCH 1/5] i8259: qdev-ify creation
On 2012-01-12 08:58, Alexander Graf wrote:
On 12.01.2012, at 08:35, Jan Kiszka wrote:
On 2012-01-12 01:04, Andreas Färber wrote:
Alex,
I have this in my mailbox, but I'm still waiting for an SoB. Hervé?
Regards,
Andreas
Original-Nachricht
Betreff: [PATCH 1/5] i8259: qdev-ify creation
Datum: Sun, 26 Jun 2011 14:47:09 +0200
Von: Hervé Poussineau hpous...@reactos.org
An: andreas.faer...@web.de
Kopie (CC): Hervé Poussineau hpous...@reactos.org
---
hw/i8259.c | 53 +
1 files changed, 49 insertions(+), 4 deletions(-)
diff --git a/hw/i8259.c b/hw/i8259.c
index 84d330d..59e8bd6 100644
--- a/hw/i8259.c
+++ b/hw/i8259.c
@@ -26,6 +26,7 @@
#include isa.h
#include monitor.h
#include qemu-timer.h
+#include sysbus.h
/* debug PIC */
//#define DEBUG_PIC
@@ -524,16 +525,60 @@ void irq_info(Monitor *mon)
qemu_irq *i8259_init(qemu_irq parent_irq)
{
-PicState2 *s;
+DeviceState *dev;
+dev = qdev_create(NULL, i8259);
+qdev_init_nofail(dev);
+qdev_connect_gpio_out(dev, 0, parent_irq);
+
+return dev-gpio_in;
+}
+
+typedef struct SysBusPicState2 {
+SysBusDevice busdev;
+PicState2 state;
+} SysBusPicState2;
+
+static void i8259_set_irq_sysbus(void *opaque, int line, int level)
+{
+SysBusPicState2 *sysbus = opaque;
+PicState2 *s = sysbus-state;
+i8259_set_irq(s, line, level);
+}
+
+static int i8259_sysbus_init(SysBusDevice *dev)
+{
+SysBusPicState2 *sysbus = FROM_SYSBUS(SysBusPicState2, dev);
+PicState2 *s = sysbus-state;
+
+if (isa_pic) {
+return 1;
+}
-s = qemu_mallocz(sizeof(PicState2));
pic_init1(0x20, 0x4d0, s-pics[0]);
pic_init1(0xa0, 0x4d1, s-pics[1]);
s-pics[0].elcr_mask = 0xf8;
s-pics[1].elcr_mask = 0xde;
-s-parent_irq = parent_irq;
s-pics[0].pics_state = s;
s-pics[1].pics_state = s;
isa_pic = s;
-return qemu_allocate_irqs(i8259_set_irq, s, 16);
+
+qdev_init_gpio_in(dev-qdev, i8259_set_irq_sysbus, 16);
+qdev_init_gpio_out(dev-qdev, s-parent_irq, 1);
+return 0;
+}
+
+static SysBusDeviceInfo i8259_sysbus_info = {
+.qdev.name = i8259,
+.qdev.size = sizeof(SysBusPicState2),
+.init = i8259_sysbus_init,
+.qdev.props = (Property[]) {
+DEFINE_PROP_END_OF_LIST()
+},
+};
+
+static void i8259_register_devices(void)
+{
+ sysbus_register_withprop(i8259_sysbus_info);
}
+
+device_init(i8259_register_devices)
This is obsolete. The i8259 has been significantly refactored (into two
ISA devices) and qdev'ified some moons ago.
The reason we were discussing this was a circular dependency on PREP.
The PIC is sitting on the ISA bus.
The ISA bus is behind a PCI-ISA bridge
the PCI-ISA bridge is behind a PCI host controller
the PCI host controller needs interrupt lines in its initialization which are
attached to the PIC
Any good ideas on how to resolve this? :)
As we do this always: Split up initialization and IRQ line wiring.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH 1/5] i8259: qdev-ify creation
On 12.01.2012, at 09:00, Jan Kiszka wrote:
On 2012-01-12 08:58, Alexander Graf wrote:
On 12.01.2012, at 08:35, Jan Kiszka wrote:
On 2012-01-12 01:04, Andreas Färber wrote:
Alex,
I have this in my mailbox, but I'm still waiting for an SoB. Hervé?
Regards,
Andreas
Original-Nachricht
Betreff: [PATCH 1/5] i8259: qdev-ify creation
Datum: Sun, 26 Jun 2011 14:47:09 +0200
Von: Hervé Poussineau hpous...@reactos.org
An: andreas.faer...@web.de
Kopie (CC): Hervé Poussineau hpous...@reactos.org
---
hw/i8259.c | 53 +
1 files changed, 49 insertions(+), 4 deletions(-)
diff --git a/hw/i8259.c b/hw/i8259.c
index 84d330d..59e8bd6 100644
--- a/hw/i8259.c
+++ b/hw/i8259.c
@@ -26,6 +26,7 @@
#include isa.h
#include monitor.h
#include qemu-timer.h
+#include sysbus.h
/* debug PIC */
//#define DEBUG_PIC
@@ -524,16 +525,60 @@ void irq_info(Monitor *mon)
qemu_irq *i8259_init(qemu_irq parent_irq)
{
-PicState2 *s;
+DeviceState *dev;
+dev = qdev_create(NULL, i8259);
+qdev_init_nofail(dev);
+qdev_connect_gpio_out(dev, 0, parent_irq);
+
+return dev-gpio_in;
+}
+
+typedef struct SysBusPicState2 {
+SysBusDevice busdev;
+PicState2 state;
+} SysBusPicState2;
+
+static void i8259_set_irq_sysbus(void *opaque, int line, int level)
+{
+SysBusPicState2 *sysbus = opaque;
+PicState2 *s = sysbus-state;
+i8259_set_irq(s, line, level);
+}
+
+static int i8259_sysbus_init(SysBusDevice *dev)
+{
+SysBusPicState2 *sysbus = FROM_SYSBUS(SysBusPicState2, dev);
+PicState2 *s = sysbus-state;
+
+if (isa_pic) {
+return 1;
+}
-s = qemu_mallocz(sizeof(PicState2));
pic_init1(0x20, 0x4d0, s-pics[0]);
pic_init1(0xa0, 0x4d1, s-pics[1]);
s-pics[0].elcr_mask = 0xf8;
s-pics[1].elcr_mask = 0xde;
-s-parent_irq = parent_irq;
s-pics[0].pics_state = s;
s-pics[1].pics_state = s;
isa_pic = s;
-return qemu_allocate_irqs(i8259_set_irq, s, 16);
+
+qdev_init_gpio_in(dev-qdev, i8259_set_irq_sysbus, 16);
+qdev_init_gpio_out(dev-qdev, s-parent_irq, 1);
+return 0;
+}
+
+static SysBusDeviceInfo i8259_sysbus_info = {
+.qdev.name = i8259,
+.qdev.size = sizeof(SysBusPicState2),
+.init = i8259_sysbus_init,
+.qdev.props = (Property[]) {
+DEFINE_PROP_END_OF_LIST()
+},
+};
+
+static void i8259_register_devices(void)
+{
+ sysbus_register_withprop(i8259_sysbus_info);
}
+
+device_init(i8259_register_devices)
This is obsolete. The i8259 has been significantly refactored (into two
ISA devices) and qdev'ified some moons ago.
The reason we were discussing this was a circular dependency on PREP.
The PIC is sitting on the ISA bus.
The ISA bus is behind a PCI-ISA bridge
the PCI-ISA bridge is behind a PCI host controller
the PCI host controller needs interrupt lines in its initialization which
are attached to the PIC
Any good ideas on how to resolve this? :)
As we do this always: Split up initialization and IRQ line wiring.
Well, yes, the theory is obvious. How would this look like in practice? To
create a PIC device I need a bus:
dev = isa_create(bus, isa-i8259);
But to create the bus, I need an interrupt line, which I only get after I
created the PIC device.
Alex
Re: [Qemu-devel] [PATCH 1/5] i8259: qdev-ify creation
On 2012-01-12 09:05, Alexander Graf wrote:
On 12.01.2012, at 09:00, Jan Kiszka wrote:
On 2012-01-12 08:58, Alexander Graf wrote:
On 12.01.2012, at 08:35, Jan Kiszka wrote:
On 2012-01-12 01:04, Andreas Färber wrote:
Alex,
I have this in my mailbox, but I'm still waiting for an SoB. Hervé?
Regards,
Andreas
Original-Nachricht
Betreff: [PATCH 1/5] i8259: qdev-ify creation
Datum: Sun, 26 Jun 2011 14:47:09 +0200
Von: Hervé Poussineau hpous...@reactos.org
An: andreas.faer...@web.de
Kopie (CC): Hervé Poussineau hpous...@reactos.org
---
hw/i8259.c | 53 +
1 files changed, 49 insertions(+), 4 deletions(-)
diff --git a/hw/i8259.c b/hw/i8259.c
index 84d330d..59e8bd6 100644
--- a/hw/i8259.c
+++ b/hw/i8259.c
@@ -26,6 +26,7 @@
#include isa.h
#include monitor.h
#include qemu-timer.h
+#include sysbus.h
/* debug PIC */
//#define DEBUG_PIC
@@ -524,16 +525,60 @@ void irq_info(Monitor *mon)
qemu_irq *i8259_init(qemu_irq parent_irq)
{
-PicState2 *s;
+DeviceState *dev;
+dev = qdev_create(NULL, i8259);
+qdev_init_nofail(dev);
+qdev_connect_gpio_out(dev, 0, parent_irq);
+
+return dev-gpio_in;
+}
+
+typedef struct SysBusPicState2 {
+SysBusDevice busdev;
+PicState2 state;
+} SysBusPicState2;
+
+static void i8259_set_irq_sysbus(void *opaque, int line, int level)
+{
+SysBusPicState2 *sysbus = opaque;
+PicState2 *s = sysbus-state;
+i8259_set_irq(s, line, level);
+}
+
+static int i8259_sysbus_init(SysBusDevice *dev)
+{
+SysBusPicState2 *sysbus = FROM_SYSBUS(SysBusPicState2, dev);
+PicState2 *s = sysbus-state;
+
+if (isa_pic) {
+return 1;
+}
-s = qemu_mallocz(sizeof(PicState2));
pic_init1(0x20, 0x4d0, s-pics[0]);
pic_init1(0xa0, 0x4d1, s-pics[1]);
s-pics[0].elcr_mask = 0xf8;
s-pics[1].elcr_mask = 0xde;
-s-parent_irq = parent_irq;
s-pics[0].pics_state = s;
s-pics[1].pics_state = s;
isa_pic = s;
-return qemu_allocate_irqs(i8259_set_irq, s, 16);
+
+qdev_init_gpio_in(dev-qdev, i8259_set_irq_sysbus, 16);
+qdev_init_gpio_out(dev-qdev, s-parent_irq, 1);
+return 0;
+}
+
+static SysBusDeviceInfo i8259_sysbus_info = {
+.qdev.name = i8259,
+.qdev.size = sizeof(SysBusPicState2),
+.init = i8259_sysbus_init,
+.qdev.props = (Property[]) {
+DEFINE_PROP_END_OF_LIST()
+},
+};
+
+static void i8259_register_devices(void)
+{
+ sysbus_register_withprop(i8259_sysbus_info);
}
+
+device_init(i8259_register_devices)
This is obsolete. The i8259 has been significantly refactored (into two
ISA devices) and qdev'ified some moons ago.
The reason we were discussing this was a circular dependency on PREP.
The PIC is sitting on the ISA bus.
The ISA bus is behind a PCI-ISA bridge
the PCI-ISA bridge is behind a PCI host controller
the PCI host controller needs interrupt lines in its initialization which
are attached to the PIC
Any good ideas on how to resolve this? :)
As we do this always: Split up initialization and IRQ line wiring.
Well, yes, the theory is obvious. How would this look like in practice? To
create a PIC device I need a bus:
dev = isa_create(bus, isa-i8259);
But to create the bus, I need an interrupt line, which I only get after I
created the PIC device.
ISA bus creation and IRQ assignment are split up IIRC.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH 1/5] i8259: qdev-ify creation
On 12.01.2012, at 09:09, Jan Kiszka wrote:
On 2012-01-12 09:05, Alexander Graf wrote:
On 12.01.2012, at 09:00, Jan Kiszka wrote:
On 2012-01-12 08:58, Alexander Graf wrote:
On 12.01.2012, at 08:35, Jan Kiszka wrote:
On 2012-01-12 01:04, Andreas Färber wrote:
Alex,
I have this in my mailbox, but I'm still waiting for an SoB. Hervé?
Regards,
Andreas
Original-Nachricht
Betreff: [PATCH 1/5] i8259: qdev-ify creation
Datum: Sun, 26 Jun 2011 14:47:09 +0200
Von: Hervé Poussineau hpous...@reactos.org
An: andreas.faer...@web.de
Kopie (CC): Hervé Poussineau hpous...@reactos.org
---
hw/i8259.c | 53 +
1 files changed, 49 insertions(+), 4 deletions(-)
diff --git a/hw/i8259.c b/hw/i8259.c
index 84d330d..59e8bd6 100644
--- a/hw/i8259.c
+++ b/hw/i8259.c
@@ -26,6 +26,7 @@
#include isa.h
#include monitor.h
#include qemu-timer.h
+#include sysbus.h
/* debug PIC */
//#define DEBUG_PIC
@@ -524,16 +525,60 @@ void irq_info(Monitor *mon)
qemu_irq *i8259_init(qemu_irq parent_irq)
{
-PicState2 *s;
+DeviceState *dev;
+dev = qdev_create(NULL, i8259);
+qdev_init_nofail(dev);
+qdev_connect_gpio_out(dev, 0, parent_irq);
+
+return dev-gpio_in;
+}
+
+typedef struct SysBusPicState2 {
+SysBusDevice busdev;
+PicState2 state;
+} SysBusPicState2;
+
+static void i8259_set_irq_sysbus(void *opaque, int line, int level)
+{
+SysBusPicState2 *sysbus = opaque;
+PicState2 *s = sysbus-state;
+i8259_set_irq(s, line, level);
+}
+
+static int i8259_sysbus_init(SysBusDevice *dev)
+{
+SysBusPicState2 *sysbus = FROM_SYSBUS(SysBusPicState2, dev);
+PicState2 *s = sysbus-state;
+
+if (isa_pic) {
+return 1;
+}
-s = qemu_mallocz(sizeof(PicState2));
pic_init1(0x20, 0x4d0, s-pics[0]);
pic_init1(0xa0, 0x4d1, s-pics[1]);
s-pics[0].elcr_mask = 0xf8;
s-pics[1].elcr_mask = 0xde;
-s-parent_irq = parent_irq;
s-pics[0].pics_state = s;
s-pics[1].pics_state = s;
isa_pic = s;
-return qemu_allocate_irqs(i8259_set_irq, s, 16);
+
+qdev_init_gpio_in(dev-qdev, i8259_set_irq_sysbus, 16);
+qdev_init_gpio_out(dev-qdev, s-parent_irq, 1);
+return 0;
+}
+
+static SysBusDeviceInfo i8259_sysbus_info = {
+.qdev.name = i8259,
+.qdev.size = sizeof(SysBusPicState2),
+.init = i8259_sysbus_init,
+.qdev.props = (Property[]) {
+DEFINE_PROP_END_OF_LIST()
+},
+};
+
+static void i8259_register_devices(void)
+{
+ sysbus_register_withprop(i8259_sysbus_info);
}
+
+device_init(i8259_register_devices)
This is obsolete. The i8259 has been significantly refactored (into two
ISA devices) and qdev'ified some moons ago.
The reason we were discussing this was a circular dependency on PREP.
The PIC is sitting on the ISA bus.
The ISA bus is behind a PCI-ISA bridge
the PCI-ISA bridge is behind a PCI host controller
the PCI host controller needs interrupt lines in its initialization which
are attached to the PIC
Any good ideas on how to resolve this? :)
As we do this always: Split up initialization and IRQ line wiring.
Well, yes, the theory is obvious. How would this look like in practice? To
create a PIC device I need a bus:
dev = isa_create(bus, isa-i8259);
But to create the bus, I need an interrupt line, which I only get after I
created the PIC device.
ISA bus creation and IRQ assignment are split up IIRC.
So you're saying we should do the same for PCI?
To create an ISA bus that sits behind a PCI device I first need to create a PCI
bus which is exposed by the host bridge which then again needs interrupt lines.
I'm still puzzled how we would pass on irq lines then. I mean setting them
after init means that during init we can't instantiate other devices that we
can wire up to anything, right?
Alex
[Qemu-devel] [PATCH v6 07/10] ARM: exynos4210: MCT support.
Signed-off-by: Evgeny Voevodin e.voevo...@samsung.com
---
Makefile.target |1 +
hw/exynos4210.c | 19 +
hw/exynos4210_mct.c | 1479 +++
3 files changed, 1499 insertions(+), 0 deletions(-)
create mode 100644 hw/exynos4210_mct.c
diff --git a/Makefile.target b/Makefile.target
index 1914870..2e46ce3 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -341,6 +341,7 @@ obj-arm-y += versatile_pci.o
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_mct.o
obj-arm-y += arm_l2x0.o
obj-arm-y += arm_mptimer.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 48f4f65..707c619 100644
--- a/hw/exynos4210.c
+++ b/hw/exynos4210.c
@@ -32,6 +32,9 @@
/* PWM */
#define EXYNOS4210_PWM_BASE_ADDR 0x139D
+/* MCT */
+#define EXYNOS4210_MCT_BASE_ADDR 0x1005
+
/* UART's definitions */
#define EXYNOS4210_UART0_BASE_ADDR 0x1380
#define EXYNOS4210_UART1_BASE_ADDR 0x1381
@@ -222,6 +225,22 @@ Exynos4210State *exynos4210_init(MemoryRegion *system_mem,
irq_table[exynos4210_get_irq(22, 4)],
NULL);
+/* Multi Core Timer */
+dev = qdev_create(NULL, exynos4210.mct);
+qdev_init_nofail(dev);
+busdev = sysbus_from_qdev(dev);
+for (n = 0; n 4; n++) {
+/* Connect global timer interrupts to Combiner gpio_in */
+sysbus_connect_irq(busdev, n,
+irq_table[exynos4210_get_irq(1, 4 + n)]);
+}
+/* Connect local timer interrupts to Combiner gpio_in */
+sysbus_connect_irq(busdev, 4,
+irq_table[exynos4210_get_irq(51, 0)]);
+sysbus_connect_irq(busdev, 5,
+irq_table[exynos4210_get_irq(35, 3)]);
+sysbus_mmio_map(busdev, 0, EXYNOS4210_MCT_BASE_ADDR);
+
/*** UARTs ***/
exynos4210_uart_create(EXYNOS4210_UART0_BASE_ADDR,
EXYNOS4210_UART0_FIFO_SIZE, 0, NULL,
diff --git a/hw/exynos4210_mct.c b/hw/exynos4210_mct.c
new file mode 100644
index 000..1d44e10
--- /dev/null
+++ b/hw/exynos4210_mct.c
@@ -0,0 +1,1479 @@
+/*
+ * Samsung exynos4210 Multi Core timer
+ *
+ * Copyright (c) 2000 - 2011 Samsung Electronics Co., Ltd.
+ * All rights reserved.
+ *
+ * Evgeny Voevodin e.voevo...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ * See the GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see http://www.gnu.org/licenses/.
+ */
+
+/*
+ * Global Timer:
+ *
+ * Consists of two timers. First represents Free Running Counter and second
+ * is used to measure interval from FRC to nearest comparator.
+ *
+ *0
UINT64_MAX
+ *| timer0 |
+ *| -- |
+ *| frc--- |
+ *|__|__|
+ *CMP0 CMP1 CMP2| CMP3
+ * __||_
+ * | timer1 |
+ * | - |
+ *frc CMPx
+ *
+ * Problem: when implementing global timer as is, overflow arises.
+ * next_time = cur_time + period * count;
+ * period and count are 64 bits width.
+ * Lets arm timer for MCT_GT_COUNTER_STEP count and update internal G_CNT
+ * register during each event.
+ *
+ * Problem: both timers need to be implemented using MCT_XT_COUNTER_STEP
because
+ * local timer contains two counters: TCNT and ICNT. TCNT == 0 - ICNT--.
+ * IRQ is generated when ICNT riches zero. Implementation where TCNT == 0
+ * generates IRQs suffers from too frequently events. Better to have one
+ * uint64_t counter equal to TCNT*ICNT and arm ptimer.c for a
minimum(TCNT*ICNT,
+ * MCT_GT_COUNTER_STEP); (yes, if target tunes ICNT * TCNT to be too low
values,
+ * there is no way to avoid frequently events).
+ */
+
+#include sysbus.h
+#include qemu-timer.h
+#include qemu-common.h
+#include osdep.h
+
+#include
[Qemu-devel] [PATCH v6 02/10] hw/arm_boot.c: Make SMP boards specify address to poll in bootup loop
The secondary CPU bootloader in arm_boot.c holds secondary CPUs in a
pen until the primary CPU releases them. Make boards specify the
address to be polled to determine whether to leave the pen (it was
previously hardcoded to 0x1030, which is a Versatile Express/
Realview specific system register address).
Signed-off-by: Evgeny Voevodin e.voevo...@samsung.com
---
hw/arm-misc.h |1 +
hw/arm_boot.c | 18 ++
hw/realview.c |2 ++
hw/vexpress.c |2 ++
4 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/hw/arm-misc.h b/hw/arm-misc.h
index af403a1..6e8ae6b 100644
--- a/hw/arm-misc.h
+++ b/hw/arm-misc.h
@@ -31,6 +31,7 @@ struct arm_boot_info {
const char *initrd_filename;
target_phys_addr_t loader_start;
target_phys_addr_t smp_loader_start;
+target_phys_addr_t smp_bootreg_addr;
target_phys_addr_t smp_priv_base;
int nb_cpus;
int board_id;
diff --git a/hw/arm_boot.c b/hw/arm_boot.c
index 215d5de..bf509a8 100644
--- a/hw/arm_boot.c
+++ b/hw/arm_boot.c
@@ -31,17 +31,17 @@ static uint32_t bootloader[] = {
/* Entry point for secondary CPUs. Enable interrupt controller and
Issue WFI until start address is written to system controller. */
static uint32_t smpboot[] = {
- 0xe59f0020, /* ldr r0, privbase */
- 0xe3a01001, /* mov r1, #1 */
- 0xe5801100, /* str r1, [r0, #0x100] */
- 0xe3a00201, /* mov r0, #0x1000 */
- 0xe3800030, /* orr r0, #0x30 */
+ 0xe59f201c, /* ldr r2, privbase */
+ 0xe59f001c, /* ldr r0, startaddr */
+ 0xe3a01001, /* mov r1, #1 */
+ 0xe5821100, /* str r1, [r2, #256] */
0xe320f003, /* wfi */
0xe5901000, /* ldr r1, [r0] */
0xe1110001, /* tst r1, r1 */
0x0afb, /* beq wfi */
0xe12fff11, /* bx r1 */
- 0 /* privbase: Private memory region base address. */
+ 0, /* privbase: Private memory region base address. */
+ 0 /* bootreg: Boot register address is held here */
};
#define WRITE_WORD(p, value) do { \
@@ -197,6 +197,7 @@ static void do_cpu_reset(void *opaque)
info-loader_start);
}
} else {
+stl_phys_notdirty(info-smp_bootreg_addr, 0);
env-regs[15] = info-smp_loader_start;
}
}
@@ -272,8 +273,9 @@ void arm_load_kernel(CPUState *env, struct arm_boot_info
*info)
rom_add_blob_fixed(bootloader, bootloader, sizeof(bootloader),
info-loader_start);
if (info-nb_cpus 1) {
-smpboot[10] = info-smp_priv_base;
-for (n = 0; n sizeof(smpboot) / 4; n++) {
+smpboot[ARRAY_SIZE(smpboot) - 1] = info-smp_bootreg_addr;
+smpboot[ARRAY_SIZE(smpboot) - 2] = info-smp_priv_base;
+for (n = 0; n ARRAY_SIZE(smpboot); n++) {
smpboot[n] = tswap32(smpboot[n]);
}
rom_add_blob_fixed(smpboot, smpboot, sizeof(smpboot),
diff --git a/hw/realview.c b/hw/realview.c
index d4191e9..3f35118 100644
--- a/hw/realview.c
+++ b/hw/realview.c
@@ -21,6 +21,7 @@
#include exec-memory.h
#define SMP_BOOT_ADDR 0xe000
+#define SMP_BOOTREG_ADDR 0x1030
typedef struct {
SysBusDevice busdev;
@@ -96,6 +97,7 @@ static void realview_register_devices(void)
static struct arm_boot_info realview_binfo = {
.smp_loader_start = SMP_BOOT_ADDR,
+.smp_bootreg_addr = SMP_BOOTREG_ADDR,
};
/* The following two lists must be consistent. */
diff --git a/hw/vexpress.c b/hw/vexpress.c
index c9ca43c..abdca14 100644
--- a/hw/vexpress.c
+++ b/hw/vexpress.c
@@ -28,11 +28,13 @@
#include exec-memory.h
#define SMP_BOOT_ADDR 0xe000
+#define SMP_BOOTREG_ADDR 0x1030
#define VEXPRESS_BOARD_ID 0x8e0
static struct arm_boot_info vexpress_binfo = {
.smp_loader_start = SMP_BOOT_ADDR,
+.smp_bootreg_addr = SMP_BOOTREG_ADDR,
};
static void vexpress_a9_init(ram_addr_t ram_size,
--
1.7.4.1
[Qemu-devel] [PATCH v6 09/10] hw/exynos4210.c: Add LAN support for SMDKC210.
SMDKC210 uses lan9215 chip, but lan9118 in 16-bit mode seems to
be enough.
Signed-off-by: Evgeny Voevodin e.voevo...@samsung.com
---
hw/exynos4_boards.c | 27 +--
1 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/hw/exynos4_boards.c b/hw/exynos4_boards.c
index b8fc5b6..56fd9a3 100644
--- a/hw/exynos4_boards.c
+++ b/hw/exynos4_boards.c
@@ -23,6 +23,7 @@
#include sysemu.h
#include sysbus.h
+#include net.h
#include arm-misc.h
#include exec-memory.h
#include exynos4210.h
@@ -42,6 +43,8 @@
#define PRINT_DEBUG(fmt, args...) do {} while (0)
#endif
+#define SMDK_LAN9118_BASE_ADDR 0x0500
+
typedef enum exynos4_board_type {
EXYNOS4_BOARD_NURI,
EXYNOS4_BOARD_SMDKC210,
@@ -68,6 +71,24 @@ static struct arm_boot_info exynos4_board_binfo = {
.smp_loader_start = EXYNOS4210_SMP_BOOT_ADDR,
};
+static void lan9215_init(uint32_t base, qemu_irq irq)
+{
+DeviceState *dev;
+SysBusDevice *s;
+
+/* This should be a 9215 but the 9118 is close enough */
+if (nd_table[0].vlan) {
+qemu_check_nic_model(nd_table[0], lan9118);
+dev = qdev_create(NULL, lan9118);
+qdev_set_nic_properties(dev, nd_table[0]);
+qdev_prop_set_uint32(dev, mode_16bit, 1);
+qdev_init_nofail(dev);
+s = sysbus_from_qdev(dev);
+sysbus_mmio_map(s, 0, base);
+sysbus_connect_irq(s, 0, irq);
+}
+}
+
static Exynos4210State *exynos4_boards_init_common(
const char *kernel_filename,
const char *kernel_cmdline,
@@ -114,9 +135,11 @@ static void smdkc210_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_SMDKC210);
+Exynos4210State *s = exynos4_boards_init_common(kernel_filename,
+kernel_cmdline, initrd_filename, EXYNOS4_BOARD_SMDKC210);
+lan9215_init(SMDK_LAN9118_BASE_ADDR,
+qemu_irq_invert(s-irq_table[exynos4210_get_irq(37, 1)]));
arm_load_kernel(first_cpu, exynos4_board_binfo);
}
--
1.7.4.1
Re: [Qemu-devel] [PATCH v6 04/10] ARM: Samsung exynos4210-based boards emulation
On 1/12/12, Evgeny Voevodin e.voevo...@samsung.com wrote:
Add initial support of NURI and SMDKC210 boards
Signed-off-by: Evgeny Voevodin e.voevo...@samsung.com
---
Makefile.target |3 +-
hw/exynos4210.c | 202
+++
hw/exynos4210.h | 37 +
hw/exynos4_boards.c | 143
4 files changed, 384 insertions(+), 1 deletions(-)
create mode 100644 hw/exynos4210.c
create mode 100644 hw/exynos4_boards.c
diff --git a/Makefile.target b/Makefile.target
index 4ac257e..6199d44 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -339,7 +339,8 @@ obj-arm-y = integratorcp.o versatilepb.o arm_pic.o
arm_timer.o
obj-arm-y += arm_boot.o pl011.o pl031.o pl050.o pl080.o pl110.o pl181.o
pl190.o
obj-arm-y += versatile_pci.o
obj-arm-y += realview_gic.o realview.o arm_sysctl.o arm11mpcore.o
a9mpcore.o
-obj-arm-y += exynos4210_gic.o exynos4210_combiner.o
+obj-arm-y += exynos4210_gic.o exynos4210_combiner.o exynos4210.o
+obj-arm-y += exynos4_boards.o
obj-arm-y += arm_l2x0.o
obj-arm-y += arm_mptimer.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
new file mode 100644
index 000..82755db
--- /dev/null
+++ b/hw/exynos4210.c
@@ -0,0 +1,202 @@
+/*
+ * Samsung exynos4210 SoC emulation
+ *
+ * Copyright (c) 2011 Samsung Electronics Co., Ltd. All rights reserved.
+ *Maksim Kozlov m.koz...@samsung.com
+ *Evgeny Voevodin e.voevo...@samsung.com
+ *Igor Mitsyanko i.mitsya...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see http://www.gnu.org/licenses/.
+ *
+ */
+
+#include boards.h
+#include sysemu.h
+#include sysbus.h
+#include arm-misc.h
+#include exynos4210.h
+
+#define EXYNOS4210_CHIPID_ADDR 0x1000
+
+/* External GIC */
+#define EXYNOS4210_EXT_GIC_CPU_BASE_ADDR0x1048
+#define EXYNOS4210_EXT_GIC_DIST_BASE_ADDR 0x1049
+
+/* Combiner */
+#define EXYNOS4210_EXT_COMBINER_BASE_ADDR 0x1044
+#define EXYNOS4210_INT_COMBINER_BASE_ADDR 0x10448000
FYI: Even though there's internal combiner, it doesn't used any more.
and there's no codes at kernel.
Thank you,
Kyungmin Park
+
+static uint8_t chipid_and_omr[] = { 0x11, 0x02, 0x21, 0x43,
+0x09, 0x00, 0x00, 0x00 };
+
+Exynos4210State *exynos4210_init(MemoryRegion *system_mem,
+unsigned long ram_size)
+{
+qemu_irq cpu_irq[4];
+int n;
+Exynos4210State *s = g_new(Exynos4210State, 1);
+qemu_irq *irq_table;
+qemu_irq *irqp;
+qemu_irq gate_irq[EXYNOS4210_IRQ_GATE_NINPUTS];
+unsigned long mem_size;
+DeviceState *dev;
+SysBusDevice *busdev;
+
+for (n = 0; n smp_cpus; n++) {
+s-env[n] = cpu_init(cortex-a9);
+if (!s-env[n]) {
+fprintf(stderr, Unable to find CPU %d definition\n, n);
+exit(1);
+}
+/* Create PIC controller for each processor instance */
+irqp = arm_pic_init_cpu(s-env[n]);
+
+/*
+ * Get GICs gpio_in cpu_irq to connect a combiner to them later.
+ * Use only IRQ for a while.
+ */
+cpu_irq[n] = irqp[ARM_PIC_CPU_IRQ];
+}
+
+/*** IRQs ***/
+
+s-irq_table = exynos4210_init_irq(s-irqs);
+irq_table = s-irq_table;
+
+/* IRQ Gate */
+dev = qdev_create(NULL, exynos4210.irq_gate);
+qdev_init_nofail(dev);
+/* Get IRQ Gate input in gate_irq */
+for (n = 0; n EXYNOS4210_IRQ_GATE_NINPUTS; n++) {
+gate_irq[n] = qdev_get_gpio_in(dev, n);
+}
+busdev = sysbus_from_qdev(dev);
+/* Connect IRQ Gate output to cpu_irq */
+for (n = 0; n smp_cpus; n++) {
+sysbus_connect_irq(busdev, n, cpu_irq[n]);
+}
+
+/* Private memory region and Internal GIC */
+dev = qdev_create(NULL, a9mpcore_priv);
+qdev_prop_set_uint32(dev, num-cpu, smp_cpus);
+qdev_init_nofail(dev);
+busdev = sysbus_from_qdev(dev);
+sysbus_mmio_map(busdev, 0, EXYNOS4210_SMP_PRIVATE_BASE_ADDR);
+for (n = 0; n smp_cpus; n++) {
+sysbus_connect_irq(busdev, n, gate_irq[n * 2]);
+}
+for (n = 0; n EXYNOS4210_INT_GIC_NIRQ; n++) {
+s-irqs.int_gic_irq[n] = qdev_get_gpio_in(dev, n);
+}
+
+/* External
Re: [Qemu-devel] 回??: [PATCH 00/21][RFC] postcopy live?migration
On Thu, Jan 12, 2012 at 04:29:44PM +0800, thfbjyddx wrote: Hi , I've dug more thess days (qemu) migration-tcp: Attempting to start an incoming migration migration-tcp: accepted migration 4872:4872 postcopy_incoming_ram_load:1018: incoming ram load 4872:4872 postcopy_incoming_ram_load:1031: addr 0x1087 flags 0x4 4872:4872 postcopy_incoming_ram_load:1057: done 4872:4872 postcopy_incoming_ram_load:1018: incoming ram load 4872:4872 postcopy_incoming_ram_load:1031: addr 0x0 flags 0x10 4872:4872 postcopy_incoming_ram_load:1037: EOS 4872:4872 postcopy_incoming_ram_load:1018: incoming ram load 4872:4872 postcopy_incoming_ram_load:1031: addr 0x0 flags 0x10 4872:4872 postcopy_incoming_ram_load:1037: EOS There should be only single EOS line. Just copy past miss? There must be two EOS for one is coming from postcopy_outgoing_ram_save_live (...stage == QEMU_SAVE_LIVE_STAGE_PART) and the other is postcopy_outgoing_ram_save_live(...stage == QEMU_SAVE_LIVE_STAGE_END) I think in postcopy the ram_save_live in the iterate part can be ignore so why there still have the qemu_put_byte(f, QEMU_VM_SECTON_PART) and qemu_put_byte(f, QEMU_VM_SECTON_END) in the procedure? Is it essential? Not so essential. Can you please track it down one more step? Which line did it stuck in kvm_put_msrs()? kvm_put_msrs() doesn't seem to block.(backtrace by the debugger would be best.) it gets to the kvm_vcpu_ioctl(env, KVM_SET_MSRS, msr_data) and never return so it gets stuck Do you know what wchan the process was blocked at? kvm_vcpu_ioctl(env, KVM_SET_MSRS, msr_data) doesn't seem to block. when I check the EOS problem I just annotated the qemu_put_byte(f, QEMU_VM_SECTION_PART); and qemu_put_be32 (f, se-section_id) (I think this is a wrong way to fix it and I don't know how it get through) and leave just the se-save_live_state in the qemu_savevm_state_iterate it didn't get stuck at kvm_put_msrs() but it has some other error (qemu) migration-tcp: Attempting to start an incoming migration migration-tcp: accepted migration 2126:2126 postcopy_incoming_ram_load:1018: incoming ram load 2126:2126 postcopy_incoming_ram_load:1031: addr 0x1087 flags 0x4 2126:2126 postcopy_incoming_ram_load:1057: done migration: successfully loaded vm state 2126:2126 postcopy_incoming_fork_umemd:1069: fork 2126:2126 postcopy_incoming_fork_umemd:1127: qemu pid: 2126 daemon pid: 2129 2130:2130 postcopy_incoming_umemd:1840: daemon pid: 2130 2130:2130 postcopy_incoming_umemd:1875: entering umemd main loop Can't find block ! 2130:2130 postcopy_incoming_umem_ram_load:1526: shmem == NULL 2130:2130 postcopy_incoming_umemd:1882: exiting umemd main loop and at the same time , the destination node didn't show the EOS so I still can't solve the stuck problem Thanks for your help~! ━━━ Tommy From: Isaku Yamahata Date: 2012-01-11 10:45 To: thfbjyddx CC: t.hirofuchi; qemu-devel; kvm; satoshi.itoh Subject: Re: [Qemu-devel]回??: [PATCH 00/21][RFC] postcopy live migration On Sat, Jan 07, 2012 at 06:29:14PM +0800, thfbjyddx wrote: Hello all! Hi, thank you for detailed report. The procedure you've tried looks good basically. Some comments below. I got the qemu basic version(03ecd2c80a64d030a22fe67cc7a60f24e17ff211) and patched it correctly but it still didn't make sense and I got the same scenario as before outgoing node intel x86_64; incoming node amd x86_64. guest image is on nfs I think I should show what I do more clearly and hope somebody can figure out the problem ・ 1, both in/out node patch the qemu and start on 3.1.7 kernel with umem ./configure --target-list= x86_64-softmmu --enable-kvm --enable-postcopy --enable-debug make make install ・ 2, outgoing qemu: qemu-system-x86_64 -m 256 -hda xxx -monitor stdio -vnc: 2 -usbdevice tablet -machine accel=kvm incoming qemu: qemu-system-x86_64 -m 256 -hda xxx -postcopy -incoming tcp:0: -monitor stdio -vnc: 2 -usbdevice tablet -machine accel=kvm ・ 3, outgoing node: migrate -d -p -n tcp:(incoming node ip): result: ・ outgoing qemu: info status: VM-status: paused (finish-migrate); ・ incoming qemu: can't type any more and can't kill the process(qemu-system-x86) I open the debug flag in migration.c migration-tcp.c migration-postcopy.c: ・ outgoing qemu: (qemu) migration-tcp: connect completed migration: beginning savevm 4500:4500 postcopy_outgoing_ram_save_live:540: stage 1 migration: iterate 4500:4500 postcopy_outgoing_ram_save_live:540: stage 2 migration: done iterating 4500:4500 postcopy_outgoing_ram_save_live:540: stage 3 4500:4500 postcopy_outgoing_begin:716: outgoing begin ・ incoming qemu: (qemu) migration-tcp: Attempting to start an incoming migration migration-tcp: accepted migration 4872:4872 postcopy_incoming_ram_load:1018: incoming ram
[Qemu-devel] [PATCH 2/2 v2] block: track dirty flag status in qed
From: Dong Xu Wang wdon...@linux.vnet.ibm.com
qed driver use QED_F_NEED_CHECK to mark if the image is clean.
Signed-off-by: Dong Xu Wang wdon...@linux.vnet.ibm.com
Reviewed-by: Kevin Wolf kw...@redhat.com
Reviewed-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
block/qed.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/block/qed.c b/block/qed.c
index 8da3ebe..c1392a3 100644
--- a/block/qed.c
+++ b/block/qed.c
@@ -1429,6 +1429,12 @@ static int bdrv_qed_check(BlockDriverState *bs,
BdrvCheckResult *result)
return qed_check(s, result, false);
}
+static bool bdrv_qed_not_cleanly_down(BlockDriverState *bs)
+{
+BDRVQEDState *s = bs-opaque;
+return s-header.features QED_F_NEED_CHECK;
+}
+
static QEMUOptionParameter qed_create_options[] = {
{
.name = BLOCK_OPT_SIZE,
@@ -1474,6 +1480,7 @@ static BlockDriver bdrv_qed = {
.bdrv_get_info= bdrv_qed_get_info,
.bdrv_change_backing_file = bdrv_qed_change_backing_file,
.bdrv_check = bdrv_qed_check,
+.bdrv_not_cleanly_down= bdrv_qed_not_cleanly_down,
};
static void bdrv_qed_init(void)
--
1.7.5.4
[Qemu-devel] [PATCH 1/2 v2] block: add dirty flag status to qemu-img
From: Dong Xu Wang wdon...@linux.vnet.ibm.com
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 wdon...@linux.vnet.ibm.com
Reviewed-by: Kevin Wolf kw...@redhat.com
Reviewed-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
Changes from v1:
1. rename bdrv_is_dirty to bdrv_not_cleanly_down, and change its return value
from int to bool.
2. Change description from dirty,need check: yes to cleanly shut down: no
block.c | 14 ++
block.h |2 ++
block_int.h |1 +
qemu-img.c |3 +++
4 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/block.c b/block.c
index 3f072f6..0718466 100644
--- a/block.c
+++ b/block.c
@@ -186,6 +186,20 @@ static void bdrv_io_limits_intercept(BlockDriverState *bs,
qemu_co_queue_next(bs-throttled_reqs);
}
+/* check if the image was cleanly shut down */
+bool bdrv_not_cleanly_down(BlockDriverState *bs)
+{
+BlockDriver *drv = bs-drv;
+
+if (!drv) {
+return 0;
+}
+if (!drv-bdrv_not_cleanly_down) {
+return 0;
+}
+return drv-bdrv_not_cleanly_down(bs);
+}
+
/* check if the path starts with protocol: */
static int path_has_protocol(const char *path)
{
diff --git a/block.h b/block.h
index 3bd4398..72cf744 100644
--- a/block.h
+++ b/block.h
@@ -104,6 +104,8 @@ void bdrv_io_limits_enable(BlockDriverState *bs);
void bdrv_io_limits_disable(BlockDriverState *bs);
bool bdrv_io_limits_enabled(BlockDriverState *bs);
+bool bdrv_not_cleanly_down(BlockDriverState *bs);
+
void bdrv_init(void);
void bdrv_init_with_whitelist(void);
BlockDriver *bdrv_find_protocol(const char *filename);
diff --git a/block_int.h b/block_int.h
index 311bd2a..f5168f6 100644
--- a/block_int.h
+++ b/block_int.h
@@ -84,6 +84,7 @@ struct BlockDriver {
int (*bdrv_create)(const char *filename, QEMUOptionParameter *options);
int (*bdrv_set_key)(BlockDriverState *bs, const char *key);
int (*bdrv_make_empty)(BlockDriverState *bs);
+bool (*bdrv_not_cleanly_down)(BlockDriverState *bs);
/* aio */
BlockDriverAIOCB *(*bdrv_aio_readv)(BlockDriverState *bs,
int64_t sector_num, QEMUIOVector *qiov, int nb_sectors,
diff --git a/qemu-img.c b/qemu-img.c
index 01cc0d3..d19cae1 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -1153,6 +1153,9 @@ static int img_info(int argc, char **argv)
if (bdrv_is_encrypted(bs)) {
printf(encrypted: yes\n);
}
+if (bdrv_not_cleanly_down(bs)) {
+printf(cleanly shut down: no\n);
+}
if (bdrv_get_info(bs, bdi) = 0) {
if (bdi.cluster_size != 0) {
printf(cluster_size: %d\n, bdi.cluster_size);
--
1.7.5.4
[Qemu-devel] unknown keycodes
Hi! getting the following message: unknown keycodes `empty_aliases(qwerty)', please report to qemu-devel@nongnu.org I'm connecting to a ubuntu 10.04 server running qemu 1.0.50 forwarding X11. Locally I'm on a Macbook pro with Swedish keyboard layout. When I run qemu my keyboard is totally messed up (Enter becomes j, j becomes 7 etc.). Running with -k en-us works but restricts me to english characters (swedish characters generates keysym errors, which is expected) my locale is: LANG=en_US.UTF-8 LC_CTYPE=sv_SE.UTF-8 LC_NUMERIC=en_US.UTF-8 LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 LC_PAPER=en_US.UTF-8 LC_NAME=en_US.UTF-8 LC_ADDRESS=en_US.UTF-8 LC_TELEPHONE=en_US.UTF-8 LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=en_US.UTF-8 LC_ALL= Regards, Daniel
[Qemu-devel] [PATCH v6 03/10] ARM: exynos4210: IRQ subsystem support.
Signed-off-by: Evgeny Voevodin e.voevo...@samsung.com
---
Makefile.target |1 +
hw/exynos4210.h | 82
hw/exynos4210_combiner.c | 464 ++
hw/exynos4210_gic.c | 437 +++
4 files changed, 984 insertions(+), 0 deletions(-)
create mode 100644 hw/exynos4210.h
create mode 100644 hw/exynos4210_combiner.c
create mode 100644 hw/exynos4210_gic.c
diff --git a/Makefile.target b/Makefile.target
index 06d79b8..4ac257e 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -339,6 +339,7 @@ obj-arm-y = integratorcp.o versatilepb.o arm_pic.o
arm_timer.o
obj-arm-y += arm_boot.o pl011.o pl031.o pl050.o pl080.o pl110.o pl181.o pl190.o
obj-arm-y += versatile_pci.o
obj-arm-y += realview_gic.o realview.o arm_sysctl.o arm11mpcore.o a9mpcore.o
+obj-arm-y += exynos4210_gic.o exynos4210_combiner.o
obj-arm-y += arm_l2x0.o
obj-arm-y += arm_mptimer.o
obj-arm-y += armv7m.o armv7m_nvic.o stellaris.o pl022.o stellaris_enet.o
diff --git a/hw/exynos4210.h b/hw/exynos4210.h
new file mode 100644
index 000..cef264b
--- /dev/null
+++ b/hw/exynos4210.h
@@ -0,0 +1,82 @@
+/*
+ * Samsung exynos4210 SoC emulation
+ *
+ * Copyright (c) 2011 Samsung Electronics Co., Ltd. All rights reserved.
+ *Maksim Kozlov m.koz...@samsung.com
+ *Evgeny Voevodin e.voevo...@samsung.com
+ *Igor Mitsyanko i.mitsya...@samsung.com
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see http://www.gnu.org/licenses/.
+ *
+ */
+
+
+#ifndef EXYNOS4210_H_
+#define EXYNOS4210_H_
+
+#include qemu-common.h
+#include memory.h
+
+#define EXYNOS4210_MAX_CPUS 2
+
+/*
+ * exynos4210 IRQ subsystem stub definitions.
+ */
+#define EXYNOS4210_IRQ_GATE_NINPUTS 8
+
+#define EXYNOS4210_MAX_INT_COMBINER_OUT_IRQ 64
+#define EXYNOS4210_MAX_EXT_COMBINER_OUT_IRQ 16
+#define EXYNOS4210_MAX_INT_COMBINER_IN_IRQ \
+(EXYNOS4210_MAX_INT_COMBINER_OUT_IRQ * 8)
+#define EXYNOS4210_MAX_EXT_COMBINER_IN_IRQ \
+(EXYNOS4210_MAX_EXT_COMBINER_OUT_IRQ * 8)
+
+#define EXYNOS4210_COMBINER_GET_IRQ_NUM(grp, bit) ((grp)*8 + (bit))
+#define EXYNOS4210_COMBINER_GET_GRP_NUM(irq) ((irq) / 8)
+#define EXYNOS4210_COMBINER_GET_BIT_NUM(irq) \
+((irq) - 8 * EXYNOS4210_COMBINER_GET_GRP_NUM(irq))
+
+/* IRQs number for external and internal GIC */
+#define EXYNOS4210_EXT_GIC_NIRQ (160-32)
+#define EXYNOS4210_INT_GIC_NIRQ 64
+
+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];
+qemu_irq int_gic_irq[EXYNOS4210_INT_GIC_NIRQ];
+qemu_irq ext_gic_irq[EXYNOS4210_EXT_GIC_NIRQ];
+qemu_irq board_irqs[EXYNOS4210_MAX_INT_COMBINER_IN_IRQ];
+} Exynos4210Irq;
+
+/* Initialize exynos4210 IRQ subsystem stub */
+qemu_irq *exynos4210_init_irq(Exynos4210Irq *env);
+
+/* Initialize board IRQs.
+ * These IRQs contain splitted Int/External Combiner and External Gic IRQs */
+void exynos4210_init_board_irqs(Exynos4210Irq *s);
+
+/* Get IRQ number from exynos4210 IRQ subsystem stub.
+ * To identify IRQ source use internal combiner group and bit number
+ * grp - group number
+ * bit - bit number inside group */
+uint32_t exynos4210_get_irq(uint32_t grp, uint32_t bit);
+
+/*
+ * Get Combiner input GPIO into irqs structure
+ */
+void exynos4210_combiner_get_gpioin(Exynos4210Irq *irqs, DeviceState *dev,
+int ext);
+
+#endif /* EXYNOS4210_H_ */
diff --git a/hw/exynos4210_combiner.c b/hw/exynos4210_combiner.c
new file mode 100644
index 000..f675581
--- /dev/null
+++ b/hw/exynos4210_combiner.c
@@ -0,0 +1,464 @@
+/*
+ * Samsung exynos4210 Interrupt Combiner
+ *
+ * Copyright (c) 2000 - 2011 Samsung Electronics Co., Ltd.
+ * All rights reserved.
+ *
+ * Evgeny Voevodin e.voevo...@samsung.com
+ *
+ * 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
Re: [Qemu-devel] [PATCH v4 04/15] block: add image streaming block job
On Wed, Jan 11, 2012 at 03:18:28PM -0200, Luiz Capitulino wrote:
On Fri, 6 Jan 2012 14:01:30 +
Stefan Hajnoczi stefa...@linux.vnet.ibm.com wrote:
+int stream_start(BlockDriverState *bs, BlockDriverState *base,
+ BlockDriverCompletionFunc *cb, void *opaque)
+{
+StreamBlockJob *s;
+Coroutine *co;
+
+if (bs-job) {
+return -EBUSY;
+}
+
+s = block_job_create(stream_job_type, bs, cb, opaque);
+s-base = base;
This is missing a check against NULL.
Good catch.
[Qemu-devel] [PATCH v6 00/10] ARM: Samsung Exynos4210-based boards support.
This set of patches adds support for Samsung S5PC210-based boards NURI and
SMDKC210.
Tested on Linux kernel v3.x series. Usage of -smp 2 option is required for
now.
Changelog:
v5-v6
- arm_boot.c, vexpress.c, realview.c: board should specify smp_bootreg_addr if
its ncpu 1
- patch order changed, boot secondary CPU is included in exynos boards
patch.
- exynos4210_mct.c: usage of UINTX_MAX, removed excessive property list, fixed
indentation,
fixed comments
- exynos4210_pwm.c: spaces and brakcets in macros, removed excessive property
list,
fixed indentation,
- exynos4210_combiner.c: removed excessive reset, fixed indentation, fixed
comments
- exynos4210_gic.c: fixed indentation, fixed syntax
- exynos4210_uart.c: fixed indentation, fixed syntax
- exynos4210.c: fixed comments
- Makefile.target: removed \
- hw/exynos4210_fimd.c: rebased against current master: all manipulation with
physical pages are dropped and
replaced with new memory API functions;
added three new members to winow's state:
MemoryRegionSection to describe section
of system RAM containing current framebuffer, host
pointer to framebuffer data and
framebuffer length;
mapping of framebuffer now performed only on
framebuffer settings change
instead on every display update;
bytes swap in uint64 variable now performed with
standard QEMU bswap64 function;
blencon register type changed to uint32_t;
fixed incorrect spelling of palette word;
if ... else statements in exynos4210_fimd_read() and
exynos4210_fimd_write() are
replaced with switch() {} statement.
v4-v5
- hw/exynos4210_gic.c: Use memory aliases for CPU interface and Distributer.
Excessive RW functions are removed.
- hw/exynos4210_pwm.c and hw/exynos4210_mct.c: Saving of timers added.
- hw/exynos4210_uart.c: VMSTATE version_id fixed.
v3-v4
- Split Exynos SOC and boards.
- Temporary removed SD and CMU support to post later.
- Lan9118 remarks took into account.
- Secondary CPU bootloader remarks took into account.
- PWM remarks took into account.
- UART remarks took into account.
v2-v3
- Reverted hw/arm_gic.c modification
- Added IRQ Gate to Exynos4210 board.
Evgeny Voevodin (8):
hw/sysbus.h: Increase maximum number of device IRQs.
hw/arm_boot.c: Make SMP boards specify address to poll in bootup loop
ARM: exynos4210: IRQ subsystem support.
ARM: Samsung exynos4210-based boards emulation
ARM: exynos4210: PWM support.
ARM: exynos4210: MCT support.
hw/lan9118: Add basic 16-bit mode support.
hw/exynos4210.c: Add LAN support for SMDKC210.
Maksim Kozlov (1):
ARM: exynos4210: UART support
Mitsyanko Igor (1):
Exynos4210: added display controller implementation
Makefile.target |3 +
hw/arm-misc.h|1 +
hw/arm_boot.c| 18 +-
hw/exynos4210.c | 272 +++
hw/exynos4210.h | 128 +++
hw/exynos4210_combiner.c | 464 +++
hw/exynos4210_fimd.c | 1924 ++
hw/exynos4210_gic.c | 437 +++
hw/exynos4210_mct.c | 1479 +++
hw/exynos4210_pwm.c | 413 ++
hw/exynos4210_uart.c | 668
hw/exynos4_boards.c | 166
hw/lan9118.c | 115 +++-
hw/realview.c|2 +
hw/sysbus.h |2 +-
hw/vexpress.c|2 +
16 files changed, 6080 insertions(+), 14 deletions(-)
create mode 100644 hw/exynos4210.c
create mode 100644 hw/exynos4210.h
create mode 100644 hw/exynos4210_combiner.c
create mode 100644 hw/exynos4210_fimd.c
create mode 100644 hw/exynos4210_gic.c
create mode 100644 hw/exynos4210_mct.c
create mode 100644 hw/exynos4210_pwm.c
create mode 100644 hw/exynos4210_uart.c
create mode 100644 hw/exynos4_boards.c
--
1.7.4.1
Re: [Qemu-devel] LLVM builds on Lion (Xcode 4.2.1)?
On Jan 11, 2012, at 19:24 , Peter Maydell wrote: This is still waiting for somebody to get round to doing a basic noddy FPU-intensive benchmark of (eg) an ARM target on a Linux host to find out whether int16_t vs int_fast16_t makes any difference at all to performance. (My suspicion is 'no'.) Quite so - I've since exchanged a couple of messages with Andreas and ascertained that. But QEMU not running properly when compiled with LLVM is the real problem here, since that means people won't be able to build it unless they have an outdated compiler around (fresh installs of Xcode don't bundle normal gcc anymore). I'm starting to think I'm the only person trying to build it with a current Mac toolchain... R.
[Qemu-devel] [PATCH v6 04/10] ARM: Samsung exynos4210-based boards emulation
Add initial support of NURI and SMDKC210 boards
Signed-off-by: Evgeny Voevodin e.voevo...@samsung.com
---
Makefile.target |3 +-
hw/exynos4210.c | 202 +++
hw/exynos4210.h | 37 +
hw/exynos4_boards.c | 143
4 files changed, 384 insertions(+), 1 deletions(-)
create mode 100644 hw/exynos4210.c
create mode 100644 hw/exynos4_boards.c
diff --git a/Makefile.target b/Makefile.target
index 4ac257e..6199d44 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -339,7 +339,8 @@ obj-arm-y = integratorcp.o versatilepb.o arm_pic.o
arm_timer.o
obj-arm-y += arm_boot.o pl011.o pl031.o pl050.o pl080.o pl110.o pl181.o pl190.o
obj-arm-y += versatile_pci.o
obj-arm-y += realview_gic.o realview.o arm_sysctl.o arm11mpcore.o a9mpcore.o
-obj-arm-y += exynos4210_gic.o exynos4210_combiner.o
+obj-arm-y += exynos4210_gic.o exynos4210_combiner.o exynos4210.o
+obj-arm-y += exynos4_boards.o
obj-arm-y += arm_l2x0.o
obj-arm-y += arm_mptimer.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
new file mode 100644
index 000..82755db
--- /dev/null
+++ b/hw/exynos4210.c
@@ -0,0 +1,202 @@
+/*
+ * Samsung exynos4210 SoC emulation
+ *
+ * Copyright (c) 2011 Samsung Electronics Co., Ltd. All rights reserved.
+ *Maksim Kozlov m.koz...@samsung.com
+ *Evgeny Voevodin e.voevo...@samsung.com
+ *Igor Mitsyanko i.mitsya...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see http://www.gnu.org/licenses/.
+ *
+ */
+
+#include boards.h
+#include sysemu.h
+#include sysbus.h
+#include arm-misc.h
+#include exynos4210.h
+
+#define EXYNOS4210_CHIPID_ADDR 0x1000
+
+/* External GIC */
+#define EXYNOS4210_EXT_GIC_CPU_BASE_ADDR0x1048
+#define EXYNOS4210_EXT_GIC_DIST_BASE_ADDR 0x1049
+
+/* Combiner */
+#define EXYNOS4210_EXT_COMBINER_BASE_ADDR 0x1044
+#define EXYNOS4210_INT_COMBINER_BASE_ADDR 0x10448000
+
+static uint8_t chipid_and_omr[] = { 0x11, 0x02, 0x21, 0x43,
+0x09, 0x00, 0x00, 0x00 };
+
+Exynos4210State *exynos4210_init(MemoryRegion *system_mem,
+unsigned long ram_size)
+{
+qemu_irq cpu_irq[4];
+int n;
+Exynos4210State *s = g_new(Exynos4210State, 1);
+qemu_irq *irq_table;
+qemu_irq *irqp;
+qemu_irq gate_irq[EXYNOS4210_IRQ_GATE_NINPUTS];
+unsigned long mem_size;
+DeviceState *dev;
+SysBusDevice *busdev;
+
+for (n = 0; n smp_cpus; n++) {
+s-env[n] = cpu_init(cortex-a9);
+if (!s-env[n]) {
+fprintf(stderr, Unable to find CPU %d definition\n, n);
+exit(1);
+}
+/* Create PIC controller for each processor instance */
+irqp = arm_pic_init_cpu(s-env[n]);
+
+/*
+ * Get GICs gpio_in cpu_irq to connect a combiner to them later.
+ * Use only IRQ for a while.
+ */
+cpu_irq[n] = irqp[ARM_PIC_CPU_IRQ];
+}
+
+/*** IRQs ***/
+
+s-irq_table = exynos4210_init_irq(s-irqs);
+irq_table = s-irq_table;
+
+/* IRQ Gate */
+dev = qdev_create(NULL, exynos4210.irq_gate);
+qdev_init_nofail(dev);
+/* Get IRQ Gate input in gate_irq */
+for (n = 0; n EXYNOS4210_IRQ_GATE_NINPUTS; n++) {
+gate_irq[n] = qdev_get_gpio_in(dev, n);
+}
+busdev = sysbus_from_qdev(dev);
+/* Connect IRQ Gate output to cpu_irq */
+for (n = 0; n smp_cpus; n++) {
+sysbus_connect_irq(busdev, n, cpu_irq[n]);
+}
+
+/* Private memory region and Internal GIC */
+dev = qdev_create(NULL, a9mpcore_priv);
+qdev_prop_set_uint32(dev, num-cpu, smp_cpus);
+qdev_init_nofail(dev);
+busdev = sysbus_from_qdev(dev);
+sysbus_mmio_map(busdev, 0, EXYNOS4210_SMP_PRIVATE_BASE_ADDR);
+for (n = 0; n smp_cpus; n++) {
+sysbus_connect_irq(busdev, n, gate_irq[n * 2]);
+}
+for (n = 0; n EXYNOS4210_INT_GIC_NIRQ; n++) {
+s-irqs.int_gic_irq[n] = qdev_get_gpio_in(dev, n);
+}
+
+/* External GIC */
+dev = qdev_create(NULL, exynos4210.gic);
+qdev_prop_set_uint32(dev, num-cpu, smp_cpus);
+qdev_init_nofail(dev);
+busdev = sysbus_from_qdev(dev);
+/* Map CPU interface */
+sysbus_mmio_map(busdev, 0, EXYNOS4210_EXT_GIC_CPU_BASE_ADDR);
+/* Map Distributer interface */
+
Re: [Qemu-devel] [PATCH v6 04/10] ARM: Samsung exynos4210-based boards emulation
On 01/12/2012 12:48 PM, Kyungmin Park wrote: On 1/12/12, Evgeny Voevodine.voevo...@samsung.com wrote: Add initial support of NURI and SMDKC210 boards Signed-off-by: Evgeny Voevodine.voevo...@samsung.com --- Makefile.target |3 +- hw/exynos4210.c | 202 +++ hw/exynos4210.h | 37 + hw/exynos4_boards.c | 143 4 files changed, 384 insertions(+), 1 deletions(-) create mode 100644 hw/exynos4210.c create mode 100644 hw/exynos4_boards.c diff --git a/Makefile.target b/Makefile.target index 4ac257e..6199d44 100644 --- a/Makefile.target +++ b/Makefile.target @@ -339,7 +339,8 @@ obj-arm-y = integratorcp.o versatilepb.o arm_pic.o arm_timer.o obj-arm-y += arm_boot.o pl011.o pl031.o pl050.o pl080.o pl110.o pl181.o pl190.o obj-arm-y += versatile_pci.o obj-arm-y += realview_gic.o realview.o arm_sysctl.o arm11mpcore.o a9mpcore.o -obj-arm-y += exynos4210_gic.o exynos4210_combiner.o +obj-arm-y += exynos4210_gic.o exynos4210_combiner.o exynos4210.o +obj-arm-y += exynos4_boards.o obj-arm-y += arm_l2x0.o obj-arm-y += arm_mptimer.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 new file mode 100644 index 000..82755db --- /dev/null +++ b/hw/exynos4210.c @@ -0,0 +1,202 @@ +/* + * Samsung exynos4210 SoC emulation + * + * Copyright (c) 2011 Samsung Electronics Co., Ltd. All rights reserved. + *Maksim Kozlovm.koz...@samsung.com + *Evgeny Voevodine.voevo...@samsung.com + *Igor Mitsyankoi.mitsya...@samsung.com + * + * 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, seehttp://www.gnu.org/licenses/. + * + */ + +#include boards.h +#include sysemu.h +#include sysbus.h +#include arm-misc.h +#include exynos4210.h + +#define EXYNOS4210_CHIPID_ADDR 0x1000 + +/* External GIC */ +#define EXYNOS4210_EXT_GIC_CPU_BASE_ADDR0x1048 +#define EXYNOS4210_EXT_GIC_DIST_BASE_ADDR 0x1049 + +/* Combiner */ +#define EXYNOS4210_EXT_COMBINER_BASE_ADDR 0x1044 +#define EXYNOS4210_INT_COMBINER_BASE_ADDR 0x10448000 FYI: Even though there's internal combiner, it doesn't used any more. and there's no codes at kernel. Kernel v3.0 uses it. And I think that if HW contains one, it shouldn't be removed from emulation. -- Kind regards, Evgeny Voevodin, Leading Software Engineer, ASWG, Moscow RD center, Samsung Electronics e-mail: e.voevo...@samsung.com
Re: [Qemu-devel] [PATCH 12/15] qtest: add support for target-i386 -M pc
On 01/11/2012 08:44 PM, Anthony Liguori wrote:
This is easier said than done. I started down this road and there's a
huge amount of code that assumes that first_cpu != NULL.
That's why I said do not create the CPU _threads_. :) But that wouldn't
be a big step forward from halted = 1; for example, it would prevent
using per-CPU work items. Currently they're only used internally by
KVM, but you never know.
So you can also create a CPU thread that does nothing. Here is how it
could look like, based on the KVM implementation:
static void *qemu_qtest_cpu_thread_fn(void *arg)
{
CPUState *env = arg;
int r;
qemu_mutex_lock(qemu_global_mutex);
qemu_thread_get_self(env-thread);
env-thread_id = qemu_get_thread_id();
sigset_t waitset;
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(sigtimedwait);
exit(1);
}
qemu_mutex_lock_iothread();
cpu_single_env = env;
qemu_wait_io_event_common(env);
}
return NULL;
}
Paolo
Re: [Qemu-devel] [PATCH v4 06/15] qmp: add block_stream command
On Wed, Jan 11, 2012 at 5:23 PM, Luiz Capitulino lcapitul...@redhat.com wrote: On Fri, 6 Jan 2012 14:01:32 + Stefan Hajnoczi stefa...@linux.vnet.ibm.com wrote: +- error: Error message (json-string) error is optional, so it should be (json-string, optional) Ok. +# @base: the common backing file name @base is optional, so it should be documented like this: @base: #optional the common backing file name Ok.
Re: [Qemu-devel] [PATCH 3/3] stop the periodic RTC update timer
On 01/12/2012 01:00 AM, Zhang, Yang Z wrote: Regarding the UIP bit, a guest could read it in a loop and wait for the value to change. But you can emulate it in cmos_ioport_read by reading the host time, that is, return 1 during 244us, 0 for remaining of the second, and have that in sync with update-cycle-ended interrupt if its enabled. Yes. Guest may use the loop to read RTC, but the point is the guest is waiting for the UIP changed to 0. If this bit always equal to 0 , guest will never go into the loop. For real RTC, this may wrong, because the RTC cannot give you the valid value during the update cycle. But the virtual RTC doesn't' need this logic, whenever you read it, it will always return the right value to you. The point is not _correctness_. It is _atomicity_. Paolo
Re: [Qemu-devel] [PATCH 1/5] i8259: qdev-ify creation
On 2012-01-12 09:18, Alexander Graf wrote:
On 12.01.2012, at 09:09, Jan Kiszka wrote:
On 2012-01-12 09:05, Alexander Graf wrote:
On 12.01.2012, at 09:00, Jan Kiszka wrote:
On 2012-01-12 08:58, Alexander Graf wrote:
On 12.01.2012, at 08:35, Jan Kiszka wrote:
On 2012-01-12 01:04, Andreas Färber wrote:
Alex,
I have this in my mailbox, but I'm still waiting for an SoB. Hervé?
Regards,
Andreas
Original-Nachricht
Betreff: [PATCH 1/5] i8259: qdev-ify creation
Datum: Sun, 26 Jun 2011 14:47:09 +0200
Von: Hervé Poussineau hpous...@reactos.org
An: andreas.faer...@web.de
Kopie (CC): Hervé Poussineau hpous...@reactos.org
---
hw/i8259.c | 53 +
1 files changed, 49 insertions(+), 4 deletions(-)
diff --git a/hw/i8259.c b/hw/i8259.c
index 84d330d..59e8bd6 100644
--- a/hw/i8259.c
+++ b/hw/i8259.c
@@ -26,6 +26,7 @@
#include isa.h
#include monitor.h
#include qemu-timer.h
+#include sysbus.h
/* debug PIC */
//#define DEBUG_PIC
@@ -524,16 +525,60 @@ void irq_info(Monitor *mon)
qemu_irq *i8259_init(qemu_irq parent_irq)
{
-PicState2 *s;
+DeviceState *dev;
+dev = qdev_create(NULL, i8259);
+qdev_init_nofail(dev);
+qdev_connect_gpio_out(dev, 0, parent_irq);
+
+return dev-gpio_in;
+}
+
+typedef struct SysBusPicState2 {
+SysBusDevice busdev;
+PicState2 state;
+} SysBusPicState2;
+
+static void i8259_set_irq_sysbus(void *opaque, int line, int level)
+{
+SysBusPicState2 *sysbus = opaque;
+PicState2 *s = sysbus-state;
+i8259_set_irq(s, line, level);
+}
+
+static int i8259_sysbus_init(SysBusDevice *dev)
+{
+SysBusPicState2 *sysbus = FROM_SYSBUS(SysBusPicState2, dev);
+PicState2 *s = sysbus-state;
+
+if (isa_pic) {
+return 1;
+}
-s = qemu_mallocz(sizeof(PicState2));
pic_init1(0x20, 0x4d0, s-pics[0]);
pic_init1(0xa0, 0x4d1, s-pics[1]);
s-pics[0].elcr_mask = 0xf8;
s-pics[1].elcr_mask = 0xde;
-s-parent_irq = parent_irq;
s-pics[0].pics_state = s;
s-pics[1].pics_state = s;
isa_pic = s;
-return qemu_allocate_irqs(i8259_set_irq, s, 16);
+
+qdev_init_gpio_in(dev-qdev, i8259_set_irq_sysbus, 16);
+qdev_init_gpio_out(dev-qdev, s-parent_irq, 1);
+return 0;
+}
+
+static SysBusDeviceInfo i8259_sysbus_info = {
+.qdev.name = i8259,
+.qdev.size = sizeof(SysBusPicState2),
+.init = i8259_sysbus_init,
+.qdev.props = (Property[]) {
+DEFINE_PROP_END_OF_LIST()
+},
+};
+
+static void i8259_register_devices(void)
+{
+ sysbus_register_withprop(i8259_sysbus_info);
}
+
+device_init(i8259_register_devices)
This is obsolete. The i8259 has been significantly refactored (into two
ISA devices) and qdev'ified some moons ago.
The reason we were discussing this was a circular dependency on PREP.
The PIC is sitting on the ISA bus.
The ISA bus is behind a PCI-ISA bridge
the PCI-ISA bridge is behind a PCI host controller
the PCI host controller needs interrupt lines in its initialization which
are attached to the PIC
Any good ideas on how to resolve this? :)
As we do this always: Split up initialization and IRQ line wiring.
Well, yes, the theory is obvious. How would this look like in practice? To
create a PIC device I need a bus:
dev = isa_create(bus, isa-i8259);
But to create the bus, I need an interrupt line, which I only get after I
created the PIC device.
ISA bus creation and IRQ assignment are split up IIRC.
So you're saying we should do the same for PCI?
To create an ISA bus that sits behind a PCI device I first need to create a
PCI bus which is exposed by the host bridge which then again needs interrupt
lines.
I'm still puzzled how we would pass on irq lines then. I mean setting them
after init means that during init we can't instantiate other devices that we
can wire up to anything, right?
The ordering is:
1. create PCI bridge
1.1. create ISA bus
2. create i8259
3. bind interrupts to i8259
4. create further ISA devices
All this can be part of the chipset instantiation. It is not today as we
reuse everything from 2. on for isapc. But that could likely be refactored.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
[Qemu-devel] [PATCH v6 06/10] ARM: exynos4210: PWM support.
Signed-off-by: Evgeny Voevodin e.voevo...@samsung.com
---
Makefile.target |2 +-
hw/exynos4210.c | 12 ++
hw/exynos4210_pwm.c | 413 +++
3 files changed, 426 insertions(+), 1 deletions(-)
create mode 100644 hw/exynos4210_pwm.c
diff --git a/Makefile.target b/Makefile.target
index c856de3..1914870 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -340,7 +340,7 @@ obj-arm-y += arm_boot.o pl011.o pl031.o pl050.o pl080.o
pl110.o pl181.o pl190.o
obj-arm-y += versatile_pci.o
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
+obj-arm-y += exynos4_boards.o exynos4210_uart.o exynos4210_pwm.o
obj-arm-y += arm_l2x0.o
obj-arm-y += arm_mptimer.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 f23a136..48f4f65 100644
--- a/hw/exynos4210.c
+++ b/hw/exynos4210.c
@@ -29,6 +29,9 @@
#define EXYNOS4210_CHIPID_ADDR 0x1000
+/* PWM */
+#define EXYNOS4210_PWM_BASE_ADDR 0x139D
+
/* UART's definitions */
#define EXYNOS4210_UART0_BASE_ADDR 0x1380
#define EXYNOS4210_UART1_BASE_ADDR 0x1381
@@ -210,6 +213,15 @@ Exynos4210State *exynos4210_init(MemoryRegion *system_mem,
memory_region_add_subregion(system_mem, EXYNOS4210_SECOND_CPU_BOOTREG,
s-bootreg_mem);
+/* PWM */
+sysbus_create_varargs(exynos4210.pwm, EXYNOS4210_PWM_BASE_ADDR,
+irq_table[exynos4210_get_irq(22, 0)],
+irq_table[exynos4210_get_irq(22, 1)],
+irq_table[exynos4210_get_irq(22, 2)],
+irq_table[exynos4210_get_irq(22, 3)],
+irq_table[exynos4210_get_irq(22, 4)],
+NULL);
+
/*** UARTs ***/
exynos4210_uart_create(EXYNOS4210_UART0_BASE_ADDR,
EXYNOS4210_UART0_FIFO_SIZE, 0, NULL,
diff --git a/hw/exynos4210_pwm.c b/hw/exynos4210_pwm.c
new file mode 100644
index 000..d9d50bf
--- /dev/null
+++ b/hw/exynos4210_pwm.c
@@ -0,0 +1,413 @@
+/*
+ * Samsung exynos4210 Pulse Width Modulation Timer
+ *
+ * Copyright (c) 2000 - 2011 Samsung Electronics Co., Ltd.
+ * All rights reserved.
+ *
+ * Evgeny Voevodin e.voevo...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ * See the GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see http://www.gnu.org/licenses/.
+ */
+
+#include sysbus.h
+#include qemu-timer.h
+#include qemu-common.h
+#include hw.h
+
+#include exynos4210.h
+
+//#define DEBUG_PWM
+
+#ifdef DEBUG_PWM
+#define DPRINTF(fmt, ...) \
+do { fprintf(stdout, PWM: [%24s:%5d] fmt, __func__, __LINE__, \
+## __VA_ARGS__); } while (0)
+#else
+#define DPRINTF(fmt, ...) do {} while (0)
+#endif
+
+#define EXYNOS4210_PWM_TIMERS_NUM 5
+#define EXYNOS4210_PWM_REG_MEM_SIZE0x50
+
+#define TCFG00x
+#define TCFG10x0004
+#define TCON 0x0008
+#define TCNTB0 0x000C
+#define TCMPB0 0x0010
+#define TCNTO0 0x0014
+#define TCNTB1 0x0018
+#define TCMPB1 0x001C
+#define TCNTO1 0x0020
+#define TCNTB2 0x0024
+#define TCMPB2 0x0028
+#define TCNTO2 0x002C
+#define TCNTB3 0x0030
+#define TCMPB3 0x0034
+#define TCNTO3 0x0038
+#define TCNTB4 0x003C
+#define TCNTO4 0x0040
+#define TINT_CSTAT 0x0044
+
+#define TCNTB(x)(0xC * (x))
+#define TCMPB(x)(0xC * (x) + 1)
+#define TCNTO(x)(0xC * (x) + 2)
+
+#define GET_PRESCALER(reg, x) (((reg) (0xFF (8 * (x 8 * (x))
+#define GET_DIVIDER(reg, x) (1 (((reg) (0xF (4 * (x (4 * (x
+
+/*
+ * Attention! Timer4 doesn't have OUTPUT_INVERTER,
+ * so Auto Reload bit is not accessible by macros!
+ */
+#define TCON_TIMER_BASE(x) (((x) ? 1 : 0) * 4 + 4 * (x))
+#define TCON_TIMER_START(x) (1 (TCON_TIMER_BASE(x) + 0))
+#define TCON_TIMER_MANUAL_UPD(x)(1 (TCON_TIMER_BASE(x) + 1))
+#define TCON_TIMER_OUTPUT_INV(x)(1 (TCON_TIMER_BASE(x) + 2))
+#define TCON_TIMER_AUTO_RELOAD(x) (1 (TCON_TIMER_BASE(x) + 3))
+#define TCON_TIMER4_AUTO_RELOAD (1 22)
+
+#define TINT_CSTAT_STATUS(x)(1 (5 + (x)))
+#define TINT_CSTAT_ENABLE(x)(1 (x))
+
+/* timer struct */
+typedef
Re: [Qemu-devel] [RFC PATCH v3 1/3] Converting tracetool.sh to tracetool.py
2012/1/10 Lluís Vilanova vilan...@ac.upc.edu:
Harsh Prateek Bora writes:
+class Event(object):
+ def __init__(self, num, line):
+ self.num = num
+ self.args = get_args(line)
+ self.arglist = self.args.split(',')
+ self.name = get_name(line)
+ self.argc = get_argc(line)
+ self.argnames = get_argnames(line)
+ self.sizestr = calc_sizeofargs(line)
+ self.fmt = get_fmt(line)
This is not not extracting the event properties (e.g., disable). A set of
strings should suffice.
Arguments could be converted to an Arguments class (or similar, like
ArgumentList) and derive the rest from there using methods (e.g., names,
types,
sizestr, arglist, etc.).
Yes, that would be nice. This will separate the trace-events parsing
from the rest of the program, which can use the Event/Argument
interface instead of parsing strings.
Stefan
[Qemu-devel] [PATCH v6 08/10] hw/lan9118: Add basic 16-bit mode support.
Signed-off-by: Evgeny Voevodin e.voevo...@samsung.com
Reviewed-by: Peter Maydell peter.mayd...@linaro.org
---
hw/lan9118.c | 115 +++---
1 files changed, 110 insertions(+), 5 deletions(-)
diff --git a/hw/lan9118.c b/hw/lan9118.c
index 7e64c5d..21b7b23 100644
--- a/hw/lan9118.c
+++ b/hw/lan9118.c
@@ -212,6 +212,17 @@ typedef struct {
int rxp_offset;
int rxp_size;
int rxp_pad;
+
+uint32_t write_word_prev_offset;
+uint32_t write_word_n;
+uint16_t write_word_l;
+uint16_t write_word_h;
+uint32_t read_word_prev_offset;
+uint32_t read_word_n;
+uint32_t read_long;
+
+uint32_t mode_16bit;
+
} lan9118_state;
static void lan9118_update(lan9118_state *s)
@@ -306,7 +317,7 @@ static void lan9118_reset(DeviceState *d)
s-fifo_int = 0x4800;
s-rx_cfg = 0;
s-tx_cfg = 0;
-s-hw_cfg = 0x0005;
+s-hw_cfg = s-mode_16bit ? 0x0005 : 0x00050004;
s-pmt_ctrl = 0x45;
s-gpio_cfg = 0;
s-txp-fifo_used = 0;
@@ -345,6 +356,9 @@ static void lan9118_reset(DeviceState *d)
s-mac_mii_data = 0;
s-mac_flow = 0;
+s-read_word_n = 0;
+s-write_word_n = 0;
+
phy_reset(s);
s-eeprom_writable = 0;
@@ -900,7 +914,7 @@ static void lan9118_writel(void *opaque, target_phys_addr_t
offset,
{
lan9118_state *s = (lan9118_state *)opaque;
offset = 0xff;
-
+
//DPRINTF(Write reg 0x%02x = 0x%08x\n, (int)offset, val);
if (offset = 0x20 offset 0x40) {
/* TX FIFO */
@@ -950,7 +964,7 @@ static void lan9118_writel(void *opaque, target_phys_addr_t
offset,
/* SRST */
lan9118_reset(s-busdev.qdev);
} else {
-s-hw_cfg = val 0x003f300;
+s-hw_cfg = (val 0x003f300) | (s-hw_cfg 0x4);
}
break;
case CSR_RX_DP_CTRL:
@@ -1029,6 +1043,46 @@ static void lan9118_writel(void *opaque,
target_phys_addr_t offset,
lan9118_update(s);
}
+static void lan9118_writew(void *opaque, target_phys_addr_t offset,
+ uint32_t val)
+{
+lan9118_state *s = (lan9118_state *)opaque;
+offset = 0xff;
+
+if (s-write_word_prev_offset != (offset ~0x3)) {
+/* New offset, reset word counter */
+s-write_word_n = 0;
+s-write_word_prev_offset = offset ~0x3;
+}
+
+if (offset 0x2) {
+s-write_word_h = val;
+} else {
+s-write_word_l = val;
+}
+
+//DPRINTF(Writew reg 0x%02x = 0x%08x\n, (int)offset, val);
+s-write_word_n++;
+if (s-write_word_n == 2) {
+s-write_word_n = 0;
+lan9118_writel(s, offset ~3, s-write_word_l +
+(s-write_word_h 16), 4);
+}
+}
+
+static void lan9118_16bit_mode_write(void *opaque, target_phys_addr_t offset,
+ uint64_t val, unsigned size)
+{
+switch (size) {
+case 2:
+return lan9118_writew(opaque, offset, (uint32_t)val);
+case 4:
+return lan9118_writel(opaque, offset, val, size);
+}
+
+hw_error(lan9118_write: Bad size 0x%x\n, size);
+}
+
static uint64_t lan9118_readl(void *opaque, target_phys_addr_t offset,
unsigned size)
{
@@ -1065,7 +1119,7 @@ static uint64_t lan9118_readl(void *opaque,
target_phys_addr_t offset,
case CSR_TX_CFG:
return s-tx_cfg;
case CSR_HW_CFG:
-return s-hw_cfg | 0x4;
+return s-hw_cfg;
case CSR_RX_DP_CTRL:
return 0;
case CSR_RX_FIFO_INF:
@@ -1103,12 +1157,60 @@ static uint64_t lan9118_readl(void *opaque,
target_phys_addr_t offset,
return 0;
}
+static uint32_t lan9118_readw(void *opaque, target_phys_addr_t offset)
+{
+lan9118_state *s = (lan9118_state *)opaque;
+uint32_t val;
+
+if (s-read_word_prev_offset != (offset ~0x3)) {
+/* New offset, reset word counter */
+s-read_word_n = 0;
+s-read_word_prev_offset = offset ~0x3;
+}
+
+s-read_word_n++;
+if (s-read_word_n == 1) {
+s-read_long = lan9118_readl(s, offset ~3, 4);
+} else {
+s-read_word_n = 0;
+}
+
+if (offset 2) {
+val = s-read_long 16;
+} else {
+val = s-read_long 0x;
+}
+
+//DPRINTF(Readw reg 0x%02x, val 0x%x\n, (int)offset, val);
+return val;
+}
+
+static uint64_t lan9118_16bit_mode_read(void *opaque, target_phys_addr_t
offset,
+unsigned size)
+{
+switch (size) {
+case 2:
+return lan9118_readw(opaque, offset);
+case 4:
+return lan9118_readl(opaque, offset, size);
+}
+
+hw_error(lan9118_read: Bad size 0x%x\n, size);
+return 0;
+}
+
static const MemoryRegionOps lan9118_mem_ops = {
.read = lan9118_readl,
.write = lan9118_writel,
.endianness = DEVICE_NATIVE_ENDIAN,
};
+static const MemoryRegionOps lan9118_16bit_mem_ops = {
+.read = lan9118_16bit_mode_read,
+.write =
[Qemu-devel] [PATCH v6 01/10] hw/sysbus.h: Increase maximum number of device IRQs.
Samsung exynos4210 Interrupt Combiner needs 512 IRQ sources. Signed-off-by: Evgeny Voevodin e.voevo...@samsung.com Reviewed-by: Peter Maydell peter.mayd...@linaro.org --- hw/sysbus.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/hw/sysbus.h b/hw/sysbus.h index 899756b..7b8ca23 100644 --- a/hw/sysbus.h +++ b/hw/sysbus.h @@ -8,7 +8,7 @@ #define QDEV_MAX_MMIO 32 #define QDEV_MAX_PIO 32 -#define QDEV_MAX_IRQ 256 +#define QDEV_MAX_IRQ 512 typedef struct SysBusDevice SysBusDevice; -- 1.7.4.1
[Qemu-devel] [PATCH v6 05/10] ARM: exynos4210: UART support
From: Maksim Kozlov m.koz...@samsung.com
Add basic support of exynos4210 UART
Signed-off-by: Evgeny Voevodin e.voevo...@samsung.com
---
Makefile.target |2 +-
hw/exynos4210.c | 29 +++
hw/exynos4210.h |9 +
hw/exynos4210_uart.c | 668 ++
4 files changed, 707 insertions(+), 1 deletions(-)
create mode 100644 hw/exynos4210_uart.c
diff --git a/Makefile.target b/Makefile.target
index 6199d44..c856de3 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -340,7 +340,7 @@ obj-arm-y += arm_boot.o pl011.o pl031.o pl050.o pl080.o
pl110.o pl181.o pl190.o
obj-arm-y += versatile_pci.o
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
+obj-arm-y += exynos4_boards.o exynos4210_uart.o
obj-arm-y += arm_l2x0.o
obj-arm-y += arm_mptimer.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 82755db..f23a136 100644
--- a/hw/exynos4210.c
+++ b/hw/exynos4210.c
@@ -29,6 +29,18 @@
#define EXYNOS4210_CHIPID_ADDR 0x1000
+/* UART's definitions */
+#define EXYNOS4210_UART0_BASE_ADDR 0x1380
+#define EXYNOS4210_UART1_BASE_ADDR 0x1381
+#define EXYNOS4210_UART2_BASE_ADDR 0x1382
+#define EXYNOS4210_UART3_BASE_ADDR 0x1383
+#define EXYNOS4210_UART0_FIFO_SIZE 256
+#define EXYNOS4210_UART1_FIFO_SIZE 64
+#define EXYNOS4210_UART2_FIFO_SIZE 16
+#define EXYNOS4210_UART3_FIFO_SIZE 16
+/* Interrupt Group of External Interrupt Combiner for UART */
+#define EXYNOS4210_UART_INT_GRP26
+
/* External GIC */
#define EXYNOS4210_EXT_GIC_CPU_BASE_ADDR0x1048
#define EXYNOS4210_EXT_GIC_DIST_BASE_ADDR 0x1049
@@ -198,5 +210,22 @@ Exynos4210State *exynos4210_init(MemoryRegion *system_mem,
memory_region_add_subregion(system_mem, EXYNOS4210_SECOND_CPU_BOOTREG,
s-bootreg_mem);
+/*** UARTs ***/
+exynos4210_uart_create(EXYNOS4210_UART0_BASE_ADDR,
+ EXYNOS4210_UART0_FIFO_SIZE, 0, NULL,
+irq_table[exynos4210_get_irq(EXYNOS4210_UART_INT_GRP, 0)]);
+
+exynos4210_uart_create(EXYNOS4210_UART1_BASE_ADDR,
+ EXYNOS4210_UART1_FIFO_SIZE, 1, NULL,
+irq_table[exynos4210_get_irq(EXYNOS4210_UART_INT_GRP, 1)]);
+
+exynos4210_uart_create(EXYNOS4210_UART2_BASE_ADDR,
+ EXYNOS4210_UART2_FIFO_SIZE, 2, NULL,
+irq_table[exynos4210_get_irq(EXYNOS4210_UART_INT_GRP, 2)]);
+
+exynos4210_uart_create(EXYNOS4210_UART3_BASE_ADDR,
+ EXYNOS4210_UART3_FIFO_SIZE, 3, NULL,
+irq_table[exynos4210_get_irq(EXYNOS4210_UART_INT_GRP, 3)]);
+
return s;
}
diff --git a/hw/exynos4210.h b/hw/exynos4210.h
index a68900d..008b94f 100644
--- a/hw/exynos4210.h
+++ b/hw/exynos4210.h
@@ -116,4 +116,13 @@ uint32_t exynos4210_get_irq(uint32_t grp, uint32_t bit);
void exynos4210_combiner_get_gpioin(Exynos4210Irq *irqs, DeviceState *dev,
int ext);
+/*
+ * exynos4210 UART
+ */
+DeviceState *exynos4210_uart_create(target_phys_addr_t addr,
+int fifo_size,
+int channel,
+CharDriverState *chr,
+qemu_irq irq);
+
#endif /* EXYNOS4210_H_ */
diff --git a/hw/exynos4210_uart.c b/hw/exynos4210_uart.c
new file mode 100644
index 000..0b500d1
--- /dev/null
+++ b/hw/exynos4210_uart.c
@@ -0,0 +1,668 @@
+/*
+ * exynos4210 UART Emulation
+ *
+ * Copyright (C) 2011 Samsung Electronics Co Ltd.
+ *Maksim Kozlov, m.koz...@samsung.com
+ *
+ * Created on: 07.2011
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see http://www.gnu.org/licenses/.
+ *
+ */
+
+#include sysbus.h
+#include sysemu.h
+#include qemu-char.h
+
+#include exynos4210.h
+
+#undef DEBUG_UART
+#undef DEBUG_UART_EXTEND
+#undef DEBUG_IRQ
+#undef DEBUG_Rx_DATA
+#undef DEBUG_Tx_DATA
+
+
+//#define DEBUG_UART
+//#define DEBUG_UART_EXTEND
+//#define DEBUG_IRQ
+//#define DEBUG_Rx_DATA
+//#define DEBUG_Tx_DATA
+
+
+#define PRINT_DEBUG(fmt, args...) \
+do {} while (0)
+#define PRINT_DEBUG_EXTEND(fmt, args...) \
+do {} while (0)
+#define
Re: [Qemu-devel] [PATCH v2] rbd: wire up snapshot removal and rollback functionality
On Wed, Jan 11, 2012 at 7:53 PM, Gregory Farnum gregory.far...@dreamhost.com wrote: Signed-off-by: Greg Farnum gregory.far...@dreamhost.com --- Remove redundant warnings and add Kevin to the CC. block/rbd.c | 22 ++ 1 files changed, 22 insertions(+), 0 deletions(-) Reviewed-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
Re: [Qemu-devel] [PATCH 00/11] virtio-scsi device model
On 01/12/2012 06:17 AM, Hu Tao wrote: Hi Paolo, How to add a virtio-scsi device? What parameters should I specify in qemu command line? Same as with other SCSI devices: -device virtio-scsi-pci then for every disk -drive if=none,file=PATH,id=NAME -device scsi-hd,drive=NAME (or scsi-cd for a CD-ROM drive). Paolo
Re: [Qemu-devel] [PATCH v2] rbd: wire up snapshot removal and rollback functionality
Am 12.01.2012 10:40, schrieb Stefan Hajnoczi: On Wed, Jan 11, 2012 at 7:53 PM, Gregory Farnum gregory.far...@dreamhost.com wrote: Signed-off-by: Greg Farnum gregory.far...@dreamhost.com --- Remove redundant warnings and add Kevin to the CC. block/rbd.c | 22 ++ 1 files changed, 22 insertions(+), 0 deletions(-) Reviewed-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com Thanks, applied to the block branch. Kevin
Re: [Qemu-devel] [PATCH 3/3] stop the periodic RTC update timer
On Thu, Jan 12, 2012 at 12:00:06AM +, Zhang, Yang Z wrote: -Original Message- From: Marcelo Tosatti [mailto:mtosa...@redhat.com] Regarding the UIP bit, a guest could read it in a loop and wait for the value to change. But you can emulate it in cmos_ioport_read by reading the host time, that is, return 1 during 244us, 0 for remaining of the second, and have that in sync with update-cycle-ended interrupt if its enabled. Yes. Guest may use the loop to read RTC, but the point is the guest is waiting for the UIP changed to 0. If this bit always equal to 0 , guest will never go into the loop. For real RTC, this may wrong, because the RTC cannot give you the valid value during the update cycle. But the virtual RTC doesn't' need this logic, whenever you read it, it will always return the right value to you. Can't it wait a change from 0 to 1?
Re: [Qemu-devel] [PATCH 3/3] stop the periodic RTC update timer
On Thu, Jan 12, 2012 at 07:59:06AM -0200, Marcelo Tosatti wrote: On Thu, Jan 12, 2012 at 12:00:06AM +, Zhang, Yang Z wrote: -Original Message- From: Marcelo Tosatti [mailto:mtosa...@redhat.com] Regarding the UIP bit, a guest could read it in a loop and wait for the value to change. But you can emulate it in cmos_ioport_read by reading the host time, that is, return 1 during 244us, 0 for remaining of the second, and have that in sync with update-cycle-ended interrupt if its enabled. Yes. Guest may use the loop to read RTC, but the point is the guest is waiting for the UIP changed to 0. If this bit always equal to 0 , guest will never go into the loop. For real RTC, this may wrong, because the RTC cannot give you the valid value during the update cycle. But the virtual RTC doesn't' need this logic, whenever you read it, it will always return the right value to you. Can't it wait a change from 0 to 1? The point is the guest can use the hardware as it pleases, not only as is suggested in the hardware documentation.
Re: [Qemu-devel] [PATCH v4 01/15] coroutine: add co_sleep_ns() coroutine sleep function
Am 06.01.2012 15:01, schrieb Stefan Hajnoczi: Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com --- Makefile.objs |1 + qemu-coroutine-sleep.c | 38 ++ qemu-coroutine.h |6 ++ 3 files changed, 45 insertions(+), 0 deletions(-) create mode 100644 qemu-coroutine-sleep.c diff --git a/qemu-coroutine.h b/qemu-coroutine.h index 8a55fe1..bae1ffe 100644 --- a/qemu-coroutine.h +++ b/qemu-coroutine.h @@ -17,6 +17,7 @@ #include stdbool.h #include qemu-queue.h +#include qemu-timer.h /** * Coroutines are a mechanism for stack switching and can be used for @@ -199,4 +200,9 @@ void qemu_co_rwlock_wrlock(CoRwlock *lock); */ void qemu_co_rwlock_unlock(CoRwlock *lock); +/** + * Yield the coroutine for a given duration + */ +void coroutine_fn co_sleep_ns(QEMUClock *clock, int64_t ns); + #endif /* QEMU_COROUTINE_H */ As you mentioned on IRC yesterday, timers don't work in the tools. There should probably be a warning in the comment (or a fix before this is merged) Kevin
[Qemu-devel] [Bug 870990] Re: compile failure on ARMv7 hosts when compiled for thumb if --enable-debug
** Changed in: qemu-linaro Status: Fix Committed = Fix Released ** Changed in: qemu Status: New = Fix Committed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/870990 Title: compile failure on ARMv7 hosts when compiled for thumb if --enable- debug Status in QEMU: Fix Committed Status in Linaro QEMU: Fix Released Bug description: QEMU won't compile if you configure --enable-debug and gcc is building in Thumb2. This is because we have picked r7 as the TCG_AREG0 (fixed register for holding the CPU environment pointer), which clashes with its use as the frame pointer in Thumb. (ARM compilation is fine because the frame pointer is a different register there.) We could fix this by forcing -fomit-frame-pointer when compiling the relevant source files (which is what we do on x86 where register pressure forces us to use EBP for AREG0) but it would be much better to just move AREG0 to something else. We can use r6 if we want to stick with a low-reg, or move up to r8 if we think a high-reg likely to be a better choice. TODO: * compile with both r6 and r8, and do a trivial benchmarking run * submit patch (before the upstream 1.0 freeze!) NB: AREG0 is set in two places that need to stay in sync: dyngen- exec.h and tcg/arm/tcg-target.h To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/870990/+subscriptions
Re: [Qemu-devel] [PATCH] hw/lan9118: Add save/load support
On 12/20/2011 02:01 AM, Peter Maydell wrote:
Implement save/load for the LAN9118.
Signed-off-by: Peter Maydellpeter.mayd...@linaro.org
---
Does anybody have a nicer solution to the can't put an enum in a
VMStateDescription problem?
hw/lan9118.c | 126 +++---
1 files changed, 103 insertions(+), 23 deletions(-)
diff --git a/hw/lan9118.c b/hw/lan9118.c
index 7e64c5d..6542a26 100644
--- a/hw/lan9118.c
+++ b/hw/lan9118.c
@@ -136,17 +136,36 @@ enum tx_state {
};
Hi Peter, I have a small question. Wouldn't it be better to use uint32_t
for variables that actually have positive values only? That would make
code easier to understand. For example in this state
typedef struct {
-enum tx_state state;
+/* state is a tx_state but we can't put enums in VMStateDescriptions. */
+uint32_t state;
uint32_t cmd_a;
uint32_t cmd_b;
-int buffer_size;
-int offset;
-int pad;
-int fifo_used;
-int len;
+int32_t buffer_size;
+int32_t offset;
+int32_t pad;
+int32_t fifo_used;
+int32_t len;
uint8_t data[2048];
} LAN9118Packet;
all member variables (except maybe buffer_size) can have positive values
only. buffer_size is probably positive-only too because this code
while (n--) {
s-txp-data[s-txp-len] = val 0xff;
s-txp-len++;
val = 8;
s-txp-buffer_size--;
}
looks wrong (I haven't dug dip into it though) and must be
...
while (s-txp-buffer_size (n--)) {
...
--
Mitsyanko Igor
ASWG, Moscow RD center, Samsung Electronics
email: i.mitsya...@samsung.com
Re: [Qemu-devel] [PATCH] hw/lan9118: Add save/load support
On 12 January 2012 10:16, Mitsyanko Igor i.mitsya...@samsung.com wrote: Hi Peter, I have a small question. Wouldn't it be better to use uint32_t for variables that actually have positive values only? That would make code easier to understand. The idea is to do a straightforward and easy to review conversion. Switching from signed to unsigned changes semantics of the variable in a way that requires review of all the code that used that variable, so it's riskier. -- PMM
[Qemu-devel] [Bug 893208] Re: qemu on ARM hosts can't boot i386 image
On the basis of this analysis by David and since we don't seem to have problems with ARM guests on ARM hosts, I think we can deprioritise this bug as not being a requirement for KVM work. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/893208 Title: qemu on ARM hosts can't boot i386 image Status in QEMU: New Status in Linaro QEMU: New Bug description: If you apply some workarounds for bug 870990, bug 883133 and bug 883136 QEMU still cannot boot the i386 debian_squeeze_i386_standard.qcow2 image from http://people.debian.org/~aurel32/qemu/i386/ -- grub starts to boot but something causes the system to reset just before display of the blue-background grub menu, so we go round in a loop forever. This image boots OK on i386 hosted qemu so this indicates some kind of ARM- host specific bug. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/893208/+subscriptions
[Qemu-devel] [Bug 883133] Re: qemu on ARM hosts asserts due to code buffer/libc heap conflict
** Changed in: qemu-linaro Status: Fix Committed = Triaged ** Changed in: qemu-linaro Status: Triaged = 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/883133 Title: qemu on ARM hosts asserts due to code buffer/libc heap conflict Status in QEMU: Fix Committed Status in Linaro QEMU: Fix Released Bug description: On ARM hosts qemu (about half the time) asserts on startup: qemu-system-i386: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char *) ((av)-bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd old_size == 0) || ((unsigned long) (old_size) = (unsigned long)__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * (sizeof(size_t))) - 1)) ~((2 * (sizeof(size_t))) - 1))) ((old_top)-size 0x1) ((unsigned long)old_end pagemask) == 0)' failed. This turns out to be because code_gen_alloc() is using mmap(MAP_FIXED) to map the code buffer at address 0x0100UL, which is in the area glibc happens to be using for its heap. This tends to make the next malloc() abort, although occasionally the stars align and we pass that and fail weirdly later on. I suspect we need to drop the MAP_FIXED requirement and fix the TCG code to cope with emitting code for longer-range branches for calls to host fns etc (calls/branches within the generated code should be ok to keep using the short-range branch insn I think). There is already no guarantee that the generated code and the host C code are within short branch range of each other... To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/883133/+subscriptions
Re: [Qemu-devel] [PATCH 3/3] stop the periodic RTC update timer
On Thu, Jan 12, 2012 at 10:26:17AM +0100, Paolo Bonzini wrote: On 01/12/2012 01:00 AM, Zhang, Yang Z wrote: Regarding the UIP bit, a guest could read it in a loop and wait for the value to change. But you can emulate it in cmos_ioport_read by reading the host time, that is, return 1 during 244us, 0 for remaining of the second, and have that in sync with update-cycle-ended interrupt if its enabled. Yes. Guest may use the loop to read RTC, but the point is the guest is waiting for the UIP changed to 0. If this bit always equal to 0 , guest will never go into the loop. For real RTC, this may wrong, because the RTC cannot give you the valid value during the update cycle. But the virtual RTC doesn't' need this logic, whenever you read it, it will always return the right value to you. The point is not _correctness_. It is _atomicity_. Quoting you earlier This is incorrect, for two reasons. First, the UIP is in the spec, and we have to implement it. Second, reading the clock is not atomic, and waiting for UIP=0 gives you 220 microseconds during which you know that the read will appear atomic. Agree with the first point, but the second, the emulated RTC never returns a bogus read. So what is your point, exactly? And what that has to do with UIP always returning 0?
[Qemu-devel] [Bug 883136] Re: qemu on ARM hosts aborts on startup because makecontext() always fails
Plan: (a) get makecontext added to eglibc (b) see if upstream eglibc are open to the idea of some sort of #define for MAKECONTEXT_ACTUALLY_IMPLEMENTED_NOW so we can detect it at compile time (c) otherwise, work around in qemu (probably by adding another layer of indirection) -- 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: New Status in Linaro QEMU: In Progress 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
Re: [Qemu-devel] [PATCH] (dont commit) virtio-gl-fixes for build on F17
On Tue, Jan 10, 2012 at 08:13:00PM +0100, andrzej zaborowski wrote:
On 10 January 2012 09:44, Alon Levy al...@redhat.com wrote:
All but the last are assigned but unused variables,
and an always true comparison, but the last looks like a logic
error - decode not returning the actual return value for the last call
in the buffer (vmgl-exec.c).
---
gl/gloffscreen-xcomposite.c | 4 +---
gl/vmgl-exec.c | 10 +-
2 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/gl/gloffscreen-xcomposite.c b/gl/gloffscreen-xcomposite.c
index 5c63ed4..00a419b 100644
--- a/gl/gloffscreen-xcomposite.c
+++ b/gl/gloffscreen-xcomposite.c
@@ -186,8 +186,6 @@ static void glo_test_readback_methods(void)
/* Initialise gloffscreen */
int glo_init(void)
{
- XErrorHandler old_handler;
-
if (glo_inited) {
return 0;
}
@@ -204,7 +202,7 @@ int glo_init(void)
/* Safe because we are single threaded. Otherwise we cause recursion
* on the next call. Set the X error handler. */
glo_inited = 1;
- old_handler = XSetErrorHandler(x_errhandler);
+ (void)XSetErrorHandler(x_errhandler);
glo_test_readback_methods();
return 0;
diff --git a/gl/vmgl-exec.c b/gl/vmgl-exec.c
index e538ff4..3cf5eba 100644
--- a/gl/vmgl-exec.c
+++ b/gl/vmgl-exec.c
@@ -668,7 +668,7 @@ static int glXGetConfigFunc(uint32_t visualid, uint32_t
attrib, uint32_t *value)
{
const VmglGLXFBConfig *config = fbconfigs[0];
- if (visualid = 0 visualid ARRAY_SIZE(fbconfigs)) {
+ if (visualid ARRAY_SIZE(fbconfigs)) {
config = fbconfigs[visualid];
} else {
DEBUGF(Unknown visual ID %d\n, visualid);
@@ -3072,11 +3072,12 @@ static inline int do_decode_call(ProcessStruct *p,
const uint8_t *args_in,
int args_len, uint8_t *r_buffer)
{
Signature *signature;
- int i, ret;
- const uint8_t *arg_ptr, *tmp;
+ int i;
+ const uint8_t *arg_ptr;
static arg_t args[50];
int func_number;
ProcessState *process = DO_UPCAST(ProcessState, p, p);
+ int ret = 1;
if (!args_len) {
return 0;
@@ -3099,7 +3100,6 @@ static inline int do_decode_call(ProcessStruct *p,
const uint8_t *args_in,
#endif
signature = (Signature *) tab_opengl_calls[func_number];
- tmp = arg_ptr;
for (i = 0; i signature-nb_args; i++) {
int args_size = *(const uint32_t *) arg_ptr;
@@ -3220,7 +3220,7 @@ static inline int do_decode_call(ProcessStruct *p,
const uint8_t *args_in,
}
#endif
- return 1;
+ return ret;
Thanks for the compile test. I think I was meaning to check ret after
every do_function_call call and return immediately if 0. I'll fix it
in a future iteration and add your other fixes if you don't mind.
Don't mind at all! But for some reason this email and the other one I
send before it to you and to the qemu-devel list didn't reach the list.
If you saw this email is it too much to assume you saw the other one as
well?
Cheers
Re: [Qemu-devel] [PATCH 3/3] stop the periodic RTC update timer
On 01/12/2012 11:20 AM, Marcelo Tosatti wrote: The point is not_correctness_. It is_atomicity_. Quoting you earlier This is incorrect, for two reasons. First, the UIP is in the spec, and we have to implement it. Second, reading the clock is not atomic, and waiting for UIP=0 gives you 220 microseconds during which you know that the read will appear atomic. (The actual figure is 244, not 220; my mistake). Agree with the first point, but the second, the emulated RTC never returns a bogus read. That's true: the update cycle takes 1984 us on the real RTC, and 0 us on QEMU. However, the data sheet says that the update cycle begins 244 us _after_ the rising edge of UIP. In other words, UIP is set for 1984 + 244 us on the real RTC, and should be set for 0 + 244 us on the emulated RTC. This is done on purpose: the data sheet says, if a low is read on the UIP bit, the user has at least 244 us before the time/calendar data will be changed. As long as you read the time within 244 us, the following cannot happen: read UIP = 0 read HOURS = 10 read MINUTES = 59 read SECONDS = 59 ... read UIP = 0 read HOURS = 10 read MINUTES = 59 update happens! (on real RTC: update cycle starts) read SECONDS = 0 (on real RTC: undefined) You are a kernel junkie and as such you are too much accustomed to seqlocks. ;) If you know the read will take more than 244 us, the data sheet suggests that you use the update-ended interrupt. But you can also wait for the falling edge of UIP, like Xen does. The falling edge of UIP will never happen if the emulated RTC always returns 0 for UIP. Paolo
Re: [Qemu-devel] [PATCH 3/3] stop the periodic RTC update timer
-Original Message- From: Marcelo Tosatti [mailto:mtosa...@redhat.com] Sent: Thursday, January 12, 2012 6:03 PM To: Zhang, Yang Z Cc: qemu-devel@nongnu.org; a...@redhat.com; aligu...@us.ibm.com; Zhang, Xiantao; Shan, Haitao; k...@vger.kernel.org Subject: Re: [PATCH 3/3] stop the periodic RTC update timer On Thu, Jan 12, 2012 at 07:59:06AM -0200, Marcelo Tosatti wrote: On Thu, Jan 12, 2012 at 12:00:06AM +, Zhang, Yang Z wrote: -Original Message- From: Marcelo Tosatti [mailto:mtosa...@redhat.com] Regarding the UIP bit, a guest could read it in a loop and wait for the value to change. But you can emulate it in cmos_ioport_read by reading the host time, that is, return 1 during 244us, 0 for remaining of the second, and have that in sync with update-cycle-ended interrupt if its enabled. Yes. Guest may use the loop to read RTC, but the point is the guest is waiting for the UIP changed to 0. If this bit always equal to 0 , guest will never go into the loop. For real RTC, this may wrong, because the RTC cannot give you the valid value during the update cycle. But the virtual RTC doesn't' need this logic, whenever you read it, it will always return the right value to you. Can't it wait a change from 0 to 1? The point is the guest can use the hardware as it pleases, not only as is suggested in the hardware documentation. You are right. I will add it to next version. best regards yang
Re: [Qemu-devel] [PATCH v4 04/15] block: add image streaming block job
Am 06.01.2012 15:01, schrieb Stefan Hajnoczi:
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
Makefile.objs |1 +
block/stream.c | 119
block_int.h|3 +
trace-events |4 ++
4 files changed, 127 insertions(+), 0 deletions(-)
create mode 100644 block/stream.c
diff --git a/Makefile.objs b/Makefile.objs
index 64d84de..fde3769 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -35,6 +35,7 @@ block-nested-y += qcow2.o qcow2-refcount.o qcow2-cluster.o
qcow2-snapshot.o qcow
block-nested-y += qed.o qed-gencb.o qed-l2-cache.o qed-table.o qed-cluster.o
block-nested-y += qed-check.o
block-nested-y += parallels.o nbd.o blkdebug.o sheepdog.o blkverify.o
+block-nested-y += stream.o
block-nested-$(CONFIG_WIN32) += raw-win32.o
block-nested-$(CONFIG_POSIX) += raw-posix.o
block-nested-$(CONFIG_LIBISCSI) += iscsi.o
diff --git a/block/stream.c b/block/stream.c
new file mode 100644
index 000..8ff98cf
--- /dev/null
+++ b/block/stream.c
@@ -0,0 +1,119 @@
+/*
+ * Image streaming
+ *
+ * Copyright IBM, Corp. 2011
+ *
+ * Authors:
+ * Stefan Hajnoczi stefa...@linux.vnet.ibm.com
+ *
+ * This work is licensed under the terms of the GNU LGPL, version 2 or later.
+ * See the COPYING.LIB file in the top-level directory.
+ *
+ */
+
+#include trace.h
+#include block_int.h
+
+enum {
+/*
+ * Size of data buffer for populating the image file. This should be
large
+ * enough to process multiple clusters in a single call, so that
populating
+ * contiguous regions of the image is efficient.
+ */
+STREAM_BUFFER_SIZE = 512 * 1024, /* in bytes */
+};
+
+typedef struct StreamBlockJob {
+BlockJob common;
+BlockDriverState *base;
+} StreamBlockJob;
+
+static int coroutine_fn stream_populate(BlockDriverState *bs,
+int64_t sector_num, int nb_sectors,
+void *buf)
+{
+struct iovec iov = {
+.iov_base = buf,
+.iov_len = nb_sectors * BDRV_SECTOR_SIZE,
+};
+QEMUIOVector qiov;
+
+qemu_iovec_init_external(qiov, iov, 1);
+
+/* Copy-on-read the unallocated clusters */
+return bdrv_co_readv(bs, sector_num, nb_sectors, qiov);
+}
+
+static void coroutine_fn stream_run(void *opaque)
+{
+StreamBlockJob *s = opaque;
+BlockDriverState *bs = s-common.bs;
+int64_t sector_num, end;
+int ret = 0;
+int n;
+void *buf;
+
+buf = qemu_blockalign(bs, STREAM_BUFFER_SIZE);
+s-common.len = bdrv_getlength(bs);
No error check?
+bdrv_get_geometry(bs, (uint64_t *)end);
Why call bdrv_getlength() twice? end = s-common.len BDRV_SECTOR_BITS
should be the same.
Kevin
Re: [Qemu-devel] [PATCH v4 01/15] coroutine: add co_sleep_ns() coroutine sleep function
On Thu, Jan 12, 2012 at 10:13 AM, Kevin Wolf kw...@redhat.com wrote: Am 06.01.2012 15:01, schrieb Stefan Hajnoczi: Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com --- Makefile.objs | 1 + qemu-coroutine-sleep.c | 38 ++ qemu-coroutine.h | 6 ++ 3 files changed, 45 insertions(+), 0 deletions(-) create mode 100644 qemu-coroutine-sleep.c diff --git a/qemu-coroutine.h b/qemu-coroutine.h index 8a55fe1..bae1ffe 100644 --- a/qemu-coroutine.h +++ b/qemu-coroutine.h @@ -17,6 +17,7 @@ #include stdbool.h #include qemu-queue.h +#include qemu-timer.h /** * Coroutines are a mechanism for stack switching and can be used for @@ -199,4 +200,9 @@ void qemu_co_rwlock_wrlock(CoRwlock *lock); */ void qemu_co_rwlock_unlock(CoRwlock *lock); +/** + * Yield the coroutine for a given duration + */ +void coroutine_fn co_sleep_ns(QEMUClock *clock, int64_t ns); + #endif /* QEMU_COROUTINE_H */ As you mentioned on IRC yesterday, timers don't work in the tools. There should probably be a warning in the comment (or a fix before this is merged) This is something I'm looking at right now and will probably want to discuss with Paolo. In a coroutine we're probably using a main loop and timers should be available there. In general, the problem we're starting to see is that some block layer features are using timers (I/O throttling, QED deferred dirty bit clearing, image streaming). The question is do we isolate this functionality so it is unavailable from a qemu-tool world when there's no main loop, or do we move everything into a main loop? Stefan
Re: [Qemu-devel] [PATCH v4 01/15] coroutine: add co_sleep_ns() coroutine sleep function
On 01/12/2012 11:58 AM, Stefan Hajnoczi wrote:
This is something I'm looking at right now and will probably want to
discuss with Paolo.
In a coroutine we're probably using a main loop and timers should be
available there. In general, the problem we're starting to see is
that some block layer features are using timers (I/O throttling, QED
deferred dirty bit clearing, image streaming). The question is do we
isolate this functionality so it is unavailable from a qemu-tool world
when there's no main loop, or do we move everything into a main loop?
Yes, I would move things into a main loop just like qemu-nbd does. I
even had some prototype patches for it. The qemu-img part is broken
because it uses callbacks that haven't been made asynchronous yet; the
one for qemu-io should be okay modulo some more testing.
Paolo
From 9b67defc5eacb9254a8140a4daa52949f0fe60e2 Mon Sep 17 00:00:00 2001
From: Paolo Bonzini pbonz...@redhat.com
Date: Mon, 26 Sep 2011 10:59:46 +0200
Subject: [PATCH 1/2] qemu-io: use main_loop_wait
This will let timers run during aio_read and aio_write commands,
though not during synchronous commands.
Not-tested-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
cmd.c | 10 +-
qemu-io.c |8 +---
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/cmd.c b/cmd.c
index 0806e18..7ffbb71 100644
--- a/cmd.c
+++ b/cmd.c
@@ -25,6 +25,7 @@
#include cmd.h
#include qemu-aio.h
+#include main-loop.h
#define _(x) x /* not gettext support yet */
@@ -146,7 +147,7 @@ static void prep_fetchline(void *opaque)
{
int *fetchable = opaque;
-qemu_aio_set_fd_handler(STDIN_FILENO, NULL, NULL, NULL, NULL, NULL);
+qemu_set_fd_handler(STDIN_FILENO, NULL, NULL, NULL);
*fetchable= 1;
}
@@ -193,12 +194,11 @@ void command_loop(void)
if (!prompted) {
printf(%s, get_prompt());
fflush(stdout);
-qemu_aio_set_fd_handler(STDIN_FILENO, prep_fetchline, NULL, NULL,
-NULL, fetchable);
+qemu_set_fd_handler(STDIN_FILENO, prep_fetchline, NULL, fetchable);
prompted = 1;
}
-qemu_aio_wait();
+main_loop_wait(false);
if (!fetchable) {
continue;
@@ -221,7 +221,7 @@ void command_loop(void)
prompted = 0;
fetchable = 0;
}
-qemu_aio_set_fd_handler(STDIN_FILENO, NULL, NULL, NULL, NULL, NULL);
+qemu_set_fd_handler(STDIN_FILENO, NULL, NULL, NULL);
}
/* from libxcmd/input.c */
diff --git a/qemu-io.c b/qemu-io.c
index ffa62fb..6e1bee3 100644
--- a/qemu-io.c
+++ b/qemu-io.c
@@ -15,6 +15,7 @@
#include libgen.h
#include qemu-common.h
+#include main-loop.h
#include block_int.h
#include cmd.h
@@ -249,7 +250,7 @@ static int do_aio_readv(QEMUIOVector *qiov, int64_t offset, int *total)
bdrv_aio_readv(bs, offset 9, qiov, qiov-size 9,
aio_rw_done, async_ret);
while (async_ret == NOT_DONE) {
-qemu_aio_wait();
+main_loop_wait(false);
}
*total = qiov-size;
@@ -263,7 +264,7 @@ static int do_aio_writev(QEMUIOVector *qiov, int64_t offset, int *total)
bdrv_aio_writev(bs, offset 9, qiov, qiov-size 9,
aio_rw_done, async_ret);
while (async_ret == NOT_DONE) {
-qemu_aio_wait();
+main_loop_wait(false);
}
*total = qiov-size;
@@ -306,7 +307,7 @@ static int do_aio_multiwrite(BlockRequest* reqs, int num_reqs, int *total)
}
while (async_ret.num_done num_reqs) {
-qemu_aio_wait();
+main_loop_wait(false);
}
return async_ret.error 0 ? async_ret.error : 1;
@@ -1793,6 +1794,7 @@ int main(int argc, char **argv)
exit(1);
}
+qemu_init_main_loop();
bdrv_init();
/* initialize commands */
--
1.7.7.1
From ac2958b0992dcd155ab76885cac044a9fec5cc06 Mon Sep 17 00:00:00 2001
From: Paolo Bonzini pbonz...@redhat.com
Date: Tue, 18 Oct 2011 12:20:44 +0200
Subject: [PATCH 2/2] qemu-img: run commands in coroutine context
The new function qemu_coroutine_schedule is in qemu-coroutine-lock.c
since it's where the other dependencies on the main loop reside.
Not-tested-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
main-loop.h | 20 ++--
qemu-coroutine-lock.c | 24
qemu-coroutine.h |8
qemu-img.c| 40
4 files changed, 70 insertions(+), 22 deletions(-)
diff --git a/main-loop.h b/main-loop.h
index f971013..4e99485 100644
--- a/main-loop.h
+++ b/main-loop.h
@@ -59,24 +59,16 @@ int qemu_init_main_loop(void);
* It is sometimes useful to put a whole program in a coroutine. In this
* case, the coroutine actually should be started from within the main loop,
* so that the main loop can run whenever the coroutine yields. To do this,
Re: [Qemu-devel] [PATCH v4 04/15] block: add image streaming block job
On Thu, Jan 12, 2012 at 10:59 AM, Kevin Wolf kw...@redhat.com wrote: Am 06.01.2012 15:01, schrieb Stefan Hajnoczi: + buf = qemu_blockalign(bs, STREAM_BUFFER_SIZE); + s-common.len = bdrv_getlength(bs); No error check? Will fix. + bdrv_get_geometry(bs, (uint64_t *)end); Why call bdrv_getlength() twice? end = s-common.len BDRV_SECTOR_BITS should be the same. Okay, I'll change it. I got sick of BDRV_SECTOR_* and called twice instead.
Re: [Qemu-devel] [PATCH v4 11/15] block: add bdrv_find_backing_image
Am 06.01.2012 15:01, schrieb Stefan Hajnoczi:
From: Marcelo Tosatti mtosa...@redhat.com
Add bdrv_find_backing_image: given a BlockDriverState pointer, and an id,
traverse the backing image chain to locate the id.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
block.c | 17 +
block.h |1 +
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/block.c b/block.c
index 5bfaa3a..9b688a0 100644
--- a/block.c
+++ b/block.c
@@ -2614,6 +2614,23 @@ int bdrv_snapshot_load_tmp(BlockDriverState *bs,
return -ENOTSUP;
}
+BlockDriverState *bdrv_find_backing_image(BlockDriverState *bs, const char
*id)
+{
+if (!bs-drv) {
+return NULL;
+}
+
+if (bs-backing_hd) {
+if (strcmp(bs-backing_file, id) == 0) {
+return bs-backing_hd;
So it's not really just some id, but the backing file name? I would find
it clearer to reflect that in the parameter name and the QMP error in
the next patch.
Kevin
Re: [Qemu-devel] [PATCH v4 13/15] block stream: add support for partial streaming
Am 06.01.2012 15:01, schrieb Stefan Hajnoczi: From: Marcelo Tosatti mtosa...@redhat.com Add support for streaming data from an intermediate section of the image chain (see patch and documentation for details). Signed-off-by: Marcelo Tosatti mtosa...@redhat.com Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com --- block.c| 64 block.h|4 +++ block/stream.c | 28 +--- block_int.h|3 +- blockdev.c | 11 ++--- 5 files changed, 101 insertions(+), 9 deletions(-) diff --git a/block.c b/block.c index 9b688a0..d2143b1 100644 --- a/block.c +++ b/block.c @@ -2263,6 +2263,70 @@ int bdrv_is_allocated(BlockDriverState *bs, int64_t sector_num, int nb_sectors, return data.ret; } +/* + * Given an image chain: [BASE] - [INTER1] - [INTER2] - [TOP] + * + * Return true if the given sector is allocated in top or base. + * Return false if the given sector is allocated in intermediate images. This description is inexact. A sector could be allocated both in base in an intermediate image. Also initially I thought that we not only need to check whether the sector is allocated in BASE, but also in any parents of BASE. You don't do this: Clusters that are completely unallocated all through the chain are reported as allocated. After reading all of the patch, I believe this provides the right semantics: Normal image streaming would copy them into the topmost file, but if you keep a backing file, you want to copy as little as possible and keep using the backing file whenever possible. So I suggest to fix the description rather than the implementation. Maybe we should also rename the function. With this semantics it's not a generic is_allocated function any more, but something quite specific to streaming with a base file. Kevin
Re: [Qemu-devel] [PATCH v9 5/6] arm: SoC model for Calxeda Highbank
On 01/11/2012 08:31 PM, Mark Langsdorf wrote:
Removed the automatic detection and resetting of ram_size. Image MUST
be loaded with -m 4089 or it will crash
I don't know what is maintainer's politics on this, but as a user of
your board I don't really like that I will have to remember this strange
number when I launch Highbank emulation. Have you considered adding an
automatic upper limitation to user-defined ram_size?
+sysram = g_new(MemoryRegion, 1);
+memory_region_init_ram(sysram, highbank.sysram, 0x8000);
+memory_region_add_subregion(sysmem, 0xfff88000, sysram);
+if (bios_name != NULL) {
+sysboot_filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name);
+if (sysboot_filename != NULL) {
+uint32_t filesize = get_image_size(sysboot_filename);
+if (load_image_targphys(sysram.bin, 0xfff88000, filesize) 0) {
+hw_error(Unable to load %s\n, bios_name);
+}
Probably should be
if (load_image_targphys(sysboot_filename, 0xfff88000, 0x8000) 0) {
and then you don't need uint32_t filesize at all.
+dev = qdev_create(NULL, l2x0);
+qdev_init_nofail(dev);
+busdev = sysbus_from_qdev(dev);
+sysbus_mmio_map(busdev, 0, 0xfff12000);
+dev = qdev_create(NULL, highbank-regs);
+qdev_init_nofail(dev);
+busdev = sysbus_from_qdev(dev);
+sysbus_mmio_map(busdev, 0, 0xfff3c000);
+
You can use sysbus_create_simple() here (of course, if you didn't avoid
it intentionally for some reason).
--
Mitsyanko Igor
ASWG, Moscow RD center, Samsung Electronics
email: i.mitsya...@samsung.com
Re: [Qemu-devel] [PATCH v4 04/15] block: add image streaming block job
Am 12.01.2012 12:39, schrieb Stefan Hajnoczi: On Thu, Jan 12, 2012 at 10:59 AM, Kevin Wolf kw...@redhat.com wrote: Am 06.01.2012 15:01, schrieb Stefan Hajnoczi: +buf = qemu_blockalign(bs, STREAM_BUFFER_SIZE); +s-common.len = bdrv_getlength(bs); No error check? Will fix. +bdrv_get_geometry(bs, (uint64_t *)end); Why call bdrv_getlength() twice? end = s-common.len BDRV_SECTOR_BITS should be the same. Okay, I'll change it. I got sick of BDRV_SECTOR_* and called twice instead. Well, you can try and change everything in the streaming code to bytes instead of sectors. We should probably do this sooner or later anyway. Sectors of 512 bytes are a completely arbitrary unit that doesn't make much sense generally. Kevin
Re: [Qemu-devel] [PATCH 1/5] i8259: qdev-ify creation
Am 12.01.2012 09:09, schrieb Jan Kiszka: On 2012-01-12 09:05, Alexander Graf wrote: On 12.01.2012, at 09:00, Jan Kiszka wrote: On 2012-01-12 08:58, Alexander Graf wrote: On 12.01.2012, at 08:35, Jan Kiszka wrote: On 2012-01-12 01:04, Andreas Färber wrote: Alex, I have this in my mailbox, but I'm still waiting for an SoB. Hervé? Regards, Andreas Original-Nachricht Betreff: [PATCH 1/5] i8259: qdev-ify creation Datum: Sun, 26 Jun 2011 14:47:09 +0200 Von: Hervé Poussineau hpous...@reactos.org An: andreas.faer...@web.de Kopie (CC): Hervé Poussineau hpous...@reactos.org --- hw/i8259.c | 53 + 1 files changed, 49 insertions(+), 4 deletions(-) [snip] This is obsolete. The i8259 has been significantly refactored (into two ISA devices) and qdev'ified some moons ago. The reason we were discussing this was a circular dependency on PREP. The PIC is sitting on the ISA bus. The ISA bus is behind a PCI-ISA bridge the PCI-ISA bridge is behind a PCI host controller the PCI host controller needs interrupt lines in its initialization which are attached to the PIC Any good ideas on how to resolve this? :) As we do this always: Split up initialization and IRQ line wiring. Well, yes, the theory is obvious. How would this look like in practice? To create a PIC device I need a bus: dev = isa_create(bus, isa-i8259); But to create the bus, I need an interrupt line, which I only get after I created the PIC device. ISA bus creation and IRQ assignment are split up IIRC. So far I haven't found a really qdev'ified example though. mips_malta uses qemu_irq_proxy() to pre-initialize 16 IRQ lines IIUC, but it does everything in a flat, sequential way, creating the i8259 on the board rather than on a chipset. I'll send v2 of my series later, with the part that works today for Anthony and the bridge that breaks. I'll cc you. Maybe we can use a QOM property to access the i8259 on the i82378? I'm aware we don't have PicState2 in upstream, so this patch doesn't apply; the interesting part from my view was that it adds a SysBus device as opposed to ISADevice, so doesn't need the ISABus. Going down that route would require to split PicState into an ISAPicState and SysBusPicState with shared core. Andreas
Re: [Qemu-devel] [PATCH v4 11/15] block: add bdrv_find_backing_image
On Thu, Jan 12, 2012 at 12:17 PM, Kevin Wolf kw...@redhat.com wrote:
Am 06.01.2012 15:01, schrieb Stefan Hajnoczi:
+BlockDriverState *bdrv_find_backing_image(BlockDriverState *bs, const char
*id)
+{
+ if (!bs-drv) {
+ return NULL;
+ }
+
+ if (bs-backing_hd) {
+ if (strcmp(bs-backing_file, id) == 0) {
+ return bs-backing_hd;
So it's not really just some id, but the backing file name? I would find
it clearer to reflect that in the parameter name and the QMP error in
the next patch.
Okay, thanks.
Re: [Qemu-devel] [PATCH v4 04/15] block: add image streaming block job
On Thu, Jan 12, 2012 at 12:53 PM, Kevin Wolf kw...@redhat.com wrote: Am 12.01.2012 12:39, schrieb Stefan Hajnoczi: On Thu, Jan 12, 2012 at 10:59 AM, Kevin Wolf kw...@redhat.com wrote: Am 06.01.2012 15:01, schrieb Stefan Hajnoczi: + buf = qemu_blockalign(bs, STREAM_BUFFER_SIZE); + s-common.len = bdrv_getlength(bs); No error check? Will fix. + bdrv_get_geometry(bs, (uint64_t *)end); Why call bdrv_getlength() twice? end = s-common.len BDRV_SECTOR_BITS should be the same. Okay, I'll change it. I got sick of BDRV_SECTOR_* and called twice instead. Well, you can try and change everything in the streaming code to bytes instead of sectors. We should probably do this sooner or later anyway. Sectors of 512 bytes are a completely arbitrary unit that doesn't make much sense generally. That doesn't work because block layer interfaces use nb_sectors. We still need to convert. Stefan
Re: [Qemu-devel] [Qemu-trivial] [PATCH] Add 'fall through' comments to case statements without break
On 10 January 2012 09:35, Stefan Hajnoczi stefa...@gmail.com wrote:
On Mon, Jan 09, 2012 at 06:29:51PM +0100, Stefan Weil wrote:
These comments are used by static code analysis tools and in code reviews
to avoid false warnings because of missing break statements.
The case statements handled here were reported by coverity.
Signed-off-by: Stefan Weil s...@weilnetz.de
---
hw/pcnet.c | 1 +
json-lexer.c | 1 +
qemu-option.c | 4
3 files changed, 6 insertions(+), 0 deletions(-)
This reminds me of another questionable fall-through:
bt-host.c:bt_host_read():
while (s-len --)
switch (*pkt ++) {
...
case HCI_SCODATA_PKT:
if (s-len 3)
goto bad_pkt;
pktlen = MIN(pkt[2] + 3, s-len);
s-len -= pktlen;
pkt += pktlen;
--- fall-through or not?
default:
bad_pkt:
fprintf(stderr, qemu: bad HCI packet type %02x\n, pkt[-1]);
}
It seems the code will skip HCI_SCODATA_PKT and report a warning (although
type
pkt[-1] will be incorrect). Any thoughts?
Yes, definitely there's a break missing. Bluetooth SCO links are like
USB Isochronous, so not really tested because they're only used by
streaming devices.
Cheers
Re: [Qemu-devel] [PATCH 1/5] i8259: qdev-ify creation
On 2012-01-12 13:54, Andreas Färber wrote: Am 12.01.2012 09:09, schrieb Jan Kiszka: On 2012-01-12 09:05, Alexander Graf wrote: On 12.01.2012, at 09:00, Jan Kiszka wrote: On 2012-01-12 08:58, Alexander Graf wrote: On 12.01.2012, at 08:35, Jan Kiszka wrote: On 2012-01-12 01:04, Andreas Färber wrote: Alex, I have this in my mailbox, but I'm still waiting for an SoB. Hervé? Regards, Andreas Original-Nachricht Betreff: [PATCH 1/5] i8259: qdev-ify creation Datum: Sun, 26 Jun 2011 14:47:09 +0200 Von: Hervé Poussineau hpous...@reactos.org An: andreas.faer...@web.de Kopie (CC): Hervé Poussineau hpous...@reactos.org --- hw/i8259.c | 53 + 1 files changed, 49 insertions(+), 4 deletions(-) [snip] This is obsolete. The i8259 has been significantly refactored (into two ISA devices) and qdev'ified some moons ago. The reason we were discussing this was a circular dependency on PREP. The PIC is sitting on the ISA bus. The ISA bus is behind a PCI-ISA bridge the PCI-ISA bridge is behind a PCI host controller the PCI host controller needs interrupt lines in its initialization which are attached to the PIC Any good ideas on how to resolve this? :) As we do this always: Split up initialization and IRQ line wiring. Well, yes, the theory is obvious. How would this look like in practice? To create a PIC device I need a bus: dev = isa_create(bus, isa-i8259); But to create the bus, I need an interrupt line, which I only get after I created the PIC device. ISA bus creation and IRQ assignment are split up IIRC. So far I haven't found a really qdev'ified example though. mips_malta uses qemu_irq_proxy() to pre-initialize 16 IRQ lines IIUC, but it does everything in a flat, sequential way, creating the i8259 on the board rather than on a chipset. As I said, the reason for this on the PC side is that fact that we model several variants with the same code, and one of them does this at board level. I'll send v2 of my series later, with the part that works today for Anthony and the bridge that breaks. I'll cc you. Maybe we can use a QOM property to access the i8259 on the i82378? I think the bridge doesn't need access to the PIC, it has to have it's output wired to the inputs of the latter. That can be done at the level that created both, ie. in the chipset (provided we refactor the init code accordingly). I'm aware we don't have PicState2 in upstream, so this patch doesn't apply; the interesting part from my view was that it adds a SysBus device as opposed to ISADevice, so doesn't need the ISABus. Going down that route would require to split PicState into an ISAPicState and SysBusPicState with shared core. Modeling the i8259 as a sysbus device is a workaround, not a solution. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH v9 5/6] arm: SoC model for Calxeda Highbank
Am 12.01.2012 13:47, schrieb Mitsyanko Igor:
On 01/11/2012 08:31 PM, Mark Langsdorf wrote:
+sysram = g_new(MemoryRegion, 1);
+memory_region_init_ram(sysram, highbank.sysram, 0x8000);
+memory_region_add_subregion(sysmem, 0xfff88000, sysram);
+if (bios_name != NULL) {
+sysboot_filename = qemu_find_file(QEMU_FILE_TYPE_BIOS,
bios_name);
+if (sysboot_filename != NULL) {
+uint32_t filesize = get_image_size(sysboot_filename);
+if (load_image_targphys(sysram.bin, 0xfff88000,
filesize) 0) {
+hw_error(Unable to load %s\n, bios_name);
+}
Probably should be
if (load_image_targphys(sysboot_filename, 0xfff88000, 0x8000) 0) {
and then you don't need uint32_t filesize at all.
You need it either way; if you use 0x8000 there, you need to check if
filesize is actually 0x8000. Doing it this way allows to load smaller
files; a check for larger files should be added though. Thanks for
making me aware.
+dev = qdev_create(NULL, l2x0);
+qdev_init_nofail(dev);
+busdev = sysbus_from_qdev(dev);
+sysbus_mmio_map(busdev, 0, 0xfff12000);
+dev = qdev_create(NULL, highbank-regs);
+qdev_init_nofail(dev);
+busdev = sysbus_from_qdev(dev);
+sysbus_mmio_map(busdev, 0, 0xfff3c000);
+
You can use sysbus_create_simple() here (of course, if you didn't avoid
it intentionally for some reason).
Depends on how you read this:
/* Legacy helper function for creating devices. */
DeviceState *sysbus_create_varargs(const char *name,
target_phys_addr_t addr, ...);
DeviceState *sysbus_try_create_varargs(const char *name,
target_phys_addr_t addr, ...);
static inline DeviceState *sysbus_create_simple(const char *name,
target_phys_addr_t addr,
qemu_irq irq)
{
return sysbus_create_varargs(name, addr, irq, NULL);
}
I interpret it as sysbus_create_simple() using deprecated
sysbus_create_varargs() and therefore being deprecated, too.
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 v4 01/15] coroutine: add co_sleep_ns() coroutine sleep function
On Thu, Jan 12, 2012 at 10:13 AM, Kevin Wolf kw...@redhat.com wrote: Am 06.01.2012 15:01, schrieb Stefan Hajnoczi: Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com --- Makefile.objs | 1 + qemu-coroutine-sleep.c | 38 ++ qemu-coroutine.h | 6 ++ 3 files changed, 45 insertions(+), 0 deletions(-) create mode 100644 qemu-coroutine-sleep.c diff --git a/qemu-coroutine.h b/qemu-coroutine.h index 8a55fe1..bae1ffe 100644 --- a/qemu-coroutine.h +++ b/qemu-coroutine.h @@ -17,6 +17,7 @@ #include stdbool.h #include qemu-queue.h +#include qemu-timer.h /** * Coroutines are a mechanism for stack switching and can be used for @@ -199,4 +200,9 @@ void qemu_co_rwlock_wrlock(CoRwlock *lock); */ void qemu_co_rwlock_unlock(CoRwlock *lock); +/** + * Yield the coroutine for a given duration + */ +void coroutine_fn co_sleep_ns(QEMUClock *clock, int64_t ns); + #endif /* QEMU_COROUTINE_H */ As you mentioned on IRC yesterday, timers don't work in the tools. There should probably be a warning in the comment (or a fix before this is merged) I will add a comment to prevent new callers using this inappropriately. qemu-img/qemu-io do not use image streaming so we never hit an abort(3). But I still have an interest in solving the larger problem because QED broken in qemu-tools! So I'll look into using the main loop in qemu-io/qemu-img based on Paolo's patches independently of this image streaming series. Stefan
Re: [Qemu-devel] [PATCH v4 04/15] block: add image streaming block job
Am 12.01.2012 14:05, schrieb Stefan Hajnoczi: On Thu, Jan 12, 2012 at 12:53 PM, Kevin Wolf kw...@redhat.com wrote: Am 12.01.2012 12:39, schrieb Stefan Hajnoczi: On Thu, Jan 12, 2012 at 10:59 AM, Kevin Wolf kw...@redhat.com wrote: Am 06.01.2012 15:01, schrieb Stefan Hajnoczi: +buf = qemu_blockalign(bs, STREAM_BUFFER_SIZE); +s-common.len = bdrv_getlength(bs); No error check? Will fix. +bdrv_get_geometry(bs, (uint64_t *)end); Why call bdrv_getlength() twice? end = s-common.len BDRV_SECTOR_BITS should be the same. Okay, I'll change it. I got sick of BDRV_SECTOR_* and called twice instead. Well, you can try and change everything in the streaming code to bytes instead of sectors. We should probably do this sooner or later anyway. Sectors of 512 bytes are a completely arbitrary unit that doesn't make much sense generally. That doesn't work because block layer interfaces use nb_sectors. We still need to convert. Sure, somewhere you'll have the conversion. You can only push it a bit closer to the invocation of the block drivers if you like. Everything else would be a major refactoring (but eventually I think we'll do it). Kevin
Re: [Qemu-devel] [Qemu-trivial] [PATCH] Add 'fall through' comments to case statements without break
On Thu, Jan 12, 2012 at 1:05 PM, andrzej zaborowski balr...@gmail.com wrote:
On 10 January 2012 09:35, Stefan Hajnoczi stefa...@gmail.com wrote:
On Mon, Jan 09, 2012 at 06:29:51PM +0100, Stefan Weil wrote:
These comments are used by static code analysis tools and in code reviews
to avoid false warnings because of missing break statements.
The case statements handled here were reported by coverity.
Signed-off-by: Stefan Weil s...@weilnetz.de
---
hw/pcnet.c | 1 +
json-lexer.c | 1 +
qemu-option.c | 4
3 files changed, 6 insertions(+), 0 deletions(-)
This reminds me of another questionable fall-through:
bt-host.c:bt_host_read():
while (s-len --)
switch (*pkt ++) {
...
case HCI_SCODATA_PKT:
if (s-len 3)
goto bad_pkt;
pktlen = MIN(pkt[2] + 3, s-len);
s-len -= pktlen;
pkt += pktlen;
--- fall-through or not?
default:
bad_pkt:
fprintf(stderr, qemu: bad HCI packet type %02x\n, pkt[-1]);
}
It seems the code will skip HCI_SCODATA_PKT and report a warning (although
type
pkt[-1] will be incorrect). Any thoughts?
Yes, definitely there's a break missing. Bluetooth SCO links are like
USB Isochronous, so not really tested because they're only used by
streaming devices.
Thanks for explaining. We can address this in a separate patch, sorry
for hijacking this thread :).
Stefan Weil: Your patch looks good.
Stefan
Re: [Qemu-devel] [Qemu-trivial] [PATCH 0/2] Fix fd leak in vvfat.c and strncmp() issue in vnc.c
On Fri, Jan 06, 2012 at 04:57:43PM +, Stefan Hajnoczi wrote: Two unrelated bugs that David Gilbert had kicking around that are easy to fix. Let's take care of them. Stefan Hajnoczi (2): vvfat: avoid leaking file descriptor in commit_one_file() vnc: fix no-lock-key-sync strncmp() length block/vvfat.c |3 +++ ui/vnc.c |2 +- 2 files changed, 4 insertions(+), 1 deletions(-) Applied to the trivial patches tree. Stefan
Re: [Qemu-devel] [PATCH] (dont commit) virtio-gl-fixes for build on F17
On 12 January 2012 11:42, Alon Levy al...@redhat.com wrote: Don't mind at all! But for some reason this email and the other one I send before it to you and to the qemu-devel list didn't reach the list. If you saw this email is it too much to assume you saw the other one as well? Thanks. http://lists.nongnu.org/archive/html/qemu-devel/2012-01/msg01441.html shows the three of your emails that I got too. Cheers
Re: [Qemu-devel] [Qemu-trivial] [PATCH] omap_dss: correct chip[1] index in RFBI_READ/RFBI_STATUS
On Sat, Jan 07, 2012 at 11:59:59AM +, Stefan Hajnoczi wrote: The RFBI_READ/RFBI_STATUS code incorrectly uses chip[0] when it should be using chip[1]. Andrzej Zaborowski bal...@zabor.org confirmed this bug since I don't know this code well. Reported-by: Dr David Alan Gilbert davidagilb...@uk.ibm.com Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com --- hw/omap_dss.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) Applied to the trivial patches tree: https://github.com/stefanha/qemu/commits/trivial-patches Stefan
Re: [Qemu-devel] [PATCH 3/9] pci: Make bounds checks on config space accesses actually work
On 01/12/2012 06:46 AM, David Gibson wrote:
The pci_host_config_{read,write}_common() functions perform PCI config
accesses. They take a limit parameter which they appear to be supposed
to bounds check against, however the bounds checking logic, such as it is,
is completely broken.
Currently, it takes the minimum of the supplied length and the remaining
space in the region and passes that as the length to the underlying
config_{read,write} function pointer. This means that accesses which
partially overrun the region will be silently truncated - which makes
little sense. Accesses which entirely overrun the region will *not*
be blocked (an exploitable bug), because in that case (limit - addr) will
be negative and so the unsigned MIN will always return len instead. Even
if signed arithmetic was used, the config_{read,write} callback wouldn't
know what to do with a negative len parameter.
This patch handles things more sanely by simply ignoring writes which
overrun, and returning -1 for reads, which is the usual hardware convention
for reads to unpopulated IO regions.
Signed-off-by: David Gibsonda...@gibson.dropbear.id.au
Michael, please ack or apply yourself. I'll cache this in my tree
regardless so it doesn't get lost.
Alex
---
hw/pci_host.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/hw/pci_host.c b/hw/pci_host.c
index 44c6c20..16b3ac3 100644
--- a/hw/pci_host.c
+++ b/hw/pci_host.c
@@ -51,14 +51,20 @@ void pci_host_config_write_common(PCIDevice *pci_dev,
uint32_t addr,
uint32_t limit, uint32_t val, uint32_t len)
{
assert(len= 4);
-pci_dev-config_write(pci_dev, addr, val, MIN(len, limit - addr));
+if ((addr + len)= limit) {
+pci_dev-config_write(pci_dev, addr, val, len);
+}
}
uint32_t pci_host_config_read_common(PCIDevice *pci_dev, uint32_t addr,
uint32_t limit, uint32_t len)
{
assert(len= 4);
-return pci_dev-config_read(pci_dev, addr, MIN(len, limit - addr));
+if ((addr + len)= limit) {
+return pci_dev-config_read(pci_dev, addr, len);
+} else {
+return ~0x0;
+}
}
void pci_data_write(PCIBus *s, uint32_t addr, uint32_t val, int len)
Re: [Qemu-devel] [Qemu-trivial] [PATCH] Add 'fall through' comments to case statements without break
On Mon, Jan 09, 2012 at 06:29:51PM +0100, Stefan Weil wrote: These comments are used by static code analysis tools and in code reviews to avoid false warnings because of missing break statements. The case statements handled here were reported by coverity. Signed-off-by: Stefan Weil s...@weilnetz.de --- hw/pcnet.c|1 + json-lexer.c |1 + qemu-option.c |4 3 files changed, 6 insertions(+), 0 deletions(-) Thanks, applied to the trivial patches tree: https://github.com/stefanha/qemu/commits/trivial-patches Stefan
Re: [Qemu-devel] [PATCH 3/9] pci: Make bounds checks on config space accesses actually work
On Thu, Jan 12, 2012 at 04:46:22PM +1100, David Gibson wrote:
The pci_host_config_{read,write}_common() functions perform PCI config
accesses. They take a limit parameter which they appear to be supposed
to bounds check against, however the bounds checking logic, such as it is,
is completely broken.
Currently, it takes the minimum of the supplied length and the remaining
space in the region and passes that as the length to the underlying
config_{read,write} function pointer. This means that accesses which
partially overrun the region will be silently truncated - which makes
little sense.
Why does it make little sense? Makes sense to me.
Accesses which entirely overrun the region will *not*
be blocked (an exploitable bug)
, because in that case (limit - addr) will
be negative and so the unsigned MIN will always return len instead. Even
if signed arithmetic was used, the config_{read,write} callback wouldn't
know what to do with a negative len parameter.
The assumption was callers never pass in such values.
Could you please give an example how this exploitable bug
can get triggered?
This patch handles things more sanely by simply ignoring writes which
overrun, and returning -1 for reads, which is the usual hardware convention
for reads to unpopulated IO regions.
Signed-off-by: David Gibson da...@gibson.dropbear.id.au
---
hw/pci_host.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/hw/pci_host.c b/hw/pci_host.c
index 44c6c20..16b3ac3 100644
--- a/hw/pci_host.c
+++ b/hw/pci_host.c
@@ -51,14 +51,20 @@ void pci_host_config_write_common(PCIDevice *pci_dev,
uint32_t addr,
uint32_t limit, uint32_t val, uint32_t len)
{
assert(len = 4);
-pci_dev-config_write(pci_dev, addr, val, MIN(len, limit - addr));
+if ((addr + len) = limit) {
+pci_dev-config_write(pci_dev, addr, val, len);
+}
}
uint32_t pci_host_config_read_common(PCIDevice *pci_dev, uint32_t addr,
uint32_t limit, uint32_t len)
{
assert(len = 4);
-return pci_dev-config_read(pci_dev, addr, MIN(len, limit - addr));
+if ((addr + len) = limit) {
+return pci_dev-config_read(pci_dev, addr, len);
+} else {
+return ~0x0;
+}
}
void pci_data_write(PCIBus *s, uint32_t addr, uint32_t val, int len)
--
1.7.7.3
Re: [Qemu-devel] [PATCH 3/9] pci: Make bounds checks on config space accesses actually work
On Thu, Jan 12, 2012 at 02:19:59PM +0100, Alexander Graf wrote:
On 01/12/2012 06:46 AM, David Gibson wrote:
The pci_host_config_{read,write}_common() functions perform PCI config
accesses. They take a limit parameter which they appear to be supposed
to bounds check against, however the bounds checking logic, such as it is,
is completely broken.
Currently, it takes the minimum of the supplied length and the remaining
space in the region and passes that as the length to the underlying
config_{read,write} function pointer. This means that accesses which
partially overrun the region will be silently truncated - which makes
little sense. Accesses which entirely overrun the region will *not*
be blocked (an exploitable bug), because in that case (limit - addr) will
be negative and so the unsigned MIN will always return len instead. Even
if signed arithmetic was used, the config_{read,write} callback wouldn't
know what to do with a negative len parameter.
This patch handles things more sanely by simply ignoring writes which
overrun, and returning -1 for reads, which is the usual hardware convention
for reads to unpopulated IO regions.
Signed-off-by: David Gibsonda...@gibson.dropbear.id.au
Michael, please ack or apply yourself. I'll cache this in my tree
regardless so it doesn't get lost.
Alex
I'd like to understand the bug a bit.
---
hw/pci_host.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/hw/pci_host.c b/hw/pci_host.c
index 44c6c20..16b3ac3 100644
--- a/hw/pci_host.c
+++ b/hw/pci_host.c
@@ -51,14 +51,20 @@ void pci_host_config_write_common(PCIDevice *pci_dev,
uint32_t addr,
uint32_t limit, uint32_t val, uint32_t
len)
{
assert(len= 4);
-pci_dev-config_write(pci_dev, addr, val, MIN(len, limit - addr));
+if ((addr + len)= limit) {
+pci_dev-config_write(pci_dev, addr, val, len);
+}
}
uint32_t pci_host_config_read_common(PCIDevice *pci_dev, uint32_t addr,
uint32_t limit, uint32_t len)
{
assert(len= 4);
-return pci_dev-config_read(pci_dev, addr, MIN(len, limit - addr));
+if ((addr + len)= limit) {
+return pci_dev-config_read(pci_dev, addr, len);
+} else {
+return ~0x0;
+}
}
void pci_data_write(PCIBus *s, uint32_t addr, uint32_t val, int len)
Re: [Qemu-devel] [Qemu-trivial] [PATCH] hmp: Fix freeing of PciInfoList
On Wed, Jan 11, 2012 at 10:51:52AM -0500, Stefan Berger wrote:
Remember the original PciInfoList in info_list and use
the info variable to traverse the list.
Signed-off-by: Stefan Berger stef...@linux.vnet.ibm.com
---
hmp.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
Thanks, applied to the trivial patches tree but see below:
https://github.com/stefanha/qemu/commits/trivial-patches
Your patch seems to use two columns instead of just one column for
'-'/'+'/' '. This confused both git-am(1) and patch(1). Perhaps you
can figure out why your patch was generated like this? It reminds me of
diff3 where there are two columns because it compares file A and B
against a common ancestor file.
Index: qemu-git.pt/hmp.c
===
--- qemu-git.pt.orig/hmp.c
+++ qemu-git.pt/hmp.c
@@ -486,17 +486,17 @@ static void hmp_info_pci_device(Monitor
void hmp_info_pci(Monitor *mon)
{
-PciInfoList *info;
+PciInfoList *info_list, info;
Missing '*' to make info a pointer too. Fails to build, I fixed this
when merging so don't worry about it.
Stefan
Re: [Qemu-devel] [PATCH v9 5/6] arm: SoC model for Calxeda Highbank
On 01/12/2012 05:09 PM, Andreas Färber wrote:
Am 12.01.2012 13:47, schrieb Mitsyanko Igor:
On 01/11/2012 08:31 PM, Mark Langsdorf wrote:
+sysram = g_new(MemoryRegion, 1);
+memory_region_init_ram(sysram, highbank.sysram, 0x8000);
+memory_region_add_subregion(sysmem, 0xfff88000, sysram);
+if (bios_name != NULL) {
+sysboot_filename = qemu_find_file(QEMU_FILE_TYPE_BIOS,
bios_name);
+if (sysboot_filename != NULL) {
+uint32_t filesize = get_image_size(sysboot_filename);
+if (load_image_targphys(sysram.bin, 0xfff88000,
filesize) 0) {
+hw_error(Unable to load %s\n, bios_name);
+}
Probably should be
if (load_image_targphys(sysboot_filename, 0xfff88000, 0x8000) 0) {
and then you don't need uint32_t filesize at all.
You need it either way; if you use 0x8000 there, you need to check if
filesize is actually 0x8000. Doing it this way allows to load smaller
files; a check for larger files should be added though. Thanks for
making me aware.
Why do we need to check if filesize is 0x8000? load_image_targphys()
will call get_image_size() and check that size is not more then 0x8000
automatically, so it would operate on any file with size=0x8000 and
return error if size0x8000, just like we need it to. Well, OK, I know
load_image_targphys() is currently broken and doesn't use max_sz
argument, but recently I saw a patch in mailing list which fixes this.
+dev = qdev_create(NULL, l2x0);
+qdev_init_nofail(dev);
+busdev = sysbus_from_qdev(dev);
+sysbus_mmio_map(busdev, 0, 0xfff12000);
+dev = qdev_create(NULL, highbank-regs);
+qdev_init_nofail(dev);
+busdev = sysbus_from_qdev(dev);
+sysbus_mmio_map(busdev, 0, 0xfff3c000);
+
You can use sysbus_create_simple() here (of course, if you didn't avoid
it intentionally for some reason).
Depends on how you read this:
/* Legacy helper function for creating devices. */
DeviceState *sysbus_create_varargs(const char *name,
target_phys_addr_t addr, ...);
DeviceState *sysbus_try_create_varargs(const char *name,
target_phys_addr_t addr, ...);
static inline DeviceState *sysbus_create_simple(const char *name,
target_phys_addr_t addr,
qemu_irq irq)
{
return sysbus_create_varargs(name, addr, irq, NULL);
}
I interpret it as sysbus_create_simple() using deprecated
sysbus_create_varargs() and therefore being deprecated, too.
Andreas
Sorry, never paid attention that these functions are deprecated.
--
Mitsyanko Igor
ASWG, Moscow RD center, Samsung Electronics
email: i.mitsya...@samsung.com
Re: [Qemu-devel] [PATCH v9 5/6] arm: SoC model for Calxeda Highbank
On 12 January 2012 13:42, Mitsyanko Igor i.mitsya...@samsung.com wrote:
On 01/12/2012 05:09 PM, Andreas Färber wrote:
Depends on how you read this:
/* Legacy helper function for creating devices. */
DeviceState *sysbus_create_varargs(const char *name,
target_phys_addr_t addr, ...);
DeviceState *sysbus_try_create_varargs(const char *name,
target_phys_addr_t addr, ...);
static inline DeviceState *sysbus_create_simple(const char *name,
target_phys_addr_t addr,
qemu_irq irq)
{
return sysbus_create_varargs(name, addr, irq, NULL);
}
I interpret it as sysbus_create_simple() using deprecated
sysbus_create_varargs() and therefore being deprecated, too.
Sorry, never paid attention that these functions are deprecated.
Personally I don't think we should deprecate either
sysbus_create_simple() or sysbus_create_varargs() until QOM has
advanced to the point where we can throw out sysbus devices altogether.
These functions are a straightforward way of instantiating simple
sysbus devices, they're widely used, and I don't see anything
particularly wrong with them.
-- PMM
Re: [Qemu-devel] [RFC][PATCH 08/14 v4] introduce a new monitor command 'dump' to dump guest's memory
On Wed, 11 Jan 2012 08:59:24 +0800
Wen Congyang we...@cn.fujitsu.com wrote:
At 01/10/2012 09:30 PM, Luiz Capitulino Wrote:
On Wed, 04 Jan 2012 14:11:01 +0800
Wen Congyang we...@cn.fujitsu.com wrote:
Signed-off-by: Wen Congyang we...@cn.fujitsu.com
---
Makefile.target |8 +-
dump.c | 588
+++
dump.h |4 +
hmp-commands.hx | 16 ++
monitor.c |3 +
qmp-commands.hx | 26 +++
6 files changed, 641 insertions(+), 4 deletions(-)
create mode 100644 dump.c
diff --git a/Makefile.target b/Makefile.target
index 29562ad..f7cc2b9 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -110,7 +110,7 @@ $(call set-vpath,
$(SRC_PATH)/linux-user:$(SRC_PATH)/linux-user/$(TARGET_ABI_DIR
QEMU_CFLAGS+=-I$(SRC_PATH)/linux-user/$(TARGET_ABI_DIR)
-I$(SRC_PATH)/linux-user
obj-y = main.o syscall.o strace.o mmap.o signal.o thunk.o \
elfload.o linuxload.o uaccess.o gdbstub.o cpu-uname.o \
- user-exec.o $(oslib-obj-y)
+ user-exec.o $(oslib-obj-y) dump.o
obj-$(TARGET_HAS_BFLT) += flatload.o
@@ -148,7 +148,7 @@ LDFLAGS+=-Wl,-segaddr,__STD_PROG_ZONE,0x1000
-image_base 0x0e00
LIBS+=-lmx
obj-y = main.o commpage.o machload.o mmap.o signal.o syscall.o thunk.o \
-gdbstub.o user-exec.o
+gdbstub.o user-exec.o dump.o
obj-i386-y += ioport-user.o
@@ -170,7 +170,7 @@ $(call set-vpath, $(SRC_PATH)/bsd-user)
QEMU_CFLAGS+=-I$(SRC_PATH)/bsd-user -I$(SRC_PATH)/bsd-user/$(TARGET_ARCH)
obj-y = main.o bsdload.o elfload.o mmap.o signal.o strace.o syscall.o \
-gdbstub.o uaccess.o user-exec.o
+gdbstub.o uaccess.o user-exec.o dump.o
obj-i386-y += ioport-user.o
@@ -186,7 +186,7 @@ endif #CONFIG_BSD_USER
# System emulator target
ifdef CONFIG_SOFTMMU
-obj-y = arch_init.o cpus.o monitor.o machine.o gdbstub.o balloon.o
ioport.o
+obj-y = arch_init.o cpus.o monitor.o machine.o gdbstub.o balloon.o
ioport.o dump.o
# virtio has to be here due to weird dependency between PCI and
virtio-net.
# need to fix this properly
obj-$(CONFIG_NO_PCI) += pci-stub.o
diff --git a/dump.c b/dump.c
new file mode 100644
index 000..ab29a4c
--- /dev/null
+++ b/dump.c
@@ -0,0 +1,588 @@
+/*
+ * QEMU dump
+ *
+ * Copyright Fujitsu, Corp. 2011
+ *
+ * Authors:
+ * Wen Congyang we...@cn.fujitsu.com
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2. See
+ * the COPYING file in the top-level directory.
+ *
+ */
+
+#include qemu-common.h
+#include unistd.h
+#include elf.h
+#include sys/procfs.h
+#include cpu.h
+#include cpu-all.h
+#include targphys.h
+#include monitor.h
+#include kvm.h
+#include dump.h
+#include sysemu.h
+#include bswap.h
+#include memory_mapping.h
+
+#define CPU_CONVERT_TO_TARGET16(val) \
+({ \
+uint16_t _val = (val); \
+if (endian == ELFDATA2LSB) { \
+_val = cpu_to_le16(_val); \
+} else {\
+_val = cpu_to_be16(_val); \
+} \
+_val; \
+})
+
+#define CPU_CONVERT_TO_TARGET32(val) \
+({ \
+uint32_t _val = (val); \
+if (endian == ELFDATA2LSB) { \
+_val = cpu_to_le32(_val); \
+} else {\
+_val = cpu_to_be32(_val); \
+} \
+_val; \
+})
+
+#define CPU_CONVERT_TO_TARGET64(val) \
+({ \
+uint64_t _val = (val); \
+if (endian == ELFDATA2LSB) { \
+_val = cpu_to_le64(_val); \
+} else {\
+_val = cpu_to_be64(_val); \
+} \
+_val; \
+})
+
+enum {
+DUMP_STATE_ERROR,
+DUMP_STATE_SETUP,
+DUMP_STATE_CANCELLED,
+DUMP_STATE_ACTIVE,
+DUMP_STATE_COMPLETED,
+};
+
+typedef struct DumpState {
+ArchDumpInfo dump_info;
+MemoryMappingList list;
+int phdr_num;
+int state;
+char *error;
+Monitor *mon;
+int fd;
+target_phys_addr_t memory_offset;
+} DumpState;
+
+static DumpState *dump_get_current(void)
+{
+static DumpState current_dump = {
+.state = DUMP_STATE_SETUP,
+};
+
+return current_dump;
+}
+
+static int dump_cleanup(DumpState *s)
+{
+int ret = 0;
+
+free_memory_mapping_list(s-list);
+if (s-fd != -1) {
+close(s-fd);
+s-fd = -1;
+}
+
+return ret;
+}
+
+static void dump_error(DumpState *s, const char *reason)
+{
+s-state = DUMP_STATE_ERROR;
+s-error = g_strdup(reason);
+dump_cleanup(s);
+}
+
+static inline int cpuid(CPUState *env)
+{
+#if defined(CONFIG_USER_ONLY) defined(CONFIG_USE_NPTL)
+return env-host_tid;
+#else
+return env-cpu_index + 1;
+#endif
+}
+
+static int write_elf64_header(DumpState *s)
+{
+Elf64_Ehdr elf_header;
+int ret;
+int endian = s-dump_info.d_endian;
+
+
Re: [Qemu-devel] [PATCH 0/2] virtfs-proxy-helper: Fix and clean include statements
On Wed, Jan 11, 2012 at 07:34:28PM +0100, Stefan Weil wrote: Obviously most Linux host systems don't have a libcap-dev package. If this package is available, make tries to build virtfs-proxy-helper and fails on recent Linux distributions because of a missing attr/xattr.h. The first patch fixes this. As I noticed that several include statements were redundant, I added the second patch which is optional but cleans the code a little bit. Please consider adding libcap-dev to the Linux build bots (and of course to the personal Linux environment when you are a maintainer). Regards, Stefan Weil [PATCH 1/2] virtfs-proxy-helper: Fix compilation on newer systems [PATCH 2/2] virtfs-proxy-helper: Clean include files Thanks, applied to the trivial patches tree: https://github.com/stefanha/qemu/commits/trivial-patches Stefan
Re: [Qemu-devel] [PATCH] virtfs-proxy-helper: Add missing printf format attribute
On Wed, Jan 11, 2012 at 07:47:37PM +0100, Stefan Weil wrote: Every function with printf like arguments must have it (see file HACKING), so add it. Signed-off-by: Stefan Weil s...@weilnetz.de --- fsdev/virtfs-proxy-helper.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Thanks, applied to the trivial patches tree: https://github.com/stefanha/qemu/commits/trivial-patches Stefan
Re: [Qemu-devel] [PATCH 0/2] virtfs-proxy-helper: Fix and clean include statements
On Wed, Jan 11, 2012 at 07:34:28PM +0100, Stefan Weil wrote: Please consider adding libcap-dev to the Linux build bots (and of course to the personal Linux environment when you are a maintainer). I have added it to yuzuki. Stefan
Re: [Qemu-devel] [PATCH v9 5/6] arm: SoC model for Calxeda Highbank
On 01/11/2012 08:31 PM, Mark Langsdorf wrote:
+sysram = g_new(MemoryRegion, 1);
+memory_region_init_ram(sysram, highbank.sysram, 0x8000);
+memory_region_add_subregion(sysmem, 0xfff88000, sysram);
+if (bios_name != NULL) {
+sysboot_filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name);
+if (sysboot_filename != NULL) {
+uint32_t filesize = get_image_size(sysboot_filename);
+if (load_image_targphys(sysram.bin, 0xfff88000, filesize) 0) {
+hw_error(Unable to load %s\n, bios_name);
+}
+} else {
+ hw_error(Unable to find %s\n, bios_name);
+}
+}
I'm sorry, I forgot to ask in my previous message, how does control is
passed to uboot image at 0xfff88000 address? Shouldn't highbank_binfo be
modified somehow if bios_name supplied?
--
Mitsyanko Igor
ASWG, Moscow RD center, Samsung Electronics
email: i.mitsya...@samsung.com
[Qemu-devel] throwing away translated code on CPU reset
When doing TCG code translation, the target-foo translate.c code is allowed to bake assumptions into the generated code from the current values of various fields in the CPUState. This then imposes the requirement that if the field is changed then tb_flush must be called to throw away the now-incorrect generated code. However, cpu_reset() changes (unsurprisingly) lots of fields in the CPUState, but it doesn't call tb_flush()... So should cpu_reset() implementations be changed to call tb_flush() as well as tlb_flush(), or is this supposed to work in some other way? thanks -- PMM
Re: [Qemu-devel] State of KVM bits in linux-headers
On Wed, Jan 11, 2012 at 08:46:38PM +0100, Alexander Graf wrote: On 11.01.2012, at 20:41, Anthony Liguori wrote: On 01/11/2012 01:38 PM, Jan Kiszka wrote: I would like to see us avoiding this in the future. Headers update patches should mention the source and should not be merged until the ABI changes actually made it at least into kvm.git. Same applies, of course, to the functional changes related to that ABI. Otherwise we risk quite some mess on everyone's side. I agree. Another thing: KVM_CAP_PPC_HIOR has been removed again from the kernel and also the header. Is there real free space now or will the cap reappear? If there should better be a placeholder, let's add it (to the kernel). I will reappear with ONE_REG semantics. OK. Then please clean up now so that update-linux-headers.sh can be used again by normal developers. :) Before we did submodules and had a responsive BIOS maintainer, we maintained patches within qemu.git for our external dependencies. I think that's a good strategy here too. It's a little painful, but not entirely awful. At least it makes it possible for you to (hopefully) trivial rebase a patch if something is still in limbo. Yeah, that works. I can easily script that part. It doesn't solve the actual underlying problem though that we don't know when the abi is actually stable. I'm slowly starting to understand Pekka ;). In my recent experience with submitting Joerg's patch series that touches both kernel and tools/perf I didn't see any advantages in having them in the same repository. Yes, the repository is the same, but maintainers are different and have their own timelines and priorities. Long story short userspace part was applied almost three month after the kernel part. -- Gleb.
Re: [Qemu-devel] unknown keycodes
On Thu, Jan 12, 2012 at 09:56:46AM +0100, Daniel Espling wrote: Hi! getting the following message: unknown keycodes `empty_aliases(qwerty)', please report to qemu-devel@nongnu.org I'm connecting to a ubuntu 10.04 server running qemu 1.0.50 forwarding X11. Locally I'm on a Macbook pro with Swedish keyboard layout. When I run qemu my keyboard is totally messed up (Enter becomes j, j becomes 7 etc.). Running with -k en-us works but restricts me to english characters (swedish characters generates keysym errors, which is expected) Unfortunately, the SDL code as written pretty much only copes with an XFree86 server running on a Linux host. Running any kind of X server on OS-X or Windows and forwarding to an app running Linux will result in fubar keyboard mappings as you see. The problem is that keymapping code assumes that it is getting either a'xt' or 'evdev' based keycodes from the X server. On OS-X you instead get a variant on Mac OS keycodes which are completely different. I've solved this problem in GTK-VNC by adding checks for the OS-X and Win32 X servers: http://git.gnome.org/browse/gtk-vnc/tree/src/vncdisplaykeymap.c Can you provide the output of 'xdpyinfo' and 'xprop -root | grep XKB' just so I can confirm my code will work. If so, I'll port the GTK-VNC code to QEMU's SDL display to fix this. Regards, 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 :|
[Qemu-devel] [PATCH 2/2] cleanup, save a syscall
Signed-off-by: Lai Jiangshan la...@cn.fujitsu.com
---
main-loop.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/main-loop.c b/main-loop.c
index 60e9748..692381c 100644
--- a/main-loop.c
+++ b/main-loop.c
@@ -142,14 +142,12 @@ static int qemu_signal_init(void)
*/
sigemptyset(set);
sigaddset(set, SIG_IPI);
-pthread_sigmask(SIG_BLOCK, set, NULL);
-
-sigemptyset(set);
sigaddset(set, SIGIO);
sigaddset(set, SIGALRM);
sigaddset(set, SIGBUS);
pthread_sigmask(SIG_BLOCK, set, NULL);
+sigdelset(set, SIG_IPI);
sigfd = qemu_signalfd(set);
if (sigfd == -1) {
fprintf(stderr, failed to create signalfd\n);
--
1.7.4.4
Re: [Qemu-devel] [PATCH 10/15] test: eliminate libcheck tests and have make check use gtester
On Tue, Jan 10, 2012 at 01:10:51PM -0600, Anthony Liguori wrote: [...] @@ -733,10 +732,6 @@ for opt do ;; --enable-fdt) fdt=yes ;; - --disable-check-utests) check_utests=no - ;; - --enable-check-utests) check_utests=yes - ;; --disable-nptl) nptl=no ;; --enable-nptl) nptl=yes You forgot to remove this: @@ -2825,7 +2825,6 @@ fi echo SDL support $sdl echo curses support$curses echo curl support $curl -echo check support $check_utests echo mingw32 support $mingw32 echo Audio drivers $audio_drv_list echo Extra audio cards $audio_card_list -- Eduardo
[Qemu-devel] [PATCH] bt-host: add missing break statement
The switch statement in bt_host_read() is missing a break in one case. Andrzej Zaborowski andrew.zaborow...@intel.com confirmed that this is not an intentional fall-through. Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com --- bt-host.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/bt-host.c b/bt-host.c index df5b7cd..0d3ad28 100644 --- a/bt-host.c +++ b/bt-host.c @@ -130,6 +130,7 @@ static void bt_host_read(void *opaque) pktlen = MIN(pkt[2] + 3, s-len); s-len -= pktlen; pkt += pktlen; +break; default: bad_pkt: -- 1.7.7.3
Re: [Qemu-devel] [PATCH 0/2][RFC] postcopy migration: Linux char device for postcopy
On 01/03/2012 04:25 PM, Andrea Arcangeli wrote: So the problem is if we do it in userland with the current functionality you'll run out of VMAs and slowdown performance too much. But all you need is the ability to map single pages in the address space. Would this also let you set different pgprots for different pages in the same VMA? It would be useful for write barriers in garbage collectors (such as boehm-gc). These do not have _that_ many VMAs, because every GC cycles could merge all of them back to a single VMA with PROT_READ permissions; however, they still put some strain on the VM subsystem. Changing permission sounds more tricky as more code may make assumptions on the vma before checking the pte. Adding a magic unmapped pte entry sounds fairly safe because there's the migration pte already used by migrate which halts page faults and wait, that creates a precedent. So I guess we could reuse the same code that already exists for the migration entry and we'd need to fire a signal and returns to userland instead of waiting. The signal should be invoked before the page fault will trigger again. Delivering signals is slow, and you can't use signalfd for it, because that can be routed to a different task. I would like an fd based protocol with an explicit ack so the other end can be implemented by the kernel, to use with RDMA. Kind of like how vhost-net talks to a guest via a kvm ioeventfd/irqfd. Of course if the signal returns and does nothing it'll loop at 100% cpu load but that's ok. Maybe it's possible to tweak the permissions but it will need a lot more thoughts. Specifically for anon pages marking them readonly sounds possible if they are supposed to behave like regular COWs (not segfaulting or anything), as you already can have a mixture of readonly and read-write ptes (not to tell readonly KSM pages), but for any other case it's non trivial. Last but not the least the API here would be like a vma-less-mremap, moving a page from one address to another without modifying the vmas, the permission tweak sounds more like an mprotect, so I'm unsure if it could do both or if it should be an optimization to consider independently. Doesn't this stuff require tlb flushes across all threads? In theory I suspect we could also teach mremap to do a not-vma-mangling mremap if we move pages that aren't shared and so we can adjust the page-index of the pages, instead of creating new vmas at the dst address with an adjusted vma-vm_pgoff, but I suspect a syscall that only works on top of fault-unmapped areas is simpler and safer. mremap semantics requires nuking the dst region before the move starts. If we would teach mremap how to handle the fault-unmapped areas we could just add one syscall prepare_fault_area (or whatever name you choose). The locking of doing a vma-less-mremap still sounds tricky but I doubt you can avoid that locking complexity by using the chardevice as long as the chardevice backed-memory still allows THP, migration and swap, if you want to do it atomic-zerocopy and I think zerocopy would be better especially if the network card is fast and all vcpus are faulting into unmapped pages simultaneously so triggering heavy amount of copying from all physical cpus. I don't mean the current device driver doing a copy_user won't work or is bad idea, it's more self contained and maybe easier to merge upstream. I'm just presenting another option more VM integrated zerocopy with just 2 syscalls. Zerocopy is really interesting here, esp. w/ RDMA. But while adding ptes is cheap, removing them is not. I wonder if we can make a write-only page? Of course it's unmapped for cpu access, but we can allow DMA write access from the NIC. Probably too wierd. vmas must not be involved in the mremap for reliability, or too much memory could get pinned in vmas even if we temporary lift the /proc/sys/vm/max_map_count for the process. Plus sending another signal (not sigsegv or sigbus) should be more reliable in case the migration crashes for real. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH 0/2][RFC] postcopy migration: Linux char device for postcopy
On 01/04/2012 05:03 AM, Isaku Yamahata wrote: Yes, it's quite doable in user space(qemu) with a kernel-enhancement. And it would be easy to convert a separated daemon process into a thread in qemu. I think it should be done out side of qemu process for some reasons. (I just repeat same discussion at the KVM-forum because no one remembers it) - ptrace (and its variant) Some people want to investigate guest ram on host (qemu stopped or lively). For example, enhance crash utility and it will attach qemu process and debug guest kernel. To debug the guest kernel you don't need to stop qemu itself. I agree it's a problem for qemu debugging though. - core dump qemu process may core-dump. As postmortem analysis, people want to investigate guest RAM. Again enhance crash utility and it will read the core file and analyze guest kernel. When creating core, the qemu process is already dead. Yes, strong point. It precludes the above possibilities to handle fault in qemu process. I agree. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH] Fix qapi code generation fix
On 12/28/2011 12:26 PM, Avi Kivity wrote: The fixes to qapi code generation had multiple bugs: - the Null class used to drop output was missing some methods - in some scripts it was never instantiated, leading to a None return, which is missing even more methods - the --source and --header options were swapped Luckily, all those bugs were hidden by a makefile bug which caused the old behaviour (with the race) to be invoked. Pings. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] throwing away translated code on CPU reset
Am 12.01.2012 15:00, schrieb Peter Maydell: When doing TCG code translation, the target-foo translate.c code is allowed to bake assumptions into the generated code from the current values of various fields in the CPUState. This then imposes the requirement that if the field is changed then tb_flush must be called to throw away the now-incorrect generated code. However, cpu_reset() changes (unsurprisingly) lots of fields in the CPUState, but it doesn't call tb_flush()... So should cpu_reset() implementations be changed to call tb_flush() as well as tlb_flush(), or is this supposed to work in some other way? I would rather suggest to introduce a new cpu_common_reset() that hides these details - memset() for common parts and whatever necessary here. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH] vga: optimize ppm_save() divisions
On 01/03/2012 03:32 PM, Avi Kivity wrote: ppm_save() spends upwards of 50% of its time doing divisions. Replace them with shifts. Pings. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH][v8] megasas: LSI Megaraid SAS HBA emulation
On 01/12/2012 11:43 AM, Hannes Reinecke wrote: +# hw/megasas.c +disable megasas_init_firmware(int xfer_len, uint64_t pa) xfer len %d pa % PRIx64 +disable megasas_init_queue(uint64_t queue_pa, int queue_len, uint64_t head, uint64_t tail, uint32_t flags) queue at % PRIx64 len %d head % PRIx64 tail % PRIx64 flags %x +megasas_initq_map_failed(int frame) scmd %d: failed to map queue +megasas_initq_mismatch(int queue_len, int fw_cmds) queue size %d max fw cmds %d +disable megasas_qf_found(unsigned int index, uint64_t pa) found mapped frame %x pa % PRIx64 +disable megasas_qf_new(unsigned int index, void *cmd) return new frame %x cmd %p +megasas_qf_failed(unsigned long pa) all frames busy for frame %lx +disable megasas_qf_enqueue(unsigned int index, unsigned int count, uint64_t context, unsigned int tail, int busy) enqueue frame %x count %d countext % PRIx64 tail %x busy %d +disable megasas_qf_update(unsigned int head, unsigned int busy) update reply queue head %x busy %d +disable megasas_qf_dequeue(unsigned int index) dequeue frame %x +disable megasas_qf_map_failed(int cmd, unsigned long frame) scmd %d: frame %lu +disable megasas_qf_complete_noirq(uint64_t context) context % PRIx64 +disable megasas_qf_complete(uint64_t context, unsigned int tail, unsigned int offset, int busy, unsigned int doorbell) context % PRIx64 tail %x offset %d busy %d doorbell %x +disable megasas_handle_frame(const char *cmd, uint64_t addr, uint64_t context, uint32_t count) MFI cmd %s addr % PRIx64 context % PRIx64 count %d +megasas_frame_busy(uint64_t addr) frame % PRIx64 busy +megasas_unhandled_frame_cmd(int cmd, uint8_t frame_cmd) scmd %d: Unhandled MFI cmd %x +disable megasas_handle_scsi(const char *frame, const char *desc, int dev, int lun, void *sdev, unsigned long size) %s %s dev %x/%x sdev %p xfer %lu +disable megasas_scsi_target_not_present(const char *frame, const char *desc, int dev, int lun) %s %s dev %x/%x target not present +megasas_scsi_invalid_cdb_len(const char *frame, const char *desc, int dev, int lun, int len) %s %s dev %x/%x invalid cdb len %d +megasas_scsi_overflow(int cmd, const char *dir, int bytes, int len) scmd %d: %s %d of %d bytes +disable megasas_scsi_underflow(int cmd, const char *dir, int bytes, int len) scmd %d: %s %d of %d bytes +megasas_scsi_req_alloc_failed(const char *frame, int dev, int lun) %s dev %x/%x req allocation failed +disable megasas_scsi_start(int cmd, const char *desc, int len) scmd %d: %s %d bytes of data +disable megasas_scsi_nodata(int cmd) scmd %d: no data to be transferred +disable megasas_scsi_complete(int cmd, uint32_t status, int len, int xfer) scmd %d: finished with status %x, len %u/%u +disable megasas_command_complete(int cmd, uint32_t status) scmd %d: command completed, status %x +disable megasas_handle_io(int cmd, const char *frame, int dev, int lun, unsigned long lba, unsigned long count) scmd %d: %s dev %x/%x lba %lx count %lu +disable megasas_io_target_not_present(int cmd, const char *frame, int dev, int lun) scmd %d: %s dev %x/%x LUN not present +disable megasas_io_start(int cmd, const char *dir, unsigned long lba, unsigned long count, unsigned long len) scmd %d: %s start LBA %lx %lu blocks (%lu bytes) +disable megasas_io_complete(int cmd, uint32_t len) scmd %d: %d bytes completed +disable megasas_io_copy(int cmd, const char *dir, int bytes, int len, unsigned long offset) scmd %d: %s %d of %d bytes, iov offset %lu +disable megasas_io_continue(int cmd, int bytes) scmd %d: %d bytes left +megasas_iovec_map_failed(int cmd, int index, unsigned long iov_size) scmd %d: iovec %d size %lu +megasas_iovec_sgl_overflow(int cmd, int index, int limit) scmd %d: iovec count %d limit %d +megasas_iovec_sgl_underflow(int cmd, int index) scmd %d: iovec count %d +megasas_iovec_sgl_invalid(int cmd, int index, uint64_t pa, uint32_t len) scmd %d: invalid sgl element %d pa % PRIx64 len %u +megasas_iovec_len(int cmd, const char *desc, int len, int limit) scmd %d: iovec %s len %d limit %d +disable megasas_handle_dcmd(int cmd, int opcode) scmd %d: MFI DCMD opcode %x +disable megasas_finish_dcmd(int cmd, int size) scmd %d: MFI DCMD wrote %d bytes +megasas_dcmd_req_alloc_failed(int cmd, const char *desc) scmd %d: %s alloc failed +disable megasas_dcmd_internal_submit(int cmd, const char *desc, int dev) scmd %d: %s to dev %d +disable megasas_dcmd_internal_finish(int cmd, int opcode, int lun) scmd %d: DCMD finish internal cmd %x lun %d +megasas_dcmd_internal_invalid(int cmd, int opcode) scmd %d: Invalid internal DCMD %x +megasas_dcmd_unhandled(int cmd, int opcode, int len) scmd %d: opcode %x, len %d +disable megasas_dcmd_zero_sge(int cmd) scmd %d: zero DCMD sge count +megasas_dcmd_invalid_sge(int cmd, int count) scmd %d: invalid DCMD sge count %d +megasas_dcmd_map_failed(int cmd) scmd %d: Failed to map DCMD buffer +megasas_dcmd_invalid_xfer_len(int cmd, const char *dcmd, unsigned long size) scmd %d: %s invalid xfer len %ld +disable megasas_dcmd_enter(int
Re: [Qemu-devel] [PATCH 21/21] postcopy: implement postcopy livemigration
On 01/04/2012 05:29 AM, Isaku Yamahata wrote:
On Thu, Dec 29, 2011 at 06:06:10PM +0200, Avi Kivity wrote:
On 12/29/2011 03:26 AM, Isaku Yamahata wrote:
This patch implements postcopy livemigration.
+/* RAM is allocated via umem for postcopy incoming mode */
+#define RAM_POSTCOPY_UMEM_MASK (1 1)
+
typedef struct RAMBlock {
uint8_t *host;
ram_addr_t offset;
@@ -485,6 +488,10 @@ typedef struct RAMBlock {
#if defined(__linux__) !defined(TARGET_S390X)
int fd;
#endif
+
+#ifdef CONFIG_POSTCOPY
+UMem *umem;/* for incoming postcopy mode */
+#endif
} RAMBlock;
Is it possible to implement this via the MemoryListener API (which
replaces CPUPhysMemoryClient)? This is how kvm, vhost, and xen manage
their memory tables.
I'm afraid no. Those three you listed above are for outgoing part,
but this case is for incoming part. The requirement is quite different
from those three. What is needed is
- get the corresponding RAMBlock and UMem from (id, idlen)
- hook ram_alloc/ram_free (or RAM api corresponding)
Okay. We'll need more hooks then. Xen already hooks qemu_ram_alloc(),
so there's more than one user.
But don't spend time on this; this area is in flux due to the memory
API, so any effort will be wasted. I'll look at adding those hooks,
either before or after postcopy is merged.
--
error compiling committee.c: too many arguments to function
[Qemu-devel] The reversion of hot adding a storage disk to Linux guest.
Hi, I am testing the hot plug of scsi disk to the KVM Linux guest with the following command. [root@kvm-rhel-01 bin]# ./virsh qemu-monitor-command RHEL6.1-C pci_add auto storage file=/nfs/images/storage1-qcow2.img,if=scsi OK domian 0, bus 0, slot 7, function 0 [root@kvm-rhel-01 bin]# lspci ... 00:05.0 SCSI storage controller: Red Hat, Inc Virtio block device 00:06.0 RAM memory: Red Hat, Inc Virtio memory balloon 00:07.0 SCSI storage controller: LSI Logic / Symbios Logic 53c895a ---new deviced added in the KVM guest: [root@RHEL6 ~]#cat /proc/scsi/scsi Attached devices: Host: scsi1 Channel: 00 Id: 00 Lun: 00 Vendor: QEMUModel: QEMU DVD-ROMRev: 1.0. Type:CD-ROM Host: scsi2 Channel: 00 Id: 00 Lun: 00 Vendor: QEMUModel: QEMU HARDDISKRev: 1.0. Type: Direct-AccessANSISCSI revision: 05 --new scsi disk attached The command successfully created a HBA device in the guest and also a scsi disk was enumerated under the HBA device. My next request is to hot detach the scsi disk from the HBA device, not necessarily detach the HBA device. That is to emulate the swapping out of the scsi disk from a physical machine and to release the image file in the backend. Because the scsi disk is not PCI device, pci_del command can not be used in this case. Can we have a way to send some commands to notice the HBA device to offline the scsi disk? By that way, HBA device can do some cleanup in their driver to fully offline the scsi disk. BTW: In the linux guest, we can do echo scsi remove-single-device 2 0 0 0 /proc/scsi/scsi to disable the disk. But I don't think it is fully removed, because you can bring it back again by echo scsi add-single-device 2 0 0 0 /proc/scsi/scsi -- Shu Mingshum...@linux.vnet.ibm.com IBM China Systems and Technology Laboratory
Re: [Qemu-devel] [PATCH] network: Added option to disable NIC option roms
On Mon, 9 Jan 2012, Gerd Hoffmann wrote:
Hi,
if (!pci_dev-qdev.hotplugged) {
static int loaded = 0;
-if (!loaded) {
+if (!loaded
pci_has_not_explicitly_disabled_option_romfile(pci_dev)) {
rom_add_option(pxe-ne2k_pci.rom, -1);
loaded = 1;
}
I think you can just remove this altogether and add a .romfile = ...
entry instead like it is done for the other nics.
I'm not sure about the consequences (hotplugging feature, etc.) when
changing it to romfile as in other PCI devices. Also the patch is more
generic and supports static and dynamic devices (hotplugable and possible
future devices). Patch supports without hotplugging both options to
disable the romfile:
,romfile=
,romfile=disabled
And the patch has already been tested ...
Therefore I suggest to commit it and maybe make a refactoring without
hotplugging later on.
Ciao,
Gerhard
--
http://www.wiesinger.com/
Re: [Qemu-devel] [PATCH 00/11] virtio-scsi device model
Hi Paolo, How to add a virtio-scsi device? What parameters should I specify in qemu command line? -- Thanks, Hu Tao
Re: [Qemu-devel] [PATCH] vga: optimize ppm_save() divisions
On Tue, Jan 03, 2012 at 03:32:57PM +0200, Avi Kivity wrote: ppm_save() spends upwards of 50% of its time doing divisions. Replace them with shifts. Reviewed-by: Alon Levy al...@redhat.com rmax/bmax/gmax are all uint8_t atm, could add a compilation error if sizeof(bmax)!=1 ever. Signed-off-by: Avi Kivity a...@redhat.com --- hw/vga.c | 10 -- 1 files changed, 4 insertions(+), 6 deletions(-) diff --git a/hw/vga.c b/hw/vga.c index ca79aa1..a228cde 100644 --- a/hw/vga.c +++ b/hw/vga.c @@ -2370,12 +2370,10 @@ int ppm_save(const char *filename, struct DisplaySurface *ds) v = *(uint32_t *)d; else v = (uint32_t) (*(uint16_t *)d); -r = ((v ds-pf.rshift) ds-pf.rmax) * 256 / -(ds-pf.rmax + 1); -g = ((v ds-pf.gshift) ds-pf.gmax) * 256 / -(ds-pf.gmax + 1); -b = ((v ds-pf.bshift) ds-pf.bmax) * 256 / -(ds-pf.bmax + 1); +/* Limited to 8 or fewer bits per channel: */ +r = ((v ds-pf.rshift) ds-pf.rmax) (8 - ds-pf.rbits); +g = ((v ds-pf.gshift) ds-pf.gmax) (8 - ds-pf.gbits); +b = ((v ds-pf.bshift) ds-pf.bmax) (8 - ds-pf.bbits); *pbuf++ = r; *pbuf++ = g; *pbuf++ = b; -- 1.7.7.1
[Qemu-devel] [PATCH 1/2] cleanup, Remove duplicated code
These two blocks of code are exactly the same, remove one.
Signed-off-by: Lai Jiangshan la...@cn.fujitsu.com
---
cpus.c |8
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/cpus.c b/cpus.c
index 857f96f..f45a438 100644
--- a/cpus.c
+++ b/cpus.c
@@ -565,14 +565,6 @@ static void qemu_kvm_init_cpu_signals(CPUState *env)
fprintf(stderr, kvm_set_signal_mask: %s\n, strerror(-r));
exit(1);
}
-
-sigdelset(set, SIG_IPI);
-sigdelset(set, SIGBUS);
-r = kvm_set_signal_mask(env, set);
-if (r) {
-fprintf(stderr, kvm_set_signal_mask: %s\n, strerror(-r));
-exit(1);
-}
}
static void qemu_tcg_init_cpu_signals(void)
--
1.7.4.4
Re: [Qemu-devel] [PATCH] vga: optimize ppm_save() divisions
On Thu, Jan 12, 2012 at 05:16:03PM +0200, Alon Levy wrote:
On Tue, Jan 03, 2012 at 03:32:57PM +0200, Avi Kivity wrote:
ppm_save() spends upwards of 50% of its time doing divisions. Replace them
with shifts.
Reviewed-by: Alon Levy al...@redhat.com
rmax/bmax/gmax are all uint8_t atm, could add a compilation error if
sizeof(bmax)!=1 ever.
meant {r,g,b}bits.
Signed-off-by: Avi Kivity a...@redhat.com
---
hw/vga.c | 10 --
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/hw/vga.c b/hw/vga.c
index ca79aa1..a228cde 100644
--- a/hw/vga.c
+++ b/hw/vga.c
@@ -2370,12 +2370,10 @@ int ppm_save(const char *filename, struct
DisplaySurface *ds)
v = *(uint32_t *)d;
else
v = (uint32_t) (*(uint16_t *)d);
-r = ((v ds-pf.rshift) ds-pf.rmax) * 256 /
-(ds-pf.rmax + 1);
-g = ((v ds-pf.gshift) ds-pf.gmax) * 256 /
-(ds-pf.gmax + 1);
-b = ((v ds-pf.bshift) ds-pf.bmax) * 256 /
-(ds-pf.bmax + 1);
+/* Limited to 8 or fewer bits per channel: */
+r = ((v ds-pf.rshift) ds-pf.rmax) (8 - ds-pf.rbits);
+g = ((v ds-pf.gshift) ds-pf.gmax) (8 - ds-pf.gbits);
+b = ((v ds-pf.bshift) ds-pf.bmax) (8 - ds-pf.bbits);
*pbuf++ = r;
*pbuf++ = g;
*pbuf++ = b;
--
1.7.7.1
Re: [Qemu-devel] State of KVM bits in linux-headers
On 01/11/2012 11:48 PM, Alexander Graf wrote: Strictly from a QEMU perspective, we can't depend on APIs that aren't committed upstream yet. We can't release any qemu that depends on something not upstream. The question again is: When do we consider something upstream? This far from a qemu release, we can consider anything in in kvm.git master (or slightly trailing that, kvm.git linux-next) as upstream. It's very rare that an ABI gets pulled out of that and not merged, and if it is, we can pull out the qemu feature. An ABI can change, but that just means we need to echo the change in qemu. As qemu gets closer to release, we'll need to look at Linus' tree instead of kvm.git. right? And then after about 3 months we'll have the feature available ;). You can always just get Acked-by's from the appropriate maintainers. That's just as good as going through the tree. So every time we change headers, I just require Avi's ack and then he can't complain on those patches later? Good idea! :) Of course I can complain about my patches later. Complained-about-by: Avi Kivity a...@redhat.com But yes, if your change involves multiple subsystem, get it through the most affected subsystem and get acks from the rest. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH v4 13/15] block stream: add support for partial streaming
On Thu, Jan 12, 2012 at 12:42 PM, Kevin Wolf kw...@redhat.com wrote: Am 06.01.2012 15:01, schrieb Stefan Hajnoczi: From: Marcelo Tosatti mtosa...@redhat.com Add support for streaming data from an intermediate section of the image chain (see patch and documentation for details). Signed-off-by: Marcelo Tosatti mtosa...@redhat.com Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com --- block.c | 64 block.h | 4 +++ block/stream.c | 28 +--- block_int.h | 3 +- blockdev.c | 11 ++--- 5 files changed, 101 insertions(+), 9 deletions(-) diff --git a/block.c b/block.c index 9b688a0..d2143b1 100644 --- a/block.c +++ b/block.c @@ -2263,6 +2263,70 @@ int bdrv_is_allocated(BlockDriverState *bs, int64_t sector_num, int nb_sectors, return data.ret; } +/* + * Given an image chain: [BASE] - [INTER1] - [INTER2] - [TOP] + * + * Return true if the given sector is allocated in top or base. + * Return false if the given sector is allocated in intermediate images. This description is inexact. A sector could be allocated both in base in an intermediate image. Also initially I thought that we not only need to check whether the sector is allocated in BASE, but also in any parents of BASE. You don't do this: Clusters that are completely unallocated all through the chain are reported as allocated. After reading all of the patch, I believe this provides the right semantics: Normal image streaming would copy them into the topmost file, but if you keep a backing file, you want to copy as little as possible and keep using the backing file whenever possible. So I suggest to fix the description rather than the implementation. Maybe we should also rename the function. With this semantics it's not a generic is_allocated function any more, but something quite specific to streaming with a base file. I have moved the function into block/stream.c and renamed it to just is_allocated_base(). The description is updated. This makes it clearer that it's a special-case is_allocated-like function. Stefan
[Qemu-devel] [PATCH] usb-redir: Add the posibility to filter out certain devices from redirecion
This patch adds the posibility to filter out certain devices from redirecion.
To use this pass the filter property to -device usb-redir. The filter
property takes a string consisting of filter rules, the format for a rule is:
class:vendor:product:version:allow
-1 can be used to allow any value for a field.
Muliple rules can be concatonated using | as a separator. Note that if
a device matches none of the passed in rules, redirecting it will not be
allowed!
Example:
-device usb-redir,filter='-1:0x0781:0x5567:-1:0|0x08:-1:-1:-1:1'
This example will deny the Sandisk Cruzer Blade being redirected, as it
has a usb id of 0781:5567, it will allow any other usb mass storage devices,
and it will deny any other devices (the default for devices not matching any
of the rules.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
configure |2 +-
usb-redir.c | 114 +-
2 files changed, 105 insertions(+), 11 deletions(-)
diff --git a/configure b/configure
index 7ecf44e..c7e37df 100755
--- a/configure
+++ b/configure
@@ -2541,7 +2541,7 @@ fi
# check for usbredirparser for usb network redirection support
if test $usb_redir != no ; then
-if $pkg_config libusbredirparser /dev/null 21 ; then
+if $pkg_config --atleast-version=0.3.3 libusbredirparser /dev/null 21 ;
then
usb_redir=yes
usb_redir_cflags=$($pkg_config --cflags libusbredirparser 2/dev/null)
usb_redir_libs=$($pkg_config --libs libusbredirparser 2/dev/null)
diff --git a/usb-redir.c b/usb-redir.c
index 6e92f14..41c0745 100644
--- a/usb-redir.c
+++ b/usb-redir.c
@@ -34,6 +34,7 @@
#include sys/ioctl.h
#include signal.h
#include usbredirparser.h
+#include usbredirfilter.h
#include hw/usb.h
@@ -72,6 +73,7 @@ struct USBRedirDevice {
/* Properties */
CharDriverState *cs;
uint8_t debug;
+char *filter_str;
/* Data passed from chardev the fd_read cb to the usbredirparser read cb */
const uint8_t *read_buf;
int read_buf_size;
@@ -84,6 +86,11 @@ struct USBRedirDevice {
struct endp_data endpoint[MAX_ENDPOINTS];
uint32_t packet_id;
QTAILQ_HEAD(, AsyncURB) asyncq;
+/* Data for device filtering */
+struct usb_redir_device_connect_header device_info;
+struct usb_redir_interface_info_header interface_info;
+struct usbredirfilter_rule *filter_rules;
+int filter_rules_count;
};
struct AsyncURB {
@@ -790,6 +797,7 @@ static int usbredir_handle_control(USBDevice *udev,
USBPacket *p,
static void usbredir_open_close_bh(void *opaque)
{
USBRedirDevice *dev = opaque;
+uint32_t caps[USB_REDIR_CAPS_SIZE] = { 0, };
usbredir_device_disconnect(dev);
@@ -820,7 +828,9 @@ static void usbredir_open_close_bh(void *opaque)
dev-parser-interrupt_packet_func = usbredir_interrupt_packet;
dev-read_buf = NULL;
dev-read_buf_size = 0;
-usbredirparser_init(dev-parser, VERSION, NULL, 0, 0);
+
+usbredirparser_caps_set_cap(caps,
usb_redir_cap_connect_device_version);
+usbredirparser_init(dev-parser, VERSION, caps, USB_REDIR_CAPS_SIZE,
0);
usbredirparser_do_write(dev-parser);
}
}
@@ -908,6 +918,16 @@ static int usbredir_initfn(USBDevice *udev)
return -1;
}
+if (dev-filter_str) {
+i = usbredirfilter_string_to_rules(dev-filter_str, :, |,
+ dev-filter_rules,
+ dev-filter_rules_count);
+if (i) {
+qerror_report(QERR_INVALID_PARAMETER_VALUE, filter, a usb
device filter string);
+return -1;
+}
+}
+
dev-open_close_bh = qemu_bh_new(usbredir_open_close_bh, dev);
dev-attach_timer = qemu_new_timer_ms(vm_clock, usbredir_do_attach, dev);
@@ -956,6 +976,44 @@ static void usbredir_handle_destroy(USBDevice *udev)
if (dev-parser) {
usbredirparser_destroy(dev-parser);
}
+
+free(dev-filter_rules);
+}
+
+static int usbredir_check_filter(USBRedirDevice *dev)
+{
+if (dev-interface_info.interface_count == 0) {
+ERROR(No interface info for device\n);
+return -1;
+}
+
+if (dev-filter_rules) {
+if (!usbredirparser_peer_has_cap(dev-parser,
+usb_redir_cap_connect_device_version)) {
+ERROR(Device filter specified and peer does not have the
+ connect_device_version capability\n);
+return -1;
+}
+
+if (usbredirfilter_check(
+dev-filter_rules,
+dev-filter_rules_count,
+dev-device_info.device_class,
+dev-device_info.device_subclass,
+dev-device_info.device_protocol,
+dev-interface_info.interface_class,
+dev-interface_info.interface_subclass,
+dev-interface_info.interface_protocol,
+dev-interface_info.interface_count,
+
Re: [Qemu-devel] [PATCH] usb-redir: Add the posibility to filter out certain devices from redirecion
On 2012-01-12 17:31, Hans de Goede wrote: This patch adds the posibility to filter out certain devices from redirecion. To use this pass the filter property to -device usb-redir. The filter property takes a string consisting of filter rules, the format for a rule is: class:vendor:product:version:allow -1 can be used to allow any value for a field. Muliple rules can be concatonated using | as a separator. Note that if a device matches none of the passed in rules, redirecting it will not be allowed! Hmm, '|' makes quoting mandatory. And the :allow is also not that beautiful IMHO. What about [+]|-class:vendor:product:version[/[+]|-class:...] ? Optional '+' means allow, '-' disallow. An empty field could also serve as wildcard (instead of explicit -1 which would collide with disallow). Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH] MAINTAINERS: update tracing repo git URL
On 01/11/2012 04:02 AM, Stefan Hajnoczi wrote: I have moved git hosting services. Signed-off-by: Stefan Hajnoczistefa...@linux.vnet.ibm.com --- MAINTAINERS |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Applied. Thanks. Regards, Anthony Liguori diff --git a/MAINTAINERS b/MAINTAINERS index 764c92d..de2a916 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -490,7 +490,7 @@ Tracing M: Stefan Hajnoczistefa...@linux.vnet.ibm.com S: Maintained F: trace/ -T: git://repo.or.cz/qemu/stefanha.git tracing +T: git://github.com/stefanha/qemu.git tracing Checkpatch M: Blue Swirlblauwir...@gmail.com
Re: [Qemu-devel] [PATCH v4] Support for UDP unicast network backend
On 01/10/2012 06:20 PM, Benjamin wrote:
Signed-off-by: Benjamin MARSILImlspira...@gmail.com
Applied. Thanks.
Regards,
Anthony Liguori
---
Added my last name. Check that localaddr= is supplied with udp=,
it crashed when misused...
net.c |6 +++-
net/socket.c| 77 +-
qemu-options.hx |2 +
3 files changed, 82 insertions(+), 3 deletions(-)
diff --git a/net.c b/net.c
index f7bebf8..2b0f766 100644
--- a/net.c
+++ b/net.c
@@ -1000,7 +1000,11 @@ static const struct {
}, {
.name = localaddr,
.type = QEMU_OPT_STRING,
-.help = source address for multicast packets,
+.help = source address and port for multicast and udp
packets,
+}, {
+.name = udp,
+.type = QEMU_OPT_STRING,
+.help = UDP unicast address and port number,
},
{ /* end of list */ }
},
diff --git a/net/socket.c b/net/socket.c
index c9d70d3..d4c2002 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -534,6 +534,57 @@ static int net_socket_mcast_init(VLANState *vlan,
}
+static int net_socket_udp_init(VLANState *vlan,
+ const char *model,
+ const char *name,
+ const char *rhost,
+ const char *lhost)
+{
+NetSocketState *s;
+int fd, val, ret;
+struct sockaddr_in laddr, raddr;
+
+if (parse_host_port(laddr, lhost) 0) {
+return -1;
+}
+
+if (parse_host_port(raddr, rhost) 0) {
+return -1;
+}
+
+fd = qemu_socket(PF_INET, SOCK_DGRAM, 0);
+if (fd 0) {
+perror(socket(PF_INET, SOCK_DGRAM));
+return -1;
+}
+val = 1;
+ret = setsockopt(fd, SOL_SOCKET, SO_REUSEADDR,
+ (const char *)val, sizeof(val));
+if (ret 0) {
+perror(setsockopt(SOL_SOCKET, SO_REUSEADDR));
+closesocket(fd);
+return -1;
+}
+ret = bind(fd, (struct sockaddr *)laddr, sizeof(laddr));
+if (ret 0) {
+perror(bind);
+closesocket(fd);
+return -1;
+}
+
+s = net_socket_fd_init(vlan, model, name, fd, 0);
+if (!s) {
+return -1;
+}
+
+s-dgram_dst = raddr;
+
+snprintf(s-nc.info_str, sizeof(s-nc.info_str),
+ socket: udp=%s:%d,
+ inet_ntoa(raddr.sin_addr), ntohs(raddr.sin_port));
+return 0;
+}
+
int net_init_socket(QemuOpts *opts,
Monitor *mon,
const char *name,
@@ -606,10 +657,32 @@ int net_init_socket(QemuOpts *opts,
if (net_socket_mcast_init(vlan, socket, name, mcast, localaddr) ==
-1) {
return -1;
}
+} else if (qemu_opt_get(opts, udp)) {
+const char *udp, *localaddr;
+
+if (qemu_opt_get(opts, fd) ||
+qemu_opt_get(opts, connect) ||
+qemu_opt_get(opts, listen) ||
+qemu_opt_get(opts, mcast)) {
+error_report(fd=, connect=, listen=\
+ and mcast= is invalid with udp=);
+return -1;
+}
+
+udp = qemu_opt_get(opts, udp);
+localaddr = qemu_opt_get(opts, localaddr);
+if (localaddr == NULL) {
+error_report(localaddr= is mandatory with udp=);
+return -1;
+}
+
+if (net_socket_udp_init(vlan, udp, name, udp, localaddr) == -1) {
+return -1;
+}
} else {
-error_report(-socket requires fd=, listen=, connect= or mcast=);
+error_report(-socket requires fd=, listen=, \
+ connect=, mcast= or udp=);
return -1;
}
-
return 0;
}
diff --git a/qemu-options.hx b/qemu-options.hx
index 7903e5c..6295cde 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1239,6 +1239,8 @@ DEF(net, HAS_ARG, QEMU_OPTION_net,
-net
socket[,vlan=n][,name=str][,fd=h][,mcast=maddr:port[,localaddr=addr]]\n
connect the vlan 'n' to multicast maddr and port\n
use 'localaddr=addr' to specify the host address to send
packets from\n
+-net
socket[,vlan=n][,name=str][,fd=h][,udp=host:port][,localaddr=host:port]\n
+connect the vlan 'n' to another VLAN using an UDP
tunnel\n
#ifdef CONFIG_VDE
-net
vde[,vlan=n][,name=str][,sock=socketpath][,port=n][,group=groupname][,mode=octalmode]\n
connect the vlan 'n' to port 'n' of a vde switch
running\n
--
1.7.6
