Re: [Qemu-devel] [RFC][MIPS][PATCH 3/6] Initial support of VIA IDE controller used by fulong mini pc

[Markus Armbruster]

Blue Swirl  writes:

> On 5/11/10, Markus Armbruster  wrote:
>> Blue Swirl  writes:
>>
>>  > On 5/9/10, chen huacai  wrote:
>>  >> This patch add initial support of VIA IDE controller used by fulong mini 
>> pc
>>  >>
>>  >>  Signed-off-by: Huacai Chen 
>>  >>  -
>>  [...]
>>
>> >>  diff --git a/hw/ide/via.c b/hw/ide/via.c
>>  >>  new file mode 100644
>>  >>  index 000..9adc5b5
>>  >>  --- /dev/null
>>  >>  +++ b/hw/ide/via.c
>>  >>  @@ -0,0 +1,189 @@
>>
>> [...]
>>
>> >>  +static void bmdma_writeb(void *opaque, uint32_t addr, uint32_t val)
>>  >>  +{
>>  >>  +BMDMAState *bm = opaque;
>>  >>  +#ifdef DEBUG_IDE
>>  >>  +printf("bmdma: writeb 0x%02x : 0x%02x\n", addr, val);
>>  >>  +#endif
>>  >>  +switch(addr & 3) {
>>  >>  +case 2:
>>  >>  +bm->status = (val & 0x60) | (bm->status & 1) | (bm->status &
>>  >>  ~val & 0x06);
>>  >>  +break;
>>  >
>>  > Some gccs complain if there is no default case.
>>
>>
>> Are you sure?  Which version?
>>
>>  It warns when the switch expression's type is an enumeration, and the
>>  switch doesn't handle all enumeration constants, and has no default
>>  case.
>>
>>  I can be made to warn whenever there's no default, but we don't do that.
>
> This problem came up with 299b520cd4092be3c53f8380b81315c33927d9d3
> (fixed before commit) and 4450521668471c7685551d8c5bcc582d754e9843,
> with mingw gcc and OpenBSD gccs.
[...]
>
> Maybe those cases were different from this.

The first commit you quoted is indeed different: the default prevents a
spurious warning: ‘context’ may be used uninitialized in this function
from some versions of gcc.  No such confusion can arise here.

In the second one, the switch expression is of enumeration type.

[Qemu-devel] [PATCH 0/6] MIPS: Initial support for fulong (Loongson-2E based) mini pc.

[chen huacai]

This series of patches are for qemu master branch. They make qemu
initially support fulong (Loongson-2E based) mini pc, a new type of
MIPS machine.
Usage:
  1, Load PMON as bios, and then load OS in PMON shell
qemu-system-mips64el -M fulong2e -bios pmon_fulong2e.bin -hda /root/hda.img
  2, Load OS directly with -kernel parameter
qemu-system-mips64el -M fulong2e -kernel vmlinux -append
"root=/dev/hda1 console=ttyS0" -hda /root/hda.img

Patches include:
[PATCH 1/6] MIPS: Initial support of bonito north bridge used by fulong mini pc
[PATCH 2/6] MIPS: Initial support of vt82686b south bridge used by
fulong mini pc
[PATCH 3/6] MIPS: Initial support of VIA IDE controller used by fulong mini pc
[PATCH 4/6] MIPS: Initial support of VIA USB controller used by fulong mini pc
[PATCH 5/6] MIPS: Initial support of fulong mini pc (CPU definition,
machine construction, etc.)
[PATCH 6/6] MIPS: add PMON (binary file) used by fulong mini pc

In this version, fulong is limited to mips64el only (doesn't affect
mips, mips64 and mipsel); qdev model is used for Bonito north bridge,
code style and other errors have been fixed.

Signed-off-by: Huacai Chen 

-- 
Huacai Chen

Re: [Qemu-devel] [PATCH 0/2] Enable qemu block layer to not flush

[Stefan Hajnoczi]

Why add a nop AIO operation instead of setting
BlockDriverState->enable_write_cache to zero?  In that case no write
cache would be reported to the guest (just like cache=writethrough).

Stefan

[Qemu-devel] [PATCH 1/6] MIPS: Initial support of bonito north bridge used by fulong mini pc

[chen huacai]

Signed-off-by: Huacai Chen 
---
 Makefile.target  |1 +
 default-configs/mips64el-softmmu.mak |1 +
 hw/bonito.c  |  950 ++
 hw/mips.h|3 +
 4 files changed, 955 insertions(+), 0 deletions(-)
 create mode 100644 hw/bonito.c

diff --git a/Makefile.target b/Makefile.target
index c092900..63d9f49 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -220,6 +220,7 @@ obj-mips-y += dma.o vga.o i8259.o
 obj-mips-y += g364fb.o jazz_led.o
 obj-mips-y += gt64xxx.o pckbd.o mc146818rtc.o
 obj-mips-y += piix4.o cirrus_vga.o
+obj-mips-$(CONFIG_FULONG) += bonito.o

 obj-microblaze-y = petalogix_s3adsp1800_mmu.o

diff --git a/default-configs/mips64el-softmmu.mak
b/default-configs/mips64el-softmmu.mak
index b9b8c71..970568c 100644
--- a/default-configs/mips64el-softmmu.mak
+++ b/default-configs/mips64el-softmmu.mak
@@ -26,3 +26,4 @@ CONFIG_DP8393X=y
 CONFIG_DS1225Y=y
 CONFIG_MIPSNET=y
 CONFIG_PFLASH_CFI01=y
+CONFIG_FULONG=y
diff --git a/hw/bonito.c b/hw/bonito.c
new file mode 100644
index 000..246c12a
--- /dev/null
+++ b/hw/bonito.c
@@ -0,0 +1,950 @@
+/*
+ * bonito north bridge support
+ *
+ * Copyright (c) 2008 yajin (ya...@vm-kernel.org)
+ * Copyright (c) 2010 Huacai Chen (zltjiang...@gmail.com)
+ *
+ * This code is licensed under the GNU GPL v2.
+ */
+
+/*
+ * fulong 2e mini pc has a bonito north bridge.
+ */
+
+/* what is the meaning of devfn in qemu and IDSEL in bonito northbridge?
+ *
+ * devfn   pci_slot<<3  + funno
+ * one pci bus can have 32 devices and each device can have 8 functions.
+ *
+ * In bonito north bridge, pci slot = IDSEL bit - 12.
+ * For example, PCI_IDSEL_VIA686B = 17,
+ * pci slot = 17-12=5
+ *
+ * so
+ * VT686B_FUN0's devfn = (5<<3)+0
+ * VT686B_FUN1's devfn = (5<<3)+1
+ *
+ * qemu also uses pci address for north bridge to access pci config register.
+ * bus_no   [23:16]
+ * dev_no   [15:11]
+ * fun_no   [10:8]
+ * reg_no   [7:2]
+ *
+ * so function bonito_sbridge_pciaddr for the translation from
+ * north bridge address to pci address.
+ */
+
+#include 
+
+#include "hw.h"
+#include "pci.h"
+#include "pc.h"
+#include "mips.h"
+
+typedef target_phys_addr_t pci_addr_t;
+#include "pci_host.h"
+
+//#define DEBUG_BONITO
+
+#ifdef DEBUG_BONITO
+#define DPRINTF(fmt, ...) fprintf(stderr, "%s: " fmt, __FUNCTION__,
##__VA_ARGS__)
+#else
+#define DPRINTF(fmt, ...)
+#endif
+
+/* from linux soure code. include/asm-mips/mips-boards/bonito64.h*/
+#define BONITO_BOOT_BASE0x1fc0
+#define BONITO_BOOT_SIZE0x0010
+#define BONITO_BOOT_TOP (BONITO_BOOT_BASE+BONITO_BOOT_SIZE-1)
+#define BONITO_FLASH_BASE   0x1c00
+#define BONITO_FLASH_SIZE   0x0300
+#define BONITO_FLASH_TOP(BONITO_FLASH_BASE+BONITO_FLASH_SIZE-1)
+#define BONITO_SOCKET_BASE  0x1f80
+#define BONITO_SOCKET_SIZE  0x0040
+#define BONITO_SOCKET_TOP   (BONITO_SOCKET_BASE+BONITO_SOCKET_SIZE-1)
+#define BONITO_REG_BASE 0x1fe0
+#define BONITO_REG_SIZE 0x0004
+#define BONITO_REG_TOP  (BONITO_REG_BASE+BONITO_REG_SIZE-1)
+#define BONITO_DEV_BASE 0x1ff0
+#define BONITO_DEV_SIZE 0x0010
+#define BONITO_DEV_TOP  (BONITO_DEV_BASE+BONITO_DEV_SIZE-1)
+#define BONITO_PCILO_BASE   0x1000
+#define BONITO_PCILO_BASE_VA0xb000
+#define BONITO_PCILO_SIZE   0x0c00
+#define BONITO_PCILO_TOP(BONITO_PCILO_BASE+BONITO_PCILO_SIZE-1)
+#define BONITO_PCILO0_BASE  0x1000
+#define BONITO_PCILO1_BASE  0x1400
+#define BONITO_PCILO2_BASE  0x1800
+#define BONITO_PCIHI_BASE   0x2000
+#define BONITO_PCIHI_SIZE   0x2000
+#define BONITO_PCIHI_TOP(BONITO_PCIHI_BASE+BONITO_PCIHI_SIZE-1)
+#define BONITO_PCIIO_BASE   0x1fd0
+#define BONITO_PCIIO_BASE_VA0xbfd0
+#define BONITO_PCIIO_SIZE   0x0001
+#define BONITO_PCIIO_TOP(BONITO_PCIIO_BASE+BONITO_PCIIO_SIZE-1)
+#define BONITO_PCICFG_BASE  0x1fe8
+#define BONITO_PCICFG_SIZE  0x0008
+#define BONITO_PCICFG_TOP   (BONITO_PCICFG_BASE+BONITO_PCICFG_SIZE-1)
+
+
+#define BONITO_PCICONFIGBASE0x00
+#define BONITO_REGBASE  0x100
+
+#define BONITO_PCICONFIG_BASE   (BONITO_PCICONFIGBASE+BONITO_REG_BASE)
+#define BONITO_PCICONFIG_SIZE   (0x100)
+
+#define BONITO_INTERNAL_REG_BASE  (BONITO_REGBASE+BONITO_REG_BASE)
+#define BONITO_INTERNAL_REG_SIZE  (0x70)
+
+#define BONITO_SPCICONFIG_BASE  (BONITO_PCICFG_BASE)
+#define BONITO_SPCICONFIG_SIZE  (BONITO_PCICFG_SIZE)
+
+
+
+/* 1. Bonito h/w Configuration */
+/* Power on register */
+
+#define BONITO_BONPONCFG(0x00 >> 2)  /* 0x100 */
+#define BONITO_BONGENCFG_OFFSET 0x4
+#define BONITO_BONGENCFG(BONITO_BONGENCFG_OFFSET>>2)   /*0x104 */
+
+/* 2. IO & IDE configuration */
+#define BONITO_IODEVCFG (0x08 >> 2)  /* 0x108 */
+
+/* 3. IO & IDE configuration */
+#define BONITO_SDCFG(0x0c >> 2

[Qemu-devel] [PATCH v2 0/2] Drop pci_add and pci_del from QMP

[Markus Armbruster]

See PATCH 1/1 for rationale.

v2: Cover pci_del, better commit message, rebased (no conflicts)

Markus Armbruster (2):
  Revert "PCI: Convert pci_device_hot_add() to QObject"
  Revert "monitor: Convert do_pci_device_hot_remove() to QObject"

 hw/pci-hotplug.c |   51 +++
 qemu-monitor.hx  |6 ++
 sysemu.h |6 ++
 3 files changed, 11 insertions(+), 52 deletions(-)

[Qemu-devel] [PATCH v2 2/2] Revert "monitor: Convert do_pci_device_hot_remove() to QObject"

[Markus Armbruster]

We don't want pci_del in QMP.  Use device_del instead.

This reverts commit 6848d827162fea039f2658414a4adb6164a4f9b0.

Conflicts:

hw/pci-hotplug.c
sysemu.h

Signed-off-by: Markus Armbruster 
---
 hw/pci-hotplug.c |5 ++---
 qemu-monitor.hx  |3 +--
 sysemu.h |3 +--
 3 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/hw/pci-hotplug.c b/hw/pci-hotplug.c
index 22a7ce4..37ac015 100644
--- a/hw/pci-hotplug.c
+++ b/hw/pci-hotplug.c
@@ -277,8 +277,7 @@ int pci_device_hot_remove(Monitor *mon, const char 
*pci_addr)
 return qdev_unplug(&d->qdev);
 }
 
-int do_pci_device_hot_remove(Monitor *mon, const QDict *qdict,
- QObject **ret_data)
+void do_pci_device_hot_remove(Monitor *mon, const QDict *qdict)
 {
-return pci_device_hot_remove(mon, qdict_get_str(qdict, "pci_addr"));
+pci_device_hot_remove(mon, qdict_get_str(qdict, "pci_addr"));
 }
diff --git a/qemu-monitor.hx b/qemu-monitor.hx
index fba4c3f..b6e3467 100644
--- a/qemu-monitor.hx
+++ b/qemu-monitor.hx
@@ -874,8 +874,7 @@ ETEXI
 .args_type  = "pci_addr:s",
 .params = "[[:]:]",
 .help   = "hot remove PCI device",
-.user_print = monitor_user_noop,
-.mhandler.cmd_new = do_pci_device_hot_remove,
+.mhandler.cmd = do_pci_device_hot_remove,
 },
 #endif
 
diff --git a/sysemu.h b/sysemu.h
index 47975b5..643c0c6 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -204,8 +204,7 @@ DriveInfo *add_init_drive(const char *opts);
 void pci_device_hot_add(Monitor *mon, const QDict *qdict);
 void drive_hot_add(Monitor *mon, const QDict *qdict);
 int pci_device_hot_remove(Monitor *mon, const char *pci_addr);
-int do_pci_device_hot_remove(Monitor *mon, const QDict *qdict,
- QObject **ret_data);
+void do_pci_device_hot_remove(Monitor *mon, const QDict *qdict);
 
 /* serial ports */
 
-- 
1.6.6.1

[Qemu-devel] [PATCH v2 1/2] Revert "PCI: Convert pci_device_hot_add() to QObject"

[Markus Armbruster]

Short story: We don't want pci_add in QMP.  Long story follows.

pci_add can do two things:

* Hot plug a PCI NIC.  device_add is more general.

* Hot plug a PCI disk controller, and a drive connected to it.

  The controller is either virtio-blk-pci (if=virtio) or lsi53c895a
  (if=scsi).  With the latter, the drive is optional.  Use drive_add to
  hotplug additional SCSI drives.  Except drive_add is not available in
  QMP.

  device_add is more general for controllers and the guest part of
  drives.  I'm working on a more general alternative for the host part
  of drives.

Why am I proposing to remove pci_add from QMP before its replacement is
ready?  I want it out sooner rather than later, because it isn't fully
functional (errors and drive_add are missing), and we do not plan to
complete the job.  In other words, it's not really usable over QMP now,
and it's not what we want for QMP anyway.  Since we don't want it to be
used over QMP, we should take it out, not leave it around as a trap for
the uninitiated.

Dan Berrange confirmed that libvirt has no need for pci_add & friends
over QMP.

This reverts commit 7a344f7ac7bb651d0556a933ed8060d3a9e5d949.

Conflicts:

hw/pci-hotplug.c
sysemu.h

Signed-off-by: Markus Armbruster 
---
 hw/pci-hotplug.c |   46 +-
 qemu-monitor.hx  |3 +--
 sysemu.h |3 +--
 3 files changed, 7 insertions(+), 45 deletions(-)

diff --git a/hw/pci-hotplug.c b/hw/pci-hotplug.c
index cc45c50..22a7ce4 100644
--- a/hw/pci-hotplug.c
+++ b/hw/pci-hotplug.c
@@ -33,7 +33,6 @@
 #include "scsi.h"
 #include "virtio-blk.h"
 #include "qemu-config.h"
-#include "qemu-objects.h"
 
 #if defined(TARGET_I386)
 static PCIDevice *qemu_pci_hot_add_nic(Monitor *mon,
@@ -224,36 +223,7 @@ static PCIDevice *qemu_pci_hot_add_storage(Monitor *mon,
 return dev;
 }
 
-void pci_device_hot_add_print(Monitor *mon, const QObject *data)
-{
-QDict *qdict;
-
-assert(qobject_type(data) == QTYPE_QDICT);
-qdict = qobject_to_qdict(data);
-
-monitor_printf(mon, "OK domain %d, bus %d, slot %d, function %d\n",
-   (int) qdict_get_int(qdict, "domain"),
-   (int) qdict_get_int(qdict, "bus"),
-   (int) qdict_get_int(qdict, "slot"),
-   (int) qdict_get_int(qdict, "function"));
-
-}
-
-/**
- * pci_device_hot_add(): Hot add a PCI device
- *
- * Return a QDict with the following device information:
- *
- * - "domain": domain number
- * - "bus": bus number
- * - "slot": slot number
- * - "function": function number
- *
- * Example:
- *
- * { "domain": 0, "bus": 0, "slot": 5, "function": 0 }
- */
-int pci_device_hot_add(Monitor *mon, const QDict *qdict, QObject **ret_data)
+void pci_device_hot_add(Monitor *mon, const QDict *qdict)
 {
 PCIDevice *dev = NULL;
 const char *pci_addr = qdict_get_str(qdict, "pci_addr");
@@ -278,20 +248,14 @@ int pci_device_hot_add(Monitor *mon, const QDict *qdict, 
QObject **ret_data)
 dev = qemu_pci_hot_add_storage(mon, pci_addr, opts);
 } else {
 monitor_printf(mon, "invalid type: %s\n", type);
-return -1;
 }
 
 if (dev) {
-*ret_data =
-qobject_from_jsonf("{ 'domain': 0, 'bus': %d, 'slot': %d, "
-   "'function': %d }", pci_bus_num(dev->bus),
-   PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn));
-} else {
+monitor_printf(mon, "OK domain %d, bus %d, slot %d, function %d\n",
+   0, pci_bus_num(dev->bus), PCI_SLOT(dev->devfn),
+   PCI_FUNC(dev->devfn));
+} else
 monitor_printf(mon, "failed to add %s\n", opts);
-return -1;
-}
-
-return 0;
 }
 #endif
 
diff --git a/qemu-monitor.hx b/qemu-monitor.hx
index a8f194c..fba4c3f 100644
--- a/qemu-monitor.hx
+++ b/qemu-monitor.hx
@@ -858,8 +858,7 @@ ETEXI
 .args_type  = "pci_addr:s,type:s,opts:s?",
 .params = "auto|[[:]:] nic|storage 
[[vlan=n][,macaddr=addr][,model=type]] [file=file][,if=type][,bus=nr]...",
 .help   = "hot-add PCI device",
-.user_print = pci_device_hot_add_print,
-.mhandler.cmd_new = pci_device_hot_add,
+.mhandler.cmd = pci_device_hot_add,
 },
 #endif
 
diff --git a/sysemu.h b/sysemu.h
index fa921df..47975b5 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -201,8 +201,7 @@ extern DriveInfo *drive_init(QemuOpts *arg, void *machine, 
int *fatal_error);
 DriveInfo *add_init_drive(const char *opts);
 
 /* pci-hotplug */
-void pci_device_hot_add_print(Monitor *mon, const QObject *data);
-int pci_device_hot_add(Monitor *mon, const QDict *qdict, QObject **ret_data);
+void pci_device_hot_add(Monitor *mon, const QDict *qdict);
 void drive_hot_add(Monitor *mon, const QDict *qdict);
 int pci_device_hot_remove(Monitor *mon, const char *pci_addr);
 int do_pci_device_hot_remove(Monitor *mon, const QDict *qdict,
-- 
1.6.6.1

[Qemu-devel] [PATCH 3/6] MIPS: Initial support of VIA IDE controller used by fulong mini pc

[chen huacai]

Signed-off-by: Huacai Chen 
---
 Makefile.objs|1 +
 default-configs/mips64el-softmmu.mak |1 +
 hw/ide.h |1 +
 hw/ide/via.c |  185 ++
 4 files changed, 188 insertions(+), 0 deletions(-)
 create mode 100644 hw/ide/via.c

diff --git a/Makefile.objs b/Makefile.objs
index ecdd53e..75be9ce 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -195,6 +195,7 @@ hw-obj-$(CONFIG_IDE_ISA) += ide/isa.o
 hw-obj-$(CONFIG_IDE_PIIX) += ide/piix.o
 hw-obj-$(CONFIG_IDE_CMD646) += ide/cmd646.o
 hw-obj-$(CONFIG_IDE_MACIO) += ide/macio.o
+hw-obj-$(CONFIG_IDE_VIA) += ide/via.o

 # SCSI layer
 hw-obj-y += lsi53c895a.o
diff --git a/default-configs/mips64el-softmmu.mak
b/default-configs/mips64el-softmmu.mak
index 970568c..8399c85 100644
--- a/default-configs/mips64el-softmmu.mak
+++ b/default-configs/mips64el-softmmu.mak
@@ -18,6 +18,7 @@ CONFIG_IDE_QDEV=y
 CONFIG_IDE_PCI=y
 CONFIG_IDE_ISA=y
 CONFIG_IDE_PIIX=y
+CONFIG_IDE_VIA=y
 CONFIG_NE2000_ISA=y
 CONFIG_SOUND=y
 CONFIG_VIRTIO_PCI=y
diff --git a/hw/ide.h b/hw/ide.h
index 0e7d540..bb635b6 100644
--- a/hw/ide.h
+++ b/hw/ide.h
@@ -12,6 +12,7 @@ void pci_cmd646_ide_init(PCIBus *bus, DriveInfo **hd_table,
  int secondary_ide_enabled);
 void pci_piix3_ide_init(PCIBus *bus, DriveInfo **hd_table, int devfn);
 void pci_piix4_ide_init(PCIBus *bus, DriveInfo **hd_table, int devfn);
+void vt82c686b_ide_init(PCIBus *bus, DriveInfo **hd_table, int devfn);

 /* ide-macio.c */
 int pmac_ide_init (DriveInfo **hd_table, qemu_irq irq,
diff --git a/hw/ide/via.c b/hw/ide/via.c
new file mode 100644
index 000..f76763c
--- /dev/null
+++ b/hw/ide/via.c
@@ -0,0 +1,185 @@
+/*
+ * QEMU IDE Emulation: PCI VIA82C686B support.
+ *
+ * Copyright (c) 2003 Fabrice Bellard
+ * Copyright (c) 2006 Openedhand Ltd.
+ * Copyright (c) 2010 Huacai Chen 
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the
"Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+#include 
+#include 
+#include 
+#include 
+#include "block.h"
+#include "block_int.h"
+#include "sysemu.h"
+#include "dma.h"
+
+#include 
+
+static uint32_t bmdma_readb(void *opaque, uint32_t addr)
+{
+BMDMAState *bm = opaque;
+uint32_t val;
+
+switch (addr & 3) {
+case 0:
+val = bm->cmd;
+break;
+case 2:
+val = bm->status;
+break;
+default:
+val = 0xff;
+break;
+}
+#ifdef DEBUG_IDE
+printf("bmdma: readb 0x%02x : 0x%02x\n", addr, val);
+#endif
+return val;
+}
+
+static void bmdma_writeb(void *opaque, uint32_t addr, uint32_t val)
+{
+BMDMAState *bm = opaque;
+#ifdef DEBUG_IDE
+printf("bmdma: writeb 0x%02x : 0x%02x\n", addr, val);
+#endif
+switch (addr & 3) {
+case 2:
+bm->status = (val & 0x60) | (bm->status & 1) | (bm->status &
~val & 0x06);
+break;
+default:;
+}
+}
+
+static void bmdma_map(PCIDevice *pci_dev, int region_num,
+pcibus_t addr, pcibus_t size, int type)
+{
+PCIIDEState *d = DO_UPCAST(PCIIDEState, dev, pci_dev);
+int i;
+
+for(i = 0;i < 2; i++) {
+BMDMAState *bm = &d->bmdma[i];
+d->bus[i].bmdma = bm;
+bm->bus = d->bus+i;
+qemu_add_vm_change_state_handler(ide_dma_restart_cb, bm);
+
+register_ioport_write(addr, 1, 1, bmdma_cmd_writeb, bm);
+
+register_ioport_write(addr + 1, 3, 1, bmdma_writeb, bm);
+register_ioport_read(addr, 4, 1, bmdma_readb, bm);
+
+register_ioport_write(addr + 4, 4, 1, bmdma_addr_writeb, bm);
+register_ioport_read(addr + 4, 4, 1, bmdma_addr_readb, bm);
+register_ioport_write(addr + 4, 4, 2, bmdma_addr_writew, bm);
+register_ioport_read(addr + 4, 4, 2, bmdma_addr_readw, bm);
+register_ioport_write(addr + 4, 4, 4, bmdma_addr_writel, bm);
+register_ioport_read(addr + 4, 4, 4, bmdma_addr_readl, bm);
+addr += 8;
+}
+}
+
+static void via_reset(void *opaque)
+{

[Qemu-devel] [PATCH 2/6] MIPS: Initial support of vt82686b south bridge used by fulong mini pc

[chen huacai]

Signed-off-by: Huacai Chen 
---
 Makefile.target |2 +-
 hw/pc.h |7 +
 hw/pci_ids.h|8 +
 hw/vt82c686.c   |  786 +++
 4 files changed, 802 insertions(+), 1 deletions(-)
 create mode 100644 hw/vt82c686.c

diff --git a/Makefile.target b/Makefile.target
index 63d9f49..4fc1290 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -220,7 +220,7 @@ obj-mips-y += dma.o vga.o i8259.o
 obj-mips-y += g364fb.o jazz_led.o
 obj-mips-y += gt64xxx.o pckbd.o mc146818rtc.o
 obj-mips-y += piix4.o cirrus_vga.o
-obj-mips-$(CONFIG_FULONG) += bonito.o
+obj-mips-$(CONFIG_FULONG) += bonito.o vt82c686.o

 obj-microblaze-y = petalogix_s3adsp1800_mmu.o

diff --git a/hw/pc.h b/hw/pc.h
index d11a576..8951609 100644
--- a/hw/pc.h
+++ b/hw/pc.h
@@ -115,6 +115,13 @@ void i440fx_init_memory_mappings(PCII440FXState *d);
 extern PCIDevice *piix4_dev;
 int piix4_init(PCIBus *bus, int devfn);

+/* vt82c686.c */
+int vt82c686b_init(PCIBus * bus, int devfn);
+void vt82c686b_ac97_init(PCIBus *bus, int devfn);
+void vt82c686b_mc97_init(PCIBus *bus, int devfn);
+i2c_bus *vt82c686b_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
+qemu_irq sci_irq);
+
 /* vga.c */
 enum vga_retrace_method {
 VGA_RETRACE_DUMB,
diff --git a/hw/pci_ids.h b/hw/pci_ids.h
index fe7a121..39e9f1d 100644
--- a/hw/pci_ids.h
+++ b/hw/pci_ids.h
@@ -78,6 +78,14 @@

 #define PCI_VENDOR_ID_XILINX 0x10ee

+#define PCI_VENDOR_ID_VIA0x1106
+#define PCI_DEVICE_ID_VIA_ISA_BRIDGE 0x0686
+#define PCI_DEVICE_ID_VIA_IDE0x0571
+#define PCI_DEVICE_ID_VIA_UHCI   0x3038
+#define PCI_DEVICE_ID_VIA_ACPI   0x3057
+#define PCI_DEVICE_ID_VIA_AC97   0x3058
+#define PCI_DEVICE_ID_VIA_MC97   0x3068
+
 #define PCI_VENDOR_ID_MARVELL0x11ab

 #define PCI_VENDOR_ID_ENSONIQ0x1274
diff --git a/hw/vt82c686.c b/hw/vt82c686.c
new file mode 100644
index 000..1045467
--- /dev/null
+++ b/hw/vt82c686.c
@@ -0,0 +1,786 @@
+/*
+ * VT82C686B south bridge support
+ *
+ * Copyright (c) 2008 yajin (ya...@vm-kernel.org)
+ * Copyright (c) 2009 chenming (chenm...@rdc.faw.com.cn)
+ * Copyright (c) 2010 Huacai Chen (zltjiang...@gmail.com)
+ * This code is licensed under the GNU GPL v2.
+ */
+
+#include "hw.h"
+#include "pc.h"
+#include "i2c.h"
+#include "smbus.h"
+#include "pci.h"
+#include "isa.h"
+#include "sysbus.h"
+#include "mips.h"
+
+typedef uint32_t pci_addr_t;
+#include "pci_host.h"
+//#define DEBUG_VT82C686B
+
+#ifdef DEBUG_VT82C686B
+#define DPRINTF(fmt, ...) fprintf(stderr, "%s: " fmt, __FUNCTION__,
##__VA_ARGS__)
+#else
+#define DPRINTF(fmt, ...)
+#endif
+
+typedef struct SuperIOConfig
+{
+uint8_t config[0xff];
+uint8_t index;
+uint8_t data;
+} SuperIOConfig;
+
+typedef struct VT82C686BState {
+PCIDevice dev;
+SuperIOConfig *superio_conf;
+} VT82C686BState;
+
+uint32_t smb_data[16];
+static void superio_ioport_writeb(void *opaque, uint32_t addr, uint32_t data)
+{
+int can_write;
+SuperIOConfig *superio_conf = (SuperIOConfig *)opaque;
+
+DPRINTF("superio_ioport_writeb  address 0x%x  val 0x%x  \n", addr, data);
+if (addr == 0x3f0) {
+superio_conf->index = data & 0xff;
+} else {
+/* 0x3f1 */
+switch (superio_conf->index) {
+case 0x00 ... 0xdf:
+case 0xe4:
+case 0xe5:
+case 0xe9 ... 0xed:
+case 0xf3:
+case 0xf5:
+case 0xf7:
+case 0xf9 ... 0xfb:
+case 0xfd ... 0xff:
+can_write = 0;
+break;
+default:
+can_write = 1;
+
+if (can_write) {
+switch (superio_conf->index) {
+case 0xe7:
+if ((data & 0xff) != 0xfe) {
+DPRINTF("chage uart 1 base. unsupported yet \n");
+}
+break;
+case 0xe8:
+if ((data & 0xff) != 0xbe) {
+DPRINTF("chage uart 2 base. unsupported yet \n");
+}
+break;
+
+default:
+superio_conf->config[superio_conf->index] = data & 0xff;
+}
+}
+}
+superio_conf->config[superio_conf->index] = data & 0xff;
+}
+}
+
+static uint32_t superio_ioport_readb(void *opaque, uint32_t addr)
+{
+SuperIOConfig *superio_conf = (SuperIOConfig *)opaque;
+
+DPRINTF("superio_ioport_readb  address 0x%x   \n", addr);
+return (superio_conf->config[superio_conf->index]);
+}
+
+static void vt82c686b_reset(void * opaque)
+{
+PCIDevice *d = opaque;
+uint8_t *pci_conf = d->config;
+VT82C686BState *vt82c = DO_UPCAST(VT82C686BState, dev, d);
+
+pci_set_long(pci_conf + PCI_CAPABILITY_LIST, 0x00c0);
+
+pci_conf[0x04] = 0x87; /* master, memory, I/O and special */
+pci_conf[0x05] = 0x00;
+pci_conf[0x06] = 0x00;
+pci_conf[0x07]

[Qemu-devel] [PATCH 4/6] MIPS: Initial support of VIA USB controller used by fulong mini pc

[chen huacai]

Signed-off-by: Huacai Chen 
---
 hw/usb-uhci.c |   30 ++
 hw/usb-uhci.h |1 +
 2 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/hw/usb-uhci.c b/hw/usb-uhci.c
index 624d55b..5fd5388 100644
--- a/hw/usb-uhci.c
+++ b/hw/usb-uhci.c
@@ -1152,6 +1152,26 @@ static int usb_uhci_piix4_initfn(PCIDevice *dev)
 return usb_uhci_common_initfn(s);
 }

+static int usb_uhci_vt82c686b_initfn(PCIDevice *dev)
+{
+UHCIState *s = DO_UPCAST(UHCIState, dev, dev);
+uint8_t *pci_conf = s->dev.config;
+
+pci_config_set_vendor_id(pci_conf, PCI_VENDOR_ID_VIA);
+pci_config_set_device_id(pci_conf, PCI_DEVICE_ID_VIA_UHCI);
+
+pci_set_long(pci_conf + 0x0c,0x1600);
+pci_set_long(pci_conf + 0x20,0x0301);
+pci_set_long(pci_conf + 0x34,0x1080);
+pci_set_long(pci_conf + 0x3c,0x0004);
+pci_set_long(pci_conf + 0x40,0x1000);
+pci_set_long(pci_conf + 0x60,0x0010);
+pci_set_long(pci_conf + 0x80,0x00020001);
+pci_set_long(pci_conf + 0xc0,0x2000);
+
+return usb_uhci_common_initfn(s);
+}
+
 static PCIDeviceInfo uhci_info[] = {
 {
 .qdev.name= "piix3-usb-uhci",
@@ -1164,6 +1184,11 @@ static PCIDeviceInfo uhci_info[] = {
 .qdev.vmsd= &vmstate_uhci,
 .init = usb_uhci_piix4_initfn,
 },{
+.qdev.name= "vt82c686b-usb-uhci",
+.qdev.size= sizeof(UHCIState),
+.qdev.vmsd= &vmstate_uhci,
+.init = usb_uhci_vt82c686b_initfn,
+},{
 /* end of list */
 }
 };
@@ -1183,3 +1208,8 @@ void usb_uhci_piix4_init(PCIBus *bus, int devfn)
 {
 pci_create_simple(bus, devfn, "piix4-usb-uhci");
 }
+
+void usb_uhci_vt82c686b_init(PCIBus *bus, int devfn)
+{
+pci_create_simple(bus, devfn, "vt82c686b-usb-uhci");
+}
diff --git a/hw/usb-uhci.h b/hw/usb-uhci.h
index 911948e..3e4d377 100644
--- a/hw/usb-uhci.h
+++ b/hw/usb-uhci.h
@@ -5,5 +5,6 @@

 void usb_uhci_piix3_init(PCIBus *bus, int devfn);
 void usb_uhci_piix4_init(PCIBus *bus, int devfn);
+void usb_uhci_vt82c686b_init(PCIBus *bus, int devfn);

 #endif
-- 
1.7.0.4

[Qemu-devel] [PATCH 5/6] MIPS: Initial support of fulong mini pc (CPU definition, machine construction, etc.)

[chen huacai]

Signed-off-by: Huacai Chen 
---
 Makefile.target  |2 +-
 hw/mips_fulong2e.c   |  420 ++
 target-mips/translate_init.c |   35 
 3 files changed, 456 insertions(+), 1 deletions(-)
 create mode 100644 hw/mips_fulong2e.c

diff --git a/Makefile.target b/Makefile.target
index 4fc1290..7a9d93b 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -220,7 +220,7 @@ obj-mips-y += dma.o vga.o i8259.o
 obj-mips-y += g364fb.o jazz_led.o
 obj-mips-y += gt64xxx.o pckbd.o mc146818rtc.o
 obj-mips-y += piix4.o cirrus_vga.o
-obj-mips-$(CONFIG_FULONG) += bonito.o vt82c686.o
+obj-mips-$(CONFIG_FULONG) += bonito.o vt82c686.o mips_fulong2e.o

 obj-microblaze-y = petalogix_s3adsp1800_mmu.o

diff --git a/hw/mips_fulong2e.c b/hw/mips_fulong2e.c
new file mode 100644
index 000..3f6d25b
--- /dev/null
+++ b/hw/mips_fulong2e.c
@@ -0,0 +1,420 @@
+/*
+ * QEMU fulong 2e mini pc support
+ *
+ * Copyright (c) 2008 yajin (ya...@vm-kernel.org)
+ * Copyright (c) 2009 chenming (chenm...@rdc.faw.com.cn)
+ * Copyright (c) 2010 Huacai Chen (zltjiang...@gmail.com)
+ * This code is licensed under the GNU GPL v2.
+ */
+
+/*
+ * Fulong 2e mini pc is based on ICT/ST Loongson 2e CPU (MIPS III like, 800MHz)
+ * http://www.linux-mips.org/wiki/Fulong
+ *
+ * Loongson 2e user manual:
+ * http://www.loongsondeveloper.com/doc/Loongson2EUserGuide.pdf
+ */
+
+#include "hw.h"
+#include "pc.h"
+#include "fdc.h"
+#include "net.h"
+#include "boards.h"
+#include "smbus.h"
+#include "block.h"
+#include "flash.h"
+#include "mips.h"
+#include "mips_cpudevs.h"
+#include "pci.h"
+#include "usb-uhci.h"
+#include "qemu-char.h"
+#include "sysemu.h"
+#include "audio/audio.h"
+#include "qemu-log.h"
+#include "loader.h"
+#include "mips-bios.h"
+#include "ide.h"
+#include "elf.h"
+
+#define DEBUG_FULONG2E_INIT
+
+#define ENVP_ADDR   0x80002000l
+#define ENVP_NB_ENTRIES16
+#define ENVP_ENTRY_SIZE256
+
+#define MAX_IDE_BUS 2
+
+/* PCI SLOT in fulong 2e */
+#define FULONG2E_VIA_SLOT5
+#define FULONG2E_ATI_SLOT6
+#define FULONG2E_RTL8139_SLOT7
+
+static PITState *pit;
+
+static struct _loaderparams {
+int ram_size;
+const char *kernel_filename;
+const char *kernel_cmdline;
+const char *initrd_filename;
+} loaderparams;
+
+static void mips_qemu_writel (void *opaque, target_phys_addr_t addr,
+ uint32_t val)
+{
+if ((addr & 0x) == 0 && val == 42)
+qemu_system_reset_request ();
+else if ((addr & 0x) == 4 && val == 42)
+qemu_system_shutdown_request ();
+}
+
+static uint32_t mips_qemu_readl (void *opaque, target_phys_addr_t addr)
+{
+return 0;
+}
+
+static CPUWriteMemoryFunc *mips_qemu_write[] = {
+mips_qemu_writel,
+mips_qemu_writel,
+mips_qemu_writel,
+};
+
+static CPUReadMemoryFunc *mips_qemu_read[] = {
+mips_qemu_readl,
+mips_qemu_readl,
+mips_qemu_readl,
+};
+static int mips_qemu_iomemtype = 0;
+
+static void prom_set(uint32_t* prom_buf, int index, const char *string, ...)
+{
+va_list ap;
+int32_t table_addr;
+
+if (index >= ENVP_NB_ENTRIES)
+return;
+
+if (string == NULL) {
+prom_buf[index] = 0;
+return;
+}
+
+table_addr = sizeof(int32_t) * ENVP_NB_ENTRIES + index * ENVP_ENTRY_SIZE;
+prom_buf[index] = tswap32(ENVP_ADDR + table_addr);
+
+va_start(ap, string);
+vsnprintf((char *)prom_buf + table_addr, ENVP_ENTRY_SIZE, string, ap);
+va_end(ap);
+}
+
+static int64_t load_kernel (CPUState *env)
+{
+int64_t kernel_entry, kernel_low, kernel_high;
+int index = 0;
+long initrd_size;
+ram_addr_t initrd_offset;
+uint32_t *prom_buf;
+long prom_size;
+
+if (load_elf(loaderparams.kernel_filename, cpu_mips_kseg0_to_phys, NULL,
+ (uint64_t *)&kernel_entry, (uint64_t *)&kernel_low,
+ (uint64_t *)&kernel_high, 0, ELF_MACHINE, 1) < 0) {
+fprintf(stderr, "qemu: could not load kernel '%s'\n",
+loaderparams.kernel_filename);
+exit(1);
+}
+
+/* load initrd */
+initrd_size = 0;
+initrd_offset = 0;
+if (loaderparams.initrd_filename) {
+initrd_size = get_image_size (loaderparams.initrd_filename);
+if (initrd_size > 0) {
+initrd_offset = (kernel_high + ~TARGET_PAGE_MASK) &
TARGET_PAGE_MASK;
+if (initrd_offset + initrd_size > ram_size) {
+fprintf(stderr,
+"qemu: memory too small for initial ram disk '%s'\n",
+loaderparams.initrd_filename);
+exit(1);
+}
+initrd_size = load_image_targphys(loaderparams.initrd_filename,
+ initrd_offset, ram_size - initrd_offset);
+}
+if (initrd_size == (target_ulong) -1) {
+fprintf(stderr, "qemu: could not load initial ram disk '%s'\n",
+loaderparams.initrd

Re: [Qemu-devel] [PATCH 0/2] Enable qemu block layer to not flush

[Jamie Lokier]

Stefan Hajnoczi wrote:
> Why add a nop AIO operation instead of setting
> BlockDriverState->enable_write_cache to zero?  In that case no write
> cache would be reported to the guest (just like cache=writethrough).

Hmm.  If the guest sees write cache absent, that prevents changing the
cache policy on the host later (from not flushing to flushing), which
you might want to do after an OS install has finished and booted up.

-- Jamie

[Qemu-devel] Re: Commit 9c9bb6c89d4 breaks code execution from flash

[Jan Kiszka]

Michael Walle wrote:
> [sorry didn't see the CC to the mailinglist]
> 
> Am Friday 23 April 2010 09:23:49 schrieb Jan Kiszka:
>> Michael Walle wrote:
>>> Hi Jan,
>>>
>>> your commit "Optimize consecutive CFI02 writes by remapping memory
>>> lazily" breaks the code execution from flash.
>>>
>>> If you write to the flash, the flash will switch into I/O mode. Now if
>>> code is executed from this flash, a cpu_abort will be raised ("Trying to
>>> execute code outside RAM or ROM").
>> Hmm, guess I didn't test execute-in-place back then. Do you happen to
>> have a test case for this scenario? I'll look into this.
> Only for my qemu-lm32 port.. But reading the flash id, while executing this 
> code from flash should trigger the bug.
> 

OK, that was a hard nut. After various dead ends, I think I found an
possible solution. Can you give this a try?

diff --git a/exec-all.h b/exec-all.h
index 1016de2..b070da9 100644
--- a/exec-all.h
+++ b/exec-all.h
@@ -329,6 +329,10 @@ static inline tb_page_addr_t
get_page_addr_code(CPUState *env1, target_ulong add
 if (unlikely(env1->tlb_table[mmu_idx][page_index].addr_code !=
  (addr & TARGET_PAGE_MASK))) {
 ldub_code(addr);
+if (unlikely(env1->tlb_table[mmu_idx][page_index].addr_code &
+ TLB_INVALID_MASK)) {
+ldub_code(addr);
+}
 }
 pd = env1->tlb_table[mmu_idx][page_index].addr_code &
~TARGET_PAGE_MASK;
 if (pd > IO_MEM_ROM && !(pd & IO_MEM_ROMD)) {
diff --git a/hw/pflash_cfi02.c b/hw/pflash_cfi02.c
index f3d3f41..201e410 100644
--- a/hw/pflash_cfi02.c
+++ b/hw/pflash_cfi02.c
@@ -40,7 +40,7 @@
 #include "qemu-timer.h"
 #include "block.h"

-//#define PFLASH_DEBUG
+#define PFLASH_DEBUG
 #ifdef PFLASH_DEBUG
 #define DPRINTF(fmt, ...)  \
 do {   \
@@ -112,7 +112,7 @@ static uint32_t pflash_read (pflash_t *pfl,
target_phys_addr_t offset,

 DPRINTF("%s: offset " TARGET_FMT_plx "\n", __func__, offset);
 ret = -1;
-if (pfl->rom_mode) {
+if (!pfl->rom_mode) {
 /* Lazy reset of to ROMD mode */
 if (pfl->wcycle == 0)
 pflash_register_memory(pfl, 1);
@@ -185,7 +185,7 @@ static uint32_t pflash_read (pflash_t *pfl,
target_phys_addr_t offset,
 default:
 goto flash_read;
 }
-DPRINTF("%s: ID " TARGET_FMT_pld " %x\n", __func__, boff, ret);
+DPRINTF("%s: ID " TARGET_FMT_plx " %x\n", __func__, boff, ret);
 break;
 case 0xA0:
 case 0x10:


Still requires proper patch split up, and I need to think about possible
side effects.

Jan



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] Re: [PATCHv2] Support for booting from virtio disks

[Avi Kivity]

On 05/11/2010 03:31 PM, Gleb Natapov wrote:

On Tue, May 11, 2010 at 11:19:07AM +0300, Avi Kivity wrote:
   

On 05/10/2010 06:48 PM, Anthony Liguori wrote:
 

On 05/10/2010 03:11 AM, Gleb Natapov wrote:
   

This patch adds native support for booting from virtio disks to Seabios.

Signed-off-by: Gleb Natapov
 

A related problem that I think we need to think about how we solve
is indicating to Seabios which device we want to boot from

With your patch, a user can select a virtio device explicitly or
if they use only one virtio device, it will Just Work.

However, if a user uses IDE and virtio, or a user has multiple
disks, they cannot select a device via -boot.

Is this something we need to address?  I don't think we'd break
libvirt if we didn't.
   

BIOSes traditionally address this by storing the boot order in RTC
non-volatile memory, and allow the user to configure the order via a
menu.  We could do the same (storing the RTC memory in a small disk
image).

 

Real BIOS can do that because it enumerates all bootable devices,
attach name for each one of them and then asks user to configure
boot order using names it attached to devices. In our case we
want to provide boot order on qemu command line before BIOS
enumerated devices, so qemu should be able to pass enough information
about boot device so that BIOS can uniquely identify it after it will
discover all bootable devices. bus/device pair can be such thing.
   


Having a BIOS menu is also useful, you don't have to drop to the 
management tool, instead you do everything from the console.


   

Alternatively we can seed the order from the command line (-boot
id1,id2,id3 where id* are some qdev property attached to disks, this
is more flexible than the current syntax I think).

 

The problem is how to communicate this order to Seabios.
   


Topology (bus/device/lun).

--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.

[Qemu-devel] Re: [PATCHv2] Support for booting from virtio disks

[Gleb Natapov]

On Wed, May 12, 2010 at 10:22:59AM +0300, Avi Kivity wrote:
> On 05/11/2010 03:31 PM, Gleb Natapov wrote:
> >On Tue, May 11, 2010 at 11:19:07AM +0300, Avi Kivity wrote:
> >>On 05/10/2010 06:48 PM, Anthony Liguori wrote:
> >>>On 05/10/2010 03:11 AM, Gleb Natapov wrote:
> This patch adds native support for booting from virtio disks to Seabios.
> 
> Signed-off-by: Gleb Natapov
> >>>A related problem that I think we need to think about how we solve
> >>>is indicating to Seabios which device we want to boot from
> >>>
> >>>With your patch, a user can select a virtio device explicitly or
> >>>if they use only one virtio device, it will Just Work.
> >>>
> >>>However, if a user uses IDE and virtio, or a user has multiple
> >>>disks, they cannot select a device via -boot.
> >>>
> >>>Is this something we need to address?  I don't think we'd break
> >>>libvirt if we didn't.
> >>BIOSes traditionally address this by storing the boot order in RTC
> >>non-volatile memory, and allow the user to configure the order via a
> >>menu.  We could do the same (storing the RTC memory in a small disk
> >>image).
> >>
> >Real BIOS can do that because it enumerates all bootable devices,
> >attach name for each one of them and then asks user to configure
> >boot order using names it attached to devices. In our case we
> >want to provide boot order on qemu command line before BIOS
> >enumerated devices, so qemu should be able to pass enough information
> >about boot device so that BIOS can uniquely identify it after it will
> >discover all bootable devices. bus/device pair can be such thing.
> 
> Having a BIOS menu is also useful, you don't have to drop to the
> management tool, instead you do everything from the console.
> 
In Seabios we have functional boot menu. But it is management who
controls what disk plugged were.

> >>Alternatively we can seed the order from the command line (-boot
> >>id1,id2,id3 where id* are some qdev property attached to disks, this
> >>is more flexible than the current syntax I think).
> >>
> >The problem is how to communicate this order to Seabios.
> 
> Topology (bus/device/lun).
> 
Yeah, that what I proposed too actually.

--
Gleb.

Re: [Qemu-devel] Re: [PATCH 2/2] Add flush=off parameter to -drive

[Jamie Lokier]

Paul Brook wrote:
> > > Paul Brook wrote:
> > > > cache=none:
> > > >   No host caching. Reads and writes both go directly to underlying
> > > >   storage.
> > > > 
> > > > Useful to avoid double-caching.
> > > > 
> > > > cache=writethrough
> > > > 
> > > >   Reads are cached. Writes go directly to underlying storage.  Useful
> > > >   for
> > > > 
> > > > broken guests that aren't aware of drive caches.
> > > 
> > > These are misleading descriptions - because cache=none does not push
> > > writes down to powerfail-safe storage, while cache=writethrough might.
> > 
> > If so, then this is a serious bug.
> 
> .. though it may be a kernel bug rather that a qemu bug, depending on the 
> exact details.

It's not a kernel bug.  cache=none uses O_DIRECT, and O_DIRECT must
not force writes to powerfail-safe storage.  If it did, it would be
unusably slow for applications using O_DIRECT as a performance
enhancer / memory saver.  They can call fsync/fdatasync when they need
to for integrity.  (There might be kernel bugs in the latter department.)

> Either way, I consider any mode that inhibits host filesystem write
> cache but not volatile drive cache to be pretty worthless.

On the contrary, it greatly reduces host memory consumption so that
guest data isn't cached twice (it's already cached in the guest), and
it may improve performance by relaxing the POSIX write-serialisation
constraint (not sure if Linux cares; Solaris does).

> Either we guaranteed data integrity on completion or we don't.

The problem with the description of cache=none is it uses O_DIRECT,
which does always not push writes to powerfail-safe storage,.

O_DIRECT is effectively a hint.  It requests less caching in kernel
memory, may reduce memory usage and copying, may invoke direct DMA.

O_DIRECT does not tell the disk hardware to commit to powerfail-safe
storage.  I.e. it doesn't issue barriers or disable disk write caching.
(However, depending on a host setup, it might have that effect if disk
write cache is disabled by the admin).

Also, it doesn't even always write to disk: It falls back to buffered
in some circumstances, even on filesystems which support it - see
recent patches for btrfs which use buffered I/O for O_DIRECT for some
parts of some files.  (Many non-Linux OSes fall back to buffered
when any other process holds a non-O_DIRECT file descriptor, or when
requests don't meet some criteria).

The POSIX thing to use for cache=none would be O_DSYNC|O_RSYNC, and
that should work on some hosts, but Linux doesn't implement real O_RSYNC.

A combination which ought to work is O_DSYNC|O_DIRECT.  O_DIRECT is
the performance hint; O_DSYNC provides the commit request.  Christoph
Hellwig has mentioned that combination elsewhere on this thread.
It makes sense to me for cache=none.

O_DIRECT by itself is a useful performance & memory hint, so there
does need to be some option which maps onto O_DIRECT alone.  But it
shouldn't be documented as stronger than cache=writethrough, because
it isn't.

--  Jamie

Re: [Qemu-devel] Re: QEMU-KVM and video performance

[Jamie Lokier]

Gerhard Wiesinger wrote:
> On Wed, 21 Apr 2010, Jamie Lokier wrote:
> 
> >Gerhard Wiesinger wrote:
> >>Hmmm. I'm very new to QEMU and KVM but at least accessing the virtual HW
> >>of QEMU even from KVM must be possible (e.g. memory and port accesses are
> >>done on nearly every virtual device) and therefore I'm ending in C code in
> >>the QEMU hw/*.c directory. Therefore also the VGA memory area should be
> >>able to be accessable from KVM but with the specialized and fast memory
> >>access of QEMU.  Am I missing something?
> >
> >What you're missing is that when KVM calls out to QEMU to handle
> >hw/*.c traps, that call is very slow.  It's because the hardware-VM
> >support is a bit slow when the trap happens, and then the the call
> >from KVM in the kernel up to QEMU is a bit slow again.  Then all the
> >way back.  It adds up to a lot, for every I/O operation.
> 
> Isn't that then a general problem of KVM virtualization (oder hardware 
> virtualization) in general? Is this CPU dependend (AMD vs. Intel)?

Yes it is a general problem, but KVM emulates some time-critical
things in the kernel (like APIC and CPU instructions), so it's not too bad.

KVM is about 5x faster than TCG for most things, and slower for a few
things, so on balance it is usually faster.

The slow 256-colour mode writes sound like just a simple bug, though.
No need for complicated changes.

> >In 256-colour mode, KVM should be writing to the VGA memory at high
> >speed a lot like normal RAM, not trapping at the hardware-VM level,
> >and not calling up to the code in hw/*.c for every byte.
> 
> Yes, same picture to me: 256 color mode should be only a memory write (16 
> color mode is more difficult as pixel/byte mapping is not the same).
> But it looks like this isn't the case in this test scenario.
> 
> >You might double-check if your guest is using VGA "Mode X".  (See 
> >Wikipedia.)
> >
> >That was a way to accelerate VGA on real PCs, but it will be slow in
> >KVM for the same reasons as 16-colour mode.
> 
> Which way do you mean?

Look up Mode X on Wikipedia if you're interested, but it isn't
relevant to the problem you've reported.  Mode X cannot be enabled
with a BIOS call; it's a VGA hardware programming trick.  It would not
be useful in a VM environment.

-- Jamie

Re: [Qemu-devel] Re: QEMU-KVM and video performance

[Jamie Lokier]

Gerhard Wiesinger wrote:
> Can one switch to the old software vmm in VMWare?

Perhaps you can install a very old version of VMWare.
Maybe run it under KVM ;-)

> That was one of the reasons why I was looking for alternatives for 
> graphical DOS programs. Overall summary so far:
> 1.) QEMU without KVM: Problem with 286 DOS Extender instruction set, but 
> fast VGA
> 2.) QEMU with KVM: 286 DOS Extender apps ok, but slow VGA memory 
> performance
> 3.) VMWare Server 2.0 under Linux, application ok, but slow VGA memory 
> performance
> 4.) Virtual PC: Problems with 286 DOS Extender
> 5.) Bochs: Works well, but very slow.

I would be interested in the 286 DOS Extender issue, as I'd like to
use some 286 programs in QEMU at some point.

There were some changes to KVM in the kernel recently.  Were those
needed to get the 286 apps working?

> Looks like that VMWare Server and QEMU with KVM maybe have the same 
> architectural problems going through the whole slow chain from Guest OS to 
> virtualization layer for VGA writes.

They do have a similar architecture.

the VGA write speed is a bit surprising, as it should be fast in
256-colour non-modeX modes for both.  But maybe there's something
we've missed that makes it architecturally slow.  It will be
interesting to see what you find :-)

Thanks,
-- Jamie

[Qemu-devel] [PATCH] doc: Update info blockstats, qdm, and roms

[Stefan Hajnoczi]

The "info blockstats" documentation was copy-pasted as "info block"
instead of "info blockstats".  The documentation for "info qdm" and
"info roms" is missing.  This patch resolves these issues in
qemu-monitor.hx.

Signed-off-by: Stefan Hajnoczi 
---
 qemu-monitor.hx |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/qemu-monitor.hx b/qemu-monitor.hx
index a8f194c..2a7ad42 100644
--- a/qemu-monitor.hx
+++ b/qemu-monitor.hx
@@ -60,7 +60,7 @@ show the various VLANs and the associated devices
 show the character devices
 @item info block
 show the block devices
-...@item info block
+...@item info blockstats
 show block device statistics
 @item info registers
 show the cpu registers
@@ -114,6 +114,10 @@ show migration status
 show balloon information
 @item info qtree
 show device tree
+...@item info qdm
+show qdev device model list
+...@item info roms
+show roms
 @end table
 ETEXI
 
-- 
1.7.1

[Qemu-devel] [RFC PATCH 1/2] close all the block drivers before the qemu process exits

[MORITA Kazutaka]

This patch calls the close handler of the block driver before the qemu
process exits.

This is necessary because the sheepdog block driver releases the lock
of VM images in the close handler.

Signed-off-by: MORITA Kazutaka 
---
 block.c   |   11 +++
 block.h   |1 +
 monitor.c |1 +
 vl.c  |1 +
 4 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/block.c b/block.c
index 7326bfe..a606820 100644
--- a/block.c
+++ b/block.c
@@ -526,6 +526,17 @@ void bdrv_close(BlockDriverState *bs)
 }
 }
 
+void bdrv_close_all(void)
+{
+BlockDriverState *bs, *n;
+
+for (bs = bdrv_first, n = bs->next; bs; bs = n, n = bs ? bs->next : NULL) {
+if (bs && bs->drv && bs->drv->bdrv_close) {
+bs->drv->bdrv_close(bs);
+}
+}
+}
+
 void bdrv_delete(BlockDriverState *bs)
 {
 BlockDriverState **pbs;
diff --git a/block.h b/block.h
index fa51ddf..1a1293a 100644
--- a/block.h
+++ b/block.h
@@ -123,6 +123,7 @@ BlockDriverAIOCB *bdrv_aio_ioctl(BlockDriverState *bs,
 /* Ensure contents are flushed to disk.  */
 void bdrv_flush(BlockDriverState *bs);
 void bdrv_flush_all(void);
+void bdrv_close_all(void);
 
 int bdrv_is_allocated(BlockDriverState *bs, int64_t sector_num, int nb_sectors,
int *pnum);
diff --git a/monitor.c b/monitor.c
index 17e59f5..44bfe83 100644
--- a/monitor.c
+++ b/monitor.c
@@ -845,6 +845,7 @@ static void do_info_cpu_stats(Monitor *mon)
  */
 static void do_quit(Monitor *mon, const QDict *qdict, QObject **ret_data)
 {
+bdrv_close_all();
 exit(0);
 }
 
diff --git a/vl.c b/vl.c
index 77677e8..65160ed 100644
--- a/vl.c
+++ b/vl.c
@@ -4205,6 +4205,7 @@ static void main_loop(void)
 vm_stop(r);
 }
 }
+bdrv_close_all();
 pause_all_vcpus();
 }
 
-- 
1.5.6.5

Re: [Qemu-devel] [PATCH 0/2] Enable qemu block layer to not flush

[Stefan Hajnoczi]

On Wed, May 12, 2010 at 10:42 AM, Jamie Lokier  wrote:
> Stefan Hajnoczi wrote:
>> Why add a nop AIO operation instead of setting
>> BlockDriverState->enable_write_cache to zero?  In that case no write
>> cache would be reported to the guest (just like cache=writethrough).
>
> Hmm.  If the guest sees write cache absent, that prevents changing the
> cache policy on the host later (from not flushing to flushing), which
> you might want to do after an OS install has finished and booted up.

Right.  There are 3 cases from the guest perspective:

1. Disable write cache or no write cache.  Flushing not needed.
2. Disable flushing but leave write cache enabled.
3. Enable write cache and use flushing.

When we don't report a write cache at all, the guest is always stuck at 1.

If you're going to do this for installs and other temporary workloads,
then enabling the write cache again isn't an issue.  After installing
successfully, restart the guest with a sane cache= mode.

Stefan

[Qemu-devel] [RFC PATCH 0/2] Sheepdog: distributed storage system for QEMU

[MORITA Kazutaka]

Hi all,

This patch adds a block driver for Sheepdog distributed storage
system.  Please consider for inclusion.

Sheepdog is a distributed storage system for QEMU.  It provides highly
available block level storage volumes to VMs like Amazon EBS.

Sheepdog features are:
- No node in the cluster is special (no metadata node, no control
  node, etc)
- Linear scalability in performance and capacity
- No single point of failure
- Autonomous management (zero configuration)
- Useful volume management support such as snapshot and cloning
- Thin provisioning
- Autonomous load balancing

The more details are available at the project site [1] and my previous
post about sheepdog [2].

We have implemented the essential part of sheepdog features, and
believe the API between Sheepdog and QEMU is finalized.

Any comments or suggestions would be greatly appreciated.


Here are examples:

$ qemu-img create -f sheepdog vol1 256G # create images

$ qemu --drive format=sheepdog,file=vol1# start up a VM

$ qemu-img snapshot -c name sheepdog:vol1   # create a snapshot

$ qemu-img snapshot -l sheepdog:vol1# list snapshots
IDTAG VM SIZEDATE   VM CLOCK
1   0 2010-05-06 02:29:29   00:00:00.000
2   0 2010-05-06 02:29:55   00:00:00.000

$ qemu --drive format=sheepdog,file=vol1:1  # start up from a snapshot

$ qemu-img create -b sheepdog:vol1:1 -f sheepdog vol2   # clone images


Thanks,

Kazutaka

[1] http://www.osrg.net/sheepdog/

[2] http://lists.nongnu.org/archive/html/qemu-devel/2009-10/msg01773.html


MORITA Kazutaka (2):
  close all the block drivers before the qemu process exits
  block: add sheepdog driver for distributed storage support

 Makefile |2 +-
 block.c  |   14 +-
 block.h  |1 +
 block/sheepdog.c | 1828 ++
 monitor.c|1 +
 vl.c |1 +
 6 files changed, 1845 insertions(+), 2 deletions(-)
 create mode 100644 block/sheepdog.c

[Qemu-devel] [RFC PATCH 2/2] block: add sheepdog driver for distributed storage support

[MORITA Kazutaka]

Sheepdog is a distributed storage system for QEMU. It provides highly
available block level storage volumes to VMs like Amazon EBS.  This
patch adds a qemu block driver for Sheepdog.

Sheepdog features are:
- No node in the cluster is special (no metadata node, no control
  node, etc)
- Linear scalability in performance and capacity
- No single point of failure
- Autonomous management (zero configuration)
- Useful volume management support such as snapshot and cloning
- Thin provisioning
- Autonomous load balancing

The more details are available at the project site:
http://www.osrg.net/sheepdog/

Signed-off-by: MORITA Kazutaka 
---
 Makefile |2 +-
 block.c  |3 +-
 block/sheepdog.c | 1828 ++
 3 files changed, 1831 insertions(+), 2 deletions(-)
 create mode 100644 block/sheepdog.c

diff --git a/Makefile b/Makefile
index c1fa08c..d03cda1 100644
--- a/Makefile
+++ b/Makefile
@@ -97,7 +97,7 @@ block-obj-$(CONFIG_LINUX_AIO) += linux-aio.o
 
 block-nested-y += cow.o qcow.o vdi.o vmdk.o cloop.o dmg.o bochs.o vpc.o vvfat.o
 block-nested-y += qcow2.o qcow2-refcount.o qcow2-cluster.o qcow2-snapshot.o
-block-nested-y += parallels.o nbd.o
+block-nested-y += parallels.o nbd.o sheepdog.o
 block-nested-$(CONFIG_WIN32) += raw-win32.o
 block-nested-$(CONFIG_POSIX) += raw-posix.o
 block-nested-$(CONFIG_CURL) += curl.o
diff --git a/block.c b/block.c
index a606820..ab00f3f 100644
--- a/block.c
+++ b/block.c
@@ -307,7 +307,8 @@ static BlockDriver *find_image_format(const char *filename)
 
 drv = find_protocol(filename);
 /* no need to test disk image formats for vvfat */
-if (drv && strcmp(drv->format_name, "vvfat") == 0)
+if (drv && (!strcmp(drv->format_name, "vvfat") ||
+!strcmp(drv->format_name, "sheepdog")))
 return drv;
 
 ret = bdrv_file_open(&bs, filename, BDRV_O_RDONLY);
diff --git a/block/sheepdog.c b/block/sheepdog.c
new file mode 100644
index 000..7c07a52
--- /dev/null
+++ b/block/sheepdog.c
@@ -0,0 +1,1828 @@
+/*
+ * Copyright (C) 2009-2010 Nippon Telegraph and Telephone Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see .
+ */
+#include 
+#include 
+
+#include "qemu-common.h"
+#include "block_int.h"
+
+#define SD_PROTO_VER 0x01
+
+#define SD_DEFAULT_ADDR "localhost:7000"
+
+#define SD_OP_CREATE_AND_WRITE_OBJ  0x01
+#define SD_OP_READ_OBJ   0x02
+#define SD_OP_WRITE_OBJ  0x03
+
+#define SD_OP_NEW_VDI0x11
+#define SD_OP_LOCK_VDI   0x12
+#define SD_OP_RELEASE_VDI0x13
+#define SD_OP_GET_VDI_INFO   0x14
+#define SD_OP_READ_VDIS  0x15
+
+#define SD_FLAG_CMD_WRITE0x01
+#define SD_FLAG_CMD_COW  0x02
+
+#define SD_RES_SUCCESS   0x00 /* Success */
+#define SD_RES_UNKNOWN   0x01 /* Unknown error */
+#define SD_RES_NO_OBJ0x02 /* No object found */
+#define SD_RES_EIO   0x03 /* I/O error */
+#define SD_RES_VDI_EXIST 0x04 /* Vdi exists already */
+#define SD_RES_INVALID_PARMS 0x05 /* Invalid parameters */
+#define SD_RES_SYSTEM_ERROR  0x06 /* System error */
+#define SD_RES_VDI_LOCKED0x07 /* Vdi is locked */
+#define SD_RES_NO_VDI0x08 /* No vdi found */
+#define SD_RES_NO_BASE_VDI   0x09 /* No base vdi found */
+#define SD_RES_VDI_READ  0x0A /* Cannot read requested vdi */
+#define SD_RES_VDI_WRITE 0x0B /* Cannot write requested vdi */
+#define SD_RES_BASE_VDI_READ 0x0C /* Cannot read base vdi */
+#define SD_RES_BASE_VDI_WRITE   0x0D /* Cannot write base vdi */
+#define SD_RES_NO_TAG0x0E /* Requested tag is not found */
+#define SD_RES_STARTUP   0x0F /* Sheepdog is on starting up */
+#define SD_RES_VDI_NOT_LOCKED   0x10 /* Vdi is not locked */
+#define SD_RES_SHUTDOWN  0x11 /* Sheepdog is shutting down */
+#define SD_RES_NO_MEM0x12 /* Cannot allocate memory */
+#define SD_RES_FULL_VDI  0x13 /* we already have the maximum vdis */
+#define SD_RES_VER_MISMATCH  0x14 /* Protocol version mismatch */
+#define SD_RES_NO_SPACE  0x15 /* Server has no room for new objects */
+#define SD_RES_WAIT_FOR_FORMAT  0x16 /* Sheepdog is waiting for a format 
operation */
+#define SD_RES_WAIT_FOR_JOIN0x17 /* Sheepdog is waiting for other nodes 
joining */
+#define SD_RES_JOIN_FAILED   0x18 /* Target node had failed to join sheepdog */
+
+/*
+ * Object ID rules
+ *
+ *  0 - 19 (20 bits): data object space
+ * 20 - 31 (12 bits): reserved data object space
+ * 32 - 55 (24 bits): vdi object space
+ * 56 - 59 ( 4 bits): reserved vdi object space
+ * 60 - 63 ( 4 bits): object type indentifier space
+ */
+
+#define VDI_SPACE_SHIFT   32
+#define VDI_BIT (UINT64_C(1) << 63)
+#define VMSTATE_BIT (UINT64_C(1) << 62)
+#define MAX

Re: [Qemu-devel] Re: QEMU-KVM and video performance

[Avi Kivity]

On 05/12/2010 09:14 AM, Gerhard Wiesinger wrote:

On Mon, 10 May 2010, Avi Kivity wrote:


On 05/09/2010 10:35 PM, Gerhard Wiesinger wrote:




For 256 color more the first priority is to find out why direct 
mapping is not used.  I'd suggest tracing the code that makes this 
decision (in hw/*vga.c) and seeing if it's right or not.


I think this is because A000 is not initialized for KVM (see log below 
and logging patch attached).


Why isn't it initialized?

Did the guest configure things such as it is impossible to map it 
directly?  Or does the configuration allow direct mapping and qemu 
incorrectly decides that it cannot direct map?


Best would be to print out all the configuration registers and interpret 
them according to the specification.





vga_dirty_log_start
vga_dirty_log_start_mapping_lfb_vram_mapped, start=0x000A, 
len=0x8000
BUG: kvm_dirty_pages_log_change: invalid parameters 
000a-000a7fff


Why does this happen?

--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.

Re: [Qemu-devel] [PATCH] doc: Update info blockstats, qdm, and roms

[Markus Armbruster]

Stefan Hajnoczi  writes:

> The "info blockstats" documentation was copy-pasted as "info block"
> instead of "info blockstats".  The documentation for "info qdm" and
> "info roms" is missing.  This patch resolves these issues in
> qemu-monitor.hx.
>
> Signed-off-by: Stefan Hajnoczi 

Appreciated!

A few more items are still missing: commands (QMP only, it's a no-op in
the human monitor, I hate that), jit, numa.  Would you mind documenting
as well?

Re: [Qemu-devel] [RFC][MIPS][PATCH 1/6] Initial support of bonito north bridge used by fulong mini pc

[yajin]

>>
>> Bonito north bridge is built on FPGA now, VENDOR_ID/DEVICE_ID are
>>  temporary value so I didn't put them in pci_ids.h
>
> In that case, perhaps the code should be committed after the design
> has stabilized a bit more?
>

In fact, the FPGA north bridge is very stable. It has been shipped in
many loongson 2e boxes.

Thanks & Regards

yajin

Re: [Qemu-devel] [RFC PATCH 0/2] Sheepdog: distributed storage system for QEMU

[Kevin Wolf]

Am 12.05.2010 12:46, schrieb MORITA Kazutaka:
> Hi all,
> 
> This patch adds a block driver for Sheepdog distributed storage
> system.  Please consider for inclusion.
> 
> Sheepdog is a distributed storage system for QEMU.  It provides highly
> available block level storage volumes to VMs like Amazon EBS.
> 
> Sheepdog features are:
> - No node in the cluster is special (no metadata node, no control
>   node, etc)
> - Linear scalability in performance and capacity
> - No single point of failure
> - Autonomous management (zero configuration)
> - Useful volume management support such as snapshot and cloning
> - Thin provisioning
> - Autonomous load balancing
> 
> The more details are available at the project site [1] and my previous
> post about sheepdog [2].
> 
> We have implemented the essential part of sheepdog features, and
> believe the API between Sheepdog and QEMU is finalized.
> 
> Any comments or suggestions would be greatly appreciated.

These patches don't apply, neither on git master nor on the block
branch. Please rebase them on git://repo.or.cz/qemu/kevin.git block for
the next submission.

I'll have a closer look at your code later, but one thing I noticed is
that the new block driver is something in between a protocol and a
format driver (just like vvfat, which should stop doing so, too). I
think it ought to be a real protocol with the raw format driver on top
(or any other format - I don't see a reason why this should be
restricted to raw).

The one thing that is unusual about it as a protocol driver is that it
supports snapshots. However, while it is the first one, supporting
snapshots in protocols is a thing that could be generally useful to
support (for example thinking of a LVM protocol, which was discussed in
the past).

So in block.c we could check if the format driver supports snapshots,
and if it doesn't we try again with the underlying protocol. Not sure
yet what we would do when both format and protocol do support snapshots
(qcow2 on sheepdog/LVM/...), but that's a detail.

Kevin

[Qemu-devel] [PATCH] block: Remove special case for vvfat

[Kevin Wolf]

The special case doesn't really us buy anything. Without it vvfat works more
consistently as a protocol. We get raw on top of vvfat now, which works just
as well as using vvfat directly.

Signed-off-by: Kevin Wolf 
---
 block.c |5 -
 1 files changed, 0 insertions(+), 5 deletions(-)

diff --git a/block.c b/block.c
index ffe82f8..b65a3e5 100644
--- a/block.c
+++ b/block.c
@@ -326,11 +326,6 @@ static BlockDriver *find_image_format(const char *filename)
 uint8_t buf[2048];
 BlockDriverState *bs;
 
-drv = find_protocol(filename);
-/* no need to test disk image formats for vvfat */
-if (drv && strcmp(drv->format_name, "vvfat") == 0)
-return drv;
-
 ret = bdrv_file_open(&bs, filename, 0);
 if (ret < 0)
 return NULL;
-- 
1.6.6.1

[Qemu-devel] Re: Another SIGFPE in display code, now in cirrus

[Stefano Stabellini]

On Mon, 10 May 2010, Avi Kivity wrote:
> On 05/10/2010 10:41 AM, Avi Kivity wrote:
> > On 05/06/2010 11:07 PM, Michael Tokarev wrote:
> >> There was a bug recently fixed in vnc code.  Apparently
> >> there's something similar in the cirrus emulation as well.
> >> Here it triggers _always_ (including old versions of kvm)
> >> when running windows NT and hitting "test" button in its
> >> display resolution dialog.  Here's what gdb is to say:
> >>
> >> Program received signal SIGFPE, Arithmetic exception.
> >> [Switching to Thread 0xf76cab70 (LWP 580)]
> >> 0x080c5e45 in cirrus_do_copy (s=0x86134dc, dst=96, src=0, w=2, h=9)
> >> at hw/cirrus_vga.c:687
> >> 687sx = (src % ABS(s->cirrus_blt_srcpitch)) / depth;
> >> (gdb) p depth
> >> $1 = 2
> >> (gdb) p s->cirrus_blt_srcpitch
> >> $2 = 0
> >>
> >>
> >> This qemu-kvm-0.12.3 - actually a debian package of it,
> >> but there's no patches relevant to video applied.
> >>
> >> Anything can be done with it?
> >
> > Well, it's trivial to check for the condition, but how to handle it?
> >
> 
> That code is wrong.  It shouldn't be using the bitblt source pitch, but 
> the actual display pitch.  If the two are different, then the blt 
> doesn't actually affect a rectangular region, but instead a parallelogram.
> 

Reading some documention about the Cirrus card we are emulating, it
seems that the source pitch is ignored in video to video operations, so
I think you are right here.
The Windows NT driver probably relies on this behaviour and doesn't set
the source pitch properly before the bitblt.

> Further:
> 
> >
> > if (notify)
> > qemu_console_copy(s->vga.ds,
> >   sx, sy, dx, dy,
> >   s->cirrus_blt_width / depth,
> >   s->cirrus_blt_height);
> >
> > /* we don't have to notify the display that this portion has
> >changed since qemu_console_copy implies this */
> >
> > cirrus_invalidate_region(s, s->cirrus_blt_dstaddr,
> > s->cirrus_blt_dstpitch, s->cirrus_blt_width,
> > s->cirrus_blt_height);
> 
> 
> Shouldn't we avoid the invalidate if notify != 0, as the comment says?
> 
> 31c05501c says this breaks bitblt, but I can't see why this is true.  
> The copy should update the display.  This is probably due to a 
> miscalculation of the affected region, and now we have two invalidates 
> instead of one, reducing performance.
> 

I agree with you: qemu_console_copy does imply that the copied portion
of the screen changed, so there is no reason to invalidate it again if
qemu_console_copy is called.

[Qemu-devel] Re: Another SIGFPE in display code, now in cirrus

[Avi Kivity]

On 05/12/2010 03:20 PM, Stefano Stabellini wrote:

On Mon, 10 May 2010, Avi Kivity wrote:
   

On 05/10/2010 10:41 AM, Avi Kivity wrote:
 

On 05/06/2010 11:07 PM, Michael Tokarev wrote:
   

There was a bug recently fixed in vnc code.  Apparently
there's something similar in the cirrus emulation as well.
Here it triggers _always_ (including old versions of kvm)
when running windows NT and hitting "test" button in its
display resolution dialog.  Here's what gdb is to say:

Program received signal SIGFPE, Arithmetic exception.
[Switching to Thread 0xf76cab70 (LWP 580)]
0x080c5e45 in cirrus_do_copy (s=0x86134dc, dst=96, src=0, w=2, h=9)
 at hw/cirrus_vga.c:687
687sx = (src % ABS(s->cirrus_blt_srcpitch)) / depth;
(gdb) p depth
$1 = 2
(gdb) p s->cirrus_blt_srcpitch
$2 = 0


This qemu-kvm-0.12.3 - actually a debian package of it,
but there's no patches relevant to video applied.

Anything can be done with it?
 

Well, it's trivial to check for the condition, but how to handle it?

   

That code is wrong.  It shouldn't be using the bitblt source pitch, but
the actual display pitch.  If the two are different, then the blt
doesn't actually affect a rectangular region, but instead a parallelogram.

 

Reading some documention about the Cirrus card we are emulating, it
seems that the source pitch is ignored in video to video operations, so
I think you are right here.
   


From what I've read I don't think it's ignored.  Rather there are two 
separate pitches, one for bitblt and one for display.


I think the code should be something like

if bitblt destination intersects display memory:
if bitblt pitch == display pitch
   use console_copy
   else
   invalidate entire display


The Windows NT driver probably relies on this behaviour and doesn't set
the source pitch properly before the bitblt.
   


Note it's just during mode changes.  During normal operation I'm sure 
the pitches are equal.



31c05501c says this breaks bitblt, but I can't see why this is true.
The copy should update the display.  This is probably due to a
miscalculation of the affected region, and now we have two invalidates
instead of one, reducing performance.

 

I agree with you: qemu_console_copy does imply that the copied portion
of the screen changed, so there is no reason to invalidate it again if
qemu_console_copy is called.
   


Well, we can't just revert 31c05501c.  There's probably another bug 
involved.


--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.

Re: [Qemu-devel] [PATCH 0/2] Enable qemu block layer to not flush

[Jamie Lokier]

Stefan Hajnoczi wrote:
> On Wed, May 12, 2010 at 10:42 AM, Jamie Lokier  wrote:
> > Stefan Hajnoczi wrote:
> >> Why add a nop AIO operation instead of setting
> >> BlockDriverState->enable_write_cache to zero?  In that case no write
> >> cache would be reported to the guest (just like cache=writethrough).
> >
> > Hmm.  If the guest sees write cache absent, that prevents changing the
> > cache policy on the host later (from not flushing to flushing), which
> > you might want to do after an OS install has finished and booted up.
> 
> Right.  There are 3 cases from the guest perspective:
> 
> 1. Disable write cache or no write cache.  Flushing not needed.
> 2. Disable flushing but leave write cache enabled.
> 3. Enable write cache and use flushing.
> 
> When we don't report a write cache at all, the guest is always stuck at 1.
> 
> If you're going to do this for installs and other temporary workloads,
> then enabling the write cache again isn't an issue.  After installing
> successfully, restart the guest with a sane cache= mode.

That only works if you're happy to reboot the guest after the process
finishes.  I guess that is usually fine, but it is a restriction.

Is it possible via QMP to request that the guest is paused when it
next reboots, so that QMP operations to change the cache= mode can be
done (as it's not safe to change the guest-visible disk write cache
availability when it's running, and probably a request to do so should
be denied).

-- Jamie

[Qemu-devel] Re: [PATCHv2] Support for booting from virtio disks

[Kevin O'Connor]

On Wed, May 12, 2010 at 10:22:59AM +0300, Avi Kivity wrote:
> On 05/11/2010 03:31 PM, Gleb Natapov wrote:
> >Real BIOS can do that because it enumerates all bootable devices,
> >attach name for each one of them and then asks user to configure
> >boot order using names it attached to devices. In our case we
> >want to provide boot order on qemu command line before BIOS
> >enumerated devices, so qemu should be able to pass enough information
> >about boot device so that BIOS can uniquely identify it after it will
> >discover all bootable devices. bus/device pair can be such thing.
> 
> Having a BIOS menu is also useful, you don't have to drop to the
> management tool, instead you do everything from the console.

Having a "setup menu" is something real hardware could use as well.  I
don't think the setup menu should be in SeaBIOS - instead, SeaBIOS
could launch another program (stored in flash or qemu_fw) dedicated to
doing setup.

> >>Alternatively we can seed the order from the command line (-boot
> >>id1,id2,id3 where id* are some qdev property attached to disks, this
> >>is more flexible than the current syntax I think).
> >>
> >The problem is how to communicate this order to Seabios.
> 
> Topology (bus/device/lun).

USB is a pain here.  It's posible with BDF (Bus/Dev/Fn) and port
number (which accounts for hubs having ports as well).

-Kevin

[Qemu-devel] [PATCH 1/2] Use ram_bytes_remaining() where possible

[Pierre Riteau]

Signed-off-by: Pierre Riteau 
---
 arch_init.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch_init.c b/arch_init.c
index cfc03ea..cf6b7b0 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -235,7 +235,7 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int stage, 
void *opaque)
 
 qemu_put_be64(f, RAM_SAVE_FLAG_EOS);
 
-expected_time = ram_save_remaining() * TARGET_PAGE_SIZE / bwidth;
+expected_time = ram_bytes_remaining() / bwidth;
 
 return (stage == 2) && (expected_time <= migrate_max_downtime());
 }
-- 
1.7.1

[Qemu-devel] [PATCH 2/2] migration: Fix calculation of bytes_transferred

[Pierre Riteau]

When a page with all identical bytes is transferred, it is counted
as a full page (TARGET_PAGE_SIZE) although only one byte is actually
sent. Fix this by changing ram_save_block() to return the number of
bytes sent instead of a boolean value. This makes bandwidth
estimation, and consequently downtime estimation, more precise.

Signed-off-by: Pierre Riteau 
---
 arch_init.c |   21 -
 1 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/arch_init.c b/arch_init.c
index cf6b7b0..76317af 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -108,7 +108,7 @@ static int ram_save_block(QEMUFile *f)
 static ram_addr_t current_addr = 0;
 ram_addr_t saved_addr = current_addr;
 ram_addr_t addr = 0;
-int found = 0;
+int bytes_sent = 0;
 
 while (addr < last_ram_offset) {
 if (cpu_physical_memory_get_dirty(current_addr, MIGRATION_DIRTY_FLAG)) 
{
@@ -123,19 +123,20 @@ static int ram_save_block(QEMUFile *f)
 if (is_dup_page(p, *p)) {
 qemu_put_be64(f, current_addr | RAM_SAVE_FLAG_COMPRESS);
 qemu_put_byte(f, *p);
+bytes_sent = 1;
 } else {
 qemu_put_be64(f, current_addr | RAM_SAVE_FLAG_PAGE);
 qemu_put_buffer(f, p, TARGET_PAGE_SIZE);
+bytes_sent = TARGET_PAGE_SIZE;
 }
 
-found = 1;
 break;
 }
 addr += TARGET_PAGE_SIZE;
 current_addr = (saved_addr + addr) % last_ram_offset;
 }
 
-return found;
+return bytes_sent;
 }
 
 static uint64_t bytes_transferred;
@@ -206,11 +207,11 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int stage, 
void *opaque)
 bwidth = qemu_get_clock_ns(rt_clock);
 
 while (!qemu_file_rate_limit(f)) {
-int ret;
+int bytes_sent;
 
-ret = ram_save_block(f);
-bytes_transferred += ret * TARGET_PAGE_SIZE;
-if (ret == 0) { /* no more blocks */
+bytes_sent = ram_save_block(f);
+bytes_transferred += bytes_sent;
+if (bytes_sent == 0) { /* no more blocks */
 break;
 }
 }
@@ -226,9 +227,11 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int stage, 
void *opaque)
 
 /* try transferring iterative blocks of memory */
 if (stage == 3) {
+int bytes_sent;
+
 /* flush all remaining blocks regardless of rate limiting */
-while (ram_save_block(f) != 0) {
-bytes_transferred += TARGET_PAGE_SIZE;
+while ((bytes_sent = ram_save_block(f)) != 0) {
+bytes_transferred += bytes_sent;
 }
 cpu_physical_memory_set_dirty_tracking(0);
 }
-- 
1.7.1

[Qemu-devel] Qemu-KVM with 3x IDE HDD + CDROM not working

[Peter Lieven]

Hi Qemu/KVM Devel Team,

if I create a VM with more than 2 harddisks and a CDROM Image and want 
to boot from CDROM this is not working.

From my understanding at least 3 IDE Drives + 1 IDE CDROM should work.

cmdline:
/usr/bin/qemu-kvm-0.12.4  -net none  -drive 
file=/dev/sdb,if=ide,boot=on,cache=none,aio=native  -drive 
file=/dev/sdc,if=ide,boot=off,cache=none,aio=native  -drive 
file=/dev/sdd,if=ide,boot=off,cache=none,aio=native  -m 256 -cpu 
qemu64,model_id='Intel(R) Xeon(R) CPU   E5430  @ 2.66GHz' 
-monitor tcp:0:4001,server,nowait -vnc :1 -name 'ide-test'  -boot 
order=dc,menu=on  -cdrom 
/home/kvm/cdrom/root/KNOPPIX_V6.2.1CD-2010-01-31-DE.iso -k de  -pidfile 
/var/run/qemu/vm-153.pid  -mem-path /hugepages -mem-prealloc  -rtc 
base=utc,clock=vm -no-kvm-irqchip -usb -usbdevice tablet


SEABIOS shows error: Could not read from CDROM (code 0001)

Thanks,
Peter

[Qemu-devel] Re: Another SIGFPE in display code, now in cirrus

[Stefano Stabellini]

On Wed, 12 May 2010, Avi Kivity wrote:
> On 05/12/2010 03:20 PM, Stefano Stabellini wrote:
> > On Mon, 10 May 2010, Avi Kivity wrote:
> >
> >> On 05/10/2010 10:41 AM, Avi Kivity wrote:
> >>  
> >>> On 05/06/2010 11:07 PM, Michael Tokarev wrote:
> >>>
>  There was a bug recently fixed in vnc code.  Apparently
>  there's something similar in the cirrus emulation as well.
>  Here it triggers _always_ (including old versions of kvm)
>  when running windows NT and hitting "test" button in its
>  display resolution dialog.  Here's what gdb is to say:
> 
>  Program received signal SIGFPE, Arithmetic exception.
>  [Switching to Thread 0xf76cab70 (LWP 580)]
>  0x080c5e45 in cirrus_do_copy (s=0x86134dc, dst=96, src=0, w=2, h=9)
>   at hw/cirrus_vga.c:687
>  687sx = (src % ABS(s->cirrus_blt_srcpitch)) / depth;
>  (gdb) p depth
>  $1 = 2
>  (gdb) p s->cirrus_blt_srcpitch
>  $2 = 0
> 
> 
>  This qemu-kvm-0.12.3 - actually a debian package of it,
>  but there's no patches relevant to video applied.
> 
>  Anything can be done with it?
>   
> >>> Well, it's trivial to check for the condition, but how to handle it?
> >>>
> >>>
> >> That code is wrong.  It shouldn't be using the bitblt source pitch, but
> >> the actual display pitch.  If the two are different, then the blt
> >> doesn't actually affect a rectangular region, but instead a parallelogram.
> >>
> >>  
> > Reading some documention about the Cirrus card we are emulating, it
> > seems that the source pitch is ignored in video to video operations, so
> > I think you are right here.
> >
> 
>  From what I've read I don't think it's ignored.  Rather there are two 
> separate pitches, one for bitblt and one for display.
>
> > The Windows NT driver probably relies on this behaviour and doesn't set
> > the source pitch properly before the bitblt.
> >
> 
> Note it's just during mode changes.  During normal operation I'm sure 
> the pitches are equal.
> 

The source blt pitch as set by the driver is always equal to the display
pitch (apart from the case reported above).
However cirrus_blt_srcpitch is not always equal to the display pitch
because of CIRRUS_BLTMODE_BACKWARDS: cirrus_blt_srcpitch can also be
negative and equal to -display_pitch.

I suggest to start using the display pitch (with the proper sign)
instead of cirrus_blt_srcpitch in cirrus_do_copy at least when
cirrus_blt_srcpitch doesn't have a proper value.



> I think the code should be something like
> 
>  if bitblt destination intersects display memory:
>  if bitblt pitch == display pitch
> use console_copy
> else
> invalidate entire display
> 

I think the following should be enough:

if bitblt destination intersects display memory:
qemu_console_copy
else
invalidate region

why do we need if bitblt pitch == display pitch or to invalidate
everything?


> >> 31c05501c says this breaks bitblt, but I can't see why this is true.
> >> The copy should update the display.  This is probably due to a
> >> miscalculation of the affected region, and now we have two invalidates
> >> instead of one, reducing performance.
> >>
> >>  
> > I agree with you: qemu_console_copy does imply that the copied portion
> > of the screen changed, so there is no reason to invalidate it again if
> > qemu_console_copy is called.
> >
> 
> Well, we can't just revert 31c05501c.  There's probably another bug 
> involved.
> 

Sure, we have to fix the other one first :)

Re: [Qemu-devel] Re: Qemu-KVM Livate Migration 0.12.2 -> 0.12.3/4 broken?

[Peter Lieven]

Hi,

I can confirm that reverting this patch makes Live Migration from 0.12.2 
to 0.12.4

again possible.

Br,
Peter

Juan Quintela wrote:

Peter Lieven  wrote:
  

Hi Qemu/KVM Devel Team,

Live Migration from a 0.12.2 qemu-kvm to a 0.12.3 (and 0.12.4)
does not work: "load of migration failed"

Is there any way to find out, why exactly it fails? I have
a lot of VMs running on 0.12.2 and would like to migrate
them to 0.12.4

cmdline:
-net tap,vlan=6,script=no,downscript=no,ifname=tap7 -net
nic,vlan=6,model=e1000,macaddr=52:54:00:fe:00:88   -net
tap,vlan=651,script=no,downscript=no,ifname=tap8 -net
nic,vlan=651,model=e1000,macaddr=52:54:00:ff:00:69   -drive
file=/dev/mapper/iqn.2001-05.com.equallogic:0-8a0906-b6eca7604-6280020bc4b4bde8-quagga,if=ide,boot=on,cache=none,aio=native
-m 256 -monitor tcp:0:4090,server,nowait -vnc :90 -name 'Quagga' -boot
order=dc,menu=on  -k de  -incoming tcp:172.21.59.132:5090 -pidfile
/var/run/qemu/vm-148.pid  -rtc base=utc,clock=vm  -usb -usbdevice
tablet  -no-kvm-irqchip  -vga cirrus

Any hints would be appreciated!



Can you try reverting this patch?

commit 3fa017e24b0a0f0e68619a689b9b02fe486dae9e
Author: Marcelo Tosatti 
Date:   Thu Feb 11 18:19:44 2010 -0200

ide save/restore pio/atapi cmd transfer fields and io buffer

and told me if it works?

Later, Juan.



  



--
Mit freundlichen Grüßen/Kind Regards

Peter Lieven

..

  KAMP Netzwerkdienste GmbH
  Vestische Str. 89-91 | 46117 Oberhausen
  Tel: +49 (0) 208.89 402-50 | Fax: +49 (0) 208.89 402-40
  mailto:p...@kamp.de | http://www.kamp.de

  Geschäftsführer: Heiner Lante | Michael Lante
  Amtsgericht Duisburg | HRB Nr. 12154
  USt-Id-Nr.: DE 120607556

. 

qemu-kvm hangs if multipath device is queing (was: Re: [Qemu-devel] Qemu-KVM 0.12.3 and Multipath -> Assertion)

[Peter Lieven]

Hi Kevin,

here we go. I created a blocking multipath device (interrupted all 
paths). qemu-kvm hangs with 100% cpu.

also monitor is not responding.

If I restore at least one path, the vm is continueing.

BR,
Peter


^C
Program received signal SIGINT, Interrupt.
0x7fd8a6aaea94 in __lll_lock_wait () from /lib/libpthread.so.0
(gdb) bt
#0  0x7fd8a6aaea94 in __lll_lock_wait () from /lib/libpthread.so.0
#1  0x7fd8a6aaa190 in _L_lock_102 () from /lib/libpthread.so.0
#2  0x7fd8a6aa9a7e in pthread_mutex_lock () from /lib/libpthread.so.0
#3  0x0042e739 in kvm_mutex_lock () at 
/usr/src/qemu-kvm-0.12.4/qemu-kvm.c:2524
#4  0x0042e76e in qemu_mutex_lock_iothread () at 
/usr/src/qemu-kvm-0.12.4/qemu-kvm.c:2537
#5  0x0040c262 in main_loop_wait (timeout=1000) at 
/usr/src/qemu-kvm-0.12.4/vl.c:3995
#6  0x0042dcf1 in kvm_main_loop () at 
/usr/src/qemu-kvm-0.12.4/qemu-kvm.c:2126

#7  0x0040c98c in main_loop () at /usr/src/qemu-kvm-0.12.4/vl.c:4212
#8  0x0041054b in main (argc=30, argv=0x7fff266a77e8, 
envp=0x7fff266a78e0) at /usr/src/qemu-kvm-0.12.4/vl.c:6252

(gdb) bt full
#0  0x7fd8a6aaea94 in __lll_lock_wait () from /lib/libpthread.so.0
No symbol table info available.
#1  0x7fd8a6aaa190 in _L_lock_102 () from /lib/libpthread.so.0
No symbol table info available.
#2  0x7fd8a6aa9a7e in pthread_mutex_lock () from /lib/libpthread.so.0
No symbol table info available.
#3  0x0042e739 in kvm_mutex_lock () at 
/usr/src/qemu-kvm-0.12.4/qemu-kvm.c:2524

No locals.
#4  0x0042e76e in qemu_mutex_lock_iothread () at 
/usr/src/qemu-kvm-0.12.4/qemu-kvm.c:2537

No locals.
#5  0x0040c262 in main_loop_wait (timeout=1000) at 
/usr/src/qemu-kvm-0.12.4/vl.c:3995

   ioh = (IOHandlerRecord *) 0x0
   rfds = {fds_bits = {1048576, 0 }}
   wfds = {fds_bits = {0 }}
   xfds = {fds_bits = {0 }}
   ret = 1
   nfds = 21
   tv = {tv_sec = 0, tv_usec = 999761}
#6  0x0042dcf1 in kvm_main_loop () at 
/usr/src/qemu-kvm-0.12.4/qemu-kvm.c:2126

   fds = {18, 19}
   mask = {__val = {268443712, 0 }}
   sigfd = 20
#7  0x0040c98c in main_loop () at /usr/src/qemu-kvm-0.12.4/vl.c:4212
   r = 0
#8  0x0041054b in main (argc=30, argv=0x7fff266a77e8, 
envp=0x7fff266a78e0) at /usr/src/qemu-kvm-0.12.4/vl.c:6252

   gdbstub_dev = 0x0
   boot_devices_bitmap = 12
   i = 0
   snapshot = 0
   linux_boot = 0
   initrd_filename = 0x0
   kernel_filename = 0x0
   kernel_cmdline = 0x588fac ""
   boot_devices = "dc", '\0' 
   ds = (DisplayState *) 0x198bf00
   dcl = (DisplayChangeListener *) 0x0
   cyls = 0
   heads = 0
   secs = 0
   translation = 0
   hda_opts = (QemuOpts *) 0x0
   opts = (QemuOpts *) 0x1957390
   optind = 30
---Type  to continue, or q  to quit---
   r = 0x7fff266a8a23 "-usbdevice"
   optarg = 0x7fff266a8a2e "tablet"
   loadvm = 0x0
   machine = (QEMUMachine *) 0x861720
   cpu_model = 0x7fff266a8917 "qemu64,model_id=Intel(R) Xeon(R) CPU", ' 
' , "E5520  @ 2.27GHz"

   fds = {644511720, 32767}
   tb_size = 0
   pid_file = 0x7fff266a89bb "/var/run/qemu/vm-150.pid"
   incoming = 0x0
   fd = 0
   pwd = (struct passwd *) 0x0
   chroot_dir = 0x0
   run_as = 0x0
   env = (struct CPUX86State *) 0x0
   show_vnc_port = 0
   params = {0x58cc76 "order", 0x58cc7c "once", 0x58cc81 "menu", 0x0}

Kevin Wolf wrote:

Am 04.05.2010 15:42, schrieb Peter Lieven:
  

hi kevin,

you did it *g*

looks promising. applied this patched and was not able to reproduce yet :-)

secure way to reproduce was to shut down all multipath paths, then 
initiate i/o
in the vm (e.g. start an application). of course, everything hangs at 
this point.


after reenabling one path, vm crashed. now it seems to behave correctly and
just report an DMA timeout and continues normally afterwards.



Great, I'm going to submit it as a proper patch then.

Christoph, by now I'm pretty sure it's right, but can you have another
look if this is correct, anyway?

  

can you imagine of any way preventing the vm to consume 100% cpu in
that waiting state?
my current approach is to run all vms with nice 1, which helped to keep the
machine responsible if all vms (in my test case 64 on a box) have hanging
i/o at the same time.



I don't have anything particular in mind, but you could just attach gdb
and get another backtrace while it consumes 100% CPU (you'll need to use
"thread apply all bt" to catch everything). Then we should see where
it's hanging.

Kevin



  



--
Mit freundlichen Grüßen/Kind Regards

Peter Lieven

..

  KAMP Netzwerkdienste GmbH
  Vestische Str. 89-91 | 46117 Oberhausen
  Tel: +49 (0) 208.89 402-50 | Fax: +49 (0) 208.89 402-40
  mailto:p...@kamp.de | http://www.kamp.de

  Geschäftsführer: Heiner Lante | Michael Lante
  Amtsgericht Duisburg | HRB Nr. 12154
  USt-Id-Nr.: DE 120607556

..

Re: [Qemu-devel] [RFC PATCH 1/2] close all the block drivers before the qemu process exits

[Christoph Hellwig]

On Wed, May 12, 2010 at 07:46:52PM +0900, MORITA Kazutaka wrote:
> This patch calls the close handler of the block driver before the qemu
> process exits.
> 
> This is necessary because the sheepdog block driver releases the lock
> of VM images in the close handler.
> 
> Signed-off-by: MORITA Kazutaka 

Looks good in principle, except that bdrv_first is gone and has been
replaced with a real list in the meantime, so this won't even apply.

[Qemu-devel] [PATCH v2] doc: Update monitor info subcommands

[Stefan Hajnoczi]

The "info blockstats" documentation was copy-pasted as "info block"
instead of "info blockstats".  The documentation for "commands", "jit",
"numa", "qdm", and "roms" is missing.  This patch resolves these issues
in qemu-monitor.hx.

Signed-off-by: Stefan Hajnoczi 
---
v2:
 * "commands", "jit", and "numa"

 qemu-monitor.hx |   12 +++-
 1 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/qemu-monitor.hx b/qemu-monitor.hx
index a8f194c..f411bd1 100644
--- a/qemu-monitor.hx
+++ b/qemu-monitor.hx
@@ -54,13 +54,15 @@ Show various information about the system state.
 @table @option
 @item info version
 show the version of QEMU
+...@item info commands
+list QMP available commands
 @item info network
 show the various VLANs and the associated devices
 @item info chardev
 show the character devices
 @item info block
 show the block devices
-...@item info block
+...@item info blockstats
 show block device statistics
 @item info registers
 show the cpu registers
@@ -80,8 +82,12 @@ show virtual to physical memory mappings (i386 only)
 show the active virtual memory mappings (i386 only)
 @item info hpet
 show state of HPET (i386 only)
+...@item info jit
+show dynamic compiler info
 @item info kvm
 show KVM information
+...@item info numa
+show NUMA information
 @item info usb
 show USB devices plugged on the virtual USB hub
 @item info usbhost
@@ -114,6 +120,10 @@ show migration status
 show balloon information
 @item info qtree
 show device tree
+...@item info qdm
+show qdev device model list
+...@item info roms
+show roms
 @end table
 ETEXI
 
-- 
1.7.1

[Qemu-devel] Re: Another SIGFPE in display code, now in cirrus

[Avi Kivity]

On 05/12/2010 04:45 PM, Stefano Stabellini wrote:


   

Note it's just during mode changes.  During normal operation I'm sure
the pitches are equal.

 

The source blt pitch as set by the driver is always equal to the display
pitch (apart from the case reported above).
However cirrus_blt_srcpitch is not always equal to the display pitch
because of CIRRUS_BLTMODE_BACKWARDS: cirrus_blt_srcpitch can also be
negative and equal to -display_pitch.
   


Yes.


I suggest to start using the display pitch (with the proper sign)
instead of cirrus_blt_srcpitch in cirrus_do_copy at least when
cirrus_blt_srcpitch doesn't have a proper value.
   


Why switch from one bug to the other?

It's perfectly possible to take into account both values.  Of course 
when abs(blt_pitch) != display pitch we can't use console_copy, but so what.



I think the code should be something like

  if bitblt destination intersects display memory:
  if bitblt pitch == display pitch
 use console_copy
 else
 invalidate entire display

 

I think the following should be enough:

if bitblt destination intersects display memory:
 qemu_console_copy
else
 invalidate region

why do we need if bitblt pitch == display pitch or to invalidate
everything?
   


Because the region is not a rectangle anymore.  We could compute exactly 
what needs to be invalidated, but since it will never happen, there's no 
point in optimizing it.



31c05501c says this breaks bitblt, but I can't see why this is true.
The copy should update the display.  This is probably due to a
miscalculation of the affected region, and now we have two invalidates
instead of one, reducing performance.


 

I agree with you: qemu_console_copy does imply that the copied portion
of the screen changed, so there is no reason to invalidate it again if
qemu_console_copy is called.

   

Well, we can't just revert 31c05501c.  There's probably another bug
involved.

 

Sure, we have to fix the other one first :)
   


And find it.

--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.

[Qemu-devel] [PATCH 2/3 v2] dmg: use pread

[Christoph Hellwig]

Use pread instead of lseek + read in preparation of using the qemu
block API.  Note that dmg actually uses the implicit file offset
a lot in dmg_open, and we had to replace it with an offset variable.

Signed-off-by: Christoph Hellwig 

Index: qemu-kevin/block/dmg.c
===
--- qemu-kevin.orig/block/dmg.c 2010-05-12 16:19:59.586012160 +0200
+++ qemu-kevin/block/dmg.c  2010-05-12 16:23:07.510005522 +0200
@@ -58,18 +58,18 @@ static int dmg_probe(const uint8_t *buf,
 return 0;
 }
 
-static off_t read_off(int fd)
+static off_t read_off(int fd, int64_t offset)
 {
uint64_t buffer;
-   if(read(fd,&buffer,8)<8)
+   if (pread(fd, &buffer, 8, offset) < 8)
return 0;
return be64_to_cpu(buffer);
 }
 
-static off_t read_uint32(int fd)
+static off_t read_uint32(int fd, int64_t offset)
 {
uint32_t buffer;
-   if(read(fd,&buffer,4)<4)
+   if (pread(fd, &buffer, 4, offset) < 4)
return 0;
return be32_to_cpu(buffer);
 }
@@ -80,6 +80,7 @@ static int dmg_open(BlockDriverState *bs
 off_t info_begin,info_end,last_in_offset,last_out_offset;
 uint32_t count;
 uint32_t max_compressed_size=1,max_sectors_per_chunk=1,i;
+int64_t offset;
 
 s->fd = open(filename, O_RDONLY | O_BINARY);
 if (s->fd < 0)
@@ -89,38 +90,45 @@ static int dmg_open(BlockDriverState *bs
 s->offsets = s->lengths = s->sectors = s->sectorcounts = NULL;
 
 /* read offset of info blocks */
-if(lseek(s->fd,-0x1d8,SEEK_END)<0) {
+offset = lseek(s->fd, -0x1d8, SEEK_END);
+if (offset < 0) {
 goto fail;
 }
 
-info_begin=read_off(s->fd);
-if(info_begin==0)
-   goto fail;
-if(lseek(s->fd,info_begin,SEEK_SET)<0)
-   goto fail;
-if(read_uint32(s->fd)!=0x100)
-   goto fail;
-if((count = read_uint32(s->fd))==0)
-   goto fail;
-info_end = info_begin+count;
-if(lseek(s->fd,0xf8,SEEK_CUR)<0)
+info_begin = read_off(s->fd, offset);
+if (info_begin == 0) {
goto fail;
+}
+
+if (read_uint32(s->fd, info_begin) != 0x100) {
+goto fail;
+}
+
+count = read_uint32(s->fd, info_begin + 4);
+if (count == 0) {
+goto fail;
+}
+info_end = info_begin + count;
+
+offset = info_begin + 0x100;
 
 /* read offsets */
 last_in_offset = last_out_offset = 0;
-while(lseek(s->fd,0,SEEK_CUR)fd);
+   count = read_uint32(s->fd, offset);
if(count==0)
goto fail;
-   type = read_uint32(s->fd);
-   if(type!=0x6d697368 || count<244)
-   lseek(s->fd,count-4,SEEK_CUR);
-   else {
+offset += 4;
+
+   type = read_uint32(s->fd, offset);
+   if (type == 0x6d697368 && count >= 244) {
int new_size, chunk_count;
-   if(lseek(s->fd,200,SEEK_CUR)<0)
-   goto fail;
+
+offset += 4;
+offset += 200;
+
chunk_count = (count-204)/40;
new_size = sizeof(uint64_t) * (s->n_chunks + chunk_count);
s->types = qemu_realloc(s->types, new_size/2);
@@ -130,7 +138,8 @@ static int dmg_open(BlockDriverState *bs
s->sectorcounts = qemu_realloc(s->sectorcounts, new_size);
 
for(i=s->n_chunks;in_chunks+chunk_count;i++) {
-   s->types[i] = read_uint32(s->fd);
+   s->types[i] = read_uint32(s->fd, offset);
+   offset += 4;
if(s->types[i]!=0x8005 && s->types[i]!=1 && s->types[i]!=2) 
{
if(s->types[i]==0x) {
last_in_offset = s->offsets[i-1]+s->lengths[i-1];
@@ -138,15 +147,23 @@ static int dmg_open(BlockDriverState *bs
}
chunk_count--;
i--;
-   if(lseek(s->fd,36,SEEK_CUR)<0)
-   goto fail;
+   offset += 36;
continue;
}
-   read_uint32(s->fd);
-   s->sectors[i] = last_out_offset+read_off(s->fd);
-   s->sectorcounts[i] = read_off(s->fd);
-   s->offsets[i] = last_in_offset+read_off(s->fd);
-   s->lengths[i] = read_off(s->fd);
+   offset += 4;
+
+   s->sectors[i] = last_out_offset+read_off(s->fd, offset);
+   offset += 8;
+
+   s->sectorcounts[i] = read_off(s->fd, offset);
+   offset += 8;
+
+   s->offsets[i] = last_in_offset+read_off(s->fd, offset);
+   offset += 8;
+
+   s->lengths[i] = read_off(s->fd, offset);
+   offset += 8;
+
if(s->lengths[i]>max_compressed_size)
max_compressed_size = s->lengths[i];
if(s->sectorcounts[i]>max_sectors_per_chunk)
@@ -210,15 +227,12 @@ static inline int dmg_read_chunk(BDRVDMG
case 0x8005: { /* zlib compressed */
int i;
 
-   ret = lseek(

[Qemu-devel] Re: [RFC PATCH 1/2] close all the block drivers before the qemu process exits

[Avi Kivity]

On 05/12/2010 01:46 PM, MORITA Kazutaka wrote:

This patch calls the close handler of the block driver before the qemu
process exits.

This is necessary because the sheepdog block driver releases the lock
of VM images in the close handler.

   


How do you handle abnormal termination?

--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.

[Qemu-devel] [PATCH 3/3 v2] dmg: use qemu block API

[Christoph Hellwig]

Use bdrv_pwrite to access the backing device instead of pread, and
convert the driver to implementing the bdrv_open method which gives
it an already opened BlockDriverState for the underlying device.

Dmg actually does an lseek to a negative offset in the open routine,
which we replace with offset arithmetics after doing a bdrv_getlength.

Signed-off-by: Christoph Hellwig 


Index: qemu-kevin/block/dmg.c
===
--- qemu-kevin.orig/block/dmg.c 2010-05-12 16:23:07.510005522 +0200
+++ qemu-kevin/block/dmg.c  2010-05-12 16:28:08.370253535 +0200
@@ -28,8 +28,6 @@
 #include 
 
 typedef struct BDRVDMGState {
-int fd;
-
 /* each chunk contains a certain number of sectors,
  * offsets[i] is the offset in the .dmg file,
  * lengths[i] is the length of the compressed chunk,
@@ -58,23 +56,23 @@ static int dmg_probe(const uint8_t *buf,
 return 0;
 }
 
-static off_t read_off(int fd, int64_t offset)
+static off_t read_off(BlockDriverState *bs, int64_t offset)
 {
uint64_t buffer;
-   if (pread(fd, &buffer, 8, offset) < 8)
+   if (bdrv_pread(bs->file, offset, &buffer, 8) < 8)
return 0;
return be64_to_cpu(buffer);
 }
 
-static off_t read_uint32(int fd, int64_t offset)
+static off_t read_uint32(BlockDriverState *bs, int64_t offset)
 {
uint32_t buffer;
-   if (pread(fd, &buffer, 4, offset) < 4)
+   if (bdrv_pread(bs->file, offset, &buffer, 4) < 4)
return 0;
return be32_to_cpu(buffer);
 }
 
-static int dmg_open(BlockDriverState *bs, const char *filename, int flags)
+static int dmg_open(BlockDriverState *bs, int flags)
 {
 BDRVDMGState *s = bs->opaque;
 off_t info_begin,info_end,last_in_offset,last_out_offset;
@@ -82,29 +80,27 @@ static int dmg_open(BlockDriverState *bs
 uint32_t max_compressed_size=1,max_sectors_per_chunk=1,i;
 int64_t offset;
 
-s->fd = open(filename, O_RDONLY | O_BINARY);
-if (s->fd < 0)
-return -errno;
 bs->read_only = 1;
 s->n_chunks = 0;
 s->offsets = s->lengths = s->sectors = s->sectorcounts = NULL;
 
 /* read offset of info blocks */
-offset = lseek(s->fd, -0x1d8, SEEK_END);
+offset = bdrv_getlength(bs->file);
 if (offset < 0) {
 goto fail;
 }
+offset -= 0x1d8;
 
-info_begin = read_off(s->fd, offset);
+info_begin = read_off(bs, offset);
 if (info_begin == 0) {
goto fail;
 }
 
-if (read_uint32(s->fd, info_begin) != 0x100) {
+if (read_uint32(bs, info_begin) != 0x100) {
 goto fail;
 }
 
-count = read_uint32(s->fd, info_begin + 4);
+count = read_uint32(bs, info_begin + 4);
 if (count == 0) {
 goto fail;
 }
@@ -117,12 +113,12 @@ static int dmg_open(BlockDriverState *bs
 while (offset < info_end) {
 uint32_t type;
 
-   count = read_uint32(s->fd, offset);
+   count = read_uint32(bs, offset);
if(count==0)
goto fail;
 offset += 4;
 
-   type = read_uint32(s->fd, offset);
+   type = read_uint32(bs, offset);
if (type == 0x6d697368 && count >= 244) {
int new_size, chunk_count;
 
@@ -138,7 +134,7 @@ static int dmg_open(BlockDriverState *bs
s->sectorcounts = qemu_realloc(s->sectorcounts, new_size);
 
for(i=s->n_chunks;in_chunks+chunk_count;i++) {
-   s->types[i] = read_uint32(s->fd, offset);
+   s->types[i] = read_uint32(bs, offset);
offset += 4;
if(s->types[i]!=0x8005 && s->types[i]!=1 && s->types[i]!=2) 
{
if(s->types[i]==0x) {
@@ -152,16 +148,16 @@ static int dmg_open(BlockDriverState *bs
}
offset += 4;
 
-   s->sectors[i] = last_out_offset+read_off(s->fd, offset);
+   s->sectors[i] = last_out_offset+read_off(bs, offset);
offset += 8;
 
-   s->sectorcounts[i] = read_off(s->fd, offset);
+   s->sectorcounts[i] = read_off(bs, offset);
offset += 8;
 
-   s->offsets[i] = last_in_offset+read_off(s->fd, offset);
+   s->offsets[i] = last_in_offset+read_off(bs, offset);
offset += 8;
 
-   s->lengths[i] = read_off(s->fd, offset);
+   s->lengths[i] = read_off(bs, offset);
offset += 8;
 
if(s->lengths[i]>max_compressed_size)
@@ -183,7 +179,6 @@ static int dmg_open(BlockDriverState *bs
 
 return 0;
 fail:
-close(s->fd);
 return -1;
 }
 
@@ -213,8 +208,10 @@ static inline uint32_t search_chunk(BDRV
 return s->n_chunks; /* error */
 }
 
-static inline int dmg_read_chunk(BDRVDMGState *s,int sector_num)
+static inline int dmg_read_chunk(BlockDriverState *bs, int sector_num)
 {
+BDRVDMGState *s = bs->opaque;
+
 if(!is_sector_in_chunk(s,s->current_chunk,sector_num)) {
int ret;
uint32_t chunk = search_

Re: [Qemu-devel] [PATCH] doc: Update info blockstats, qdm, and roms

[Stefan Hajnoczi]

On Wed, May 12, 2010 at 12:16 PM, Markus Armbruster  wrote:
> A few more items are still missing: commands (QMP only, it's a no-op in
> the human monitor, I hate that), jit, numa.  Would you mind documenting
> as well?

Resent as v2 with commands, jit, and numa added.

Stefan

[Qemu-devel] Re: [PATCH 3/3] target-sparc: Inline some generation of carry for ADDX/SUBX.

[Richard Henderson]

> The new code doesn't update dc->cc_op, shouldn't that happen if the
> condition codes are changed? For example 'addx' in the sequence
> 'addcc; addxcc; addx;' should need the C flag from the second addxcc,
> not from first addcc.

Oops, yes, that needs updating too.  Will fix.


r~

Re: [Qemu-devel] [PATCH v2] doc: Update monitor info subcommands

[Markus Armbruster]

Stefan Hajnoczi  writes:

> The "info blockstats" documentation was copy-pasted as "info block"
> instead of "info blockstats".  The documentation for "commands", "jit",
> "numa", "qdm", and "roms" is missing.  This patch resolves these issues
> in qemu-monitor.hx.

Looks good, thanks!

Re: [Qemu-devel] [PATCH 2/3] target-sparc: Simplify ICC generation; fix ADDX carry generation.

[Richard Henderson]

On 05/11/2010 02:31 PM, Artyom Tarasenko wrote:
> Nack. It looks like you reverted carry generation to the previous
> (broken) behavior.

Oh?  I suppose I should go back and look at the logs, but the way
it's written there sure seems to match 5.1.5.1 of the sparcv9 manual:
You'll only get carry into the high bit on X - Y if X < Y.

In any case, if you meant to fix carry computation for subtraction,
you missed changing the 64-bit carry computation too.  It is still
written the same way before and after my patch, and matches both 
the expectation I have from the v9 manual and the post-patch code
along the 32-bit path.



r~

[Qemu-devel] Re: [PATCH] virtio-serial-bus: fix ports_map allocation on init

[Amit Shah]

On (Wed) May 12 2010 [17:50:02], Alon Levy wrote:
> Fix for too small allocation to ports_map
> 
>  Signed-off-by: Alon Levy 

ACK

Amit

Re: [Qemu-devel] [PATCH 2/3] target-sparc: Simplify ICC generation; fix ADDX carry generation.

[Richard Henderson]

On 05/11/2010 02:31 PM, Artyom Tarasenko wrote:
> Nack. It looks like you reverted carry generation to the previous
> (broken) behavior.

Perhaps you could point out the change I'm reverting?  I don't see
any change to the actual computation of the flags since 
f0f26a06d51b7e7764f8951cdbf67ac9ad507f6d, last year.


r~

[Qemu-devel] Re: [PATCH 2/2] Add flush=off parameter to -drive

[Alexander Graf]

Kevin Wolf wrote:
> Am 10.05.2010 23:51, schrieb Alexander Graf:
>   
>> Usually the guest can tell the host to flush data to disk. In some cases we
>> don't want to flush though, but try to keep everything in cache.
>>
>> So let's add a new parameter to -drive that allows us to set the flushing
>> behavior to "on" or "off", defaulting to enabling the guest to flush.
>>
>> Signed-off-by: Alexander Graf 
>> 
>
> What about another cache=... value instead of adding more options? I'm
> quite sure you'll only ever need this with writeback caching. So we
> could have cache=none|writethrough|writeback|wb-noflush or something
> like that.
>
>   

Yes, cache=volatile seems reasonable. Or cache=unsafe.

>> ---
>>  block/raw-posix.c |   13 +
>> 
>
> This is obviously wrong. If you want to introduce new behaviour to the
> block layer, you must do it consistently and not just for one block
> driver. So these changes should be made to the generic functions in
> block.c instead.
>   

How so? The callback functions are called using bdrv->drv->xxx. If I
modify that pointer, I end up affecting all other virtual disks as well.

Alex

Re: [Qemu-devel] [PATCH 2/3] target-sparc: Simplify ICC generation; fix ADDX carry generation.

[Artyom Tarasenko]

2010/5/12 Richard Henderson :
> On 05/11/2010 02:31 PM, Artyom Tarasenko wrote:
>> Nack. It looks like you reverted carry generation to the previous
>> (broken) behavior.
>
> Oh?  I suppose I should go back and look at the logs, but the way
> it's written there sure seems to match 5.1.5.1 of the sparcv9 manual:
> You'll only get carry into the high bit on X - Y if X < Y.
>
> In any case, if you meant to fix carry computation for subtraction,
> you missed changing the 64-bit carry computation too.

May very well be the case. I cared only about sparcv8. Was sort of
expecting that someone would stop me telling I broke v9...

> It is still
> written the same way before and after my patch, and matches both
> the expectation I have from the v9 manual and the post-patch code
> along the 32-bit path.

Probably v9 differs from v8?

> Perhaps you could point out the change I'm reverting?  I don't
> see any change to the actual computation of the flags since
> f0f26a06d51b7e7764f8951cdbf67ac9ad507f6d, last year.

It is last year, but
 3e6ba503400c34cbe0f9ad6e289921688bf303a3


-- 
Regards,
Artyom Tarasenko

solaris/sparc under qemu blog: http://tyom.blogspot.com/

[Qemu-devel] Re: [PATCH v5 4/5] Inter-VM shared memory PCI device

[Cam Macdonell]

On Tue, May 11, 2010 at 12:13 PM, Avi Kivity  wrote:
> On 05/11/2010 08:05 PM, Anthony Liguori wrote:
>>
>> On 05/11/2010 11:39 AM, Cam Macdonell wrote:
>>>
>>> Most of the people I hear from who are using my patch are using a peer
>>> model to share data between applications (simulations, JVMs, etc).
>>> But guest-to-host applications work as well of course.
>>>
>>> I think "transparent migration" can be achieved by making the
>>> connected/disconnected state transparent to the application.
>>>
>>> When using the shared memory server, the server has to be setup anyway
>>> on the new host and copying the memory region could be part of that as
>>> well if the application needs the contents preserved.  I don't think
>>> it has to be handled by the savevm/loadvm operations.  There's little
>>> difference between naming one VM the master or letting the shared
>>> memory server act like a master.
>>
>> Except that to make it work with the shared memory server, you need the
>> server to participate in the live migration protocol which is something I'd
>> prefer to avoid at it introduces additional down time.
>
> We can tunnel its migration data through qemu.  Of course, gathering its
> dirty bitmap will be interesting.  DSM may be the way to go here (we can
> even live migrate qemu through DSM: share the guest address space and
> immediately start running on the destination node; the guest will fault its
> memory to the destination.  An advantage is that that the cpu load is
> immediately transferred.
>

Given the potential need to develop DSM and migrating multiple VMs
simultaneously as well as few details to decide on, can the patch
series (with other review tweaks fixed) be accepted without migration
support?  I'll continue to work on it of course, but I think the patch
is useful to users without migration at the moment.

Cam

[Qemu-devel] Re: [PATCH 2/2] Add flush=off parameter to -drive

[Kevin Wolf]

Am 12.05.2010 17:05, schrieb Alexander Graf:
> Kevin Wolf wrote:
>> Am 10.05.2010 23:51, schrieb Alexander Graf:
>>   
>>> Usually the guest can tell the host to flush data to disk. In some cases we
>>> don't want to flush though, but try to keep everything in cache.
>>>
>>> So let's add a new parameter to -drive that allows us to set the flushing
>>> behavior to "on" or "off", defaulting to enabling the guest to flush.
>>>
>>> Signed-off-by: Alexander Graf 
>>> 
>>
>> What about another cache=... value instead of adding more options? I'm
>> quite sure you'll only ever need this with writeback caching. So we
>> could have cache=none|writethrough|writeback|wb-noflush or something
>> like that.
>>
>>   
> 
> Yes, cache=volatile seems reasonable. Or cache=unsafe.
> 
>>> ---
>>>  block/raw-posix.c |   13 +
>>> 
>>
>> This is obviously wrong. If you want to introduce new behaviour to the
>> block layer, you must do it consistently and not just for one block
>> driver. So these changes should be made to the generic functions in
>> block.c instead.
>>   
> 
> How so? The callback functions are called using bdrv->drv->xxx. If I
> modify that pointer, I end up affecting all other virtual disks as well.

By doing the check in bdrv_flush/bdrv_aio_flush before this function
pointer is even called.

Kevin

[Qemu-devel] Re: [PATCH v5 4/5] Inter-VM shared memory PCI device

[Avi Kivity]

On 05/12/2010 06:32 PM, Cam Macdonell wrote:



We can tunnel its migration data through qemu.  Of course, gathering its
dirty bitmap will be interesting.  DSM may be the way to go here (we can
even live migrate qemu through DSM: share the guest address space and
immediately start running on the destination node; the guest will fault its
memory to the destination.  An advantage is that that the cpu load is
immediately transferred.

 

Given the potential need to develop DSM and migrating multiple VMs
simultaneously as well as few details to decide on, can the patch
series (with other review tweaks fixed) be accepted without migration
support?


Definitely.  I don't expect DSM to materialize tomorrow (or ever).

--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.

[Qemu-devel] Re: [PATCH v5 4/5] Inter-VM shared memory PCI device

[Avi Kivity]

On 05/10/2010 07:48 PM, Cam Macdonell wrote:

On Mon, May 10, 2010 at 10:40 AM, Avi Kivity  wrote:
   

On 05/10/2010 06:41 PM, Cam Macdonell wrote:
 
   

What would happen to any data written to the BAR before the the handshake
completed?  I think it would disappear.

 

But, the BAR isn't there until the handshake is completed.  Only after
receiving the shared memory fd does my device call pci_register_bar()
in the callback function.  So there may be a case with BAR2 (the
shared memory BAR) missing during initialization.  FWIW, I haven't
encountered this.

   

Well, that violates PCI.  You can't have a PCI device with no BAR, then have
a BAR appear.  It may work since the BAR is registered a lot faster than the
BIOS is able to peek at it, but it's a race nevertheless.
 

Agreed.  I'll get Anthony's idea up and running.  It seems that is the
way forward.
   


What, with the separate allocation and memcpy?  Or another one?

Why can't we complete initialization before exposing the card and BAR?  
Seems to be the simplest solution.


--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.

[Qemu-devel] Re: [PATCH 2/2] Add flush=off parameter to -drive

[Alexander Graf]

Am 12.05.2010 um 17:36 schrieb Kevin Wolf :


Am 12.05.2010 17:05, schrieb Alexander Graf:

Kevin Wolf wrote:

Am 10.05.2010 23:51, schrieb Alexander Graf:

Usually the guest can tell the host to flush data to disk. In  
some cases we

don't want to flush though, but try to keep everything in cache.

So let's add a new parameter to -drive that allows us to set the  
flushing
behavior to "on" or "off", defaulting to enabling the guest to  
flush.


Signed-off-by: Alexander Graf 



What about another cache=... value instead of adding more options?  
I'm

quite sure you'll only ever need this with writeback caching. So we
could have cache=none|writethrough|writeback|wb-noflush or something
like that.




Yes, cache=volatile seems reasonable. Or cache=unsafe.


---
block/raw-posix.c |   13 +



This is obviously wrong. If you want to introduce new behaviour to  
the

block layer, you must do it consistently and not just for one block
driver. So these changes should be made to the generic functions in
block.c instead.



How so? The callback functions are called using bdrv->drv->xxx. If I
modify that pointer, I end up affecting all other virtual disks as  
well.


By doing the check in bdrv_flush/bdrv_aio_flush before this function
pointer is even called.


Sorry yeah, realized that 2 minutes after writing the mail myself :).

I put together an updated patch, but need to test it properly first.

Alex

Re: [Qemu-devel] [PATCH 3/3 v2] dmg: use qemu block API

[Kevin Wolf]

Am 12.05.2010 16:31, schrieb Christoph Hellwig:
> Use bdrv_pwrite to access the backing device instead of pread, and
> convert the driver to implementing the bdrv_open method which gives
> it an already opened BlockDriverState for the underlying device.
> 
> Dmg actually does an lseek to a negative offset in the open routine,
> which we replace with offset arithmetics after doing a bdrv_getlength.
> 
> Signed-off-by: Christoph Hellwig 

Thanks, applied all to the block branch.

Kevin

[Qemu-devel] Re: Another SIGFPE in display code, now in cirrus

[Stefano Stabellini]

On Wed, 12 May 2010, Avi Kivity wrote:
> > I suggest to start using the display pitch (with the proper sign)
> > instead of cirrus_blt_srcpitch in cirrus_do_copy at least when
> > cirrus_blt_srcpitch doesn't have a proper value.
> >
> 
> Why switch from one bug to the other?
> 
> It's perfectly possible to take into account both values.  Of course 
> when abs(blt_pitch) != display pitch we can't use console_copy, but so what.
> 

I see: you want to support the case when abs(src_blt_pitch) != display_pitch,
while I though it is some sort of error.

Considering that src_blt_pitch can even be 0 (as in the bug report), we
would still need to calculate sx and sy using display_pitch instead, so
the only place in which it would make a difference is when src_blt_pitch
is passed as an argument to cirrus_rop.
I guess even a src blt pitch of 0 could be useful there, however in
practice I think the only rop function that was written with this case in
mind has:

dstpitch -= bltwidth;
srcpitch -= bltwidth;

if (dstpitch < 0 || srcpitch < 0) {
/* is 0 valid? srcpitch == 0 could be useful */
return;
}

at the beginning and the others probably just don't deal with the case
with possibly buggy consequences.
Also the documentation I have states:

3CEh index 26h W(R/W):  BLT Source Pitch  (5426 +)
bit 0-11  (5426-28) Number of bytes in a scanline at the source.
0-12  (5429 +)  do

if the source BLT is supposed to be the number of bytes in a scanline at
the source, then 0 is not a correct value for it.

[Qemu-devel] Re: [PATCH 1/6] MIPS: Initial support of bonito north bridge used by fulong mini pc

[Stefan Weil]

Am 12.05.2010 10:50, schrieb chen huacai:

Signed-off-by: Huacai Chen
---
  Makefile.target  |1 +
  default-configs/mips64el-softmmu.mak |1 +
  hw/bonito.c  |  950 ++
  hw/mips.h|3 +
  4 files changed, 955 insertions(+), 0 deletions(-)
  create mode 100644 hw/bonito.c

diff --git a/Makefile.target b/Makefile.target
index c092900..63d9f49 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -220,6 +220,7 @@ obj-mips-y += dma.o vga.o i8259.o
  obj-mips-y += g364fb.o jazz_led.o
  obj-mips-y += gt64xxx.o pckbd.o mc146818rtc.o
  obj-mips-y += piix4.o cirrus_vga.o
+obj-mips-$(CONFIG_FULONG) += bonito.o

  obj-microblaze-y = petalogix_s3adsp1800_mmu.o

diff --git a/default-configs/mips64el-softmmu.mak
b/default-configs/mips64el-softmmu.mak
index b9b8c71..970568c 100644
--- a/default-configs/mips64el-softmmu.mak
+++ b/default-configs/mips64el-softmmu.mak
@@ -26,3 +26,4 @@ CONFIG_DP8393X=y
  CONFIG_DS1225Y=y
  CONFIG_MIPSNET=y
  CONFIG_PFLASH_CFI01=y
+CONFIG_FULONG=y
diff --git a/hw/bonito.c b/hw/bonito.c
new file mode 100644
index 000..246c12a
--- /dev/null
+++ b/hw/bonito.c
@@ -0,0 +1,950 @@
+/*
+ * bonito north bridge support
+ *
+ * Copyright (c) 2008 yajin (ya...@vm-kernel.org)
+ * Copyright (c) 2010 Huacai Chen (zltjiang...@gmail.com)
+ *
+ * This code is licensed under the GNU GPL v2.
+ */
+
+/*
+ * fulong 2e mini pc has a bonito north bridge.
+ */
+
+/* what is the meaning of devfn in qemu and IDSEL in bonito northbridge?
+ *
+ * devfn   pci_slot<<3  + funno
+ * one pci bus can have 32 devices and each device can have 8 functions.
+ *
+ * In bonito north bridge, pci slot = IDSEL bit - 12.
+ * For example, PCI_IDSEL_VIA686B = 17,
+ * pci slot = 17-12=5
+ *
+ * so
+ * VT686B_FUN0's devfn = (5<<3)+0
+ * VT686B_FUN1's devfn = (5<<3)+1
+ *
+ * qemu also uses pci address for north bridge to access pci config register.
+ * bus_no   [23:16]
+ * dev_no   [15:11]
+ * fun_no   [10:8]
+ * reg_no   [7:2]
+ *
+ * so function bonito_sbridge_pciaddr for the translation from
+ * north bridge address to pci address.
+ */
+
+#include
+
+#include "hw.h"
+#include "pci.h"
+#include "pc.h"
+#include "mips.h"
+
+typedef target_phys_addr_t pci_addr_t;
+#include "pci_host.h"
+
+//#define DEBUG_BONITO
+
+#ifdef DEBUG_BONITO
+#define DPRINTF(fmt, ...) fprintf(stderr, "%s: " fmt, __FUNCTION__,
##__VA_ARGS__)
+#else
+#define DPRINTF(fmt, ...)
+#endif
+
+/* from linux soure code. include/asm-mips/mips-boards/bonito64.h*/
+#define BONITO_BOOT_BASE0x1fc0
+#define BONITO_BOOT_SIZE0x0010
+#define BONITO_BOOT_TOP (BONITO_BOOT_BASE+BONITO_BOOT_SIZE-1)
+#define BONITO_FLASH_BASE   0x1c00
+#define BONITO_FLASH_SIZE   0x0300
+#define BONITO_FLASH_TOP(BONITO_FLASH_BASE+BONITO_FLASH_SIZE-1)
+#define BONITO_SOCKET_BASE  0x1f80
+#define BONITO_SOCKET_SIZE  0x0040
+#define BONITO_SOCKET_TOP   (BONITO_SOCKET_BASE+BONITO_SOCKET_SIZE-1)
+#define BONITO_REG_BASE 0x1fe0
+#define BONITO_REG_SIZE 0x0004
+#define BONITO_REG_TOP  (BONITO_REG_BASE+BONITO_REG_SIZE-1)
+#define BONITO_DEV_BASE 0x1ff0
+#define BONITO_DEV_SIZE 0x0010
+#define BONITO_DEV_TOP  (BONITO_DEV_BASE+BONITO_DEV_SIZE-1)
+#define BONITO_PCILO_BASE   0x1000
+#define BONITO_PCILO_BASE_VA0xb000
+#define BONITO_PCILO_SIZE   0x0c00
+#define BONITO_PCILO_TOP(BONITO_PCILO_BASE+BONITO_PCILO_SIZE-1)
+#define BONITO_PCILO0_BASE  0x1000
+#define BONITO_PCILO1_BASE  0x1400
+#define BONITO_PCILO2_BASE  0x1800
+#define BONITO_PCIHI_BASE   0x2000
+#define BONITO_PCIHI_SIZE   0x2000
+#define BONITO_PCIHI_TOP(BONITO_PCIHI_BASE+BONITO_PCIHI_SIZE-1)
+#define BONITO_PCIIO_BASE   0x1fd0
+#define BONITO_PCIIO_BASE_VA0xbfd0
+#define BONITO_PCIIO_SIZE   0x0001
+#define BONITO_PCIIO_TOP(BONITO_PCIIO_BASE+BONITO_PCIIO_SIZE-1)
+#define BONITO_PCICFG_BASE  0x1fe8
+#define BONITO_PCICFG_SIZE  0x0008
+#define BONITO_PCICFG_TOP   (BONITO_PCICFG_BASE+BONITO_PCICFG_SIZE-1)
+
+
+#define BONITO_PCICONFIGBASE0x00
+#define BONITO_REGBASE  0x100
+
+#define BONITO_PCICONFIG_BASE   (BONITO_PCICONFIGBASE+BONITO_REG_BASE)
+#define BONITO_PCICONFIG_SIZE   (0x100)
+
+#define BONITO_INTERNAL_REG_BASE  (BONITO_REGBASE+BONITO_REG_BASE)
+#define BONITO_INTERNAL_REG_SIZE  (0x70)
+
+#define BONITO_SPCICONFIG_BASE  (BONITO_PCICFG_BASE)
+#define BONITO_SPCICONFIG_SIZE  (BONITO_PCICFG_SIZE)
+
+
+
+/* 1. Bonito h/w Configuration */
+/* Power on register */
+
+#define BONITO_BONPONCFG(0x00>>  2)  /* 0x100 */
+#define BONITO_BONGENCFG_OFFSET 0x4
+#define BONITO_BONGENCFG(BONITO_BONGENCFG_OFFSET>>2)   /*0x104 */
+
+/* 2. IO&  IDE configuration */
+#define BONITO_IODEVCFG (0x08>>  2)  /* 0x108 */
+
+/* 3. IO&  IDE confi

Re: [Qemu-devel] Re: Webcam solution for QEMU

[David Ahern]

On 05/09/2010 08:28 PM, Natalia Portillo wrote:
> Hello Arnon,
> Hola Albert,
> 
> Wouldn't be easier to implement a custom video capture device?
> You can always emulate a simple one, like (to say) OV511 webcam, and feed 
> that emulated device with video taken from any V4L2/DirectShow/BDA supported 
> device (real host webcam).
> 
> I think this way, timing issues will not arise, and will support indeed any 
> webcam or video capture device (tuners) past, present, and future.
> 
> Of course not to say video will come with a little lag to the guest but that 
> lag will be a lot less than the timing lag connecting host<->guest devices in 
> a more directly way.
> 
> That's just my 2 euro cent.


Earlier this year I got a streaming audio device to work as a
passthrough device. The biggest pain was needing to modify the guest
driver to increase its number of outstanding URBs. That was required due
to the way isochronous requests are handled within the USB controller.

Based on that experience I thought an emulated device in qemu would help
with the low level timing issues. In addition it would provide an option
for VDI wherein the VM on a remote server is running a video/audio
streaming ap that requires webcam interaction (e.g., video phone or
integrated conferencing software).

Are you planning to create such a device for qemu?

David

[Qemu-devel] Re: Another SIGFPE in display code, now in cirrus

[Avi Kivity]

On 05/12/2010 06:57 PM, Stefano Stabellini wrote:

On Wed, 12 May 2010, Avi Kivity wrote:
   

I suggest to start using the display pitch (with the proper sign)
instead of cirrus_blt_srcpitch in cirrus_do_copy at least when
cirrus_blt_srcpitch doesn't have a proper value.

   

Why switch from one bug to the other?

It's perfectly possible to take into account both values.  Of course
when abs(blt_pitch) != display pitch we can't use console_copy, but so what.

 

I see: you want to support the case when abs(src_blt_pitch) != display_pitch,
while I though it is some sort of error.
   


When blting withinh the screen, it is an error from the point of view of 
writing a sane driver.  My guess is that it's a bug in the NT driver.


It's not an error from the point of view of the hardware, or when blting 
offscreen bitmaps (which can have different geomeries than the display).



Considering that src_blt_pitch can even be 0 (as in the bug report), we
would still need to calculate sx and sy using display_pitch instead, so
the only place in which it would make a difference is when src_blt_pitch
is passed as an argument to cirrus_rop.
   


cirrus_rop() and its arguments don't need to change.  They're correctly 
using the blt pitch.


My point is: x[xy] and d[xy] are only valid if both source and 
destination overlap the display, and if both src_pitch and dst_pitch are 
absequal to the display pitch.  When they aren't valid, there's no point 
in calculating them or using them in anything.  The raster operation is 
still valid though.




I guess even a src blt pitch of 0 could be useful there, however in
practice I think the only rop function that was written with this case in
mind has:

dstpitch -= bltwidth;
srcpitch -= bltwidth;

if (dstpitch<  0 || srcpitch<  0) {
 /* is 0 valid? srcpitch == 0 could be useful */
 return;
}

at the beginning and the others probably just don't deal with the case
with possibly buggy consequences.
Also the documentation I have states:

3CEh index 26h W(R/W):  BLT Source Pitch  (5426 +)
bit 0-11  (5426-28) Number of bytes in a scanline at the source.
 0-12  (5429 +)  do

if the source BLT is supposed to be the number of bytes in a scanline at
the source, then 0 is not a correct value for it.
   


It's useful if you have a one-line horizontal pattern you want to 
propagate all over.


--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.

[Qemu-devel] Re: [PATCH v5 4/5] Inter-VM shared memory PCI device

[Cam Macdonell]

On Wed, May 12, 2010 at 9:49 AM, Avi Kivity  wrote:
> On 05/10/2010 07:48 PM, Cam Macdonell wrote:
>>
>> On Mon, May 10, 2010 at 10:40 AM, Avi Kivity  wrote:
>>
>>>
>>> On 05/10/2010 06:41 PM, Cam Macdonell wrote:
>>>


>
> What would happen to any data written to the BAR before the the
> handshake
> completed?  I think it would disappear.
>
>

 But, the BAR isn't there until the handshake is completed.  Only after
 receiving the shared memory fd does my device call pci_register_bar()
 in the callback function.  So there may be a case with BAR2 (the
 shared memory BAR) missing during initialization.  FWIW, I haven't
 encountered this.


>>>
>>> Well, that violates PCI.  You can't have a PCI device with no BAR, then
>>> have
>>> a BAR appear.  It may work since the BAR is registered a lot faster than
>>> the
>>> BIOS is able to peek at it, but it's a race nevertheless.
>>>
>>
>> Agreed.  I'll get Anthony's idea up and running.  It seems that is the
>> way forward.
>>
>
> What, with the separate allocation and memcpy?  Or another one?

Mapping in the memory when it is received from the server.

>
> Why can't we complete initialization before exposing the card and BAR?
>  Seems to be the simplest solution.

Looking at it more closely, you're right, the fds for shared
memory/eventfds are received in a fraction of a second, so that's why
I haven't seen any problems since the memory is mapped before the BIOS
detects and configures the device.

We can't block on a qemu char device (in anyway I can see) so we have
to handle mapping the memory BAR in the callback function.  But, we
can make the semantics that the VM ID is not set until the memory is
mapped.  So if the VM ID is -1, then the memory has not been mapped
yet, reads/writes work but don't do anything useful.  So the user can
detect the mapping of the memory
and it does not invalidate PCI since the BAR is always present, but
just not mapped to the shared memory.

Cam

[Qemu-devel] Re: [PATCH v5 4/5] Inter-VM shared memory PCI device

[Avi Kivity]

On 05/12/2010 07:14 PM, Cam Macdonell wrote:



Why can't we complete initialization before exposing the card and BAR?
  Seems to be the simplest solution.
 

Looking at it more closely, you're right, the fds for shared
memory/eventfds are received in a fraction of a second, so that's why
I haven't seen any problems since the memory is mapped before the BIOS
detects and configures the device.

We can't block on a qemu char device (in anyway I can see) so we have
to handle mapping the memory BAR in the callback function.  But, we
can make the semantics that the VM ID is not set until the memory is
mapped.  So if the VM ID is -1, then the memory has not been mapped
yet, reads/writes work but don't do anything useful.  So the user can
detect the mapping of the memory
and it does not invalidate PCI since the BAR is always present, but
just not mapped to the shared memory.
   


I don't like this very much.  We expose an internal qemu implementation 
detail, the lack of ability to complete negotiation during init, and 
make the device more error prone to use.


However, it does make some sense if we regard the device as an HBA 
accessing an external memory, so it's not unreasonable.  But please be 
sure to document this.


--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.

Re: [Qemu-devel] [PATCH 1/2] QMP: Introduce commands doc

[Markus Armbruster]

Luiz Capitulino  writes:

> One of the most important missing feature in QMP today is its
> supported commands documentation.
>
> The plan is to make it part of self-description support, however
> self-description is a big task we have been postponing for a
> long time now and still don't know when it's going to be done.
>
> In order not to compromise QMP adoption and make users' life easier,
> this commit adds a simple text documentation which fully describes
> all QMP supported commands.
>
> This is not ideal for a number of reasons (harder to maintain,
> text-only, etc) but does improve the current situation.
>
> Signed-off-by: Luiz Capitulino 
> ---
>  QMP/README   |5 +-
>  QMP/qmp-commands.txt | 1033 
> ++
>  2 files changed, 1036 insertions(+), 2 deletions(-)
>  create mode 100644 QMP/qmp-commands.txt
>
> diff --git a/QMP/README b/QMP/README
> index 9334c25..35a80c7 100644
> --- a/QMP/README
> +++ b/QMP/README
> @@ -15,8 +15,9 @@ QMP is JSON[1] based and has the following features:
>  
>  For more information, please, refer to the following files:
>  
> -o qmp-spec.txtQEMU Monitor Protocol current specification
> -o qmp-events.txt  List of available asynchronous events
> +o qmp-spec.txt  QEMU Monitor Protocol current specification
> +o qmp-commands.txt  QMP supported commands
> +o qmp-events.txtList of available asynchronous events
>  
>  There are also two simple Python scripts available:
>  
> diff --git a/QMP/qmp-commands.txt b/QMP/qmp-commands.txt
> new file mode 100644
> index 000..b1b0e02
> --- /dev/null
> +++ b/QMP/qmp-commands.txt
> @@ -0,0 +1,1033 @@

I reviewed this part before, and it looks good now.

[...]
> +2. Query Commands
> +=
> +
> +query-balloon
> +-
> +
> +Show balloon information.
> +
> +Make an asynchronous request for balloon info. When the request completes a
> +json-object will be returned containing the following data:
> +
> +- "actual": current balloon value in bytes (json-int)
> +- "mem_swapped_in": Amount of memory swapped in bytes (json-int, optional)
> +- "mem_swapped_out": Amount of memory swapped out in bytes (json-int, 
> optional)
> +- "major_page_faults": Number of major faults (json-int, optional)
> +- "minor_page_faults": Number of minor faults (json-int, optional)
> +- "free_mem":Total amount of free and unused memory in bytes 
> (json-int,optional)

Nitpick: space after comma, please.

> +- "total_mem": Total amount of available memory in bytes (json-int, optional)
> +
> +Example:
> +
> +{
> +   "return":{
> +  "actual":1073741824,
> +  "mem_swapped_in":0,
> +  "mem_swapped_out":0,
> +  "major_page_faults":142,
> +  "minor_page_faults":239245,
> +  "free_mem":1014185984,
> +  "total_mem":1044668416
> +   }
> +}
> +
> +query-block
> +---
> +
> +Show the block devices.
> +
> +Each block device information is stored in a json-object and the returned 
> value
> +is a json-array of all devices.
> +
> +Each json-object contain the following:
> +
> +- "device": device name (json-string)
> +- "type": device type (json-string)

Possible values?  "hd", "cdrom", "floppy".  Code also has "unknown", but
when it uses that, it's badly broken.

> +- "removable": true if the device is removable, false otherwise (json-bool)
> +- "locked": true if the device is locked, false otherwise (json-bool)
> +- "inserted": only present if the device is inserted, it is a json-object
> +   containing the following:
> + - "file": device file name (json-string)
> + - "ro": true if read-only, false otherwise (json-bool)
> + - "drv": driver format name (json-string)

Possible values?

> + - "backing_file": backing file name if one is used (json-string)

Suggest

- "backing_file": backing file name (json-string, optional)

for consistency with optional members elsewhere.

> + - "encrypted": true if encrypted, false otherwise (json-bool)
> +
> +Example:
> +
> +{
> +   "return":[
> +  {
> + "device":"ide0-hd0",
> + "type":"hd",
> + "removable":false,
> + "locked":false,
> + "inserted":{
> +"file":"/tmp/foobar",
> +"ro":false,
> +"drv":"qcow2"

"encrypted" is missing here.

> + }
> +  },
> +  {
> + "device":"floppy0",
> + "type":"floppy",
> + "removable":true,
> + "locked":false
> +  }
> +   ]
> +}
> +
> +query-blockstats
> +
> +
> +Show block device statistics.
> +
> +Each device statistic information is stored in a json-object and the returned
> +value is a json-array of all devices.
> +
> +Each json-object contain the following:
> +
> +- "device": device name (json-string)
> +- "stats": A json-object with the statistics information, it contains:
> +- "rd_bytes": bytes read (json-int)
> +- "wr_bytes": bytes written (json-int)
> +- "rd_operations": read

[Qemu-devel] Re: Another SIGFPE in display code, now in cirrus

[Stefano Stabellini]

On Wed, 12 May 2010, Avi Kivity wrote:
> > I guess even a src blt pitch of 0 could be useful there, however in
> > practice I think the only rop function that was written with this case in
> > mind has:
> >
> > dstpitch -= bltwidth;
> > srcpitch -= bltwidth;
> >
> > if (dstpitch<  0 || srcpitch<  0) {
> >  /* is 0 valid? srcpitch == 0 could be useful */
> >  return;
> > }
> >
> > at the beginning and the others probably just don't deal with the case
> > with possibly buggy consequences.
> > Also the documentation I have states:
> >
> > 3CEh index 26h W(R/W):  BLT Source Pitch  (5426 
> > +)
> > bit 0-11  (5426-28) Number of bytes in a scanline at the source.
> >  0-12  (5429 +)  do
> >
> > if the source BLT is supposed to be the number of bytes in a scanline at
> > the source, then 0 is not a correct value for it.
> >
> 
> It's useful if you have a one-line horizontal pattern you want to 
> propagate all over.
> 
 
It might be useful all right, but it is not entirely clear what the
hardware should do in this situation from the documentation we have, and
certainly the current state of the cirrus emulation code doesn't help.

Without any clear indication of what a Cirrus Logic graphic card would
have done here, I would choose the safest answer that is disregard the
"delicate" case (if it doesn't break Windows NT).

However I don't mind if we try to handle this case too, provided
that we handle it well, without SIGFPEs that is :)

[Qemu-devel] Re: [PATCH v2 0/2] Drop pci_add and pci_del from QMP

[Luiz Capitulino]

On Wed, 12 May 2010 10:52:59 +0200
Markus Armbruster  wrote:

> See PATCH 1/1 for rationale.
> 
> v2: Cover pci_del, better commit message, rebased (no conflicts)
> 
> Markus Armbruster (2):
>   Revert "PCI: Convert pci_device_hot_add() to QObject"
>   Revert "monitor: Convert do_pci_device_hot_remove() to QObject"

 Looks good to me.

> 
>  hw/pci-hotplug.c |   51 +++
>  qemu-monitor.hx  |6 ++
>  sysemu.h |6 ++
>  3 files changed, 11 insertions(+), 52 deletions(-)
> 

[Qemu-devel] Re: Another SIGFPE in display code, now in cirrus

[Avi Kivity]

On 05/12/2010 07:55 PM, Stefano Stabellini wrote:



3CEh index 26h W(R/W):  BLT Source Pitch  (5426 +)
bit 0-11  (5426-28) Number of bytes in a scanline at the source.
  0-12  (5429 +)  do

if the source BLT is supposed to be the number of bytes in a scanline at
the source, then 0 is not a correct value for it.

   

It's useful if you have a one-line horizontal pattern you want to
propagate all over.

 


It might be useful all right, but it is not entirely clear what the
hardware should do in this situation from the documentation we have, and
certainly the current state of the cirrus emulation code doesn't help.

Without any clear indication of what a Cirrus Logic graphic card would
have done here, I would choose the safest answer that is disregard the
"delicate" case (if it doesn't break Windows NT).
   


My guess is that the src or dst address simply doesn't increment.  I 
think it's also fine to ignore the operation completely.



However I don't mind if we try to handle this case too, provided
that we handle it well, without SIGFPEs that is :)
   



--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.

Re: [Qemu-devel] Re: Another SIGFPE in display code, now in cirrus

[Jamie Lokier]

Stefano Stabellini wrote:
> On Wed, 12 May 2010, Avi Kivity wrote:
> > It's useful if you have a one-line horizontal pattern you want to 
> > propagate all over.
>  
> It might be useful all right, but it is not entirely clear what the
> hardware should do in this situation from the documentation we have, and
> certainly the current state of the cirrus emulation code doesn't help.

It's quite a reasonable thing for hardware to do, even if not documented.
It would be surprising if the hardware didn't copy the one-line pattern.

-- Jamie

Re: [Qemu-devel] [PATCH 2/3] target-sparc: Simplify ICC generation; fix ADDX carry generation.

[Richard Henderson]

On 05/12/2010 08:18 AM, Artyom Tarasenko wrote:
> It is last year, but
>  3e6ba503400c34cbe0f9ad6e289921688bf303a3

> The page 108 of the SPARC Version 8 Architecture Manual describes
> that addcc and addxcc shall compute carry flag the same way.
> The page 110 claims the same about subcc and subxcc instructions.
> This patch fixes carry computation in corner cases and removes redundant 
> cod
> The most visible effect of the patch is enabling Solaris boot when using 
> OBP

I'll contradict you right there by asserting that the manual
says no such thing about computing the carry flag "the same way".

What it says is:

p29:
# Carry is set on addition if there is a carry out of bit 31.
# Carry is set on subtraction if there is borrow into bit 31.

p108:
# ADDX and ADDXcc also add the PSR's carry (c) bit; that is
# they compute "r[rs1] + r[rs2] + c"...

How are the two computations "the same"?  First, it says that
carry is set if there is carry out.  Second, it says that there
is the extra addition of the (previous) C bit.  If there is an
extra addition, there must be an extra chance for carry, and
thus the carry flag *cannot* be computed in the same way.

Looking closely at the generation of the addx carry (with the
attached test program), I see that the original definition of
the ADDX carry, as still seen in the _xcc versions, does not
generate correct values, and your definition of the carry does.
However, that does not mean that we need to use your version
of the carry for plain ADD, only for ADDX.

I'll send a revised patch sequence shortly.


r~
#include 


static inline int test_rolw(unsigned short *s)
{
  int i, start, end;
  asm volatile("rdtsc\n\t"
   "movl %%eax, %1\n\t"
   "movzwl %3,%2\n\t"
   "rolw $8, %w2\n\t"
   "addl $1,%2\n\t"
   "rdtsc"
   : "=&a"(end), "=r"(start), "=r"(i) : "m"(*s) : "edx");
  return end - start;
}

static inline int test_bswap(unsigned short *s)
{
  int i, start, end;
  asm volatile("rdtsc\n\t"
   "movl %%eax, %1\n\t"
   "movzwl %3,%2\n\t"
   "bswap %2\n\t"
   "shl $16,%2\n\t"
   "addl $1,%2\n\t"
   "rdtsc"
   : "=&a"(end), "=r"(start), "=r"(i) : "m"(*s) : "edx");
  return end - start;
}

#define N 10
int main()
{
  unsigned t_r[N], t_b[N];
  unsigned short s = 0;
  int i;

  for (i = 0; i < N; ++i)
t_r[i] = test_rolw(&s);

  for (i = 0; i < N; ++i)
t_b[i] = test_bswap(&s);

  printf("rolw\t");
  for (i = 0; i < N; ++i)
printf("%5u", t_r[i]);
  printf("\nbswap\t");
  for (i = 0; i < N; ++i)
printf("%5u", t_b[i]);
  printf("\n");
}

Re: [Qemu-devel] [PATCH] [S390] Remove warning in tcg stub (tcg_out_reloc)

[Aurelien Jarno]

On Tue, May 11, 2010 at 09:50:34PM +0200, Alexander Graf wrote:
>
> Am 11.05.2010 um 19:26 schrieb Richard Henderson :
>
>> On 05/11/2010 09:47 AM, Stefan Weil wrote:
>>> Won't you get another warning about unreachable code
>>> because tcg_abort never returns?
>>
>> We don't enable that warning.
>>
>>> What about condition compilation for tcg_out_reloc
>>> (don't compile it for hosts which don't need it)?
>>
>> All hosts should need it.  S390 doesn't only because
>> it's all stubbed out.
>>
>> Frankly, it shouldn't take much effort to get a working
>> TCG for s390x...
>
> Yeah, I have submitted a patch months ago, but Aurelien didn't get  
> around to review it yet :(.
>

This is indeed the best solution. It's still on my TODO list, just that
I have limited time and it's always easier to choose to ignore one big
patch and got complains from a single person, than ignoring a lot of
small patches and getting a lot of complains...

If only people were reviewing other people patches a bit more...

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net

[Qemu-devel] [PATCH 1/3] Revert "Monitor: Return before exiting with 'quit'"

[Luiz Capitulino]

This reverts commit 0e8d2b5575938b8876a3c4bb66ee13c5d306fb6d.

Next commits will do the same thing in a better way.

Signed-off-by: Luiz Capitulino 
---
 monitor.c |3 +--
 sysemu.h  |2 --
 vl.c  |   18 --
 3 files changed, 1 insertions(+), 22 deletions(-)

diff --git a/monitor.c b/monitor.c
index 4c95d7b..e984122 100644
--- a/monitor.c
+++ b/monitor.c
@@ -942,8 +942,7 @@ static void do_info_cpu_stats(Monitor *mon)
  */
 static int do_quit(Monitor *mon, const QDict *qdict, QObject **ret_data)
 {
-monitor_suspend(mon);
-qemu_system_exit_request();
+exit(0);
 return 0;
 }
 
diff --git a/sysemu.h b/sysemu.h
index 47975b5..fcfccdf 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -45,11 +45,9 @@ void cpu_disable_ticks(void);
 void qemu_system_reset_request(void);
 void qemu_system_shutdown_request(void);
 void qemu_system_powerdown_request(void);
-void qemu_system_exit_request(void);
 int qemu_shutdown_requested(void);
 int qemu_reset_requested(void);
 int qemu_powerdown_requested(void);
-int qemu_exit_requested(void);
 extern qemu_irq qemu_system_powerdown;
 void qemu_system_reset(void);
 
diff --git a/vl.c b/vl.c
index 85bcc84..791564a 100644
--- a/vl.c
+++ b/vl.c
@@ -1708,7 +1708,6 @@ static int shutdown_requested;
 static int powerdown_requested;
 int debug_requested;
 int vmstop_requested;
-static int exit_requested;
 
 int qemu_shutdown_requested(void)
 {
@@ -1731,12 +1730,6 @@ int qemu_powerdown_requested(void)
 return r;
 }
 
-int qemu_exit_requested(void)
-{
-/* just return it, we'll exit() anyway */
-return exit_requested;
-}
-
 static int qemu_debug_requested(void)
 {
 int r = debug_requested;
@@ -1807,12 +1800,6 @@ void qemu_system_powerdown_request(void)
 qemu_notify_event();
 }
 
-void qemu_system_exit_request(void)
-{
-exit_requested = 1;
-qemu_notify_event();
-}
-
 #ifdef _WIN32
 static void host_main_loop_wait(int *timeout)
 {
@@ -1949,8 +1936,6 @@ static int vm_can_run(void)
 return 0;
 if (debug_requested)
 return 0;
-if (exit_requested)
-return 0;
 return 1;
 }
 
@@ -2003,9 +1988,6 @@ static void main_loop(void)
 if ((r = qemu_vmstop_requested())) {
 vm_stop(r);
 }
-if (qemu_exit_requested()) {
-exit(0);
-}
 }
 pause_all_vcpus();
 }
-- 
1.7.1.11.g3bf78

[Qemu-devel] [PATCH 3/3] Monitor: Return before exiting with 'quit'

[Luiz Capitulino]

This is a new version of the (now reverted) following commit:

0e8d2b5575938b8876a3c4bb66ee13c5d306fb6d

The 'quit' Monitor command (implemented by do_quit()) calls
exit() directly, this is problematic under QMP because QEMU
exits before having a chance to send the ok response.

Clients don't know if QEMU exited because of a problem or
because the 'quit' command has been executed.

This commit fixes that by making do_quit() use
qemu_system_shutdown_request(), so that we exit gracefully.

Thanks to Paolo Bonzini  for suggesting
this solution.

Signed-off-by: Luiz Capitulino 
---
 monitor.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/monitor.c b/monitor.c
index e984122..15b53b9 100644
--- a/monitor.c
+++ b/monitor.c
@@ -942,7 +942,10 @@ static void do_info_cpu_stats(Monitor *mon)
  */
 static int do_quit(Monitor *mon, const QDict *qdict, QObject **ret_data)
 {
-exit(0);
+monitor_suspend(mon);
+no_shutdown = 0;
+qemu_system_shutdown_request();
+
 return 0;
 }
 
-- 
1.7.1.11.g3bf78

[Qemu-devel] [PATCH 0/3]: Monitor: Better fix for 'quit' return

[Luiz Capitulino]

 Right after when 0e8d2b55 was merged, Paolo suggested using
qemu_system_shutdown_request() instead of adding yet another 'system request'
operation.

 This series implements his suggestion, passes my tests :)

[Qemu-devel] [PATCH 2/3] target-sparc: Simplify ICC generation.

[Richard Henderson]

Use int32 types instead of target_ulong when computing ICC.  This
simplifies the generated code for 32-bit host and 64-bit guest.
Use the same simplified expressions for ICC as were already used
for XCC in carry flag generation.

Simplify the ADD carry generation to not consider a possible carry-in.
Use the more complex carry computation for ADDX only.  Use the same
carry algorithm for the XCC result of ADDX.  Similarly for SUB/SUBX.

Use the ADD carry generation functions for TADD/TADDTV.  Similarly
for SUB and TSUB/TSUBTV.

Tidy the code with respect to CODING_STYLE.

Signed-off-by: Richard Henderson 
---
 target-sparc/op_helper.c |  220 +-
 1 files changed, 140 insertions(+), 80 deletions(-)

diff --git a/target-sparc/op_helper.c b/target-sparc/op_helper.c
index 09449c5..3783b02 100644
--- a/target-sparc/op_helper.c
+++ b/target-sparc/op_helper.c
@@ -896,14 +896,15 @@ static uint32_t compute_C_flags(void)
 return env->psr & PSR_CARRY;
 }
 
-static inline uint32_t get_NZ_icc(target_ulong dst)
+static inline uint32_t get_NZ_icc(int32_t dst)
 {
 uint32_t ret = 0;
 
-if (!(dst & 0xULL))
-ret |= PSR_ZERO;
-if ((int32_t) (dst & 0xULL) < 0)
-ret |= PSR_NEG;
+if (dst == 0) {
+ret = PSR_ZERO;
+} else if (dst < 0) {
+ret = PSR_NEG;
+}
 return ret;
 }
 
@@ -918,14 +919,15 @@ static uint32_t compute_C_flags_xcc(void)
 return env->xcc & PSR_CARRY;
 }
 
-static inline uint32_t get_NZ_xcc(target_ulong dst)
+static inline uint32_t get_NZ_xcc(target_long dst)
 {
 uint32_t ret = 0;
 
-if (!dst)
-ret |= PSR_ZERO;
-if ((int64_t)dst < 0)
-ret |= PSR_NEG;
+if (!dst) {
+ret = PSR_ZERO;
+} else if (dst < 0) {
+ret = PSR_NEG;
+}
 return ret;
 }
 #endif
@@ -934,8 +936,9 @@ static inline uint32_t get_V_div_icc(target_ulong src2)
 {
 uint32_t ret = 0;
 
-if (src2 != 0)
-ret |= PSR_OVF;
+if (src2 != 0) {
+ret = PSR_OVF;
+}
 return ret;
 }
 
@@ -953,26 +956,35 @@ static uint32_t compute_C_div(void)
 return 0;
 }
 
-/* carry = (src1[31] & src2[31]) | ( ~dst[31] & (src1[31] | src2[31])) */
-static inline uint32_t get_C_add_icc(target_ulong dst, target_ulong src1,
- target_ulong src2)
+static inline uint32_t get_C_add_icc(uint32_t dst, uint32_t src1)
 {
 uint32_t ret = 0;
 
-if (((src1 & (1ULL << 31)) & (src2 & (1ULL << 31)))
-| ((~(dst & (1ULL << 31)))
-   & ((src1 & (1ULL << 31)) | (src2 & (1ULL << 31)
-ret |= PSR_CARRY;
+if (dst < src1) {
+ret = PSR_CARRY;
+}
 return ret;
 }
 
-static inline uint32_t get_V_add_icc(target_ulong dst, target_ulong src1,
- target_ulong src2)
+static inline uint32_t get_C_addx_icc(uint32_t dst, uint32_t src1,
+  uint32_t src2)
 {
 uint32_t ret = 0;
 
-if (((src1 ^ src2 ^ -1) & (src1 ^ dst)) & (1ULL << 31))
-ret |= PSR_OVF;
+if (((src1 & src2) | (~dst & (src1 | src2))) & (1U << 31)) {
+ret = PSR_CARRY;
+}
+return ret;
+}
+
+static inline uint32_t get_V_add_icc(uint32_t dst, uint32_t src1,
+ uint32_t src2)
+{
+uint32_t ret = 0;
+
+if (((src1 ^ src2 ^ -1) & (src1 ^ dst)) & (1U << 31)) {
+ret = PSR_OVF;
+}
 return ret;
 }
 
@@ -981,8 +993,20 @@ static inline uint32_t get_C_add_xcc(target_ulong dst, 
target_ulong src1)
 {
 uint32_t ret = 0;
 
-if (dst < src1)
-ret |= PSR_CARRY;
+if (dst < src1) {
+ret = PSR_CARRY;
+}
+return ret;
+}
+
+static inline uint32_t get_C_addx_xcc(target_ulong dst, target_ulong src1,
+  target_ulong src2)
+{
+uint32_t ret = 0;
+
+if (((src1 & src2) | (~dst & (src1 | src2))) & (1ULL << 63)) {
+ret = PSR_CARRY;
+}
 return ret;
 }
 
@@ -991,8 +1015,9 @@ static inline uint32_t get_V_add_xcc(target_ulong dst, 
target_ulong src1,
 {
 uint32_t ret = 0;
 
-if (((src1 ^ src2 ^ -1) & (src1 ^ dst)) & (1ULL << 63))
-ret |= PSR_OVF;
+if (((src1 ^ src2 ^ -1) & (src1 ^ dst)) & (1ULL << 63)) {
+ret = PSR_OVF;
+}
 return ret;
 }
 
@@ -1017,14 +1042,14 @@ static uint32_t compute_all_add(void)
 uint32_t ret;
 
 ret = get_NZ_icc(CC_DST);
-ret |= get_C_add_icc(CC_DST, CC_SRC, CC_SRC2);
+ret |= get_C_add_icc(CC_DST, CC_SRC);
 ret |= get_V_add_icc(CC_DST, CC_SRC, CC_SRC2);
 return ret;
 }
 
 static uint32_t compute_C_add(void)
 {
-return get_C_add_icc(CC_DST, CC_SRC, CC_SRC2);
+return get_C_add_icc(CC_DST, CC_SRC);
 }
 
 #ifdef TARGET_SPARC64
@@ -1033,8 +1058,7 @@ static uint32_t compute_all_addx_xcc(void)
 uint32_t ret;
 
 ret = get_NZ_xcc(CC_DST);
-ret |= get_C_add_xcc(CC_DST - CC_SRC2, CC_SRC);
-ret |= get_C_add_xcc(CC_DST, CC_SRC);
+ret |=

[Qemu-devel] [PATCH 0/3] Fix ADDX compilation plus improvements, v2

[Richard Henderson]

Changes v1->v2:
  * Fix ADDX carry generation properly, i.e. use the previous ADD
ICC carry computation for ADDX ICC and XCC.
  * Tidy PSR generators wrt CODING_STYLE, other minor improvements.
  * Set CC_OP properly in patch 3.


r~



Richard Henderson (3):
  target-sparc: Fix compilation with --enable-debug.
  target-sparc: Simplify ICC generation.
  target-sparc: Inline some generation of carry for ADDX/SUBX.

 target-sparc/op_helper.c |  220 --
 target-sparc/translate.c |  272 +-
 2 files changed, 338 insertions(+), 154 deletions(-)

[Qemu-devel] [PATCH 3/3] target-sparc: Inline some generation of carry for ADDX/SUBX.

[Richard Henderson]

Computing carry is trivial for some inputs.  By avoiding an
external function call, we generate near-optimal code for
the common cases of add+addx (double-word arithmetic) and
cmp+addx (a setcc pattern).

Signed-off-by: Richard Henderson 
---
 target-sparc/helper.h|2 +-
 target-sparc/op_helper.c |2 +-
 target-sparc/translate.c |  272 +-
 3 files changed, 200 insertions(+), 76 deletions(-)

diff --git a/target-sparc/helper.h b/target-sparc/helper.h
index 04c1306..6f103e7 100644
--- a/target-sparc/helper.h
+++ b/target-sparc/helper.h
@@ -158,6 +158,6 @@ VIS_CMPHELPER(cmpne);
 #undef VIS_HELPER
 #undef VIS_CMPHELPER
 DEF_HELPER_0(compute_psr, void);
-DEF_HELPER_0(compute_C_icc, tl);
+DEF_HELPER_0(compute_C_icc, i32);
 
 #include "def-helper.h"
diff --git a/target-sparc/op_helper.c b/target-sparc/op_helper.c
index 3783b02..125cd67 100644
--- a/target-sparc/op_helper.c
+++ b/target-sparc/op_helper.c
@@ -1342,7 +1342,7 @@ void helper_compute_psr(void)
 CC_OP = CC_OP_FLAGS;
 }
 
-target_ulong helper_compute_C_icc(void)
+uint32_t helper_compute_C_icc(void)
 {
 uint32_t ret;
 
diff --git a/target-sparc/translate.c b/target-sparc/translate.c
index ea7c71b..713d3e1 100644
--- a/target-sparc/translate.c
+++ b/target-sparc/translate.c
@@ -332,24 +332,132 @@ static inline void gen_op_add_cc(TCGv dst, TCGv src1, 
TCGv src2)
 tcg_gen_mov_tl(dst, cpu_cc_dst);
 }
 
-static inline void gen_op_addxi_cc(TCGv dst, TCGv src1, target_long src2)
+static TCGv_i32 gen_add32_carry32(void)
 {
-gen_helper_compute_C_icc(cpu_tmp0);
-tcg_gen_mov_tl(cpu_cc_src, src1);
-tcg_gen_movi_tl(cpu_cc_src2, src2);
-tcg_gen_add_tl(cpu_cc_dst, cpu_cc_src, cpu_tmp0);
-tcg_gen_addi_tl(cpu_cc_dst, cpu_cc_dst, src2);
-tcg_gen_mov_tl(dst, cpu_cc_dst);
+TCGv_i32 carry_32, cc_src1_32, cc_src2_32;
+
+/* Carry is computed from a previous add: (dst < src)  */
+#if TARGET_LONG_BITS == 64
+cc_src1_32 = tcg_temp_new_i32();
+cc_src2_32 = tcg_temp_new_i32();
+tcg_gen_trunc_i64_i32(cc_src1_32, cpu_cc_dst);
+tcg_gen_trunc_i64_i32(cc_src2_32, cpu_cc_src);
+#else
+cc_src1_32 = cpu_cc_dst;
+cc_src2_32 = cpu_cc_src;
+#endif
+
+carry_32 = tcg_temp_new_i32();
+tcg_gen_setcond_i32(TCG_COND_LTU, carry_32, cc_src1_32, cc_src2_32);
+
+#if TARGET_LONG_BITS == 64
+tcg_temp_free_i32(cc_src1_32);
+tcg_temp_free_i32(cc_src2_32);
+#endif
+
+return carry_32;
 }
 
-static inline void gen_op_addx_cc(TCGv dst, TCGv src1, TCGv src2)
+static TCGv_i32 gen_sub32_carry32(void)
 {
-gen_helper_compute_C_icc(cpu_tmp0);
-tcg_gen_mov_tl(cpu_cc_src, src1);
-tcg_gen_mov_tl(cpu_cc_src2, src2);
-tcg_gen_add_tl(cpu_cc_dst, cpu_cc_src, cpu_tmp0);
-tcg_gen_add_tl(cpu_cc_dst, cpu_cc_dst, cpu_cc_src2);
-tcg_gen_mov_tl(dst, cpu_cc_dst);
+TCGv_i32 carry_32, cc_src1_32, cc_src2_32;
+
+/* Carry is computed from a previous borrow: (src1 < src2)  */
+#if TARGET_LONG_BITS == 64
+cc_src1_32 = tcg_temp_new_i32();
+cc_src2_32 = tcg_temp_new_i32();
+tcg_gen_trunc_i64_i32(cc_src1_32, cpu_cc_src);
+tcg_gen_trunc_i64_i32(cc_src2_32, cpu_cc_src2);
+#else
+cc_src1_32 = cpu_cc_src;
+cc_src2_32 = cpu_cc_src2;
+#endif
+
+carry_32 = tcg_temp_new_i32();
+tcg_gen_setcond_i32(TCG_COND_LTU, carry_32, cc_src1_32, cc_src2_32);
+
+#if TARGET_LONG_BITS == 64
+tcg_temp_free_i32(cc_src1_32);
+tcg_temp_free_i32(cc_src2_32);
+#endif
+
+return carry_32;
+}
+
+static void gen_op_addx_int(DisasContext *dc, TCGv dst, TCGv src1,
+TCGv src2, int update_cc)
+{
+TCGv_i32 carry_32;
+TCGv carry;
+
+switch (dc->cc_op) {
+case CC_OP_DIV:
+case CC_OP_LOGIC:
+/* Carry is known to be zero.  Fall back to plain ADD.  */
+if (update_cc) {
+gen_op_add_cc(dst, src1, src2);
+} else {
+tcg_gen_add_tl(dst, src1, src2);
+}
+return;
+
+case CC_OP_ADD:
+case CC_OP_TADD:
+case CC_OP_TADDTV:
+#if TCG_TARGET_REG_BITS == 32 && TARGET_LONG_BITS == 32
+{
+/* For 32-bit hosts, we can re-use the host's hardware carry
+   generation by using an ADD2 opcode.  We discard the low
+   part of the output.  Ideally we'd combine this operation
+   with the add that generated the carry in the first place.  */
+TCGv dst_low = tcg_temp_new();
+tcg_gen_op6_i32(INDEX_op_add2_i32, dst_low, dst, 
+cpu_cc_src, src1, cpu_cc_src2, src2);
+tcg_temp_free(dst_low);
+goto add_done;
+}
+#endif
+carry_32 = gen_add32_carry32();
+break;
+
+case CC_OP_SUB:
+case CC_OP_TSUB:
+case CC_OP_TSUBTV:
+carry_32 = gen_sub32_carry32();
+break;
+
+default:
+/* We need external help to produce the carry.  */
+carry_32 = tcg_temp_new_i32();
+gen_helper_compute_C_ic

[Qemu-devel] [PATCH 1/3] target-sparc: Fix compilation with --enable-debug.

[Richard Henderson]

Return a target_ulong from compute_C_icc to match the width of the users.

Signed-off-by: Richard Henderson 
---
 target-sparc/helper.h|2 +-
 target-sparc/op_helper.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/target-sparc/helper.h b/target-sparc/helper.h
index 6f103e7..04c1306 100644
--- a/target-sparc/helper.h
+++ b/target-sparc/helper.h
@@ -158,6 +158,6 @@ VIS_CMPHELPER(cmpne);
 #undef VIS_HELPER
 #undef VIS_CMPHELPER
 DEF_HELPER_0(compute_psr, void);
-DEF_HELPER_0(compute_C_icc, i32);
+DEF_HELPER_0(compute_C_icc, tl);
 
 #include "def-helper.h"
diff --git a/target-sparc/op_helper.c b/target-sparc/op_helper.c
index fcfd3f3..09449c5 100644
--- a/target-sparc/op_helper.c
+++ b/target-sparc/op_helper.c
@@ -1282,7 +1282,7 @@ void helper_compute_psr(void)
 CC_OP = CC_OP_FLAGS;
 }
 
-uint32_t helper_compute_C_icc(void)
+target_ulong helper_compute_C_icc(void)
 {
 uint32_t ret;
 
-- 
1.7.0.1

[Qemu-devel] [PATCH 2/3] sysemu: Export 'no_shutdown'

[Luiz Capitulino]

It's a global variable already, do_quit() will use it.

Signed-off-by: Luiz Capitulino 
---
 sysemu.h |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/sysemu.h b/sysemu.h
index fcfccdf..58c9733 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -128,6 +128,7 @@ extern int max_cpus;
 extern int cursor_hide;
 extern int graphic_rotate;
 extern int no_quit;
+extern int no_shutdown;
 extern int semihosting_enabled;
 extern int old_param;
 extern int boot_menu;
-- 
1.7.1.11.g3bf78

[Qemu-devel] [PATCH] block/vdi: Fix image opening and creation for odd disk sizes

[Stefan Weil]

The fix is based on a patch from Kevin Wolf. Here his comment:

"The number of blocks needs to be rounded up to cover all of the virtual hard
disk. Without this fix, we can't even open our own images if their size is not
a multiple of the block size."

While Kevin's patch addressed vdi_create, my modification also fixes
vdi_open which now accepts images with odd disk sizes.

v3:
Don't allow reading of disk images with too large disk sizes.
Neither VBoxManage nor old versions of qemu-img read such images.
This change requires rounding of odd disk sizes before we do the checks.

Cc: Kevin Wolf 
Cc: François Revol 
Signed-off-by: Stefan Weil 
---
 block/vdi.c |   23 ---
 1 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/block/vdi.c b/block/vdi.c
index 1ce18d5..b53a3c1 100644
--- a/block/vdi.c
+++ b/block/vdi.c
@@ -393,6 +393,15 @@ static int vdi_open(BlockDriverState *bs, int flags)
 vdi_header_print(&header);
 #endif
 
+if (header.disk_size % SECTOR_SIZE != 0) {
+/* 'VBoxManage convertfromraw' can create images with odd disk sizes.
+   We accept them but round the disk size to the next multiple of
+   SECTOR_SIZE. */
+logout("odd disk size %" PRIu64 " B, round up\n", header.disk_size);
+header.disk_size += SECTOR_SIZE - 1;
+header.disk_size &= ~(SECTOR_SIZE - 1);
+}
+
 if (header.version != VDI_VERSION_1_1) {
 logout("unsupported version %u.%u\n",
header.version >> 16, header.version & 0x);
@@ -405,18 +414,15 @@ static int vdi_open(BlockDriverState *bs, int flags)
 /* We only support data blocks which start on a sector boundary. */
 logout("unsupported data offset 0x%x B\n", header.offset_data);
 goto fail;
-} else if (header.disk_size % SECTOR_SIZE != 0) {
-logout("unsupported disk size %" PRIu64 " B\n", header.disk_size);
-goto fail;
 } else if (header.sector_size != SECTOR_SIZE) {
 logout("unsupported sector size %u B\n", header.sector_size);
 goto fail;
 } else if (header.block_size != 1 * MiB) {
 logout("unsupported block size %u B\n", header.block_size);
 goto fail;
-} else if ((header.disk_size + header.block_size - 1) / header.block_size 
!=
-   (uint64_t)header.blocks_in_image) {
-logout("unexpected block number %u B\n", header.blocks_in_image);
+} else if (header.disk_size >
+   (uint64_t)header.blocks_in_image * header.block_size) {
+logout("unsupported disk size %" PRIu64 " B\n", header.disk_size);
 goto fail;
 } else if (!uuid_is_null(header.uuid_link)) {
 logout("link uuid != 0, unsupported\n");
@@ -829,7 +835,10 @@ static int vdi_create(const char *filename, 
QEMUOptionParameter *options)
 return -errno;
 }
 
-blocks = bytes / block_size;
+/* We need enough blocks to store the given disk size,
+   so always round up. */
+blocks = (bytes + block_size - 1) / block_size;
+
 bmap_size = blocks * sizeof(uint32_t);
 bmap_size = ((bmap_size + SECTOR_SIZE - 1) & ~(SECTOR_SIZE -1));
 
-- 
1.7.1

Re: [Qemu-devel] Re: Another SIGFPE in display code, now in cirrus

[Stefano Stabellini]

On Wed, 12 May 2010, Jamie Lokier wrote:
> Stefano Stabellini wrote:
> > On Wed, 12 May 2010, Avi Kivity wrote:
> > > It's useful if you have a one-line horizontal pattern you want to 
> > > propagate all over.
> >  
> > It might be useful all right, but it is not entirely clear what the
> > hardware should do in this situation from the documentation we have, and
> > certainly the current state of the cirrus emulation code doesn't help.
> 
> It's quite a reasonable thing for hardware to do, even if not documented.
> It would be surprising if the hardware didn't copy the one-line pattern.
 
All right then, you convinced me :)

This is my proposed solution, however it is untested with Windows NT.


Signed-off-by: Stefano Stabellini 

---



diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
index 9f61a01..a7f0d3c 100644
--- a/hw/cirrus_vga.c
+++ b/hw/cirrus_vga.c
@@ -676,15 +676,17 @@ static void cirrus_do_copy(CirrusVGAState *s, int dst, 
int src, int w, int h)
 int sx, sy;
 int dx, dy;
 int width, height;
+uint32_t start_addr, line_offset, line_compare;
 int depth;
 int notify = 0;
 
 depth = s->vga.get_bpp(&s->vga) / 8;
 s->vga.get_resolution(&s->vga, &width, &height);
+s->vga.get_offsets(&s->vga, &line_offset, &start_addr, &line_compare);
 
 /* extra x, y */
-sx = (src % ABS(s->cirrus_blt_srcpitch)) / depth;
-sy = (src / ABS(s->cirrus_blt_srcpitch));
+sx = (src % line_offset) / depth;
+sy = (src / line_offset);
 dx = (dst % ABS(s->cirrus_blt_dstpitch)) / depth;
 dy = (dst / ABS(s->cirrus_blt_dstpitch));
 
@@ -725,18 +727,23 @@ static void cirrus_do_copy(CirrusVGAState *s, int dst, 
int src, int w, int h)
  s->cirrus_blt_dstpitch, s->cirrus_blt_srcpitch,
  s->cirrus_blt_width, s->cirrus_blt_height);
 
-if (notify)
-   qemu_console_copy(s->vga.ds,
- sx, sy, dx, dy,
- s->cirrus_blt_width / depth,
- s->cirrus_blt_height);
-
-/* we don't have to notify the display that this portion has
-   changed since qemu_console_copy implies this */
-
-cirrus_invalidate_region(s, s->cirrus_blt_dstaddr,
-   s->cirrus_blt_dstpitch, s->cirrus_blt_width,
-   s->cirrus_blt_height);
+ if (ABS(s->cirrus_blt_dstpitch) != line_offset ||
+ ABS(s->cirrus_blt_srcpitch) != line_offset) {
+ /* this is not going to happen very often */
+ vga_hw_invalidate();
+ } else {
+ if (notify)
+ /* we don't have to notify the display that this portion has
+changed since qemu_console_copy implies this */
+ qemu_console_copy(s->vga.ds,
+   sx, sy, dx, dy,
+   s->cirrus_blt_width / depth,
+   s->cirrus_blt_height);
+ else
+ cirrus_invalidate_region(s, s->cirrus_blt_dstaddr,
+  s->cirrus_blt_dstpitch, 
s->cirrus_blt_width,
+  s->cirrus_blt_height);
+ }
 }
 
 static int cirrus_bitblt_videotovideo_copy(CirrusVGAState * s)
diff --git a/hw/cirrus_vga_rop.h b/hw/cirrus_vga_rop.h
index 39a7b72..80f135b 100644
--- a/hw/cirrus_vga_rop.h
+++ b/hw/cirrus_vga_rop.h
@@ -32,10 +32,10 @@ glue(cirrus_bitblt_rop_fwd_, ROP_NAME)(CirrusVGAState *s,
 dstpitch -= bltwidth;
 srcpitch -= bltwidth;
 
-if (dstpitch < 0 || srcpitch < 0) {
-/* is 0 valid? srcpitch == 0 could be useful */
+if (dstpitch < 0)
 return;
-}
+if (srcpitch < 0)
+srcpitch = 0;
 
 for (y = 0; y < bltheight; y++) {
 for (x = 0; x < bltwidth; x++) {
@@ -57,6 +57,12 @@ glue(cirrus_bitblt_rop_bkwd_, ROP_NAME)(CirrusVGAState *s,
 int x,y;
 dstpitch += bltwidth;
 srcpitch += bltwidth;
+
+if (dstpitch > 0)
+return;
+if (srcpitch > 0)
+srcpitch = 0;
+
 for (y = 0; y < bltheight; y++) {
 for (x = 0; x < bltwidth; x++) {
 ROP_OP(*dst, *src);
@@ -78,6 +84,12 @@ glue(glue(cirrus_bitblt_rop_fwd_transp_, 
ROP_NAME),_8)(CirrusVGAState *s,
 uint8_t p;
 dstpitch -= bltwidth;
 srcpitch -= bltwidth;
+
+if (dstpitch < 0)
+return;
+if (srcpitch < 0)
+srcpitch = 0;
+
 for (y = 0; y < bltheight; y++) {
 for (x = 0; x < bltwidth; x++) {
p = *dst;
@@ -101,6 +113,12 @@ glue(glue(cirrus_bitblt_rop_bkwd_transp_, 
ROP_NAME),_8)(CirrusVGAState *s,
 uint8_t p;
 dstpitch += bltwidth;
 srcpitch += bltwidth;
+
+if (dstpitch > 0)
+return;
+if (srcpitch > 0)
+srcpitch = 0;
+
 for (y = 0; y < bltheight; y++) {
 for (x = 0; x < bltwidth; x++) {
p = *dst;
@@ -124,6 +142,12 @@ glue(glue(cirrus_bitblt_rop_fwd_transp_, 
ROP_NAME),_16)(CirrusVGAState *s,
 uint8_t p1, p2;
 dstpitch -= bltwidth

[Qemu-devel] [PATCH] target-sparc: Fix wrong printf argument

[Stefan Weil]

cpu_get_ccr() returns a target_ulong, so a type cast is needed to avoid
wrong output on big endian hosts. We could also use TARGET_FMT_lx,
but that would print 8 instead of 2 digits.

Cc: Blue Swirl 
Signed-off-by: Stefan Weil 
---
 target-sparc/helper.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/target-sparc/helper.c b/target-sparc/helper.c
index 4642122..582de10 100644
--- a/target-sparc/helper.c
+++ b/target-sparc/helper.c
@@ -1490,7 +1490,7 @@ void cpu_dump_state(CPUState *env, FILE *f,
 }
 #ifdef TARGET_SPARC64
 cpu_fprintf(f, "pstate: %08x ccr: %02x (icc: ", env->pstate,
-cpu_get_ccr(env));
+(unsigned)cpu_get_ccr(env));
 cpu_print_cc(f, cpu_fprintf, cpu_get_ccr(env) << PSR_CARRY_SHIFT);
 cpu_fprintf(f, " xcc: ");
 cpu_print_cc(f, cpu_fprintf, cpu_get_ccr(env) << (PSR_CARRY_SHIFT - 4));
-- 
1.7.1

[Qemu-devel] Re: [PATCH] char: Flush read buffer in mux_chr_can_read

[Jan Kiszka]

Alexander Graf wrote:
> Jan Kiszka wrote:
>> Alexander Graf wrote:
>>   
>>> Jan Kiszka wrote:
>>> 
 Move the buffer flush from mux_chr_read to mux_chr_can_read. While the
 latter is called periodically, the former will only be invoked when new
 characters arrive at the back-end. This caused problems to front-end
 drivers whenever they were unable to read data immediately, e.g.
 virtio-console attached to stdio.
   
   
>>> I don't see this patch applied, but also don't see any issues with
>>> virtio-console anymore on today's git. Odd.
>>>
>>> 
>> Hmm, I had a clear before-after experience using virtio console with an
>> x86 Linux guest. I still think my patch is correct and required. Maybe
>> you can bisect this positive "regression"? Something might paper over
>> the core issue now.
>>   
> 
> I just did a git reset --hard on
> baf0b55a9e57b909b1f8b0f732c0b10242867418 and it worked! What the ...

Whatever "worked" now means (I'm slightly confused), I just rechecked
the situation over current git head ("qemu linux-guest.img -chardev
stdio,id=cons,mux=on -device virtio-serial -device
virtconsole,chardev=cons -mon chardev=cons", "cat /dev/hvc0" in the
guest, typing some chars on the host console): The problem still
persists, my patch still solves it. Can you confirm this, ideally also
for s390?

Jan



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] Re: [PATCH] block/vdi: Fix image opening and creation for odd disk sizes

[Kevin Wolf]

Am 12.05.2010 20:25, schrieb Stefan Weil:
> The fix is based on a patch from Kevin Wolf. Here his comment:
> 
> "The number of blocks needs to be rounded up to cover all of the virtual hard
> disk. Without this fix, we can't even open our own images if their size is not
> a multiple of the block size."
> 
> While Kevin's patch addressed vdi_create, my modification also fixes
> vdi_open which now accepts images with odd disk sizes.
> 
> v3:
> Don't allow reading of disk images with too large disk sizes.
> Neither VBoxManage nor old versions of qemu-img read such images.
> This change requires rounding of odd disk sizes before we do the checks.
> 
> Cc: Kevin Wolf 
> Cc: François Revol 
> Signed-off-by: Stefan Weil 

Thanks, applied to the block branch.

Kevin

[Qemu-devel] Re: [PPC] Can't boot iso images

[Blue Swirl]

On 5/11/10, Alexander Graf  wrote:
> Howdy,
>
>  While trying to boot an openSUSE 11.1 iso I always get
>  "/packages/elf-loader is missing". Apparently that bug was fixed in a
>  more recent version of OpenBIOS. According to git log the version in
>  pc-bios is r721.
>
>  Could we please pull in a more recent version?

I updated all images to r771.

Re: [Qemu-devel] [PATCH 2/2] all vga: fail graicefully when vga ports are taken

[Blue Swirl]

On 5/11/10, Gerd Hoffmann  wrote:
> Try to pci hotplug a vga card, watch qemu die with hw_error().
>  This patch fixes it.
>
>  Signed-off-by: Gerd Hoffmann 
>  ---
>   hw/cirrus_vga.c |3 +++
>   hw/vga-pci.c|3 +++
>   hw/vmware_vga.c |3 +++
>   3 files changed, 9 insertions(+), 0 deletions(-)
>
>  diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
>  index 9f61a01..2f50e86 100644
>  --- a/hw/cirrus_vga.c
>  +++ b/hw/cirrus_vga.c
>  @@ -3189,6 +3189,9 @@ static int pci_cirrus_vga_initfn(PCIDevice *dev)
>   uint8_t *pci_conf = d->dev.config;
>   int device_id = CIRRUS_ID_CLGD5446;
>
>  + if (is_ioport_assigned(0x3c0))
>  + return -1;
>  +

-ECODING_STYLE.

>   /* setup VGA */
>   vga_common_init(&s->vga, VGA_RAM_SIZE);
>   cirrus_init_common(s, device_id, 1);
>  diff --git a/hw/vga-pci.c b/hw/vga-pci.c
>  index c8d260c..2ef3278 100644
>  --- a/hw/vga-pci.c
>  +++ b/hw/vga-pci.c
>  @@ -79,6 +79,9 @@ static int pci_vga_initfn(PCIDevice *dev)
>   VGACommonState *s = &d->vga;
>   uint8_t *pci_conf = d->dev.config;
>
>  + if (is_ioport_assigned(0x3c0))
>  + return -1;
>  +
>   // vga + console init
>   vga_common_init(s, VGA_RAM_SIZE);
>   vga_init(s);
>  diff --git a/hw/vmware_vga.c b/hw/vmware_vga.c
>  index 4e7a75d..cd0eb57 100644
>  --- a/hw/vmware_vga.c
>  +++ b/hw/vmware_vga.c
>  @@ -1232,6 +1232,9 @@ static int pci_vmsvga_initfn(PCIDevice *dev)
>  struct pci_vmsvga_state_s *s =
>  DO_UPCAST(struct pci_vmsvga_state_s, card, dev);
>
>  +if (is_ioport_assigned(0x3c0))
>  +return -1;
>  +
>  pci_config_set_vendor_id(s->card.config, PCI_VENDOR_ID_VMWARE);
>  pci_config_set_device_id(s->card.config, SVGA_PCI_DEVICE_ID);
>  s->card.config[PCI_COMMAND]= PCI_COMMAND_IO |
>
> --
>  1.6.6.1
>
>
>

Re: [Qemu-devel] [RFC] tcg/interpreter: Add TCG + interpreter for bytecode (virtual machine)

[Stefan Weil]

Am 28.09.2009 18:50, schrieb Stefan Weil:

Hello

The patch following this mail adds a new code generator
to qemu. It includes a README file with more details.

Comments and contributions to complete it are welcome.

Regards
Stefan Weil


Hello,

The latest version of the TCG interpreter ("TCI") runs QEMU system emulation
booting 32 or 64 bit x86 or mips linux on 32 or 64 bit x86 hosts.

x86 bios boot also works on arm hosts (real hardware) and mips hosts
(qemu malta emulation).

Compilation was tested for powerpc host, too.

The code is available from http://repo.or.cz/w/qemu/ar7.git, see also
http://repo.or.cz/w/qemu/ar7.git/blob_plain/master:/tcg/bytecode/README

Of course I can also send patches to the list if people want integration
in qemu master.

I am still looking for new test environments, especially hosts
which are still unsupported by qemu.

Regards
Stefan Weil

Re: [Qemu-devel] Re: Another SIGFPE in display code, now in cirrus

[Michael Tokarev]

12.05.2010 22:11, Stefano Stabellini wrote:

On Wed, 12 May 2010, Jamie Lokier wrote:

Stefano Stabellini wrote:

On Wed, 12 May 2010, Avi Kivity wrote:

It's useful if you have a one-line horizontal pattern you want to
propagate all over.


It might be useful all right, but it is not entirely clear what the
hardware should do in this situation from the documentation we have, and
certainly the current state of the cirrus emulation code doesn't help.


It's quite a reasonable thing for hardware to do, even if not documented.
It would be surprising if the hardware didn't copy the one-line pattern.


All right then, you convinced me :)

This is my proposed solution, however it is untested with Windows NT.


Well.  At least it does not crash anymore.

With this patch applied, when hitting "Test" (of a new video mode)
button on WindowsNT, the guest window gets resized to correct size,
but is painted with yellow and nothing happens.  The CPU enters
100%, and on the kvm console the following messages are displayed:

 BUG: kvm_dirty_pages_log_enable_slot: invalid parameters
 BUG: kvm_dirty_pages_log_enable_slot: invalid parameters

That's not new, it sometimes displays that shit on attempt to
migrate too, as I mentioned in another thread.

Thanks!

/mjt


diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
index 9f61a01..a7f0d3c 100644
--- a/hw/cirrus_vga.c
+++ b/hw/cirrus_vga.c
@@ -676,15 +676,17 @@ static void cirrus_do_copy(CirrusVGAState *s, int dst, 
int src, int w, int h)
  int sx, sy;
  int dx, dy;
  int width, height;
+uint32_t start_addr, line_offset, line_compare;
  int depth;
  int notify = 0;

[...]

[Qemu-devel] Re: [PATCH v2] Fix -device help and documentation

[Stefan Weil]

Am 11.05.2010 14:02, schrieb Markus Armbruster:

Commit 6616b2ad reverted commit 40ea285c.  Looks like a mismerge to
me.

Signed-off-by: Markus Armbruster
---
v2: rebased (v1 fell through the cracks apparently)

  qemu-options.hx |   15 ++-
  1 files changed, 6 insertions(+), 9 deletions(-)

diff --git a/qemu-options.hx b/qemu-options.hx
index 12f6b51..03e95fd 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -464,18 +464,15 @@ DEF("device", HAS_ARG, QEMU_OPTION_device,
  "add device (based on driver)\n"
  "prop=value,... sets driver properties\n"
  "use -device ? to print all possible drivers\n"
-"use -device driver,? to print all possible options\n"
-"use -device driver,option=? to print a help for value\n",
+"use -device driver,? to print all possible properties\n",
  QEMU_ARCH_ALL)
  STEXI
-...@item -device @var{driver}[,@var{option...@var{value}][,...]]
+...@item -device @var{driver}[,@var{prop...@var{value}][,...]]
  @findex -device
-Add device @var{driver}. Depending on the device type,
-...@var{option} (with default or given @var{value}) may be useful.
-To get a help on possible @var{driver}s, @var{option}s or @var{value}s, use
-...@code{-device ?},
-...@code{-device @var{driver},?} or
-...@code{-device @var{driver},@var{option}=?}.
+Add device @var{driver}.  @var{pro...@var{value} sets driver
+properties.  Valid properties depend on the driver.  To get help on
+possible drivers and properties, use @code{-device ?} and
+...@code{-device @var{driver},?}.
  ETEXI

  #ifdef CONFIG_LINUX
   


Acked-by: Stefan Weil 

[Qemu-devel] Re: [PATCH] target-sparc: Fix wrong printf argument

[Blue Swirl]

Thanks, applied.

Another solution would have been to change the return value to uint32_t.

On 5/12/10, Stefan Weil  wrote:
> cpu_get_ccr() returns a target_ulong, so a type cast is needed to avoid
>  wrong output on big endian hosts. We could also use TARGET_FMT_lx,
>  but that would print 8 instead of 2 digits.
>
>  Cc: Blue Swirl 
>  Signed-off-by: Stefan Weil 
>  ---
>   target-sparc/helper.c |2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)
>
>  diff --git a/target-sparc/helper.c b/target-sparc/helper.c
>  index 4642122..582de10 100644
>  --- a/target-sparc/helper.c
>  +++ b/target-sparc/helper.c
>  @@ -1490,7 +1490,7 @@ void cpu_dump_state(CPUState *env, FILE *f,
>  }
>   #ifdef TARGET_SPARC64
>  cpu_fprintf(f, "pstate: %08x ccr: %02x (icc: ", env->pstate,
>  -cpu_get_ccr(env));
>  +(unsigned)cpu_get_ccr(env));
>  cpu_print_cc(f, cpu_fprintf, cpu_get_ccr(env) << PSR_CARRY_SHIFT);
>  cpu_fprintf(f, " xcc: ");
>  cpu_print_cc(f, cpu_fprintf, cpu_get_ccr(env) << (PSR_CARRY_SHIFT - 4));
>
> --
>  1.7.1
>
>

[Qemu-devel] [PATCH] target-i386: Avoid kvm related compiler error

[Stefan Weil]

Some versions of kvm.h (debian lenny) define KVM_CAP_VCPU_EVENTS
without defining KVM_VCPUEVENT_VALID_NMI_PENDING or
KVM_VCPUEVENT_VALID_SIPI_VECTOR.

Without the patch, compilation fails:

  CCx86_64-softmmu/kvm.o
/qemu/target-i386/kvm.c: In function 'kvm_put_vcpu_events':
/qemu/target-i386/kvm.c:824: error: 'KVM_VCPUEVENT_VALID_NMI_PENDING' 
undeclared (first use in this function)
/qemu/target-i386/kvm.c:824: error: (Each undeclared identifier is reported 
only once
/qemu/target-i386/kvm.c:824: error: for each function it appears in.)
/qemu/target-i386/kvm.c:824: error: 'KVM_VCPUEVENT_VALID_SIPI_VECTOR' 
undeclared (first use in this function)
make[1]: *** [kvm.o] Error 1

Cc: Jan Kiszka 
Signed-off-by: Stefan Weil 
---
 target-i386/kvm.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index f73b47b..9a37753 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -796,7 +796,7 @@ static int kvm_get_mp_state(CPUState *env)
 
 static int kvm_put_vcpu_events(CPUState *env, int level)
 {
-#ifdef KVM_CAP_VCPU_EVENTS
+#if defined(KVM_CAP_VCPU_EVENTS) && defined(KVM_VCPUEVENT_VALID_NMI_PENDING)
 struct kvm_vcpu_events events;
 
 if (!kvm_has_vcpu_events()) {
-- 
1.7.1

[Qemu-devel] Re: ehci fixes

[Jan Kiszka]

Vincent Palatin wrote:
> Dear developers,
> 
> While using the EHCI patchset, I have found 2 minor issues.
> So, I send in this email thread 2 fix proposals.

Thanks, merged both and pushed an updated ehci branch.

Jan



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] Migration failure from AMD to Intel

[Tomoe Sugihara]

Hi,

Does anyone have any idea on a issue that I have regarding VM migration from 
AMD to Intel host?

When the guest is migrated from AMD host and right after it starts on Intel 
host,
qemu process crashes with log messages like below.  
Looks like, when the guest is loaded on its network, it is more likely to manifests the issue.


Platform is CentOS 5.4(x86_64) without any updates both for the hosts and the 
guest,
and KVM related packages are the following:

kernel–2.6.18–164.el5
kmod-kvm–83–105.el5_4.9
kvm–83–105.el5_4.9

I'd appreciate any info on this issue.

-
LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin HOME=/root USER=root LOGNAME=root 
/usr/libexec/qemu-kvm -S -M pc -m 1024
 -smp 1 -name stress-test-4 -uuid 425edb11-be36-46c5-b8b6-2570f09a3f27 
-no-kvm-pit-reinjection -monitor pty -pidfile
 /var/ru
n/libvirt/qemu//stress-test-4.pid -boot cd -drive 
file=/data/images/stress-test-4.img,if=ide,index=0,boot=on -drive 
file=/data/iso/CentOS-5.4-x86_64-bin-DVD.iso,if=ide,media=cdrom,index=2 -drive 
file=/data/images/stdisk-4-1.img,if=virtio,index=0 -drive 
file=/data/images/stdisk-4-2.img,if=virtio,index=1 -net 
nic,macaddr=00:42:5e:27:3f:9a,vlan=0,model=virtio -net 
tap,fd=18,script=,vlan=0,ifname=vnet2 -serial none -parallel none -usb -vnc 
0.0.0.0:2 -k ja -incoming tcp:0.0.0.0:49213 213 0.0.0:49213 0.0.0:49213 213 
0:49213  ja -incoming tcp:0.0.0.0:49213 213
char device redirected to /dev/pts/1
unhandled vm exit: 0x8021 vcpu_id 0
rax 0001 rbx 81003dcd7d00 rcx 81003e0cc000 rdx 
c050
rsi 0001c050 rdi 0001 rsp 81001db31960 rbp 
81001bbca080
r8   r9  81003e0cc000 r10 0220 r11 
881cf53d
r12 81003dcd7800 r13 81003b853c00 r14 81003dcd7a00 r15 
0001083e14c5
rip 80151895 rflags 0246
cs 0010 (/ p 1 dpl 0 db 0 s 1 type b l 1 g 1 avl 0)
ds  (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0)
es  (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0)
ss 0018 (/ p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0)
fs 0063 (42a37940/ p 1 dpl 3 db 1 s 1 type 2 l 0 g 1 avl 1)
gs  (803c/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0)
tr 0040 (810001573000/206f p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0)
ldt  (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0)
gdt 803f2000/80
idt 80442000/fff
cr0 8005003b cr2 3a9ce9a070 cr3 1dba6000 cr4 6e0 cr8 0 efer d01
-

--- cpuinfoon AMD

processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 16
model   : 2
model name  : Quad-Core AMD Opteron(tm) Processor 1354
stepping: 3
cpu MHz : 1100.000
cache size  : 512 KB
physical id : 0
siblings: 4
core id : 0
cpu cores   : 4
apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 5
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb 
rdtscp lm 3dnowext 3dnow constant_tsc nonstop_tsc pni cx16 popcnt lahf_lm 
cmp_legacy svm extapic cr8_legacy altmovcr8 abm sse4a misalignsse 3dnowprefetch 
osvw
bogomips: 4399.99
TLB size: 1024 4K pages
clflush size: 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate [8]

 cpuinfo on Intel

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 15
model name  : Intel(R) Xeon(R) CPU   X3210  @ 2.13GHz
stepping: 11
cpu MHz : 1600.000
cache size  : 4096 KB
physical id : 0
siblings: 4
core id : 0
cpu cores   : 4
apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 10
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm 
constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm
bogomips: 4256.12
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:


TIA,
Tomoe

[Qemu-devel] Re: [RFC PATCH 1/2] close all the block drivers before the qemu process exits

[MORITA Kazutaka]

At Thu, 13 May 2010 05:16:35 +0900,
MORITA Kazutaka wrote:
> 
> On 2010/05/12 23:28, Avi Kivity wrote:
> > On 05/12/2010 01:46 PM, MORITA Kazutaka wrote:
> >> This patch calls the close handler of the block driver before the qemu
> >> process exits.
> >>
> >> This is necessary because the sheepdog block driver releases the lock
> >> of VM images in the close handler.
> >>
> >>
> > 
> > How do you handle abnormal termination?
> > 
> 
> In the case, we need to release the lock manually, unfortunately.
> Sheepdog admin tool has a command to do that.
> 

More precisely, if qemu fails down with its host machine, we detect
the qemu failure and release the lock.  It is because Sheepdog
currently assumes that all the qemu processes are in the sheepdog
cluster, and remember that where they are running.  When machine
failures happen, sheepdog release the lock of the VMs on the machines
(We uses corosync to check which machines are alive or not).

If the qemu process exits abnormally and its host machine is alive,
the sheepdog daemon on the host needs to detect the qemu failure.
However, the feature is not implemented yet.  We think of checking a
socket connection between qemu and sheepdog daemon to detect the
failure.  Currently, we need to release the lock manually from the
admin tool in this case.

Thanks,

Kazutaka

[Qemu-devel] [PATCH resend 2/6] MIPS: Initial support of vt82686b south bridge used by fulong mini pc

[Huacai Chen]

resend by git send-email to avoid line-wrapping

Signed-off-by: Huacai Chen 
---
 Makefile.target |2 +-
 hw/pc.h |7 +
 hw/pci_ids.h|8 +
 hw/vt82c686.c   |  786 +++
 4 files changed, 802 insertions(+), 1 deletions(-)
 create mode 100644 hw/vt82c686.c

diff --git a/Makefile.target b/Makefile.target
index 63d9f49..4fc1290 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -220,7 +220,7 @@ obj-mips-y += dma.o vga.o i8259.o
 obj-mips-y += g364fb.o jazz_led.o
 obj-mips-y += gt64xxx.o pckbd.o mc146818rtc.o
 obj-mips-y += piix4.o cirrus_vga.o
-obj-mips-$(CONFIG_FULONG) += bonito.o
+obj-mips-$(CONFIG_FULONG) += bonito.o vt82c686.o
 
 obj-microblaze-y = petalogix_s3adsp1800_mmu.o
 
diff --git a/hw/pc.h b/hw/pc.h
index d11a576..8951609 100644
--- a/hw/pc.h
+++ b/hw/pc.h
@@ -115,6 +115,13 @@ void i440fx_init_memory_mappings(PCII440FXState *d);
 extern PCIDevice *piix4_dev;
 int piix4_init(PCIBus *bus, int devfn);
 
+/* vt82c686.c */
+int vt82c686b_init(PCIBus * bus, int devfn);
+void vt82c686b_ac97_init(PCIBus *bus, int devfn);
+void vt82c686b_mc97_init(PCIBus *bus, int devfn);
+i2c_bus *vt82c686b_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
+qemu_irq sci_irq);
+
 /* vga.c */
 enum vga_retrace_method {
 VGA_RETRACE_DUMB,
diff --git a/hw/pci_ids.h b/hw/pci_ids.h
index fe7a121..39e9f1d 100644
--- a/hw/pci_ids.h
+++ b/hw/pci_ids.h
@@ -78,6 +78,14 @@
 
 #define PCI_VENDOR_ID_XILINX 0x10ee
 
+#define PCI_VENDOR_ID_VIA0x1106
+#define PCI_DEVICE_ID_VIA_ISA_BRIDGE 0x0686
+#define PCI_DEVICE_ID_VIA_IDE0x0571
+#define PCI_DEVICE_ID_VIA_UHCI   0x3038
+#define PCI_DEVICE_ID_VIA_ACPI   0x3057
+#define PCI_DEVICE_ID_VIA_AC97   0x3058
+#define PCI_DEVICE_ID_VIA_MC97   0x3068
+
 #define PCI_VENDOR_ID_MARVELL0x11ab
 
 #define PCI_VENDOR_ID_ENSONIQ0x1274
diff --git a/hw/vt82c686.c b/hw/vt82c686.c
new file mode 100644
index 000..1045467
--- /dev/null
+++ b/hw/vt82c686.c
@@ -0,0 +1,786 @@
+/*
+ * VT82C686B south bridge support
+ *
+ * Copyright (c) 2008 yajin (ya...@vm-kernel.org)
+ * Copyright (c) 2009 chenming (chenm...@rdc.faw.com.cn)
+ * Copyright (c) 2010 Huacai Chen (zltjiang...@gmail.com)
+ * This code is licensed under the GNU GPL v2.
+ */
+
+#include "hw.h"
+#include "pc.h"
+#include "i2c.h"
+#include "smbus.h"
+#include "pci.h"
+#include "isa.h"
+#include "sysbus.h"
+#include "mips.h"
+
+typedef uint32_t pci_addr_t;
+#include "pci_host.h"
+//#define DEBUG_VT82C686B
+
+#ifdef DEBUG_VT82C686B
+#define DPRINTF(fmt, ...) fprintf(stderr, "%s: " fmt, __FUNCTION__, 
##__VA_ARGS__)
+#else
+#define DPRINTF(fmt, ...)
+#endif
+
+typedef struct SuperIOConfig
+{
+uint8_t config[0xff];
+uint8_t index;
+uint8_t data;
+} SuperIOConfig;
+
+typedef struct VT82C686BState {
+PCIDevice dev;
+SuperIOConfig *superio_conf;
+} VT82C686BState;
+
+uint32_t smb_data[16];
+static void superio_ioport_writeb(void *opaque, uint32_t addr, uint32_t data)
+{
+int can_write;
+SuperIOConfig *superio_conf = (SuperIOConfig *)opaque;
+
+DPRINTF("superio_ioport_writeb  address 0x%x  val 0x%x  \n", addr, data);
+if (addr == 0x3f0) {
+superio_conf->index = data & 0xff;
+} else {
+/* 0x3f1 */
+switch (superio_conf->index) {
+case 0x00 ... 0xdf:
+case 0xe4:
+case 0xe5:
+case 0xe9 ... 0xed:
+case 0xf3:
+case 0xf5:
+case 0xf7:
+case 0xf9 ... 0xfb:
+case 0xfd ... 0xff:
+can_write = 0;
+break;
+default:
+can_write = 1;
+
+if (can_write) {
+switch (superio_conf->index) {
+case 0xe7:
+if ((data & 0xff) != 0xfe) {
+DPRINTF("chage uart 1 base. unsupported yet \n");
+}
+break;
+case 0xe8:
+if ((data & 0xff) != 0xbe) {
+DPRINTF("chage uart 2 base. unsupported yet \n");
+}
+break;
+
+default:
+superio_conf->config[superio_conf->index] = data & 0xff;
+}
+}
+}
+superio_conf->config[superio_conf->index] = data & 0xff;
+}
+}
+
+static uint32_t superio_ioport_readb(void *opaque, uint32_t addr)
+{
+SuperIOConfig *superio_conf = (SuperIOConfig *)opaque;
+
+DPRINTF("superio_ioport_readb  address 0x%x   \n", addr);
+return (superio_conf->config[superio_conf->index]);
+}
+
+static void vt82c686b_reset(void * opaque)
+{
+PCIDevice *d = opaque;
+uint8_t *pci_conf = d->config;
+VT82C686BState *vt82c = DO_UPCAST(VT82C686BState, dev, d);
+
+pci_set_long(pci_conf + PCI_CAPABILITY_LIST, 0x00c0);
+
+pci_conf[0x04] = 0x87; /* master, memory, I/O and special */
+pci_conf[0x05]

[Qemu-devel] [PATCH resend 5/6] MIPS: Initial support of fulong mini pc (CPU definition, machine construction, etc.)

[Huacai Chen]

resend by git send-email to avoid line-wrapping

Signed-off-by: Huacai Chen 
---
 Makefile.target  |2 +-
 hw/mips_fulong2e.c   |  420 ++
 target-mips/translate_init.c |   35 
 3 files changed, 456 insertions(+), 1 deletions(-)
 create mode 100644 hw/mips_fulong2e.c

diff --git a/Makefile.target b/Makefile.target
index 4fc1290..7a9d93b 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -220,7 +220,7 @@ obj-mips-y += dma.o vga.o i8259.o
 obj-mips-y += g364fb.o jazz_led.o
 obj-mips-y += gt64xxx.o pckbd.o mc146818rtc.o
 obj-mips-y += piix4.o cirrus_vga.o
-obj-mips-$(CONFIG_FULONG) += bonito.o vt82c686.o
+obj-mips-$(CONFIG_FULONG) += bonito.o vt82c686.o mips_fulong2e.o
 
 obj-microblaze-y = petalogix_s3adsp1800_mmu.o
 
diff --git a/hw/mips_fulong2e.c b/hw/mips_fulong2e.c
new file mode 100644
index 000..3f6d25b
--- /dev/null
+++ b/hw/mips_fulong2e.c
@@ -0,0 +1,420 @@
+/*
+ * QEMU fulong 2e mini pc support
+ *
+ * Copyright (c) 2008 yajin (ya...@vm-kernel.org)
+ * Copyright (c) 2009 chenming (chenm...@rdc.faw.com.cn)
+ * Copyright (c) 2010 Huacai Chen (zltjiang...@gmail.com)
+ * This code is licensed under the GNU GPL v2.
+ */
+
+/*
+ * Fulong 2e mini pc is based on ICT/ST Loongson 2e CPU (MIPS III like, 800MHz)
+ * http://www.linux-mips.org/wiki/Fulong
+ *
+ * Loongson 2e user manual:
+ * http://www.loongsondeveloper.com/doc/Loongson2EUserGuide.pdf
+ */
+
+#include "hw.h"
+#include "pc.h"
+#include "fdc.h"
+#include "net.h"
+#include "boards.h"
+#include "smbus.h"
+#include "block.h"
+#include "flash.h"
+#include "mips.h"
+#include "mips_cpudevs.h"
+#include "pci.h"
+#include "usb-uhci.h"
+#include "qemu-char.h"
+#include "sysemu.h"
+#include "audio/audio.h"
+#include "qemu-log.h"
+#include "loader.h"
+#include "mips-bios.h"
+#include "ide.h"
+#include "elf.h"
+
+#define DEBUG_FULONG2E_INIT
+
+#define ENVP_ADDR   0x80002000l
+#define ENVP_NB_ENTRIES16
+#define ENVP_ENTRY_SIZE256
+
+#define MAX_IDE_BUS 2
+
+/* PCI SLOT in fulong 2e */
+#define FULONG2E_VIA_SLOT5
+#define FULONG2E_ATI_SLOT6
+#define FULONG2E_RTL8139_SLOT7
+
+static PITState *pit;
+
+static struct _loaderparams {
+int ram_size;
+const char *kernel_filename;
+const char *kernel_cmdline;
+const char *initrd_filename;
+} loaderparams;
+
+static void mips_qemu_writel (void *opaque, target_phys_addr_t addr,
+ uint32_t val)
+{
+if ((addr & 0x) == 0 && val == 42)
+qemu_system_reset_request ();
+else if ((addr & 0x) == 4 && val == 42)
+qemu_system_shutdown_request ();
+}
+
+static uint32_t mips_qemu_readl (void *opaque, target_phys_addr_t addr)
+{
+return 0;
+}
+
+static CPUWriteMemoryFunc *mips_qemu_write[] = {
+mips_qemu_writel,
+mips_qemu_writel,
+mips_qemu_writel,
+};
+
+static CPUReadMemoryFunc *mips_qemu_read[] = {
+mips_qemu_readl,
+mips_qemu_readl,
+mips_qemu_readl,
+};
+static int mips_qemu_iomemtype = 0;
+
+static void prom_set(uint32_t* prom_buf, int index, const char *string, ...)
+{
+va_list ap;
+int32_t table_addr;
+
+if (index >= ENVP_NB_ENTRIES)
+return;
+
+if (string == NULL) {
+prom_buf[index] = 0;
+return;
+}
+
+table_addr = sizeof(int32_t) * ENVP_NB_ENTRIES + index * ENVP_ENTRY_SIZE;
+prom_buf[index] = tswap32(ENVP_ADDR + table_addr);
+
+va_start(ap, string);
+vsnprintf((char *)prom_buf + table_addr, ENVP_ENTRY_SIZE, string, ap);
+va_end(ap);
+}
+
+static int64_t load_kernel (CPUState *env)
+{
+int64_t kernel_entry, kernel_low, kernel_high;
+int index = 0;
+long initrd_size;
+ram_addr_t initrd_offset;
+uint32_t *prom_buf;
+long prom_size;
+
+if (load_elf(loaderparams.kernel_filename, cpu_mips_kseg0_to_phys, NULL,
+ (uint64_t *)&kernel_entry, (uint64_t *)&kernel_low,
+ (uint64_t *)&kernel_high, 0, ELF_MACHINE, 1) < 0) {
+fprintf(stderr, "qemu: could not load kernel '%s'\n",
+loaderparams.kernel_filename);
+exit(1);
+}
+
+/* load initrd */
+initrd_size = 0;
+initrd_offset = 0;
+if (loaderparams.initrd_filename) {
+initrd_size = get_image_size (loaderparams.initrd_filename);
+if (initrd_size > 0) {
+initrd_offset = (kernel_high + ~TARGET_PAGE_MASK) & 
TARGET_PAGE_MASK;
+if (initrd_offset + initrd_size > ram_size) {
+fprintf(stderr,
+"qemu: memory too small for initial ram disk '%s'\n",
+loaderparams.initrd_filename);
+exit(1);
+}
+initrd_size = load_image_targphys(loaderparams.initrd_filename,
+ initrd_offset, ram_size - initrd_offset);
+}
+if (initrd_size == (target_ulong) -1) {
+fprintf(stderr, "qemu: could not load initial ram di

Re: [Qemu-devel] [RFC] tcg/interpreter: Add TCG + interpreter for bytecode (virtual machine)

[Jun Koi]

On Tue, Sep 29, 2009 at 1:50 AM, Stefan Weil  wrote:
> Hello
>
> The patch following this mail adds a new code generator
> to qemu. It includes a README file with more details.
>
> Comments and contributions to complete it are welcome.

Could you compare the performance of TCG and TCI? I suppose that TCG
is still faster, but by how much?

(I know TCI still needs a lot of optimization, but lets compare TCG
and TCI with assumption that TCI is already matured)

Thanks,
J

[Qemu-devel] [PATCH resend 4/6] MIPS: Initial support of VIA USB controller used by fulong mini pc

[Huacai Chen]

resend by git send-email to avoid line-wrapping

Signed-off-by: Huacai Chen 
---
 hw/usb-uhci.c |   30 ++
 hw/usb-uhci.h |1 +
 2 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/hw/usb-uhci.c b/hw/usb-uhci.c
index 624d55b..5fd5388 100644
--- a/hw/usb-uhci.c
+++ b/hw/usb-uhci.c
@@ -1152,6 +1152,26 @@ static int usb_uhci_piix4_initfn(PCIDevice *dev)
 return usb_uhci_common_initfn(s);
 }
 
+static int usb_uhci_vt82c686b_initfn(PCIDevice *dev)
+{
+UHCIState *s = DO_UPCAST(UHCIState, dev, dev);
+uint8_t *pci_conf = s->dev.config;
+
+pci_config_set_vendor_id(pci_conf, PCI_VENDOR_ID_VIA);
+pci_config_set_device_id(pci_conf, PCI_DEVICE_ID_VIA_UHCI);
+
+pci_set_long(pci_conf + 0x0c,0x1600);
+pci_set_long(pci_conf + 0x20,0x0301);
+pci_set_long(pci_conf + 0x34,0x1080);
+pci_set_long(pci_conf + 0x3c,0x0004);
+pci_set_long(pci_conf + 0x40,0x1000);
+pci_set_long(pci_conf + 0x60,0x0010);
+pci_set_long(pci_conf + 0x80,0x00020001);
+pci_set_long(pci_conf + 0xc0,0x2000);
+
+return usb_uhci_common_initfn(s);
+}
+
 static PCIDeviceInfo uhci_info[] = {
 {
 .qdev.name= "piix3-usb-uhci",
@@ -1164,6 +1184,11 @@ static PCIDeviceInfo uhci_info[] = {
 .qdev.vmsd= &vmstate_uhci,
 .init = usb_uhci_piix4_initfn,
 },{
+.qdev.name= "vt82c686b-usb-uhci",
+.qdev.size= sizeof(UHCIState),
+.qdev.vmsd= &vmstate_uhci,
+.init = usb_uhci_vt82c686b_initfn,
+},{
 /* end of list */
 }
 };
@@ -1183,3 +1208,8 @@ void usb_uhci_piix4_init(PCIBus *bus, int devfn)
 {
 pci_create_simple(bus, devfn, "piix4-usb-uhci");
 }
+
+void usb_uhci_vt82c686b_init(PCIBus *bus, int devfn)
+{
+pci_create_simple(bus, devfn, "vt82c686b-usb-uhci");
+}
diff --git a/hw/usb-uhci.h b/hw/usb-uhci.h
index 911948e..3e4d377 100644
--- a/hw/usb-uhci.h
+++ b/hw/usb-uhci.h
@@ -5,5 +5,6 @@
 
 void usb_uhci_piix3_init(PCIBus *bus, int devfn);
 void usb_uhci_piix4_init(PCIBus *bus, int devfn);
+void usb_uhci_vt82c686b_init(PCIBus *bus, int devfn);
 
 #endif
-- 
1.7.0.4

Re: [Qemu-devel] [PATCH] linux-user: rlimit conversion between host and target.

[Richard Henderson]

On 04/11/2010 12:07 PM, takas...@ops.dti.ne.jp wrote:
> rlim_t conversion between host and target added.
> Otherwise there are some incorrect case like
> - RLIM_INFINITY on 32bit target -> 64bit host. 
> - RLIM_INFINITY on 64bit host -> mips and sparc target ?
> - Big value(for 32bit target) on 64bit host -> 32bit target.
> 
> One is added into getrlimit, setrlimit, and ugetrlimit. It converts both
> RLIM_INFINITY and value bigger than target can hold(>31bit) to RLIM_INFINITY.
> 
> Another one is added to guest_stack_size calculation introduced by
> 703e0e89. The rule is mostly same except the result on the case is keeping
> the value of guest_stack_size.
> 
> Slightly tested for SH4, and x86_64 -linux-user on x86_64-pc-linux host.
> 
> Signed-off-by: Takashi YOSHII 

Acked-by: Richard Henderson 


> ---
>  linux-user/main.c |3 ++-
>  linux-user/syscall.c  |   30 ++
>  linux-user/syscall_defs.h |8 
>  3 files changed, 32 insertions(+), 9 deletions(-)
> 
> diff --git a/linux-user/main.c b/linux-user/main.c
> index b394c00..60eea3a 100644
> --- a/linux-user/main.c
> +++ b/linux-user/main.c
> @@ -2645,7 +2645,8 @@ int main(int argc, char **argv, char **envp)
>  {
>  struct rlimit lim;
>  if (getrlimit(RLIMIT_STACK, &lim) == 0
> -&& lim.rlim_cur != RLIM_INFINITY) {
> +&& lim.rlim_cur != RLIM_INFINITY
> +&& lim.rlim_cur == (target_long)lim.rlim_cur) {
>  guest_stack_size = lim.rlim_cur;
>  }
>  }
> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
> index a03e432..cfc91d1 100644
> --- a/linux-user/syscall.c
> +++ b/linux-user/syscall.c
> @@ -831,6 +831,22 @@ static inline abi_long host_to_target_rusage(abi_ulong 
> target_addr,
>  return 0;
>  }
>  
> +static inline rlim_t target_to_host_rlim(target_ulong target_rlim)
> +{
> +if (target_rlim == TARGET_RLIM_INFINITY)
> +return RLIM_INFINITY;
> +else
> +return tswapl(target_rlim);
> +}
> +
> +static inline target_ulong host_to_target_rlim(rlim_t rlim)
> +{
> +if (rlim == RLIM_INFINITY || rlim != (target_long)rlim)
> +return TARGET_RLIM_INFINITY;
> +else
> +return tswapl(rlim);
> +}
> +
>  static inline abi_long copy_from_user_timeval(struct timeval *tv,
>abi_ulong target_tv_addr)
>  {
> @@ -5124,21 +5140,19 @@ abi_long do_syscall(void *cpu_env, int num, abi_long 
> arg1,
>  break;
>  case TARGET_NR_setrlimit:
>  {
> -/* XXX: convert resource ? */
>  int resource = arg1;
>  struct target_rlimit *target_rlim;
>  struct rlimit rlim;
>  if (!lock_user_struct(VERIFY_READ, target_rlim, arg2, 1))
>  goto efault;
> -rlim.rlim_cur = tswapl(target_rlim->rlim_cur);
> -rlim.rlim_max = tswapl(target_rlim->rlim_max);
> +rlim.rlim_cur = target_to_host_rlim(target_rlim->rlim_cur);
> +rlim.rlim_max = target_to_host_rlim(target_rlim->rlim_max);
>  unlock_user_struct(target_rlim, arg2, 0);
>  ret = get_errno(setrlimit(resource, &rlim));
>  }
>  break;
>  case TARGET_NR_getrlimit:
>  {
> -/* XXX: convert resource ? */
>  int resource = arg1;
>  struct target_rlimit *target_rlim;
>  struct rlimit rlim;
> @@ -5147,8 +5161,8 @@ abi_long do_syscall(void *cpu_env, int num, abi_long 
> arg1,
>  if (!is_error(ret)) {
>  if (!lock_user_struct(VERIFY_WRITE, target_rlim, arg2, 0))
>  goto efault;
> -target_rlim->rlim_cur = tswapl(rlim.rlim_cur);
> -target_rlim->rlim_max = tswapl(rlim.rlim_max);
> +target_rlim->rlim_cur = host_to_target_rlim(rlim.rlim_cur);
> +target_rlim->rlim_max = host_to_target_rlim(rlim.rlim_max);
>  unlock_user_struct(target_rlim, arg2, 1);
>  }
>  }
> @@ -6233,8 +6247,8 @@ abi_long do_syscall(void *cpu_env, int num, abi_long 
> arg1,
>   struct target_rlimit *target_rlim;
>  if (!lock_user_struct(VERIFY_WRITE, target_rlim, arg2, 0))
>  goto efault;
> - target_rlim->rlim_cur = tswapl(rlim.rlim_cur);
> - target_rlim->rlim_max = tswapl(rlim.rlim_max);
> + target_rlim->rlim_cur = host_to_target_rlim(rlim.rlim_cur);
> + target_rlim->rlim_max = host_to_target_rlim(rlim.rlim_max);
>  unlock_user_struct(target_rlim, arg2, 1);
>   }
>   break;
> diff --git a/linux-user/syscall_defs.h b/linux-user/syscall_defs.h
> index 63c2bc3..255e89c 100644
> --- a/linux-user/syscall_defs.h
> +++ b/linux-user/syscall_defs.h
> @@ -669,6 +669,14 @@ struct target_rlimit {
>  abi_ulong   rlim_max;
>  };
>  
> +#if defined(TARGET_ALPHA)
> +#define TARGET_RLIM_INFINITY 0x7ff

[Qemu-devel] [PATCH 0/2] Enable qemu block layer to not flush v2

[Alexander Graf]

Thanks to recent improvements, qemu flushes guest data to disk when the guest
tells us to do so.

This is great if we care about data consistency on host disk failures. In cases
where we don't it just creates additional overhead for no net win. One such use
case is the building of appliances in SUSE Studio. We write the resulting images
out of the build VM, but compress it directly afterwards. So if possible we'd
love to keep it in RAM.

This patchset introduces a new cache option to -drive called "volatile" which
allows a user to signal qemu that he doesn't care about data integrity.
To show the difference in performance this makes, I have put together a small
test case. Inside the initrd, I call the following piece of code on a 500MB
preallocated vmdk image:

  mkfs.ext3 /dev/vda
  mkdir -p /mnt
  mount /dev/vda /mnt
  dd if=/dev/zero of=/mnt/test bs=1M
  umount /mnt
  sync
  halt -fp

With cache=writeback

real0m34.653s
user0m16.957s
sys 0m5.872s

With cache=volatile

real0m27.068s
user0m15.829s
sys 0m6.648s

When I use a loopback file with msdos format and put the vmdk inside there,
performance for cache=writeback and cache=volatile is basically identical.

It nevertheless does make sense to offer a cache=volatile option to the user,
as it's not always possible to loopback mount your own file systems, especially
given qemu's non-root nature.

v1 -> v2:

  - clean up no_op patch
  - move to cache=volatile instead of flush=off
  - make code less intrusive by catching everything in block.c

Alexander Graf (2):
  Add no-op aio emulation stub
  Add cache=volatile parameter to -drive

 block.c |   28 
 block.h |1 +
 qemu-config.c   |2 +-
 qemu-options.hx |7 ---
 vl.c|3 +++
 5 files changed, 37 insertions(+), 4 deletions(-)