Re: [Qemu-devel] 80-column rule and breaking output statements
On (Sat) 02 Jul 2011 [09:38:30], Stefan Hajnoczi wrote: ... I don't see split lines as an issue because I never grep for an entire line. Pick a small, unique, fixed part of the message and you'll find it. Small in order to avoid any formatting or split line issues. Unless you pick your Small string that was split across multiple lines. Unique in order to cut down the number of grep results. Fixed in order to avoid format string expansions as Blue Swirl mentioned. Amit
Re: [Qemu-devel] [PATCH 3/3] megasas: LSI Megaraid SAS emulation
On 07/03/2011 04:36 PM, Paolo Bonzini wrote: On 07/02/2011 03:50 PM, Hannes Reinecke wrote: (And no, I will not getting into another dog-fight with Paul B. here. Virtio can do without bounce buffers. AHCI can. So I fail to see why SCSI has to rely on bounce buffers.) I agree, but I do see why a SCSI device might prefer to rely on bounce buffers for non-I/O commands. This is why in my last RFC series for vmw_pvscsi I let the device choose whether to force a bounce buffer or get an external iovec from the HBA. Yes, sure, for non-I/O commands it's perfectly okay. Most of which will be emulated anyway. It's bounce buffers for I/O which kills performance. But I seem to have missed your last RFC (I'm not reading qemu-devel on a regular basis ...). Care to send me a pointer to it? Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
Re: [Qemu-devel] buildbot failure in qemu on disable_kvm_x86_64_debian_5_0
On Mon, Jul 4, 2011 at 6:41 AM, Daniel Gollub gol...@b1-systems.de wrote: On Monday, July 04, 2011 06:23:41 am Stefan Hajnoczi wrote: BUILD FAILED: failed compile In file included from /usr/include/png.h:438, from ui/vnc-enc-tight.c:40: /usr/include/pngconf.h:326: error: expected '=', ',', ';', 'asm' or '__attribute__' before '.' token /usr/include/pngconf.h:327: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'include' make: *** [ui/vnc-enc-tight.o] Error 1 program finished with exit code 2 Not sure what exactly is missing, but the last change in that code was from Stefan Weil (2fb0c09f4ff036f68474277ed4edc036f6529de8). Daniel, Would it be possible to post the contents of /usr/include/pngconf.h from b1_qemu_1? I checked my local copy and I don't understand these compiler errors. Perhaps you have a different version of the file. Good catch. I readded my Debian 5 x86_64 buildslave to the qemu continous build yesterday. Thats the reason of this regression, which very likely isn't one ... All the other build failures from last night have the same root cause i guess. Because the run for the first time on b1_qemu_1 since a while ... Stefan, which distro is your slave currently running on? yuzuki is running Debian squeeze x86_64. Stefan
Re: [Qemu-devel] [PATCH 3/3] megasas: LSI Megaraid SAS emulation
On 07/04/2011 08:13 AM, Hannes Reinecke wrote: On 07/03/2011 04:36 PM, Paolo Bonzini wrote: On 07/02/2011 03:50 PM, Hannes Reinecke wrote: (And no, I will not getting into another dog-fight with Paul B. here. Virtio can do without bounce buffers. AHCI can. So I fail to see why SCSI has to rely on bounce buffers.) I agree, but I do see why a SCSI device might prefer to rely on bounce buffers for non-I/O commands. This is why in my last RFC series for vmw_pvscsi I let the device choose whether to force a bounce buffer or get an external iovec from the HBA. Yes, sure, for non-I/O commands it's perfectly okay. Most of which will be emulated anyway. It's bounce buffers for I/O which kills performance. But I seem to have missed your last RFC (I'm not reading qemu-devel on a regular basis ...). Care to send me a pointer to it? Sure, http://lists.gnu.org/archive/html/qemu-devel/2011-06/msg00668.html Paolo
Re: [Qemu-devel] [PATCH 3/3] megasas: LSI Megaraid SAS emulation
On 07/04/2011 08:34 AM, Paolo Bonzini wrote: On 07/04/2011 08:13 AM, Hannes Reinecke wrote: On 07/03/2011 04:36 PM, Paolo Bonzini wrote: On 07/02/2011 03:50 PM, Hannes Reinecke wrote: (And no, I will not getting into another dog-fight with Paul B. here. Virtio can do without bounce buffers. AHCI can. So I fail to see why SCSI has to rely on bounce buffers.) I agree, but I do see why a SCSI device might prefer to rely on bounce buffers for non-I/O commands. This is why in my last RFC series for vmw_pvscsi I let the device choose whether to force a bounce buffer or get an external iovec from the HBA. Yes, sure, for non-I/O commands it's perfectly okay. Most of which will be emulated anyway. It's bounce buffers for I/O which kills performance. But I seem to have missed your last RFC (I'm not reading qemu-devel on a regular basis ...). Care to send me a pointer to it? Sure, http://lists.gnu.org/archive/html/qemu-devel/2011-06/msg00668.html Cool. Exactly what I need. FWIW, feel free to add my 'Acked-by' to it. Any chance of getting them included? Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
Re: [Qemu-devel] Wiki spam
On Mon, 4 Jul 2011 03:15:06 PM Stefan Hajnoczi wrote: Thanks. I have a regular wiki account so I checked the Recent Changes page and undid the spam changes that I saw: http://wiki.qemu.org/Special:RecentChanges Is there a way to completely remove it? There is still spam on the wiki showing at: http://wiki.qemu.org/index.php?title=Special:DeadendPageslimit=500offset=0 I'd prefer not to have it in the history at all if thats possible. Brad
[Qemu-devel] KVM call agenda for July 5
Hi Please send in any agenda items you are interested in covering. Later, Juan.
Re: [Qemu-devel] Wiki spam
On Mon, Jul 4, 2011 at 8:27 AM, Brad Hards br...@frogmouth.net wrote: On Mon, 4 Jul 2011 03:15:06 PM Stefan Hajnoczi wrote: Thanks. I have a regular wiki account so I checked the Recent Changes page and undid the spam changes that I saw: http://wiki.qemu.org/Special:RecentChanges Is there a way to completely remove it? There is still spam on the wiki showing at: http://wiki.qemu.org/index.php?title=Special:DeadendPageslimit=500offset=0 I'd prefer not to have it in the history at all if thats possible. Only an administrator can delete pages: http://www.mediawiki.org/wiki/Help:Deleting_a_page Stefan
Re: [Qemu-devel] [PATCH 3/3] megasas: LSI Megaraid SAS emulation
On 07/02/2011 06:14 PM, Stefan Hajnoczi wrote:
On Fri, Jul 1, 2011 at 4:35 PM, Hannes Reineckeh...@suse.de wrote:
+static void megasas_mmio_writel(void *opaque, target_phys_addr_t addr,
+uint32_t val)
+{
+MPTState *s = opaque;
+target_phys_addr_t frame_addr;
+uint32_t frame_count;
+int i;
+
+DPRINTF_REG(writel mmio %lx: %x\n, (unsigned long)addr, val);
+
+switch (addr) {
+case MFI_IDB:
+if (val MFI_FWINIT_ABORT) {
+/* Abort all pending cmds */
+for (i = 0; i= s-fw_cmds; i++) {
+megasas_abort_command(s-frames[i]);
+}
+}
+if (val MFI_FWINIT_READY) {
+/* move to FW READY */
+megasas_soft_reset(s);
+}
+if (val MFI_FWINIT_MFIMODE) {
+/* discard MFIs */
+}
+break;
+case MFI_OMSK:
+s-intr_mask = val;
+if (!MEGASAS_INTR_ENABLED(s)) {
+qemu_irq_lower(s-dev.irq[0]);
+}
+break;
+case MFI_ODCR0:
+/* Update reply queue pointer */
+DPRINTF_QUEUE(Update reply queue head %x busy %d\n,
+ s-reply_queue_index, s-busy);
+stl_phys(s-producer_pa, s-reply_queue_index);
+s-doorbell = 0;
+qemu_irq_lower(s-dev.irq[0]);
+break;
+case MFI_IQPH:
+s-frame_hi = val;
+break;
+case MFI_IQPL:
+case MFI_IQP:
+/* Received MFI frame address */
+frame_addr = (val ~0xFF);
+/* Add possible 64 bit offset */
+frame_addr |= (uint64_t)s-frame_hi;
Is this missing 32 before ORing the high bits?
Yes, true. Linux doesn't use the high part, so
I haven't seen it yet.
Might explain the strange Win7 failures I've had :-)
Fixed.
+static int megasas_scsi_uninit(PCIDevice *d)
+{
+MPTState *s = DO_UPCAST(MPTState, dev, d);
+
+cpu_unregister_io_memory(s-mmio_io_addr);
Need to unregister io_addr and queue_addr.
Yeah, the unregister function is a bit of a stub currently.
Fixed.
+
+return 0;
+}
+
+static const struct SCSIBusOps megasas_scsi_ops = {
+.transfer_data = megasas_xfer_complete,
+.complete = megasas_command_complete,
+.cancel = megasas_command_cancel,
+};
+
+static int megasas_scsi_init(PCIDevice *dev)
+{
+MPTState *s = DO_UPCAST(MPTState, dev, dev);
+uint8_t *pci_conf;
+int i;
+
+pci_conf = s-dev.config;
+
+/* PCI Vendor ID (word) */
+pci_config_set_vendor_id(pci_conf, PCI_VENDOR_ID_LSI_LOGIC);
+/* PCI device ID (word) */
+pci_config_set_device_id(pci_conf, PCI_DEVICE_ID_LSI_SAS1078);
+/* PCI subsystem ID */
+pci_set_word(pci_conf[PCI_SUBSYSTEM_VENDOR_ID], 0x1000);
+pci_set_word(pci_conf[PCI_SUBSYSTEM_ID], 0x1013);
+/* PCI base class code */
+pci_config_set_class(pci_conf, PCI_CLASS_STORAGE_RAID);
PCIDeviceInfo now has vendor_id, device_id, and other fields. These
values can be set in the megasas_info definition below.
Argl. Interface change again. Okay, will be doing so.
+
+/* PCI latency timer = 0 */
+pci_conf[0x0d] = 0;
+/* Interrupt pin 1 */
+pci_conf[0x3d] = 0x01;
+
+s-mmio_io_addr = cpu_register_io_memory(megasas_mmio_readfn,
+ megasas_mmio_writefn, s,
+ DEVICE_NATIVE_ENDIAN);
+s-io_addr = cpu_register_io_memory(megasas_io_readfn,
+megasas_io_writefn, s,
+DEVICE_NATIVE_ENDIAN);
+s-queue_addr = cpu_register_io_memory(megasas_queue_readfn,
+ megasas_queue_writefn, s,
+ DEVICE_NATIVE_ENDIAN);
Should these be little-endian?
Presumably. Haven't tested on big-endian emulations as of now.
+pci_register_bar((struct PCIDevice *)s, 0, 0x4,
+ PCI_BASE_ADDRESS_SPACE_MEMORY, megasas_mmio_mapfunc);
+pci_register_bar((struct PCIDevice *)s, 2, 256,
+ PCI_BASE_ADDRESS_SPACE_IO, megasas_io_mapfunc);
+pci_register_bar((struct PCIDevice *)s, 3, 0x4,
+ PCI_BASE_ADDRESS_SPACE_MEMORY, megasas_queue_mapfunc);
+if (s-fw_sge= MEGASAS_MAX_SGE - MFI_PASS_FRAME_SIZE) {
+s-fw_sge = MEGASAS_MAX_SGE - MFI_PASS_FRAME_SIZE;
+} else if (s-fw_sge= 128 - MFI_PASS_FRAME_SIZE) {
+s-fw_sge = 128 - MFI_PASS_FRAME_SIZE;
+} else {
+s-fw_sge = 64 - MFI_PASS_FRAME_SIZE;
+}
+if (s-fw_cmds MEGASAS_MAX_FRAMES) {
+s-fw_cmds = MEGASAS_MAX_FRAMES;
+}
+if (s-raid_mode_str) {
+if (!strcmp(s-raid_mode_str, jbod)) {
+s-is_jbod = 1;
+} else {
+s-is_jbod = 0;
+}
+}
+DPRINTF(Using %d sges, %d cmds, %s mode\n,
+s-fw_sge, s-fw_cmds, s-is_jbod ? jbod : raid);
+s-fw_luns = (MFI_MAX_LD MAX_SCSI_DEVS) ?
+MAX_SCSI_DEVS :
Re: [Qemu-devel] buildbot failure in qemu on disable_kvm_x86_64_debian_5_0
On 04.07.2011, at 07:51, Stefan Weil wrote: Am 04.07.2011 06:23, schrieb Stefan Hajnoczi: On Mon, Jul 4, 2011 at 12:47 AM, Alexander Graf ag...@suse.de wrote: On 04.07.2011, at 02:04, q...@buildbot.b1-systems.de wrote: The Buildbot has detected a new failure on builder disable_kvm_x86_64_debian_5_0 while building qemu. Full details are available at: http://buildbot.b1-systems.de/qemu/builders/disable_kvm_x86_64_debian_5_0/builds/148 Buildbot URL: http://buildbot.b1-systems.de/qemu/ Buildslave for this Build: b1_qemu_1 Build Reason: The Nightly scheduler named 'nightly_disable_kvm' triggered this build Build Source Stamp: [branch master] HEAD Blamelist: BUILD FAILED: failed compile In file included from /usr/include/png.h:438, from ui/vnc-enc-tight.c:40: /usr/include/pngconf.h:326: error: expected '=', ',', ';', 'asm' or '__attribute__' before '.' token /usr/include/pngconf.h:327: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'include' make: *** [ui/vnc-enc-tight.o] Error 1 program finished with exit code 2 Not sure what exactly is missing, but the last change in that code was from Stefan Weil (2fb0c09f4ff036f68474277ed4edc036f6529de8). Daniel, Would it be possible to post the contents of /usr/include/pngconf.h from b1_qemu_1? I checked my local copy and I don't understand these compiler errors. Perhaps you have a different version of the file. Thanks, Stefan The compiler errors come again from the setjmp check in pngconf.h: __pngconf.h__ in libpng already includes setjmp.h; __dont__ include it again.; The buildbot runs Debian Lenny which includes an old version of libpng. That version does not use PNG_SKIP_SETJMP_CHECK to skip the setjmp check. Defining PNG_SETJMP_NOT_SUPPORTED might help with this version, but I still have to test that. Updating the buildbot to Debian Squeeze would also work. So it's a real bug and a good thing the buildbot is running on Lenny. Maybe we should add the define and #include setjmp.h to configure, so at least that one fails when compilation wouldn't work either? Alex
[Qemu-devel] [PATCH] pci: add standard bridge device
This adds support for a standard pci to pci bridge,
enabling support for more than 32 PCI devices in the system.
To use, specify the device id as a 'bus' option.
Example:
-device pci-bridge,id=bridge1 \
-netdev user,id=u \
-device ne2k_pci,id=net2,bus=bridge1,netdev=u
TODO: device hotplug support.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
Makefile.objs |2 +-
hw/pci_bridge_dev.c | 70 +++
2 files changed, 71 insertions(+), 1 deletions(-)
create mode 100644 hw/pci_bridge_dev.c
diff --git a/Makefile.objs b/Makefile.objs
index cea15e4..9e82b12 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -174,7 +174,7 @@ hw-obj-y += vl.o loader.o
hw-obj-$(CONFIG_VIRTIO) += virtio.o virtio-console.o
hw-obj-$(CONFIG_VIRTIO_PCI) += virtio-pci.o
hw-obj-y += fw_cfg.o
-hw-obj-$(CONFIG_PCI) += pci.o pci_bridge.o
+hw-obj-$(CONFIG_PCI) += pci.o pci_bridge.o pci_bridge_dev.o
hw-obj-$(CONFIG_PCI) += msix.o msi.o
hw-obj-$(CONFIG_PCI) += pci_host.o pcie_host.o
hw-obj-$(CONFIG_PCI) += ioh3420.o xio3130_upstream.o xio3130_downstream.o
diff --git a/hw/pci_bridge_dev.c b/hw/pci_bridge_dev.c
new file mode 100644
index 000..c7ab5ad
--- /dev/null
+++ b/hw/pci_bridge_dev.c
@@ -0,0 +1,70 @@
+/*
+ * Standard PCI Bridge Device
+ *
+ * Copyright (c) 2011 Red Hat Inc. Author: Michael S. Tsirkin m...@redhat.com
+ *
+ *
http://www.pcisig.com/specifications/conventional/pci_to_pci_bridge_architecture/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see http://www.gnu.org/licenses/.
+ */
+
+#include pci_bridge.h
+#include pci_ids.h
+#include pci_internals.h
+
+#define REDHAT_PCI_VENDOR_ID 0x1b36
+#define PCI_BRIDGE_DEV_VENDOR_ID REDHAT_PCI_VENDOR_ID
+#define PCI_BRIDGE_DEV_DEVICE_ID 0x1
+
+/* Mapping mandated by PCI-to-PCI Bridge architecture specification,
+ * revision 1.2 */
+/* Table 9-1: Interrupt Binding for Devices Behind a Bridge */
+static int pci_bridge_dev_map_irq_fn(PCIDevice *dev, int irq_num)
+{
+return (irq_num + PCI_SLOT(dev-devfn) + irq_num) % PCI_NUM_PINS;
+}
+
+static int pci_bridge_dev_initfn(PCIDevice *dev)
+{
+PCIBridge *br = DO_UPCAST(PCIBridge, dev, dev);
+br-map_irq = pci_bridge_dev_map_irq_fn;
+/* If we don't specify the name, the bus will be addressed as id.0, where
+ * id is the parent id. But it seems more natural to address the bus using
+ * the parent device name. */
+if (dev-qdev.id *dev-qdev.id) {
+br-bus_name = dev-qdev.id;
+}
+return pci_bridge_initfn(dev);
+}
+
+static PCIDeviceInfo pci_bridge_dev_info = {
+.qdev.name = pci-bridge,
+.qdev.desc = Standard PCI Bridge,
+.qdev.size = sizeof(PCIBridge),
+.qdev.reset = pci_bridge_reset,
+.is_bridge = 1,
+.config_write = pci_bridge_write_config,
+.init = pci_bridge_dev_initfn,
+.exit = pci_bridge_exitfn,
+.vendor_id = PCI_BRIDGE_DEV_VENDOR_ID,
+.device_id = PCI_BRIDGE_DEV_DEVICE_ID,
+.class_id = PCI_CLASS_BRIDGE_PCI,
+};
+
+static void pci_bridge_dev_register(void)
+{
+pci_qdev_register(pci_bridge_dev_info);
+}
+
+device_init(pci_bridge_dev_register);
--
1.7.5.53.gc233e
Re: [Qemu-devel] [PATCH 3/3] megasas: LSI Megaraid SAS emulation
On 07/04/2011 09:26 AM, Hannes Reinecke wrote: Cool. Exactly what I need. FWIW, feel free to add my 'Acked-by' to it. Any chance of getting them included? I'm not very tied to pvscsi; I just needed an HBA that is not a joke by modern standards :) to play with the SCSI layer. There may be hope that megasas will come before pvscsi or eliminate the need for it altogether. So, feel free to pick up patches 5-8 from that series. That said, note that scsi-generic does *not* support scatter/gather in that series, so you should still make sure the fallback paths work well. :) In pvscsi I added a qdev property to toggle scatter/gather, it was useful for benchmarking. Paolo
[Qemu-devel] [V4 Patch 1/4]Qemu: Enhance info block to display host cache setting
Enhance info block to display hostcache setting for each
block device.
Example:
(qemu) info block
ide0-hd0: type=hd removable=0 file=../rhel6-32.qcow2 ro=0 drv=qcow2
encrypted=0
Enhanced to display hostcache setting:
(qemu) info block
ide0-hd0: type=hd removable=0 hostcache=true file=../rhel6-32.qcow2
ro=0 drv=qcow2 encrypted=0
Signed-off-by: Supriya Kannery supri...@in.ibm.com
---
block.c | 21 +
qmp-commands.hx |2 ++
2 files changed, 19 insertions(+), 4 deletions(-)
Index: qemu/block.c
===
--- qemu.orig/block.c
+++ qemu/block.c
@@ -1694,6 +1694,14 @@ static void bdrv_print_dict(QObject *obj
monitor_printf(mon, locked=%d, qdict_get_bool(bs_dict, locked));
}
+if (qdict_haskey(bs_dict, open_flags)) {
+int open_flags = qdict_get_int(bs_dict, open_flags);
+if (open_flags BDRV_O_NOCACHE)
+monitor_printf(mon, hostcache=false);
+else
+monitor_printf(mon, hostcache=true);
+}
+
if (qdict_haskey(bs_dict, inserted)) {
QDict *qdict = qobject_to_qdict(qdict_get(bs_dict, inserted));
@@ -1730,13 +1738,18 @@ void bdrv_info(Monitor *mon, QObject **r
QObject *bs_obj;
bs_obj = qobject_from_jsonf({ 'device': %s, 'type': 'unknown',
-'removable': %i, 'locked': %i },
-bs-device_name, bs-removable,
-bs-locked);
+ 'removable': %i, 'locked': %i,
+ 'hostcache': %s },
+ bs-device_name, bs-removable,
+ bs-locked,
+ (bs-open_flags BDRV_O_NOCACHE) ?
+ false : true);
+
+QDict *bs_dict = qobject_to_qdict(bs_obj);
+qdict_put(bs_dict, open_flags, qint_from_int(bs-open_flags));
if (bs-drv) {
QObject *obj;
-QDict *bs_dict = qobject_to_qdict(bs_obj);
obj = qobject_from_jsonf({ 'file': %s, 'ro': %i, 'drv': %s,
'encrypted': %i },
Index: qemu/qmp-commands.hx
===
--- qemu.orig/qmp-commands.hx
+++ qemu/qmp-commands.hx
@@ -1070,6 +1070,7 @@ Each json-object contain the following:
- Possible values: unknown
- removable: true if the device is removable, false otherwise (json-bool)
- locked: true if the device is locked, false otherwise (json-bool)
+- hostcache: true if hostcache enabled, 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)
@@ -1091,6 +1092,7 @@ Example:
{
device:ide0-hd0,
locked:false,
+hostcache:false,
removable:false,
inserted:{
ro:false,
[Qemu-devel] [V4 Patch 2/4]Qemu: Error classes for file reopen and data sync failure
New error classes defined for cases where device not inserted
and file reopen failed.
Signed-off-by: Supriya Kannery supri...@in.ibm.com
---
qerror.c |8
qerror.h |6 ++
2 files changed, 14 insertions(+)
Index: qemu/qerror.c
===
--- qemu.orig/qerror.c
+++ qemu/qerror.c
@@ -97,6 +97,14 @@ static const QErrorStringTable qerror_ta
.desc = Device '%(device)' is not removable,
},
{
+.error_fmt = QERR_DATA_SYNC_FAILED,
+.desc = Syncing of data failed for device '%(device)',
+},
+{
+.error_fmt = QERR_REOPEN_FILE_FAILED,
+.desc = Could not reopen '%(filename)',
+},
+{
.error_fmt = QERR_DEVICE_NO_BUS,
.desc = Device '%(device)' has no child bus,
},
Index: qemu/qerror.h
===
--- qemu.orig/qerror.h
+++ qemu/qerror.h
@@ -85,6 +85,9 @@ QError *qobject_to_qerror(const QObject
#define QERR_DEVICE_NOT_FOUND \
{ 'class': 'DeviceNotFound', 'data': { 'device': %s } }
+#define QERR_DATA_SYNC_FAILED \
+{ 'class': 'DataSyncFailed', 'data': { 'device': %s } }
+
#define QERR_DEVICE_NOT_REMOVABLE \
{ 'class': 'DeviceNotRemovable', 'data': { 'device': %s } }
@@ -139,6 +142,9 @@ QError *qobject_to_qerror(const QObject
#define QERR_OPEN_FILE_FAILED \
{ 'class': 'OpenFileFailed', 'data': { 'filename': %s } }
+#define QERR_REOPEN_FILE_FAILED \
+{ 'class': 'ReopenFileFailed', 'data': { 'filename': %s } }
+
#define QERR_PROPERTY_NOT_FOUND \
{ 'class': 'PropertyNotFound', 'data': { 'device': %s, 'property': %s } }
Re: [Qemu-devel] [PATCH v7 03/12] VMDK: probe for monolithicFlat images
Am 03.07.2011 17:06, schrieb Fam Zheng:
Probe as the same behavior as VMware does.
Recognize image as monolithicFlat descriptor file when the file is text
and the first effective line (not '#' leaded comment or space line) is
either 'version=1' or 'version=2'. No space or upper case charactors
accepted.
Signed-off-by: Fam Zheng famc...@gmail.com
---
block/vmdk.c | 44 ++--
1 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/block/vmdk.c b/block/vmdk.c
index 03a4619..05a58db 100644
--- a/block/vmdk.c
+++ b/block/vmdk.c
@@ -103,10 +103,50 @@ static int vmdk_probe(const uint8_t *buf, int buf_size,
const char *filename)
return 0;
magic = be32_to_cpu(*(uint32_t *)buf);
if (magic == VMDK3_MAGIC ||
-magic == VMDK4_MAGIC)
+magic == VMDK4_MAGIC) {
return 100;
-else
+} else {
+const char *p = (const char *)buf;
+const char *end = p + buf_size;
+while (p end) {
+if (*p == '#') {
+/* skip comment line */
+while (p end *p != '\n') {
+p++;
+}
+p++;
+continue;
+}
+if (*p == ' ') {
+while (p end *p == ' ') {
+p++;
+}
+/* skip '\r' if windows line endings used. */
+if (p end *p == '\r') {
+p++;
+}
+/* only accept blank lines before 'version=' line */
+if (p == end || *p != '\n') {
+return 0;
+}
+p++;
+continue;
+}
+if (end - p = strlen(version=X\n)) {
+if (strncmp(version=1\n, p, strlen(version=1\n)) == 0 ||
+strncmp(version=2\n, p, strlen(version=2\n)) == 0) {
+return 100;
+}
+}
+if (end - p = strlen(version=X\r\n)) {
+if (strncmp(version=1\r\n, p, strlen(version=1\r\n)) ==
0 ||
+strncmp(version=2\r\n, p, strlen(version=2\r\n)) ==
0) {
+return 100;
+}
+}
I think you may want to insert something right here. :-)
This code (actually v6, but it doesn't seem to have changed) gives my an
endless loop in vmdk_probe when trying to open a qcow2 image. So
something might be p++ or probably just return 0;
Kevin
+}
return 0;
+}
}
#define CHECK_CID 1
[Qemu-devel] [V4 Patch 0/4]Qemu: Hostcache setting from cmdline and monitor
Currently cache setting of a block device cannot be changed without restarting a running VM. Following patchset is for enabling dynamic change of cache setting for block devices through qemu monitor. Code changes are based on patches from Christoph Hellwig and Prerna Saxena. This patchset introduces monitor command 'block_set' using which various parameters for block devices can be changed dynamically. Dynamic changing of host cache setting is implemented for now. This patchset also introduces 'hostcache', a new option for setting host cache from qemu command line. 'Hostcache and 'cache' options cannot be used simultaneously from commandline. Changes from patchset V3: 1. Added 'hostcache' option to '-drive' commandline option. New block command added: block_set -- Sets block device parameters while guest is running. Usage: block_set device param value device = block device param = parameter (say, hostcache) value = on/off New 'hostcache' option added to -drive: -drive [file=file][,if=type][,bus=n][,unit=m][,media=d][,index=i]\n [,readonly=on|off][,hostcache=on|off]\n 1/4 Enhance info block to display hostcache setting 2/4 New error classes for file reopen and device insertion 3/4 Command block_set for dynamic params change for block device 4/4 'hostcache' option added to -drive in qemu commandline qemu/block.c | 73 +++ qemu/block.h |2 + qemu/blockdev.c | 43 +++ qemu/blockdev.h |1 qemu/hmp-commands.hx | 15 ++ qemu/qemu-config.c |4 +++ qemu/qemu-options.hx |2 - qemu/qemu.pod|5 qemu/qerror.c|8 +++ qemu/qerror.h|6 + qemu/qmp-commands.hx | 30 +++ 11 files changed, 184 insertions(+), 5 deletions(-)
[Qemu-devel] [V4 Patch 3/4]Qemu: Command block_set for dynamic block params change
New command block_set added for dynamically changing any of the block
device parameters. For now, dynamic setting of hostcache params using this
command is implemented. Other block device parameters, can be integrated
in similar lines.
Signed-off-by: Supriya Kannery supri...@in.ibm.com
---
block.c | 52
block.h |2 ++
blockdev.c | 26 ++
blockdev.h |1 +
hmp-commands.hx | 15 +++
qmp-commands.hx | 28
6 files changed, 124 insertions(+)
Index: qemu/block.c
===
--- qemu.orig/block.c
+++ qemu/block.c
@@ -651,6 +651,32 @@ unlink_and_fail:
return ret;
}
+int bdrv_reopen(BlockDriverState *bs, int bdrv_flags)
+{
+BlockDriver *drv = bs-drv;
+int ret = 0;
+
+/* Quiesce IO for the given block device */
+qemu_aio_flush();
+if (bdrv_flush(bs)) {
+qerror_report(QERR_DATA_SYNC_FAILED, bs-device_name);
+return ret;
+}
+bdrv_close(bs);
+
+ret = bdrv_open(bs, bs-filename, bdrv_flags, drv);
+
+/*
+ * A failed attempt to reopen the image file must lead to 'abort()'
+*/
+if (ret != 0) {
+qerror_report(QERR_REOPEN_FILE_FAILED, bs-filename);
+abort();
+}
+
+return ret;
+}
+
void bdrv_close(BlockDriverState *bs)
{
if (bs-drv) {
@@ -691,6 +717,32 @@ void bdrv_close_all(void)
}
}
+int bdrv_change_hostcache(BlockDriverState *bs, bool enable_host_cache)
+{
+int bdrv_flags = bs-open_flags;
+
+/* set hostcache flags (without changing WCE/flush bits) */
+if (enable_host_cache) {
+bdrv_flags = ~BDRV_O_NOCACHE;
+} else {
+bdrv_flags |= BDRV_O_NOCACHE;
+}
+
+/* If no change in flags, no need to reopen */
+if (bdrv_flags == bs-open_flags) {
+return 0;
+}
+
+if (bdrv_is_inserted(bs)) {
+/* Reopen file with changed set of flags */
+return bdrv_reopen(bs, bdrv_flags);
+} else {
+/* Save hostcache change for future use */
+bs-open_flags = bdrv_flags;
+return 0;
+}
+}
+
/* make a BlockDriverState anonymous by removing from bdrv_state list.
Also, NULL terminate the device_name to prevent double remove */
void bdrv_make_anon(BlockDriverState *bs)
Index: qemu/block.h
===
--- qemu.orig/block.h
+++ qemu/block.h
@@ -71,6 +71,7 @@ void bdrv_delete(BlockDriverState *bs);
int bdrv_file_open(BlockDriverState **pbs, const char *filename, int flags);
int bdrv_open(BlockDriverState *bs, const char *filename, int flags,
BlockDriver *drv);
+int bdrv_reopen(BlockDriverState *bs, int bdrv_flags);
void bdrv_close(BlockDriverState *bs);
int bdrv_attach(BlockDriverState *bs, DeviceState *qdev);
void bdrv_detach(BlockDriverState *bs, DeviceState *qdev);
@@ -96,6 +97,7 @@ void bdrv_commit_all(void);
int bdrv_change_backing_file(BlockDriverState *bs,
const char *backing_file, const char *backing_fmt);
void bdrv_register(BlockDriver *bdrv);
+int bdrv_change_hostcache(BlockDriverState *bs, bool enable_host_cache);
typedef struct BdrvCheckResult {
Index: qemu/blockdev.c
===
--- qemu.orig/blockdev.c
+++ qemu/blockdev.c
@@ -797,3 +797,29 @@ int do_block_resize(Monitor *mon, const
return 0;
}
+
+
+/*
+ * Handle changes to block device settings, like hostcache,
+ * while guest is running.
+*/
+int do_block_set(Monitor *mon, const QDict *qdict, QObject **ret_data)
+{
+const char *device = qdict_get_str(qdict, device);
+const char *name = qdict_get_str(qdict, name);
+int enable = qdict_get_bool(qdict, enable);
+BlockDriverState *bs;
+
+bs = bdrv_find(device);
+if (!bs) {
+qerror_report(QERR_DEVICE_NOT_FOUND, device);
+return -1;
+}
+
+if (!strcmp(name, hostcache)) {
+return bdrv_change_hostcache(bs, enable);
+}
+
+return 0;
+}
+
Index: qemu/blockdev.h
===
--- qemu.orig/blockdev.h
+++ qemu/blockdev.h
@@ -65,5 +65,6 @@ int do_change_block(Monitor *mon, const
int do_drive_del(Monitor *mon, const QDict *qdict, QObject **ret_data);
int do_snapshot_blkdev(Monitor *mon, const QDict *qdict, QObject **ret_data);
int do_block_resize(Monitor *mon, const QDict *qdict, QObject **ret_data);
+int do_block_set(Monitor *mon, const QDict *qdict, QObject **ret_data);
#endif
Index: qemu/hmp-commands.hx
===
--- qemu.orig/hmp-commands.hx
+++ qemu/hmp-commands.hx
@@ -70,6 +70,21 @@ but should be used with extreme caution.
resizes image files, it can not resize block devices like LVM volumes.
ETEXI
+{
+.name = block_set,
+.args_type = device:B,name:s,enable:b,
+
[Qemu-devel] [V4 Patch 4/4]Qemu: Add commandline -drive option 'hostcache'
qemu command option 'hostcache' added to -drive for block devices.
While starting a VM from qemu commandline, this option can be used
for setting host cache usage for block data access. It is not
allowed to specify both 'hostcache' and 'cache' options in the same
commandline. User has to specify only one among these.
Signed-off-by: Supriya Kannery supri...@in.ibm.com
---
blockdev.c | 17 +
qemu-config.c |4
qemu-options.hx |2 +-
qemu.pod|5 +
4 files changed, 27 insertions(+), 1 deletion(-)
Index: qemu/blockdev.c
===
--- qemu.orig/blockdev.c
+++ qemu/blockdev.c
@@ -238,6 +238,7 @@ DriveInfo *drive_init(QemuOpts *opts, in
DriveInfo *dinfo;
int snapshot = 0;
int ret;
+bool option_hostcache = false;
translation = BIOS_ATA_TRANSLATION_AUTO;
@@ -324,7 +325,23 @@ DriveInfo *drive_init(QemuOpts *opts, in
}
}
+if ((buf = qemu_opt_get(opts, hostcache)) != NULL) {
+if (!strcmp(buf, off)) {
+bdrv_flags |= BDRV_O_NOCACHE;
+} else if (!strcmp(buf, on)) {
+bdrv_flags = ~BDRV_O_NOCACHE;
+} else {
+error_report(invalid hostcache option);
+return NULL;
+}
+option_hostcache = true;
+}
+
if ((buf = qemu_opt_get(opts, cache)) != NULL) {
+if (option_hostcache) {
+error_report('hostcache' and 'cache' cannot co-exist);
+return NULL;
+}
if (!strcmp(buf, off) || !strcmp(buf, none)) {
bdrv_flags |= BDRV_O_NOCACHE | BDRV_O_CACHE_WB;
} else if (!strcmp(buf, writeback)) {
Index: qemu/qemu-options.hx
===
--- qemu.orig/qemu-options.hx
+++ qemu/qemu-options.hx
@@ -120,7 +120,7 @@ DEF(drive, HAS_ARG, QEMU_OPTION_drive,
[,cyls=c,heads=h,secs=s[,trans=t]][,snapshot=on|off]\n
[,cache=writethrough|writeback|none|unsafe][,format=f]\n
[,serial=s][,addr=A][,id=name][,aio=threads|native]\n
- [,readonly=on|off]\n
+ [,readonly=on|off][,hostcache=on|off]\n
use 'file' as a drive image\n, QEMU_ARCH_ALL)
STEXI
@item -drive @var{option}[,@var{option}[,@var{option}[,...]]]
Index: qemu/qemu-config.c
===
--- qemu.orig/qemu-config.c
+++ qemu/qemu-config.c
@@ -78,6 +78,10 @@ static QemuOptsList qemu_drive_opts = {
},{
.name = readonly,
.type = QEMU_OPT_BOOL,
+},{
+.name = hostcache,
+.type = QEMU_OPT_BOOL,
+.help = set or reset hostcache (on/off)
},
{ /* end of list */ }
},
Index: qemu/qemu.pod
===
--- qemu.orig/qemu.pod
+++ qemu/qemu.pod
@@ -226,6 +226,11 @@ Isnapshot is on or off and allows
Icache is none, writeback, unsafe, or writethrough and controls how
the host cache is used to access block data.
+=item Bhostcache=Ihostcache
+
+Ihostcache is on or off and allows to enable or disable hostcache while
accessing block data.
+Both 'cache=' and 'hostcache=' should not used in same command line. Use only
one among them.
+
=item Baio=Iaio
Iaio is threads, or native and selects between pthread based disk I/O
and native Linux AIO.
[Qemu-devel] [PATCH] qxl: make sure primary surface is saved on migration
---
hw/qxl.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/hw/qxl.c b/hw/qxl.c
index 2bb36c6..9fdeffb 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -1165,11 +1165,14 @@ static void qxl_vm_change_state_handler(void *opaque,
int running, int reason)
qemu_spice_vm_change_state_handler(qxl-ssd, running, reason);
if (!running qxl-mode == QXL_MODE_NATIVE) {
-/* dirty all vram (which holds surfaces) to make sure it is saved */
+/* dirty all vram (which holds surfaces) and devram (primary surface)
+ * to make sure they are saved */
/* FIXME #1: should go out during live stage */
/* FIXME #2: we only need to save the areas which are actually used */
-ram_addr_t addr = qxl-vram_offset;
-qxl_set_dirty(addr, addr + qxl-vram_size);
+ram_addr_t vram_addr = qxl-vram_offset;
+ram_addr_t devram_addr = qxl-vga.vram_offset;
+qxl_set_dirty(vram_addr, vram_addr + qxl-vram_size);
+qxl_set_dirty(devram_addr, devram_addr + qxl-vga.vram_size);
}
}
--
1.7.4.4
Re: [Qemu-devel] [PATCH] qxl: make sure primary surface is saved on migration
Hi, +qxl_set_dirty(devram_addr, devram_addr + qxl-vga.vram_size); It is enougth to dirty the surface0 area. Otherwise the patch looks fine. cheers, Gerd
[Qemu-devel] [PATCHv2] qxl: make sure primary surface is saved on migration
---
hw/qxl.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/hw/qxl.c b/hw/qxl.c
index 2bb36c6..cff95a4 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -1165,11 +1165,14 @@ static void qxl_vm_change_state_handler(void *opaque,
int running, int reason)
qemu_spice_vm_change_state_handler(qxl-ssd, running, reason);
if (!running qxl-mode == QXL_MODE_NATIVE) {
-/* dirty all vram (which holds surfaces) to make sure it is saved */
+/* dirty all vram (which holds surfaces) and devram (primary surface)
+ * to make sure they are saved */
/* FIXME #1: should go out during live stage */
/* FIXME #2: we only need to save the areas which are actually used */
-ram_addr_t addr = qxl-vram_offset;
-qxl_set_dirty(addr, addr + qxl-vram_size);
+ram_addr_t vram_addr = qxl-vram_offset;
+ram_addr_t devram_addr = qxl-vga.vram_offset;
+qxl_set_dirty(vram_addr, vram_addr + qxl-vram_size);
+qxl_set_dirty(devram_addr, devram_addr + qxl-rom-surface0_area_size);
}
}
--
1.7.4.4
Re: [Qemu-devel] [PATCH] virtio-blk: Turn drive serial into a qdev property
Kevin Wolf kw...@redhat.com writes:
Am 20.06.2011 11:35, schrieb Markus Armbruster:
It needs to be a qdev property, because it belongs to the drive's
guest part. Precedence: commit a0fef654 and 6ced55a5.
Bonus: info qtree now shows the serial number.
Signed-off-by: Markus Armbruster arm...@redhat.com
---
hw/s390-virtio-bus.c |4 +++-
hw/s390-virtio-bus.h |1 +
hw/virtio-blk.c | 29 +++--
hw/virtio-blk.h |2 ++
hw/virtio-pci.c |4 +++-
hw/virtio-pci.h |1 +
hw/virtio.h |3 ++-
7 files changed, 31 insertions(+), 13 deletions(-)
diff --git a/hw/s390-virtio-bus.c b/hw/s390-virtio-bus.c
index d4a12f7..2bf4821 100644
--- a/hw/s390-virtio-bus.c
+++ b/hw/s390-virtio-bus.c
@@ -128,7 +128,8 @@ static int s390_virtio_blk_init(VirtIOS390Device *dev)
{
VirtIODevice *vdev;
-vdev = virtio_blk_init((DeviceState *)dev, dev-block);
+vdev = virtio_blk_init((DeviceState *)dev, dev-block,
+ dev-block_serial);
if (!vdev) {
return -1;
}
@@ -355,6 +356,7 @@ static VirtIOS390DeviceInfo s390_virtio_blk = {
.qdev.size = sizeof(VirtIOS390Device),
.qdev.props = (Property[]) {
DEFINE_BLOCK_PROPERTIES(VirtIOS390Device, block),
+DEFINE_PROP_STRING(serial, VirtIOS390Device, block_serial),
DEFINE_PROP_END_OF_LIST(),
},
};
diff --git a/hw/s390-virtio-bus.h b/hw/s390-virtio-bus.h
index 0c412d0..f1bece7 100644
--- a/hw/s390-virtio-bus.h
+++ b/hw/s390-virtio-bus.h
@@ -42,6 +42,7 @@ typedef struct VirtIOS390Device {
uint8_t feat_len;
VirtIODevice *vdev;
BlockConf block;
+char *block_serial;
NICConf nic;
uint32_t host_features;
virtio_serial_conf serial;
diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
index 91e0394..6471ac8 100644
--- a/hw/virtio-blk.c
+++ b/hw/virtio-blk.c
@@ -28,8 +28,8 @@ typedef struct VirtIOBlock
void *rq;
QEMUBH *bh;
BlockConf *conf;
+char *serial;
unsigned short sector_mask;
-char sn[BLOCK_SERIAL_STRLEN];
DeviceState *qdev;
} VirtIOBlock;
@@ -362,8 +362,13 @@ static void virtio_blk_handle_request(VirtIOBlockReq
*req,
} else if (type VIRTIO_BLK_T_GET_ID) {
VirtIOBlock *s = req-dev;
-memcpy(req-elem.in_sg[0].iov_base, s-sn,
- MIN(req-elem.in_sg[0].iov_len, sizeof(s-sn)));
+/*
+ * NB: per existing s/n string convention the string is
+ * terminated by '\0' only when shorter than buffer.
+ */
+strncpy(req-elem.in_sg[0].iov_base,
+s-serial ? s-serial : ,
+MIN(req-elem.in_sg[0].iov_len, VIRTIO_BLK_ID_BYTES));
Not sure what you're trying to do with VIRTIO_BLK_ID_BYTES here.
s-string either is dinfo-serial, in which case it happens to be the
You mean s-serial, don't you?
same as BLOCK_SERIAL_STRLEN and as such makes some sense. Or it may be a
qdev property, in which case the string just has the length it has. Or
it's the empty string. So I think in two of three cases you're
potentially reading beyond the end of the buffer.
I can't see that.
strncpy(dst, src, n) reads up to n characters or the terminating zero,
whatever comes first.
strncpy()'s second argument is zero-terminated. trivially is.
s-serial is a malloc'ed, zero-terminated string. It's set either by
qdev_prop_string's parse_string(), or two patch hunks down (some snipped
text restored for your convenience). In both cases, the value is
freshly strdup'ed. Therefore, strncpy() won't read beyond the buffer.
strncpy(dst, src, n) writes exactly n characters.
Its third argument is the minimum of the buffer size and
VIRTIO_BLK_ID_BYTES.
The old code works the same, only it uses sizeof(s-sn) instead of
VIRTIO_BLK_ID_BYTES, with sn defined as char sn[BLOCK_SERIAL_STRLEN].
VIRTIO_BLK_ID_BYTES is really part of the virtio protocol. Its value
indeed happens to be the same as BLOCK_SERIAL_STRLEN, but I chose not to
rely on that. Matches IDE and SCSI, only they use literals instead of
defines.
The kernel has it in include/linux/virtio_blk.h. Our partial copy of
that header is hw/virtio-blk.h. I added VIRTIO_BLK_ID_BYTES to that
copy (four patch hunks down).
@@ -531,7 +536,8 @@ static void virtio_blk_change_cb(void *opaque, int
reason)
}
}
-VirtIODevice *virtio_blk_init(DeviceState *dev, BlockConf *conf)
+VirtIODevice *virtio_blk_init(DeviceState *dev, BlockConf *conf,
+ char **serial)
{
VirtIOBlock *s;
int cylinders, heads, secs;
@@ -547,6 +553,14 @@ VirtIODevice *virtio_blk_init(DeviceState *dev,
BlockConf *conf)
return NULL;
}
+if (!*serial) {
+/* try to fall back to value set with legacy -drive serial=... */
+dinfo = drive_get_by_blockdev(conf-bs);
+if (*dinfo-serial) {
+*serial =
Re: [Qemu-devel] [PATCH v2 0/2]: block: Small drive_init() improvements
Luiz Capitulino lcapitul...@redhat.com writes: Please, see individual patches for details. v1 - v2: - o Drop indentation patch o Use error message suggested by Markus blockdev.c | 14 +- 1 files changed, 5 insertions(+), 9 deletions(-) Reviewed-by: Markus Armbruster arm...@redhat.com
Re: [Qemu-devel] [PATCHv2] qxl: make sure primary surface is saved on migration
Hi, +qxl_set_dirty(devram_addr, devram_addr + qxl-rom-surface0_area_size); s/rom/shadow_rom/, then it is perfect. rom points directly to guest memory, better don't trust that. cheers, Gerd
Re: [Qemu-devel] [V4 Patch 1/4]Qemu: Enhance info block to display host cache setting
On Mon, Jul 4, 2011 at 11:42 AM, Supriya Kannery supri...@linux.vnet.ibm.com wrote: Enhance info block to display hostcache setting for each block device. Example: (qemu) info block ide0-hd0: type=hd removable=0 file=../rhel6-32.qcow2 ro=0 drv=qcow2 encrypted=0 Enhanced to display hostcache setting: (qemu) info block ide0-hd0: type=hd removable=0 hostcache=true file=../rhel6-32.qcow2 ro=0 drv=qcow2 encrypted=0 The other boolean options use 0 or 1. Please use the same HMP output for consistency. For QMP the true/false output is good (it's JSON). Stefan
Re: [Qemu-devel] [PATCH] virtio-blk: Turn drive serial into a qdev property
Am 04.07.2011 13:29, schrieb Markus Armbruster:
Kevin Wolf kw...@redhat.com writes:
Am 20.06.2011 11:35, schrieb Markus Armbruster:
It needs to be a qdev property, because it belongs to the drive's
guest part. Precedence: commit a0fef654 and 6ced55a5.
Bonus: info qtree now shows the serial number.
Signed-off-by: Markus Armbruster arm...@redhat.com
---
hw/s390-virtio-bus.c |4 +++-
hw/s390-virtio-bus.h |1 +
hw/virtio-blk.c | 29 +++--
hw/virtio-blk.h |2 ++
hw/virtio-pci.c |4 +++-
hw/virtio-pci.h |1 +
hw/virtio.h |3 ++-
7 files changed, 31 insertions(+), 13 deletions(-)
diff --git a/hw/s390-virtio-bus.c b/hw/s390-virtio-bus.c
index d4a12f7..2bf4821 100644
--- a/hw/s390-virtio-bus.c
+++ b/hw/s390-virtio-bus.c
@@ -128,7 +128,8 @@ static int s390_virtio_blk_init(VirtIOS390Device *dev)
{
VirtIODevice *vdev;
-vdev = virtio_blk_init((DeviceState *)dev, dev-block);
+vdev = virtio_blk_init((DeviceState *)dev, dev-block,
+ dev-block_serial);
if (!vdev) {
return -1;
}
@@ -355,6 +356,7 @@ static VirtIOS390DeviceInfo s390_virtio_blk = {
.qdev.size = sizeof(VirtIOS390Device),
.qdev.props = (Property[]) {
DEFINE_BLOCK_PROPERTIES(VirtIOS390Device, block),
+DEFINE_PROP_STRING(serial, VirtIOS390Device, block_serial),
DEFINE_PROP_END_OF_LIST(),
},
};
diff --git a/hw/s390-virtio-bus.h b/hw/s390-virtio-bus.h
index 0c412d0..f1bece7 100644
--- a/hw/s390-virtio-bus.h
+++ b/hw/s390-virtio-bus.h
@@ -42,6 +42,7 @@ typedef struct VirtIOS390Device {
uint8_t feat_len;
VirtIODevice *vdev;
BlockConf block;
+char *block_serial;
NICConf nic;
uint32_t host_features;
virtio_serial_conf serial;
diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
index 91e0394..6471ac8 100644
--- a/hw/virtio-blk.c
+++ b/hw/virtio-blk.c
@@ -28,8 +28,8 @@ typedef struct VirtIOBlock
void *rq;
QEMUBH *bh;
BlockConf *conf;
+char *serial;
unsigned short sector_mask;
-char sn[BLOCK_SERIAL_STRLEN];
DeviceState *qdev;
} VirtIOBlock;
@@ -362,8 +362,13 @@ static void virtio_blk_handle_request(VirtIOBlockReq
*req,
} else if (type VIRTIO_BLK_T_GET_ID) {
VirtIOBlock *s = req-dev;
-memcpy(req-elem.in_sg[0].iov_base, s-sn,
- MIN(req-elem.in_sg[0].iov_len, sizeof(s-sn)));
+/*
+ * NB: per existing s/n string convention the string is
+ * terminated by '\0' only when shorter than buffer.
+ */
+strncpy(req-elem.in_sg[0].iov_base,
+s-serial ? s-serial : ,
+MIN(req-elem.in_sg[0].iov_len, VIRTIO_BLK_ID_BYTES));
Not sure what you're trying to do with VIRTIO_BLK_ID_BYTES here.
s-string either is dinfo-serial, in which case it happens to be the
You mean s-serial, don't you?
same as BLOCK_SERIAL_STRLEN and as such makes some sense. Or it may be a
qdev property, in which case the string just has the length it has. Or
it's the empty string. So I think in two of three cases you're
potentially reading beyond the end of the buffer.
I can't see that.
You're right, sorry for the noise.
What confused me is that I didn't expect some limit in the protocol (and
if any, then certainly not 20), so I started making wild guesses what
this might be used for, and reading strncpy as memcpy because it made
more sense with the guesses...
I should just stop reviewing patches early in the morning. :-)
Applied the patch to the block branch.
Kevin
Re: [Qemu-devel] [V4 Patch 3/4]Qemu: Command block_set for dynamic block params change
On Mon, Jul 4, 2011 at 11:43 AM, Supriya Kannery
supri...@linux.vnet.ibm.com wrote:
+/*
+ * Handle changes to block device settings, like hostcache,
+ * while guest is running.
+*/
+int do_block_set(Monitor *mon, const QDict *qdict, QObject **ret_data)
+{
+ const char *device = qdict_get_str(qdict, device);
+ const char *name = qdict_get_str(qdict, name);
+ int enable = qdict_get_bool(qdict, enable);
+ BlockDriverState *bs;
+
+ bs = bdrv_find(device);
+ if (!bs) {
+ qerror_report(QERR_DEVICE_NOT_FOUND, device);
+ return -1;
+ }
+
+ if (!strcmp(name, hostcache)) {
+ return bdrv_change_hostcache(bs, enable);
+ }
+
+ return 0;
No error for unknown name argument?
#endif
Index: qemu/hmp-commands.hx
===
--- qemu.orig/hmp-commands.hx
+++ qemu/hmp-commands.hx
@@ -70,6 +70,21 @@ but should be used with extreme caution.
resizes image files, it can not resize block devices like LVM volumes.
ETEXI
+ {
+ .name = block_set,
+ .args_type = device:B,name:s,enable:b,
+ .params = device name enable,
+ .help = On/Off block device parameters like hostcache,
+ .user_print = monitor_user_noop,
+ .mhandler.cmd_new = do_block_set,
+ },
+
+STEXI
+@item block_set
+@findex block_set
+Change block device params (eg:hostcache=on/off) while guest is running.
+ETEXI
See QMP comments below.
+
{
.name = eject,
Index: qemu/qmp-commands.hx
===
--- qemu.orig/qmp-commands.hx
+++ qemu/qmp-commands.hx
@@ -694,6 +694,34 @@ Example:
EQMP
{
+ .name = block_set,
+ .args_type = device:B,name:s,enable:b,
+ .params = device name enable,
Perhaps:
.args_type = device:B,name:s,enable:b?,
.params = device name [enable],
But I am not sure what the best way to express this is.
+ .help = Enable/Disable block device params like hostcache,
Arguments (like enable) should depend on the block parameter that is
being set:
.help = Set block device parameter
If there is no good way to support different optional arguments and
types then a json-string value argument would be best.
+ .user_print = monitor_user_noop,
+ .mhandler.cmd_new = do_block_set,
+ },
+
+SQMP
+block_set
+-
+
+Change various block device parameters like hostcache.
+
+Arguments:
+
+- device: the device's ID, must be unique (json-string)
+- name: name of the parameter to be changed (json-string)
Trailing ''.
+- enable: value to be set for the parameter, 'true' or 'false' (json-bool)
The relevant arguments depend on which block parameter you are
changing. I think enable should be documented specifically for
hostcache:
Block parameters:
- hostcache: Enable/disable host buffer cache
- enable: 'true' or 'false' (json-bool)
Stefan
[Qemu-devel] [PATCHv3] qxl: make sure primary surface is saved on migration
---
hw/qxl.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/hw/qxl.c b/hw/qxl.c
index 2bb36c6..b3a3507 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -1165,11 +1165,14 @@ static void qxl_vm_change_state_handler(void *opaque,
int running, int reason)
qemu_spice_vm_change_state_handler(qxl-ssd, running, reason);
if (!running qxl-mode == QXL_MODE_NATIVE) {
-/* dirty all vram (which holds surfaces) to make sure it is saved */
+/* dirty all vram (which holds surfaces) and devram (primary surface)
+ * to make sure they are saved */
/* FIXME #1: should go out during live stage */
/* FIXME #2: we only need to save the areas which are actually used */
-ram_addr_t addr = qxl-vram_offset;
-qxl_set_dirty(addr, addr + qxl-vram_size);
+ram_addr_t vram_addr = qxl-vram_offset;
+ram_addr_t surface0_addr = qxl-vga.vram_offset +
qxl-shadow_rom.draw_area_offset;
+qxl_set_dirty(vram_addr, vram_addr + qxl-vram_size);
+qxl_set_dirty(surface0_addr, surface0_addr +
qxl-shadow_rom.surface0_area_size);
}
}
--
1.7.4.4
Re: [Qemu-devel] [V4 Patch 4/4]Qemu: Add commandline -drive option 'hostcache'
On Mon, Jul 4, 2011 at 11:43 AM, Supriya Kannery
supri...@linux.vnet.ibm.com wrote:
@@ -324,7 +325,23 @@ DriveInfo *drive_init(QemuOpts *opts, in
}
}
+ if ((buf = qemu_opt_get(opts, hostcache)) != NULL) {
+ if (!strcmp(buf, off)) {
Please use qemu_opt_get_bool().
Stefan
Re: [Qemu-devel] [PATCH v2 0/2]: block: Small drive_init() improvements
Am 01.07.2011 15:46, schrieb Luiz Capitulino: Please, see individual patches for details. v1 - v2: - o Drop indentation patch o Use error message suggested by Markus blockdev.c | 14 +- 1 files changed, 5 insertions(+), 9 deletions(-) Thanks, applied to the block branch. Kevin
Re: [Qemu-devel] Benchmarking activities
Andreas Färber writes: Am 02.07.2011 um 10:32 schrieb Stefan Hajnoczi: On Fri, Jul 1, 2011 at 8:32 PM, Blue Swirl blauwir...@gmail.com wrote: 2011/6/27 Ben Vogler bvog...@toyotatech.com.au: - Are there any inbuilt data tracing features? For example, hardware signal tracing, register monitoring etc. Tracing is quite new addition, so far it's only used for development or debugging QEMU point of view I think. I think you are referring to hardware model debugging and logging. The QEMU tracing mechanism that Blue Swirl mentioned is a DTrace/SystemTap style tool for observing QEMU internals and not what you are looking for. I believe Lluís (cc'ed) has worked on using/extending the trace framework to instrument guests. Yes, the idea is to have a set of generic guest events (e.g., information during instruction fetch, privilege-level change, control flow instructions, etc.) that are target agnostic. This is coupled with the possibility to statically instrument tracing points with user-provided code, so that almost anything can be done with these few basic pieces, ranging from code instrumentation tools a-la PIN, information flow tracking analysis or even cycle-accurate simulations driven by QEMU as the target emulation component. All with a target-agnostic interface that is common to both system-wide and user application functional simulation. I've also modified the timing infrasructure to have a more accurate guest cycle counter that is able to handle a per-vCPU CPI (cycles per instruction), as the current approach in QEMU is not adecuate for cycle-accurate simulations. I've been developing all these changes in small self-contained patches, as my intention is to work towards having these generic pieces integrated into QEMU proper, so that everybody can benefit from that work, as well as avoid having a separate project that will otherwise quickly fall behind QEMU's codebase. What I still haven't decided is whether this generic interface should provide the user with a way to modify the behaviour of the guest, like skipping the execution of QEMU-generated code and instead execute user-provided code to change the semantics of certain instructions without having to hack directly into QEMU. Lluis -- And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer. -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth
Re: [Qemu-devel] [PATCH 3/3] megasas: LSI Megaraid SAS emulation
On 07/04/2011 12:29 PM, Paolo Bonzini wrote: On 07/04/2011 09:26 AM, Hannes Reinecke wrote: Cool. Exactly what I need. FWIW, feel free to add my 'Acked-by' to it. Any chance of getting them included? I'm not very tied to pvscsi; I just needed an HBA that is not a joke by modern standards :) to play with the SCSI layer. There may be hope that megasas will come before pvscsi or eliminate the need for it altogether. So, feel free to pick up patches 5-8 from that series. Hmm. My goal was actually to get the megasas HBA emulation upstream. When sticking it behind another set of patches chances are not exactly increasing. However, it would certainly make my life easier. That said, note that scsi-generic does *not* support scatter/gather in that series, so you should still make sure the fallback paths work well. :) In pvscsi I added a qdev property to toggle scatter/gather, it was useful for benchmarking. Have to check. My patchset did, so it should be reasonably easy to port that one to your infrastructure. However, I probably will see to fixup the megasas emulation with the current infrastructure, get that in, and then move over to the iovec infrastructure. But if you promise to merge the iovec infrastructure I'm more than willing to fixup the scsi-generic backend. Just say the word. Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
Re: [Qemu-devel] [PATCH 3/3] megasas: LSI Megaraid SAS emulation
On 07/04/2011 02:52 PM, Hannes Reinecke wrote: However, I probably will see to fixup the megasas emulation with the current infrastructure, get that in, and then move over to the iovec infrastructure. Makes sense also for ease of review. But if you promise to merge the iovec infrastructure I'm more than willing to fixup the scsi-generic backend. I am certainly going to get it upstream, but maintainers would like it to have users at the time it is committed. Paolo
Re: [Qemu-devel] [V4 Patch 3/4]Qemu: Command block_set for dynamic block params change
On Mon, Jul 4, 2011 at 11:43 AM, Supriya Kannery
supri...@linux.vnet.ibm.com wrote:
+int bdrv_reopen(BlockDriverState *bs, int bdrv_flags)
+{
+ BlockDriver *drv = bs-drv;
+ int ret = 0;
+
+ /* Quiesce IO for the given block device */
+ qemu_aio_flush();
+ if (bdrv_flush(bs)) {
+ qerror_report(QERR_DATA_SYNC_FAILED, bs-device_name);
+ return ret;
+ }
+ bdrv_close(bs);
+
+ ret = bdrv_open(bs, bs-filename, bdrv_flags, drv);
+
+ /*
+ * A failed attempt to reopen the image file must lead to 'abort()'
+ */
+ if (ret != 0) {
+ qerror_report(QERR_REOPEN_FILE_FAILED, bs-filename);
+ abort();
I think it is still worth trying to reopen with the old flags. If you
specialy hostcache=off for a file on tmpfs then the open will fail
(tmpfs doesn't support O_DIRECT), but we can still save ourselves by
reopening with the old flags.
Ideally we'd probably treat this condition just like ENOSPC and keep
the VM paused until the administrator has taken action, and then
retry.
BTW qerror_report() followed by abort(3) does not actually report the
error because we exit before QMP has a chance to send out the error.
Stefan
Re: [Qemu-devel] [PATCHv3] qxl: make sure primary surface is saved on migration
On 07/04/11 14:08, Yonit Halperin wrote: --- hw/qxl.c |9 ++--- 1 files changed, 6 insertions(+), 3 deletions(-) Added to spice patch queue. thanks, Gerd
Re: [Qemu-devel] virtio scsi host draft specification, v3
On 07/01/2011 09:14 AM, Hannes Reinecke wrote:
Actually, the kernel does _not_ do a LUN remapping.
Not the kernel, the in-kernel target. The in-kernel target can and will
map hardware LUNs (target_lun in drivers/target/*) to arbitrary LUNs
(mapped_lun).
Put in another way: the virtio-scsi device is itself a SCSI
target,
Argl. No way. The virtio-scsi device has to map to a single LUN.
I think we are talking about different things. By virtio-scsi device
I meant the virtio-scsi HBA. When I referred to a LUN as seen by the
guest, I was calling it a virtual SCSI device. So yes, we were
calling things with different names. Perhaps from now on
we can call them virtio-scsi {initiator,target,LUN} and have no
ambiguity? I'll also modify the spec in this sense.
The SCSI spec itself only deals with LUNs, so anything you'll read in
there obviously will only handle the interaction between the
initiator (read: host) and the LUN itself. However, the actual
command is send via an intermediat target, hence you'll always see
the reference to the ITL (initiator-target-lun) nexus.
Yes, this I understand.
The SCSI spec details discovery of the individual LUNs presented by a
given target, it does _NOT_ detail the discovery of the targets
themselves. That is being delegated to the underlying transport
And in fact I have this in virtio-scsi too, since virtio-scsi _is_ a
transport:
Oh, here I catch up. I was wondering why there're ordering issues when
talking
about virtio-scsi, since in SAM3, the third and the last paragraph of
section
4.6.3 Request/Response ordering clearly describe it:
The manner in which ordering constraints are established is vendor
specific. An
implementation may delegate this responsibility to the application client
(e.g., the device driver). In-order delivery may be an intrinsic property of
the service delivery subsystem or a requirement established by the SCSI
transport protocol standard.
To simplify the description of behavior, the SCSI architecture model assumes
in-order delivery of requests or responses to be a property of the service
delivery subsystem. This assumption does not constitute a requirement. The
SCSI architecture model makes no assumption about and places no
requirement on
the ordering of requests or responses for different I_T nexuses.
So if I understand correctly, virtio-scsi looks like an SCSI tranport
protocol,
such as iSCSI, FCP and SRP which use tcp/ip, FC and Infiniband RDMA
respectively as the transfer media while virtio-scsi uses virtio, an
virtual IO
channel, as the transfer media?
When VIRTIO_SCSI_EVT_RESET_REMOVED or VIRTIO_SCSI_EVT_RESET_RESCAN
is sent for LUN 0, the driver should ask the initiator to rescan
the target, in order to detect the case when an entire target has
appeared or disappeared.
[If the device fails] to report an event due to missing buffers,
[...] the driver should poll the logical units for unit attention
conditions, and/or do whatever form of bus scan is appropriate for
the guest operating system.
In the case of NPIV it would make sense to map the virtual SCSI host
to the backend, so that all devices presented to the virtual SCSI
host will be presented to the backend, too. However, when doing so
these devices will normally be referenced by their original LUN, as
these will be presented to the guest via eg 'REPORT LUNS'.
Right.
The above thread now tries to figure out if we should remap those LUN
numbers or just expose them as they are. If we decide on remapping,
we have to emulate _all_ commands referring explicitely to those LUN
numbers (persistent reservations, anyone?).
But it seems to me that commands referring explicitly to LUN numbers
most likely have to be reimplemented anyway for virtualization. I'm
thinking exactly of persistent reservations. If two guests on the same
host try a persistent reservation, they should conflict with each other.
If reservation commands were just passed through, they would be seen
as coming from the same initiator (the HBA driver or iSCSI initiator in
the host OS).
etc.
If we don't, we would expose some hardware detail to the guest, but
would save us _a lot_ of processing.
But can we afford it? And would the architecture allow that at all?
Paolo
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] virtio scsi host draft specification, v3
On Mon, Jul 4, 2011 at 2:38 PM, Hai Dong,Li haido...@linux.vnet.ibm.com wrote: So if I understand correctly, virtio-scsi looks like an SCSI tranport protocol, such as iSCSI, FCP and SRP which use tcp/ip, FC and Infiniband RDMA respectively as the transfer media while virtio-scsi uses virtio, an virtual IO channel, as the transfer media? Correct. Stefan
Re: [Qemu-devel] [PATCH V2] [PowerPC][RFC] booke timers
On 01/07/2011 22:22, Scott Wood wrote:
On Fri, 1 Jul 2011 16:13:41 +0200
Fabien Chouteau chout...@adacore.com wrote:
+static void booke_update_fixed_timer(CPUState *env,
+ uint8_t target_bit,
+ uint64_t *next,
+ struct QEMUTimer *timer)
+{
+ppc_tb_t *tb_env = env-tb_env;
+uint64_t lapse;
+uint64_t tb;
+uint64_t period = 1 (target_bit + 1);
+uint64_t now;
+
+now = qemu_get_clock_ns(vm_clock);
+tb = cpu_ppc_get_tb(tb_env, now, tb_env-tb_offset);
+
+if (tb = (1 target_bit)) {
+lapse = (1 target_bit) - tb;
+} else {
+lapse = period - ((tb - (1 target_bit)) % period);
We know period is a power of two, so just do (period - 1).
That should let you get rid of the special case for
tb = (1 target_bit) as well.
Do you mean lapse = period - ((tb - (1 target_bit)) (period - 1)); ?
I don't see how this solves the tb = (1 target_bit) case.
--
Fabien Chouteau
[Qemu-devel] [PATCH 3/9] qxl: set mm_time in vga update
From: Alon Levy al...@redhat.com
This fixes a problem where on windows 7 startup phase, before the qxl driver
is loaded, the drawables are sufficiently large and video like to trigger a
stream, but the lack of a filled mm time field triggers a warning in spice-gtk.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
ui/spice-display.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/ui/spice-display.c b/ui/spice-display.c
index 15f0704..f73 100644
--- a/ui/spice-display.c
+++ b/ui/spice-display.c
@@ -70,6 +70,7 @@ static SimpleSpiceUpdate
*qemu_spice_create_update(SimpleSpiceDisplay *ssd)
QXLCommand *cmd;
uint8_t *src, *dst;
int by, bw, bh;
+struct timespec time_space;
if (qemu_spice_rect_is_empty(ssd-dirty)) {
return NULL;
@@ -96,6 +97,10 @@ static SimpleSpiceUpdate
*qemu_spice_create_update(SimpleSpiceDisplay *ssd)
drawable-surfaces_dest[0] = -1;
drawable-surfaces_dest[1] = -1;
drawable-surfaces_dest[2] = -1;
+clock_gettime(CLOCK_MONOTONIC, time_space);
+/* time in milliseconds from epoch. */
+drawable-mm_time = time_space.tv_sec * 1000
+ + time_space.tv_nsec / 1000 / 1000;
drawable-u.copy.rop_descriptor = SPICE_ROPD_OP_PUT;
drawable-u.copy.src_bitmap = (intptr_t)image;
--
1.7.1
[Qemu-devel] [PULL] spice patch queue
Hi, Here is the spice patch queue with a bunch of small fixes and improvements collected over time. No major changes. please pull, Gerd Alon Levy (5): qxl: set mm_time in vga update qxl: interface_get_command: fix reported mode qxl-logger: add timestamp to command log qxl: add dev id to guest prints qxl: allow QXL_IO_LOG also in vga Gerd Hoffmann (3): qxl: device id fixup spice: catch spice server initialization failures. qxl: put QXL_IO_UPDATE_IRQ into vgamode whitelist Yonit Halperin (1): qxl: make sure primary surface is saved on migration hw/qxl-logger.c|4 +++- hw/qxl.c | 50 ++ ui/spice-core.c|5 - ui/spice-display.c |5 + 4 files changed, 46 insertions(+), 18 deletions(-) The following changes since commit 75ef849696830fc2ddeff8bb90eea5887ff50df6: esp: correctly fill bus id with requested lun (2011-07-02 18:50:19 +) are available in the git repository at: git://anongit.freedesktop.org/spice/qemu spice.v38 Alon Levy (5): qxl: set mm_time in vga update qxl: interface_get_command: fix reported mode qxl-logger: add timestamp to command log qxl: add dev id to guest prints qxl: allow QXL_IO_LOG also in vga Gerd Hoffmann (3): qxl: device id fixup spice: catch spice server initialization failures. qxl: put QXL_IO_UPDATE_IRQ into vgamode whitelist Yonit Halperin (1): qxl: make sure primary surface is saved on migration hw/qxl-logger.c|4 +++- hw/qxl.c | 50 ++ ui/spice-core.c|5 - ui/spice-display.c |5 + 4 files changed, 46 insertions(+), 18 deletions(-)
[Qemu-devel] [PATCH 5/9] qxl-logger: add timestamp to command log
From: Alon Levy al...@redhat.com
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
hw/qxl-logger.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/hw/qxl-logger.c b/hw/qxl-logger.c
index 76f43e6..74cadba 100644
--- a/hw/qxl-logger.c
+++ b/hw/qxl-logger.c
@@ -19,6 +19,7 @@
* along with this program; if not, see http://www.gnu.org/licenses/.
*/
+#include qemu-timer.h
#include qxl.h
static const char *qxl_type[] = {
@@ -223,7 +224,8 @@ void qxl_log_command(PCIQXLDevice *qxl, const char *ring,
QXLCommandExt *ext)
if (!qxl-cmdlog) {
return;
}
-fprintf(stderr, qxl-%d/%s:, qxl-id, ring);
+fprintf(stderr, %ld qxl-%d/%s:, qemu_get_clock_ns(vm_clock),
+qxl-id, ring);
fprintf(stderr, cmd @ 0x% PRIx64 %s%s, ext-cmd.data,
qxl_name(qxl_type, ext-cmd.type),
compat ? (compat) : );
--
1.7.1
[Qemu-devel] [PATCH 4/9] qxl: interface_get_command: fix reported mode
From: Alon Levy al...@redhat.com
report correct mode when in undefined mode.
introduces qxl_mode_to_string(), and uses it in other places too.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
hw/qxl.c | 25 +
1 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/hw/qxl.c b/hw/qxl.c
index e95d6f7..3722f55 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -336,6 +336,21 @@ static void interface_get_init_info(QXLInstance *sin,
QXLDevInitInfo *info)
info-n_surfaces = NUM_SURFACES;
}
+static const char *qxl_mode_to_string(int mode)
+{
+switch (mode) {
+case QXL_MODE_COMPAT:
+return compat;
+case QXL_MODE_NATIVE:
+return native;
+case QXL_MODE_UNDEFINED:
+return undefined;
+case QXL_MODE_VGA:
+return vga;
+}
+return INVALID;
+}
+
/* called from spice server thread context only */
static int interface_get_command(QXLInstance *sin, struct QXLCommandExt *ext)
{
@@ -358,18 +373,19 @@ static int interface_get_command(QXLInstance *sin, struct
QXLCommandExt *ext)
}
qemu_mutex_unlock(qxl-ssd.lock);
if (ret) {
+dprint(qxl, 2, %s %s\n, __FUNCTION__,
qxl_mode_to_string(qxl-mode));
qxl_log_command(qxl, vga, ext);
}
return ret;
case QXL_MODE_COMPAT:
case QXL_MODE_NATIVE:
case QXL_MODE_UNDEFINED:
-dprint(qxl, 2, %s: %s\n, __FUNCTION__,
- qxl-cmdflags ? compat : native);
+dprint(qxl, 4, %s: %s\n, __FUNCTION__,
qxl_mode_to_string(qxl-mode));
ring = qxl-ram-cmd_ring;
if (SPICE_RING_IS_EMPTY(ring)) {
return false;
}
+dprint(qxl, 2, %s: %s\n, __FUNCTION__,
qxl_mode_to_string(qxl-mode));
SPICE_RING_CONS_ITEM(ring, cmd);
ext-cmd = *cmd;
ext-group_id = MEMSLOT_GROUP_GUEST;
@@ -993,7 +1009,7 @@ static void ioport_write(void *opaque, uint32_t addr,
uint32_t val)
break;
case QXL_IO_DESTROY_PRIMARY:
PANIC_ON(val != 0);
-dprint(d, 1, QXL_IO_DESTROY_PRIMARY\n);
+dprint(d, 1, QXL_IO_DESTROY_PRIMARY (%s)\n,
qxl_mode_to_string(d-mode));
qxl_destroy_primary(d);
break;
case QXL_IO_DESTROY_SURFACE_WAIT:
@@ -1368,7 +1384,8 @@ static int qxl_post_load(void *opaque, int version)
d-modes = (QXLModes*)((uint8_t*)d-rom + d-rom-modes_offset);
-dprint(d, 1, %s: restore mode\n, __FUNCTION__);
+dprint(d, 1, %s: restore mode (%s)\n, __FUNCTION__,
+qxl_mode_to_string(d-mode));
newmode = d-mode;
d-mode = QXL_MODE_UNDEFINED;
switch (newmode) {
--
1.7.1
[Qemu-devel] [PATCH 2/9] spice: catch spice server initialization failures.
When the spice server initialization fails report this and exit instead
of ignoring the error.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
ui/spice-core.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/ui/spice-core.c b/ui/spice-core.c
index dd9905b..e142452 100644
--- a/ui/spice-core.c
+++ b/ui/spice-core.c
@@ -602,7 +602,10 @@ void qemu_spice_init(void)
qemu_opt_foreach(opts, add_channel, NULL, 0);
-spice_server_init(spice_server, core_interface);
+if (0 != spice_server_init(spice_server, core_interface)) {
+fprintf(stderr, failed to initialize spice server);
+exit(1);
+};
using_spice = 1;
migration_state.notify = migration_state_notifier;
--
1.7.1
[Qemu-devel] [PATCH 8/9] qxl: put QXL_IO_UPDATE_IRQ into vgamode whitelist
Signed-off-by: Gerd Hoffmann kra...@redhat.com --- hw/qxl.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/hw/qxl.c b/hw/qxl.c index 5e49536..848c90f 100644 --- a/hw/qxl.c +++ b/hw/qxl.c @@ -942,6 +942,7 @@ static void ioport_write(void *opaque, uint32_t addr, uint32_t val) case QXL_IO_MEMSLOT_ADD: case QXL_IO_MEMSLOT_DEL: case QXL_IO_CREATE_PRIMARY: +case QXL_IO_UPDATE_IRQ: break; default: if (d-mode == QXL_MODE_NATIVE || d-mode == QXL_MODE_COMPAT) -- 1.7.1
[Qemu-devel] [PATCH 9/9] qxl: allow QXL_IO_LOG also in vga
From: Alon Levy al...@redhat.com The driver may change us to vga mode and still issue a QXL_IO_LOG, which we can easily support. Signed-off-by: Gerd Hoffmann kra...@redhat.com --- hw/qxl.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/hw/qxl.c b/hw/qxl.c index 848c90f..0b9a4c7 100644 --- a/hw/qxl.c +++ b/hw/qxl.c @@ -943,6 +943,7 @@ static void ioport_write(void *opaque, uint32_t addr, uint32_t val) case QXL_IO_MEMSLOT_DEL: case QXL_IO_CREATE_PRIMARY: case QXL_IO_UPDATE_IRQ: +case QXL_IO_LOG: break; default: if (d-mode == QXL_MODE_NATIVE || d-mode == QXL_MODE_COMPAT) -- 1.7.1
[Qemu-devel] [PATCH 7/9] qxl: make sure primary surface is saved on migration
From: Yonit Halperin yhalp...@redhat.com
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
hw/qxl.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/hw/qxl.c b/hw/qxl.c
index d55b68d..5e49536 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -1184,11 +1184,14 @@ static void qxl_vm_change_state_handler(void *opaque,
int running, int reason)
qemu_spice_vm_change_state_handler(qxl-ssd, running, reason);
if (!running qxl-mode == QXL_MODE_NATIVE) {
-/* dirty all vram (which holds surfaces) to make sure it is saved */
+/* dirty all vram (which holds surfaces) and devram (primary surface)
+ * to make sure they are saved */
/* FIXME #1: should go out during live stage */
/* FIXME #2: we only need to save the areas which are actually used */
-ram_addr_t addr = qxl-vram_offset;
-qxl_set_dirty(addr, addr + qxl-vram_size);
+ram_addr_t vram_addr = qxl-vram_offset;
+ram_addr_t surface0_addr = qxl-vga.vram_offset +
qxl-shadow_rom.draw_area_offset;
+qxl_set_dirty(vram_addr, vram_addr + qxl-vram_size);
+qxl_set_dirty(surface0_addr, surface0_addr +
qxl-shadow_rom.surface0_area_size);
}
}
--
1.7.1
[Qemu-devel] [PATCH 6/9] qxl: add dev id to guest prints
From: Alon Levy al...@redhat.com
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
hw/qxl.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/hw/qxl.c b/hw/qxl.c
index 3722f55..d55b68d 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -985,7 +985,8 @@ static void ioport_write(void *opaque, uint32_t addr,
uint32_t val)
break;
case QXL_IO_LOG:
if (d-guestdebug) {
-fprintf(stderr, qxl/guest: %s, d-ram-log_buf);
+fprintf(stderr, qxl/guest-%d: %ld: %s, d-id,
+qemu_get_clock_ns(vm_clock), d-ram-log_buf);
}
break;
case QXL_IO_RESET:
--
1.7.1
[Qemu-devel] [PATCH 1/9] qxl: device id fixup
Move device ID to PCIDeviceInfo.
Remove support for the unused unstable device ID.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
hw/qxl.c | 11 +++
1 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/hw/qxl.c b/hw/qxl.c
index 16316f2..e95d6f7 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -1207,7 +1207,6 @@ static DisplayChangeListener display_listener = {
static int qxl_init_common(PCIQXLDevice *qxl)
{
uint8_t* config = qxl-pci.config;
-uint32_t pci_device_id;
uint32_t pci_device_rev;
uint32_t io_size;
@@ -1218,20 +1217,14 @@ static int qxl_init_common(PCIQXLDevice *qxl)
switch (qxl-revision) {
case 1: /* spice 0.4 -- qxl-1 */
-pci_device_id = QXL_DEVICE_ID_STABLE;
pci_device_rev = QXL_REVISION_STABLE_V04;
break;
case 2: /* spice 0.6 -- qxl-2 */
-pci_device_id = QXL_DEVICE_ID_STABLE;
+default:
pci_device_rev = QXL_REVISION_STABLE_V06;
break;
-default: /* experimental */
-pci_device_id = QXL_DEVICE_ID_DEVEL;
-pci_device_rev = 1;
-break;
}
-pci_config_set_device_id(config, pci_device_id);
pci_set_byte(config[PCI_REVISION_ID], pci_device_rev);
pci_set_byte(config[PCI_INTERRUPT_PIN], 1);
@@ -1492,6 +1485,7 @@ static PCIDeviceInfo qxl_info_primary = {
.config_write = qxl_write_config,
.romfile = vgabios-qxl.bin,
.vendor_id= REDHAT_PCI_VENDOR_ID,
+.device_id= QXL_DEVICE_ID_STABLE,
.class_id = PCI_CLASS_DISPLAY_VGA,
.qdev.props = (Property[]) {
DEFINE_PROP_UINT32(ram_size, PCIQXLDevice, vga.vram_size, 64 * 1024
* 1024),
@@ -1512,6 +1506,7 @@ static PCIDeviceInfo qxl_info_secondary = {
.qdev.vmsd= qxl_vmstate,
.init = qxl_init_secondary,
.vendor_id= REDHAT_PCI_VENDOR_ID,
+.device_id= QXL_DEVICE_ID_STABLE,
.class_id = PCI_CLASS_DISPLAY_OTHER,
.qdev.props = (Property[]) {
DEFINE_PROP_UINT32(ram_size, PCIQXLDevice, vga.vram_size, 64 * 1024
* 1024),
--
1.7.1
[Qemu-devel] [PATCH 1/2] ide: Ignore reads during PIO in and writes during PIO out
This fixes https://bugs.launchpad.net/qemu/+bug/786209:
When the DRQ_STAT bit is set, the IDE core permits both data reads
and data writes, regardless of whether the current transfer was
initiated as a read or write.
This potentially leaks uninitialized host memory into the guest,
if, before doing anything else to an IDE device, the guest begins a
write transaction (e.g. WIN_WRITE), but then *reads* from the IO
port instead of writing to it.
Signed-off-by: Kevin Wolf kw...@redhat.com
---
hw/ide/core.c | 40
1 files changed, 32 insertions(+), 8 deletions(-)
diff --git a/hw/ide/core.c b/hw/ide/core.c
index ca17a43..2c5395b 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -56,6 +56,7 @@ static const int smart_attributes[][12] = {
};
static int ide_handle_rw_error(IDEState *s, int error, int op);
+static void ide_dummy_transfer_stop(IDEState *s);
static void padstr(char *str, const char *src, int len)
{
@@ -1532,15 +1533,32 @@ void ide_cmd_write(void *opaque, uint32_t addr,
uint32_t val)
bus-cmd = val;
}
+static bool ide_is_pio_out(IDEState *s)
+{
+if (s-end_transfer_func == ide_sector_write ||
+s-end_transfer_func == ide_atapi_cmd) {
+return false;
+} else if (s-end_transfer_func == ide_sector_read ||
+ s-end_transfer_func == ide_transfer_stop ||
+ s-end_transfer_func == ide_atapi_cmd_reply_end ||
+ s-end_transfer_func == ide_dummy_transfer_stop) {
+return true;
+}
+
+abort();
+}
+
void ide_data_writew(void *opaque, uint32_t addr, uint32_t val)
{
IDEBus *bus = opaque;
IDEState *s = idebus_active_if(bus);
uint8_t *p;
-/* PIO data access allowed only when DRQ bit is set */
-if (!(s-status DRQ_STAT))
+/* PIO data access allowed only when DRQ bit is set. The result of a write
+ * during PIO out is indeterminate, just ignore it. */
+if (!(s-status DRQ_STAT) || ide_is_pio_out(s)) {
return;
+}
p = s-data_ptr;
*(uint16_t *)p = le16_to_cpu(val);
@@ -1557,9 +1575,11 @@ uint32_t ide_data_readw(void *opaque, uint32_t addr)
uint8_t *p;
int ret;
-/* PIO data access allowed only when DRQ bit is set */
-if (!(s-status DRQ_STAT))
+/* PIO data access allowed only when DRQ bit is set. The result of a read
+ * during PIO in is indeterminate, return 0 and don't move forward. */
+if (!(s-status DRQ_STAT) || !ide_is_pio_out(s)) {
return 0;
+}
p = s-data_ptr;
ret = cpu_to_le16(*(uint16_t *)p);
@@ -1576,9 +1596,11 @@ void ide_data_writel(void *opaque, uint32_t addr,
uint32_t val)
IDEState *s = idebus_active_if(bus);
uint8_t *p;
-/* PIO data access allowed only when DRQ bit is set */
-if (!(s-status DRQ_STAT))
+/* PIO data access allowed only when DRQ bit is set. The result of a write
+ * during PIO out is indeterminate, just ignore it. */
+if (!(s-status DRQ_STAT) || ide_is_pio_out(s)) {
return;
+}
p = s-data_ptr;
*(uint32_t *)p = le32_to_cpu(val);
@@ -1595,9 +1617,11 @@ uint32_t ide_data_readl(void *opaque, uint32_t addr)
uint8_t *p;
int ret;
-/* PIO data access allowed only when DRQ bit is set */
-if (!(s-status DRQ_STAT))
+/* PIO data access allowed only when DRQ bit is set. The result of a read
+ * during PIO in is indeterminate, return 0 and don't move forward. */
+if (!(s-status DRQ_STAT) || !ide_is_pio_out(s)) {
return 0;
+}
p = s-data_ptr;
ret = cpu_to_le32(*(uint32_t *)p);
--
1.7.6
[Qemu-devel] [PATCH 1/1] usb_register_port(): do not set port-opaque and port-index twice
From: Jes Sorensen jes.soren...@redhat.com
Signed-off-by: Jes Sorensen jes.soren...@redhat.com
---
hw/usb-bus.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/hw/usb-bus.c b/hw/usb-bus.c
index 2abce12..6e082ab 100644
--- a/hw/usb-bus.c
+++ b/hw/usb-bus.c
@@ -145,8 +145,6 @@ void usb_register_port(USBBus *bus, USBPort *port, void
*opaque, int index,
{
port-opaque = opaque;
port-index = index;
-port-opaque = opaque;
-port-index = index;
port-ops = ops;
port-speedmask = speedmask;
QTAILQ_INSERT_TAIL(bus-free, port, next);
--
1.7.4.4
Re: [Qemu-devel] [PATCH2] ppc: provide PIR register on all book-S CPUs
On 04.07.2011, at 17:43, Nathan Whitehorn wrote: On 07/04/11 10:21, Alexander Graf wrote: On 12.06.2011, at 17:50, Nathan Whitehorn wrote: The PIR register is architecturally specified on all PowerPC non-embedded CPUs, but currently is only available on the 604, 620, and G4. Add it to all 601-derived CPUs. Looking through the respective specs, I found the following matrix on PIR support: 601 yes 603e? (no) 604eyes 750 ? (no) 7540yes 970 yes 601 and 750 user manuals don't mention PIR. The overall 32-bit microarchitecture states PIR as optional. So I'd say 750 and 603 simply don't implement it. However, that means it's missing for 970 and 601. Could you please update your patch accordingly? The actual 750 next to my desk has it, at least, but Freescale claims the 603 doesn't. Should I update it for all of the individual CPUs, then, instead of the 6xx patch? If you have actual hardware to verify against, I'd say that overrules specs. But yes, please update it for the individual CPUs :). Alex PS: Please always reply-to-all on mailing list mails unless there's a very good reason not to (personal, nda, ...).
Re: [Qemu-devel] PCI: how handle multifunction / compound devices best?
Anthony Liguori anth...@codemonkey.ws writes: On 07/01/2011 06:27 AM, Gerd Hoffmann wrote: Hi folks, I'm still looking for a sane way to handle multifunction pci devices, specifically a EHCI USB controller with UHCI companion controllers. Here comes a small (incomplete[1]) two patch series to make the issue more clear. The first patch adds a function which creates all devices with the properties set as needed. The second patch adds a '-usb2' switch to windup this in a user-friendly way. Adding a -usb2 switch sucks though. I'd prefer to have some way to create such devices via -device, but without asking the user to create all functions individually on the command line, i.e. have something along the lines of ... qemu -device ich9-usb,slot=08 This is the place where are current infrastructure pretty much stinks. The first problem is that the device factory interface should be involved with device addressing. We really should have: qemu -device ich9-usb,id=uhci0 -set i440fx.slot[8]=uhci0 The device doesn't care what it's PCI slot address is. What exactly would such a split buy us? -device is not a message to the device, it's a message to whatever makes devices. Therefore, the fact that we specify the device address with -device doesn't mean we've artificially made the device to care for its address. [...]
Re: [Qemu-devel] PCI: how handle multifunction / compound devices best?
Gerd Hoffmann kra...@redhat.com writes: Hi folks, I'm still looking for a sane way to handle multifunction pci devices, specifically a EHCI USB controller with UHCI companion controllers. Here comes a small (incomplete[1]) two patch series to make the issue more clear. The first patch adds a function which creates all devices with the properties set as needed. The second patch adds a '-usb2' switch to windup this in a user-friendly way. Adding a -usb2 switch sucks though. I'd prefer to have some way to create such devices via -device, but without asking the user to create all functions individually on the command line, i.e. have something along the lines of ... qemu -device ich9-usb,slot=08 ... instead of ... qemu \ -device ich9-usb-ehci1,addr=08.7,multifunction=on,id=ehci \ -device ich9-usb-uhci1,addr=08.0,multifunction=on,masterbus=ehci.0,firstport=0 \ -device ich9-usb-uhci2,addr=08.1,multifunction=on,masterbus=ehci.0,firstport=2 \ -device ich9-usb-uhci3,addr=08.2,multifunction=on,masterbus=ehci.0,firstport=4 Suggestions? This special case of composition is simple enough that some kind of macro expansion could work. A device defines a name, properties and a bunch of methods. A device macro could define a name, properties (the macro parameters), and an expansion. Expansions could be as simple as a list of -device where the property values can also be macro parameter names. -device MACRO,... could then be replaced by MACRO's expansion with the property values substituted. Use to make -device ich9-usb,... expand into its functions. Just an idea; I'm not claiming this is the way to go. Device macros destroy the 1:1 relationship between -device and device tree nodes. Or rather what's left of it: we already have a device that expands into multiple devices, namely usb-storage. But it's an ad hoc hack, which has caused us some grief.
Re: [Qemu-devel] [PATCH2] ppc: provide PIR register on all book-S CPUs
On 12.06.2011, at 17:50, Nathan Whitehorn wrote:
The PIR register is architecturally specified on all PowerPC non-embedded
CPUs, but currently is only available on the 604, 620, and G4. Add it to all
601-derived CPUs.
Looking through the respective specs, I found the following matrix on PIR
support:
601 yes
603e? (no)
604eyes
750 ? (no)
7540yes
970 yes
601 and 750 user manuals don't mention PIR. The overall 32-bit
microarchitecture states PIR as optional. So I'd say 750 and 603 simply don't
implement it. However, that means it's missing for 970 and 601. Could you
please update your patch accordingly?
Alex
Signed-off-by: Nathan Whitehorn nwhiteh...@freebsd.org
---
target-ppc/translate_init.c | 20 +---
1 files changed, 5 insertions(+), 15 deletions(-)
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index b511afa..1286ddf 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -670,6 +670,11 @@ static void gen_spr_ne_601 (CPUPPCState *env)
SPR_NOACCESS, SPR_NOACCESS,
spr_read_generic, spr_write_sdr1,
0x);
+/* Processor identification */
+spr_register(env, SPR_PIR, PIR,
+ SPR_NOACCESS, SPR_NOACCESS,
+ spr_read_generic, spr_write_pir,
+ env-cpu_index);
}
/* BATs 0-3 */
@@ -1019,11 +1024,6 @@ static void gen_spr_thrm (CPUPPCState *env)
/* SPR specific to PowerPC 604 implementation */
static void gen_spr_604 (CPUPPCState *env)
{
-/* Processor identification */
-spr_register(env, SPR_PIR, PIR,
- SPR_NOACCESS, SPR_NOACCESS,
- spr_read_generic, spr_write_pir,
- 0x);
/* Breakpoints */
/* XXX : not implemented */
spr_register(env, SPR_IABR, IABR,
@@ -1259,11 +1259,6 @@ static void gen_spr_601 (CPUPPCState *env)
static void gen_spr_74xx (CPUPPCState *env)
{
-/* Processor identification */
-spr_register(env, SPR_PIR, PIR,
- SPR_NOACCESS, SPR_NOACCESS,
- spr_read_generic, spr_write_pir,
- 0x);
/* XXX : not implemented */
spr_register(env, SPR_MMCR2, MMCR2,
SPR_NOACCESS, SPR_NOACCESS,
@@ -2118,11 +2113,6 @@ static void gen_spr_compress (CPUPPCState *env)
/* SPR specific to PowerPC 620 */
static void gen_spr_620 (CPUPPCState *env)
{
-/* Processor identification */
-spr_register(env, SPR_PIR, PIR,
- SPR_NOACCESS, SPR_NOACCESS,
- spr_read_generic, spr_write_pir,
- 0x);
spr_register(env, SPR_ASR, ASR,
SPR_NOACCESS, SPR_NOACCESS,
spr_read_asr, spr_write_asr,
[Qemu-devel] [PATCH] libcacard: don't leak vcard_emul_alloc_arrays mem
vcard_emul_mirror_card and vcard_emul_init use
vcard_emul_alloc_arrays to allocate memory for temporary arrays
which will contain elements that in the end will be used one by
one in cac_card_init. The arrays themselves are never stored
anywhere, they are only used as temporary containers. Hence
the memory that was allocated for these arrays should be freed
after use or they will be leaked.
---
libcacard/vcard_emul_nss.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/libcacard/vcard_emul_nss.c b/libcacard/vcard_emul_nss.c
index de324ba..4fee471 100644
--- a/libcacard/vcard_emul_nss.c
+++ b/libcacard/vcard_emul_nss.c
@@ -476,6 +476,7 @@ vcard_emul_mirror_card(VReader *vreader)
VCardKey **keys;
PK11SlotInfo *slot;
PRBool ret;
+VCard *card;
slot = vcard_emul_reader_get_slot(vreader);
if (slot == NULL) {
@@ -535,7 +536,12 @@ vcard_emul_mirror_card(VReader *vreader)
}
/* now create the card */
-return vcard_emul_make_card(vreader, certs, cert_len, keys, cert_count);
+card = vcard_emul_make_card(vreader, certs, cert_len, keys, cert_count);
+qemu_free(certs);
+qemu_free(cert_len);
+qemu_free(keys);
+
+return card;
}
static VCardEmulType default_card_type = VCARD_EMUL_NONE;
@@ -820,6 +826,9 @@ vcard_emul_init(const VCardEmulOptions *options)
vreader_free(vreader);
has_readers = PR_TRUE;
}
+qemu_free(certs);
+qemu_free(cert_len);
+qemu_free(keys);
}
/* if we aren't suppose to use hw, skip looking up hardware tokens */
--
1.7.5.4
Re: [Qemu-devel] buildbot failure in qemu on disable_kvm_x86_64_debian_5_0
Am 04.07.2011 11:21, schrieb Alexander Graf: On 04.07.2011, at 07:51, Stefan Weil wrote: Am 04.07.2011 06:23, schrieb Stefan Hajnoczi: On Mon, Jul 4, 2011 at 12:47 AM, Alexander Graf ag...@suse.de wrote: On 04.07.2011, at 02:04, q...@buildbot.b1-systems.de wrote: The Buildbot has detected a new failure on builder disable_kvm_x86_64_debian_5_0 while building qemu. Full details are available at: http://buildbot.b1-systems.de/qemu/builders/disable_kvm_x86_64_debian_5_0/builds/148 Buildbot URL: http://buildbot.b1-systems.de/qemu/ Buildslave for this Build: b1_qemu_1 Build Reason: The Nightly scheduler named 'nightly_disable_kvm' triggered this build Build Source Stamp: [branch master] HEAD Blamelist: BUILD FAILED: failed compile In file included from /usr/include/png.h:438, from ui/vnc-enc-tight.c:40: /usr/include/pngconf.h:326: error: expected '=', ',', ';', 'asm' or '__attribute__' before '.' token /usr/include/pngconf.h:327: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'include' make: *** [ui/vnc-enc-tight.o] Error 1 program finished with exit code 2 Not sure what exactly is missing, but the last change in that code was from Stefan Weil (2fb0c09f4ff036f68474277ed4edc036f6529de8). Daniel, Would it be possible to post the contents of /usr/include/pngconf.h from b1_qemu_1? I checked my local copy and I don't understand these compiler errors. Perhaps you have a different version of the file. Thanks, Stefan The compiler errors come again from the setjmp check in pngconf.h: __pngconf.h__ in libpng already includes setjmp.h; __dont__ include it again.; The buildbot runs Debian Lenny which includes an old version of libpng. That version does not use PNG_SKIP_SETJMP_CHECK to skip the setjmp check. Defining PNG_SETJMP_NOT_SUPPORTED might help with this version, but I still have to test that. Updating the buildbot to Debian Squeeze would also work. So it's a real bug and a good thing the buildbot is running on Lenny. Maybe we should add the define and #include setjmp.h to configure, so at least that one fails when compilation wouldn't work either? Alex It's a real bug, or at least an incompatibility with libpng. It can be fixed in several ways, for example these: 1 Don't use libpng because it restricts usage of setjmp.h and raises confusing compiler errors instead of a clear #error. Code which needs libpng would have to be removed. 2 Don't use libpng if it fails to accepts the current code (setjmp.h before png.h). This needs a small modification of the libpng check in configure. 3 Define PNG_SETJMP_NOT_SUPPORTED, so Debian Lenny's libpng works, too. Enhancing the libpng in check in configure would be reasonable to avoid more surprises with other variants of libpng. 4 Remove setjmp.h from qemu-common.h. I expected that I would have to add setjmp.h in some source files after this operation, but was surprised that this was not needed. I suggest solution 4 because it is simple, and it also avoids an unnecessary inclusion of setjmp.h in nearly all compiler invocations. Optionally, commit 2fb0c09f4ff036f68474277ed4edc036f6529de8 can be reverted then to detect any use of setjmp.h before png.h. Regards, Stefan
[Qemu-devel] [PATCH 2/2] ide: Initialise buffers with zeros
Just in case there's still a way how a guest can read out buffers when it's not supposed to, let's zero the buffers during initialisation so that we don't leak information to the guest. Signed-off-by: Kevin Wolf kw...@redhat.com --- hw/ide/core.c |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/hw/ide/core.c b/hw/ide/core.c index 2c5395b..9cace01 100644 --- a/hw/ide/core.c +++ b/hw/ide/core.c @@ -1785,9 +1785,13 @@ static void ide_init1(IDEBus *bus, int unit) s-unit = unit; s-drive_serial = drive_serial++; /* we need at least 2k alignment for accessing CDROMs using O_DIRECT */ -s-io_buffer = qemu_memalign(2048, IDE_DMA_BUF_SECTORS*512 + 4); s-io_buffer_total_len = IDE_DMA_BUF_SECTORS*512 + 4; +s-io_buffer = qemu_memalign(2048, s-io_buffer_total_len); +memset(s-io_buffer, 0, s-io_buffer_total_len); + s-smart_selftest_data = qemu_blockalign(s-bs, 512); +memset(s-smart_selftest_data, 0, 512); + s-sector_write_timer = qemu_new_timer_ns(vm_clock, ide_sector_write_timer_cb, s); } -- 1.7.6
Re: [Qemu-devel] KVM call agenda for July 5
On 07/04/2011 09:52 AM, Juan Quintela wrote: Hi Please send in any agenda items you are interested in covering. SCSI without bounce buffers: talk now, or forever hold your peace. Paolo
Re: [Qemu-devel] qemu crashes on Mac OS X
Hi Damjan,
On Fri, Jul 1, 2011 at 10:56 AM, Damjan Marion damjan.mar...@gmail.com wrote:
On Jul 1, 2011, at 11:17 AM, Damjan Marion (damarion) wrote:
Hi,
I have an issue when I try to run qemu-system-arm on Mac OS X.
Sometime between 1 and 15 secs after qemu is started it crashes
as shown bellow.
Same thing on linux host works fine.
Is anybody else experiencing this?
Any Hints?
After bisection seems that this starts happening after following patch:
commit 09716e45a05cc0c93bcf55bd0c0888dd678e490f
Author: Alexander Graf ag...@suse.de
Date: Thu Jun 9 00:55:37 2011 +0200
sigfd: use pthread_sigmask
diff --git a/compatfd.c b/compatfd.c
index bd377c4..41586ce 100644
--- a/compatfd.c
+++ b/compatfd.c
@@ -29,7 +29,7 @@ static void *sigwait_compat(void *opaque)
sigset_t all;
sigfillset(all);
- sigprocmask(SIG_BLOCK, all, NULL);
+ pthread_sigmask(SIG_BLOCK, all, NULL);
while (1) {
However before this patch qemu doesn't respond to keyboard (i.e. commit
31b7c261).
Last full working commit is 630ecca.
Thanks,
Damjan
Can you try applying the following two patches and see if it solves
your problem?
http://patchwork.ozlabs.org/patch/100348/
http://patchwork.ozlabs.org/patch/100477/
Alexandre
Re: [Qemu-devel] [PATCH 1/1] usb_register_port(): do not set port-opaque and port-index twice
port-opaque = opaque; port-index = index; -port-opaque = opaque; -port-index = index; Added to usb patch queue. thanks, Gerd
[Qemu-devel] [PULL] pci, vhost
The following changes since commit 1dfdcaa83f9ce34aded8bc0669e81753d94f1b7d: user: Fix -d debug logging for usermode emulation (2011-06-28 20:57:09 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu.git for_anthony Anthony PERARD (1): hw/piix_pci.c: Fix PIIX3-xen to initialize ids Michael S. Tsirkin (3): vhost: fix double free on device stop pci_ids: tweak names to match linux/pci_ids.h xen: move to new pci initializers hw/pci_ids.h |3 ++- hw/piix_pci.c |3 +++ hw/vhost.c|1 + hw/xen_platform.c | 15 +++ 4 files changed, 13 insertions(+), 9 deletions(-)
Re: [Qemu-devel] [PATCH v5] xen_console: support the new extended xenstore protocol
On Mon, 4 Jul 2011, Alexander Graf wrote: On 30.06.2011, at 19:26, stefano.stabell...@eu.citrix.com stefano.stabell...@eu.citrix.com wrote: From: Stefano Stabellini stefano.stabell...@eu.citrix.com Since CS 21994 on xen-unstable.hg and CS 466608f3a32e1f9808acdf832a5843af37e5fcec on qemu-xen-unstable.git, few changes have been introduced to the PV console xenstore protocol, as described by the document docs/misc/console.txt under xen-unstable.hg. From the Qemu point of view, very few modifications are needed to correctly support the protocol: read from xenstore the output node that tell us what the output of the PV console is going to be. In case the output is a tty, write to xenstore the device name. This one breaks my usual smoke test case of executing a Xen PV machine: $ ./x86_64-softmmu/qemu-system-x86_64 -xen-create -xen-domid 2 -M xenpv -kernel /boot/vmlinux-xen -initrd /boot/initrd-xen -append 'xencons=tty root=/dev/null' -nographic How about this patch on top? That way you can still override Qemu's serial choice with xenstore, but keep the Qemu infrastructure in place for people who don't want to use it. This will be especially important when Xenner comes around, where a Xen PV VM feels the same as any other Qemu machine. I think it is a reasonable compromise.
Re: [Qemu-devel] [PATCH] usb-hid: Fix 0/0 position for Windows in tablet mode
On 26 June 2011 11:11, Jan Kiszka jan.kis...@web.de wrote:
On 2011-06-25 15:10, Andreas Färber wrote:
Am 25.06.2011 um 14:55 schrieb Jan Kiszka:
On 2011-06-25 14:37, Andreas Färber wrote:
Am 24.06.2011 um 16:27 schrieb Jan Kiszka:
For unknown reasons, Windows drivers (tested with XP and Win7) ignore
usb-tablet events that move the pointer to 0/0. So always set bit 0 of
the coordinates.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/usb-hid.c | 6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/hw/usb-hid.c b/hw/usb-hid.c
index d711b5c..2b9a451 100644
--- a/hw/usb-hid.c
+++ b/hw/usb-hid.c
@@ -457,8 +457,10 @@ static void
usb_pointer_event_combine(USBPointerEvent *e, int xyrel,
e-xdx += x1;
e-ydy += y1;
} else {
- e-xdx = x1;
- e-ydy = y1;
+ /* Windows drivers do not like the 0/0 position and ignore
such
+ * events. */
+ e-xdx = x1 | 1;
+ e-ydy = y1 | 1;
Doesn't this change mean we can't access any other even pixel either?
Only on 32767x32767 screens (that's the resolution of the tablet).
Well, if it's just a fix for 0/0 I would've expected something like:
e-xdx = x1 ? x1 : 1;
e-ydy = y1 ? y1 : 1;
Works as well, my version is a little bit simpler. But I don't mind,
will post whatever is preferred to fix this.
Would it be enough to just do this for x or y, not both?
Cheers
Re: [Qemu-devel] [PATCH v5] showing a splash picture when start, seabios image for test
jpeg decoder have its limitation, it only accept jpg file with width=16*M, height=16*N. bmp decoder only accept 24bpp file, with a resolution that a video mode could support. Recommended is 640x480(mostly used). Doing image decoding in the bios seems particularly pointless. Why don't you just pass the bios raw image data? If you really want to directly support fancier formats IMO it makes much more sense to do that in qemu itself. There we can use the same libraries as everyone else (libjpeg, libpng, etc) rather than badly reimpleenting them inside the bios. Paul
[Qemu-devel] [PATCH] Remove unneeded setjmp.h (fix compilation with on Debian lenny)
Some versions of png.h cannot be included after setjmp.h, even when PNG_SKIP_SETJMP_CHECK was defined. setjmp.h was included from qemu-common.h and is not needed there. Removing the include statement fixes compilation of ui/vnc-enc-tight.c with CONFIG_VNC_PNG defined. Signed-off-by: Stefan Weil w...@mail.berlios.de --- qemu-common.h |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/qemu-common.h b/qemu-common.h index abd7a75..c2b79bd 100644 --- a/qemu-common.h +++ b/qemu-common.h @@ -117,7 +117,6 @@ static inline char *realpath(const char *path, char *resolved_path) /* FIXME: Remove NEED_CPU_H. */ #ifndef NEED_CPU_H -#include setjmp.h #include osdep.h #include bswap.h -- 1.7.2.5
Re: [Qemu-devel] [PATCH] Remove unneeded setjmp.h (fix compilation with on Debian lenny)
Am 04.07.2011 20:44, schrieb Stefan Weil: Some versions of png.h cannot be included after setjmp.h, even when PNG_SKIP_SETJMP_CHECK was defined. setjmp.h was included from qemu-common.h and is not needed there. Removing the include statement fixes compilation of ui/vnc-enc-tight.c with CONFIG_VNC_PNG defined. Signed-off-by: Stefan Weilw...@mail.berlios.de --- Sorry, I noticed that the subject is not correct (with on) after I had sent the patch. Please use patch v2. Stefan
[Qemu-devel] [PATCH v2] Remove unneeded setjmp.h (fix compilation on Debian lenny)
Some versions of png.h cannot be included after setjmp.h, even when PNG_SKIP_SETJMP_CHECK was defined. setjmp.h was included from qemu-common.h and is not needed there. Removing the include statement fixes compilation of ui/vnc-enc-tight.c with CONFIG_VNC_PNG defined. Signed-off-by: Stefan Weil w...@mail.berlios.de --- qemu-common.h |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/qemu-common.h b/qemu-common.h index abd7a75..c2b79bd 100644 --- a/qemu-common.h +++ b/qemu-common.h @@ -117,7 +117,6 @@ static inline char *realpath(const char *path, char *resolved_path) /* FIXME: Remove NEED_CPU_H. */ #ifndef NEED_CPU_H -#include setjmp.h #include osdep.h #include bswap.h -- 1.7.2.5
[Qemu-devel] Fwd: Benchmarking activities
[Somehow qemu-devel got lost...] Anfang der weitergeleiteten E-Mail: Von: Andreas Färber andreas.faer...@web.de Datum: 2. Juli 2011 19:21:07 MESZ An: Ben Vogler bvog...@toyotatech.com.au Kopie: Hans de Goede hdego...@redhat.com, Alon Levy al...@redhat.com Betreff: Re: [Qemu-devel] Benchmarking activities Hi Ben, Am 27.06.2011 um 01:02 schrieb Ben Vogler: - I have seen examples of QEMU processor cores being wrapped in SystemC and used in OSCI based virtual systems is this the general approach, or is there other/better ways of going about using QEMU not as an emulator (such as VMware), but as a simulator? (VMware like KVM and VirtualBox, I thought, was doing virtualization rather than emulation.) QEMU uses a device model called qdev. Your device can set up handlers for I/O accesses and then do anything it likes from C code. Be it obtaining data from a local device (passthrough) or from a remote server (e.g., USB redirection) or via socket from an external process (e.g., usb-ccid). - Is there full backwards compatibility between versions of QEMU? Define what architecture/machine you use and what exactly you want to be backwards compatible. As examples, command line options and device state (VMState) are being kept backwards compatible for x86 PC so that you can load old snapshots, whereas the QEMU-internal APIs may evolve incompatibly (v0.9.x is highly incompatible with recent versions, for instance). - I have been looking but could not find a complete list of processor core models supported by QEMU. I have seen there are processors from Sparc, ARM, MIPS, but are there any core models from NEC, or Renesas in particular? Would you please be able to point me in the right direction? There are a couple of forks on the Internet adding support for additional architectures, but no Renesas that I'm aware of. http://wiki.qemu.org/Links - Alternate QEMU repositories http://wiki.qemu.org/Contribute/StartHere - Features http://repo.or.cz/w/qemu.git/forks I have a v850 board around but adding a QEMU target for it just to debug a few LEDs and GPIOs seemed like overkill. Still waiting for an RL78 starter kit... If you find or contribute anything in that area I'll be happy to help review patches. The rest of my questions are based on the assumption that QEMU IP will be used in a virtual system simulation, rather than emulation. - Is co-simulation possible? For example, connecting an engine model running in Dymola to the QEMU (processor model) based virtual system simulator. Since that particular product seems closed-source and the demo download is for Windows only, it's hard to tell. As stated above, it's possible to communicate with external processes or clients/ servers from QEMU. In which ways particular simulators support receiving external queries or publishing internal state would be for the simulator's authors to answer. I've heard of the IEEE 1516 High Level Architecture (HLA) as a general way of synchronizing distributed simulations but haven't worked with it personally. Regards, Andreas
Re: [Qemu-devel] [PATCH][uq/master] kvmclock: Fix feature detection
On Thu, Jun 23, 2011 at 10:23:10AM +0200, Jan Kiszka wrote: From: Jan Kiszka jan.kis...@siemens.com Bit-wise or the feature flags and drop the obsolete #ifdef. Signed-off-by: Jan Kiszka jan.kis...@siemens.com --- hw/kvmclock.c |7 ++- 1 files changed, 2 insertions(+), 5 deletions(-) Applied, thanks.
Re: [Qemu-devel] [PATCH][uq/master] kvm: Drop obsolete KVM_IOEVENTFD #ifdefs
On Thu, Jun 23, 2011 at 10:26:27AM +0200, Jan Kiszka wrote: From: Jan Kiszka jan.kis...@siemens.com Signed-off-by: Jan Kiszka jan.kis...@siemens.com --- kvm-all.c |8 1 files changed, 0 insertions(+), 8 deletions(-) Applied, thanks.
Re: [Qemu-devel] [PATCH v4 1/2] pxa2xx_lcd: add proper rotation support
On 17 June 2011 12:04, Vasily Khoruzhick anars...@gmail.com wrote: Until now, pxa2xx_lcd only supported 90deg rotation, but some machines (for example Zipit Z2) needs 270deg rotation. Signed-off-by: Vasily Khoruzhick anars...@gmail.com --- v2: codestyle fixes v3: fix dpy_update calls for 180 and 360 deg. rotation. v4: codestyle fixes; replace atoi with strtol Thanks, I pushed this version. Cheers
Re: [Qemu-devel] [PATCH] arm: Add const attribute to some arm_boot_info pointers
On 23 June 2011 17:53, Stefan Weil w...@mail.berlios.de wrote: Parameter 'info' is const, so add the missing attribute. v2: Add 'const' to the local variable info in do_cpu_reset() and to the boot_info field in CPUARMState (suggested by Peter Maydell). I pushed this version, thanks. Cheers
Re: [Qemu-devel] [PATCH v2] Remove unneeded setjmp.h (fix compilation on Debian lenny)
On 4 July 2011 19:52, Stefan Weil w...@mail.berlios.de wrote: Some versions of png.h cannot be included after setjmp.h, even when PNG_SKIP_SETJMP_CHECK was defined. setjmp.h was included from qemu-common.h and is not needed there. Removing the include statement fixes compilation of ui/vnc-enc-tight.c with CONFIG_VNC_PNG defined. This isn't the only unnecessary include of setjmp.h, incidentally. The includes in target-alpha/cpu.h and target-ppc/cpu.h could also be removed (cpu-defs.h includes setjmp.h). That would also make those targets consistent with all the rest (which don't include setjmp), so it seems worth the minor cleanup. I'll send a patch... -- PMM
[Qemu-devel] [PATCH] target-alpha, target-ppc: Remove unnecessary setjmp.h include
Remove the include of setjmp.h from the cpu.h of target-alpha and target-ppc. This is unnecessary because cpu-defs.h already includes this header; this change brings these two targets into line with all the rest. Signed-off-by: Peter Maydell peter.mayd...@linaro.org --- target-alpha/cpu.h |2 -- target-ppc/cpu.h |2 -- 2 files changed, 0 insertions(+), 4 deletions(-) diff --git a/target-alpha/cpu.h b/target-alpha/cpu.h index 411bd55..78caa79 100644 --- a/target-alpha/cpu.h +++ b/target-alpha/cpu.h @@ -28,8 +28,6 @@ #include cpu-defs.h -#include setjmp.h - #include softfloat.h #define TARGET_HAS_ICE 1 diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h index 84f8ff6..d903366 100644 --- a/target-ppc/cpu.h +++ b/target-ppc/cpu.h @@ -75,8 +75,6 @@ #include cpu-defs.h -#include setjmp.h - #include softfloat.h #define TARGET_HAS_ICE 1 -- 1.7.4.1
Re: [Qemu-devel] [PATCH] target-alpha, target-ppc: Remove unnecessary setjmp.h include
On 04.07.2011, at 23:02, Peter Maydell wrote: Remove the include of setjmp.h from the cpu.h of target-alpha and target-ppc. This is unnecessary because cpu-defs.h already includes this header; this change brings these two targets into line with all the rest. Signed-off-by: Peter Maydell peter.mayd...@linaro.org Yeah, I actually think no code (unless specifically configure'd for it) should include non-local headers (... instead of ...). Of course that would include device/target specific headers as well ;). Acked-by: Alexander Graf ag...@suse.de --- target-alpha/cpu.h |2 -- target-ppc/cpu.h |2 -- 2 files changed, 0 insertions(+), 4 deletions(-) diff --git a/target-alpha/cpu.h b/target-alpha/cpu.h index 411bd55..78caa79 100644 --- a/target-alpha/cpu.h +++ b/target-alpha/cpu.h @@ -28,8 +28,6 @@ #include cpu-defs.h -#include setjmp.h - #include softfloat.h #define TARGET_HAS_ICE 1 diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h index 84f8ff6..d903366 100644 --- a/target-ppc/cpu.h +++ b/target-ppc/cpu.h @@ -75,8 +75,6 @@ #include cpu-defs.h -#include setjmp.h - #include softfloat.h #define TARGET_HAS_ICE 1 -- 1.7.4.1
[Qemu-devel] [PATCH] xen_console: fall back to qemu serial device
The new xen_console protocol changed the default xen_console output device
from whatever Qemu chose to whatever xenstore choses and pty as fallback.
This is not how Qemu works. It has its own serial redirection semantics. So
it xenstore doesn't contain information on what to do, Qemu is the place to
ask.
Signed-off-by: Alexander Graf ag...@suse.de
---
hw/xen_console.c | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/hw/xen_console.c b/hw/xen_console.c
index bdb8540..8ef104c 100644
--- a/hw/xen_console.c
+++ b/hw/xen_console.c
@@ -196,12 +196,15 @@ static int con_init(struct XenDevice *xendev)
}
output = xenstore_read_str(con-console, output);
-/* output is a pty by default */
+
+/* no Xen override, use qemu output device */
if (output == NULL) {
-output = pty;
+con-chr = serial_hds[con-xendev.dev];
+} else {
+snprintf(label, sizeof(label), xencons%d, con-xendev.dev);
+con-chr = qemu_chr_open(label, output, NULL);
}
-snprintf(label, sizeof(label), xencons%d, con-xendev.dev);
-con-chr = qemu_chr_open(label, output, NULL);
+
xenstore_store_pv_console_info(con-xendev.dev, con-chr);
out:
--
1.6.0.2
[Qemu-devel] [PATCH 0/3] Build fixes
Hi, With default configure, the qemu-kvm client build was failing for me since Werror is enabled by default in configure. Deprecations (gnutls), gcc signed-overflow optimization (Werror=strict-overflows) and few unused-but-set variables were causing it. I have attached the patches after applying which, I got no further errors. Raghavendra D Prabhu (3): Avoid the use of deprecated gnutls gnutls_*_set_priority functions. Add fno-strict-overflow Avoid Wunsed-but-set warnings (or errors in case of Werror) Makefile.hw|2 +- hw/device-assignment.c |6 +++--- simpletrace.c |2 +- ui/vnc-tls.c | 20 +--- xen-mapcache.c |7 ++- 5 files changed, 8 insertions(+), 29 deletions(-) -- 1.7.6 -- Raghavendra Prabhu GPG Id : 0xD72BE977 Fingerprint: B93F EBCB 8E05 7039 CD3C A4B8 A616 DCA1 D72B E977 www: wnohang.net
[Qemu-devel] [PATCH 1/3] Avoid the use of deprecated gnutls gnutls_*_set_priority functions.
The gnutls_*_set_priority family of functions has been marked deprecated
in 2.12.x. These functions have been superceded by
gnutls_priority_set_direct().
Signed-off-by: Raghavendra D Prabhu rpra...@wnohang.net
---
ui/vnc-tls.c | 20 +---
1 files changed, 1 insertions(+), 19 deletions(-)
diff --git a/ui/vnc-tls.c b/ui/vnc-tls.c
index dec626c..33a5d8c 100644
--- a/ui/vnc-tls.c
+++ b/ui/vnc-tls.c
@@ -286,10 +286,6 @@ int vnc_tls_validate_certificate(struct VncState *vs)
int vnc_tls_client_setup(struct VncState *vs,
int needX509Creds) {
-static const int cert_type_priority[] = { GNUTLS_CRT_X509, 0 };
-static const int protocol_priority[]= { GNUTLS_TLS1_1, GNUTLS_TLS1_0,
GNUTLS_SSL3, 0 };
-static const int kx_anon[] = {GNUTLS_KX_ANON_DH, 0};
-static const int kx_x509[] = {GNUTLS_KX_DHE_DSS, GNUTLS_KX_RSA,
GNUTLS_KX_DHE_RSA, GNUTLS_KX_SRP, 0};
VNC_DEBUG(Do TLS setup\n);
if (vnc_tls_initialize() 0) {
@@ -310,21 +306,7 @@ int vnc_tls_client_setup(struct VncState *vs,
return -1;
}
-if (gnutls_kx_set_priority(vs-tls.session, needX509Creds ? kx_x509 :
kx_anon) 0) {
-gnutls_deinit(vs-tls.session);
-vs-tls.session = NULL;
-vnc_client_error(vs);
-return -1;
-}
-
-if (gnutls_certificate_type_set_priority(vs-tls.session,
cert_type_priority) 0) {
-gnutls_deinit(vs-tls.session);
-vs-tls.session = NULL;
-vnc_client_error(vs);
-return -1;
-}
-
-if (gnutls_protocol_set_priority(vs-tls.session, protocol_priority)
0) {
+if (gnutls_priority_set_direct(vs-tls.session, needX509Creds ?
NORMAL : NORMAL:+ANON-DH, NULL) 0) {
gnutls_deinit(vs-tls.session);
vs-tls.session = NULL;
vnc_client_error(vs);
--
1.7.6
Re: [Qemu-devel] [PATCH] Build fixes
* On Sat, Jul 02, 2011 at 03:58:34PM +0100, Stefan Hajnoczi stefa...@gmail.com wrote: On Sat, Jul 2, 2011 at 3:06 PM, Raghavendra D Prabhu rpra...@wnohang.net wrote: With default configure, the qemu-kvm client build was failing for me since Werror is enabled by default in configure. Deprecations (gnutls), gcc signed-overflow optimization (Werror=strict-overflows) and few unused-but-set variables were causing it. I have attached the patches after applying which, I got no further errors. Thanks for the patches. Please submit patches as individual inline emails so that it is easy to review and reply to them. For more information, see http://wiki.qemu.org/Contribute/SubmitAPatch. Stefan Thanks. I have sent them correctly this time. -- Raghavendra Prabhu GPG Id : 0xD72BE977 Fingerprint: B93F EBCB 8E05 7039 CD3C A4B8 A616 DCA1 D72B E977 www: wnohang.net pgp3FNUtVdS7e.pgp Description: PGP signature
[Qemu-devel] [PATCH 3/3] Avoid Wunsed-but-set warnings (or errors in case of Werror)
In a few cases, variable attributed 'unused' has been added, in other cases
unused variable has been either removed or commented out.
Signed-off-by: Raghavendra D Prabhu rpra...@wnohang.net
---
hw/device-assignment.c |6 +++---
simpletrace.c |2 +-
xen-mapcache.c |7 ++-
3 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/hw/device-assignment.c b/hw/device-assignment.c
index 36ad6b0..19a59b4 100644
--- a/hw/device-assignment.c
+++ b/hw/device-assignment.c
@@ -1654,7 +1654,7 @@ static void reset_assigned_device(DeviceState *dev)
AssignedDevice *adev = DO_UPCAST(AssignedDevice, dev, pci_dev);
char reset_file[64];
const char reset[] = 1;
-int fd, ret;
+int fd, __attribute__((unused)) ret;
snprintf(reset_file, sizeof(reset_file),
/sys/bus/pci/devices/%04x:%02x:%02x.%01x/reset,
@@ -1682,7 +1682,7 @@ static void reset_assigned_device(DeviceState *dev)
static int assigned_initfn(struct PCIDevice *pci_dev)
{
AssignedDevice *dev = DO_UPCAST(AssignedDevice, dev, pci_dev);
-uint8_t e_device, e_intx;
+uint8_t e_intx;
int r;
if (!kvm_enabled()) {
@@ -1709,7 +1709,7 @@ static int assigned_initfn(struct PCIDevice *pci_dev)
goto out;
/* handle interrupt routing */
-e_device = (dev-dev.devfn 3) 0x1f;
+/*e_device = (dev-dev.devfn 3) 0x1f;*/
e_intx = dev-dev.config[0x3d] - 1;
dev-intpin = e_intx;
dev-run = 0;
diff --git a/simpletrace.c b/simpletrace.c
index f1dbb5e..2ce9cff 100644
--- a/simpletrace.c
+++ b/simpletrace.c
@@ -119,7 +119,7 @@ static void *writeout_thread(void *opaque)
TraceRecord record;
unsigned int writeout_idx = 0;
unsigned int num_available, idx;
-size_t unused;
+size_t __attribute__((unused)) unused;
for (;;) {
wait_for_trace_records_available();
diff --git a/xen-mapcache.c b/xen-mapcache.c
index fac47cd..94642bc 100644
--- a/xen-mapcache.c
+++ b/xen-mapcache.c
@@ -166,7 +166,7 @@ static void qemu_remap_bucket(MapCacheEntry *entry,
uint8_t *qemu_map_cache(target_phys_addr_t phys_addr, target_phys_addr_t size,
uint8_t lock)
{
-MapCacheEntry *entry, *pentry = NULL;
+MapCacheEntry *entry;
target_phys_addr_t address_index = phys_addr MCACHE_BUCKET_SHIFT;
target_phys_addr_t address_offset = phys_addr (MCACHE_BUCKET_SIZE - 1);
target_phys_addr_t __size = size;
@@ -192,12 +192,10 @@ uint8_t *qemu_map_cache(target_phys_addr_t phys_addr,
target_phys_addr_t size, u
(entry-paddr_index != address_index || entry-size != __size ||
!test_bits(address_offset XC_PAGE_SHIFT, size XC_PAGE_SHIFT,
entry-valid_mapping))) {
-pentry = entry;
entry = entry-next;
}
if (!entry) {
entry = qemu_mallocz(sizeof (MapCacheEntry));
-pentry-next = entry;
qemu_remap_bucket(entry, __size, address_index);
} else if (!entry-lock) {
if (!entry-vaddr_base || entry-paddr_index != address_index ||
@@ -232,7 +230,7 @@ uint8_t *qemu_map_cache(target_phys_addr_t phys_addr,
target_phys_addr_t size, u
ram_addr_t qemu_ram_addr_from_mapcache(void *ptr)
{
-MapCacheEntry *entry = NULL, *pentry = NULL;
+MapCacheEntry *entry = NULL;
MapCacheRev *reventry;
target_phys_addr_t paddr_index;
target_phys_addr_t size;
@@ -258,7 +256,6 @@ ram_addr_t qemu_ram_addr_from_mapcache(void *ptr)
entry = mapcache-entry[paddr_index % mapcache-nr_buckets];
while (entry (entry-paddr_index != paddr_index || entry-size !=
size)) {
-pentry = entry;
entry = entry-next;
}
if (!entry) {
--
1.7.6
[Qemu-devel] [PATCH 2/3] Add fno-strict-overflow
This is to avoid gcc optimizating out the comparison in assert, due to assumption of signed overflow being undefined by default (-Werror=strict-overflow). Signed-off-by: Raghavendra D Prabhu rpra...@wnohang.net --- Makefile.hw |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Makefile.hw b/Makefile.hw index b9181ab..23dac45 100644 --- a/Makefile.hw +++ b/Makefile.hw @@ -9,7 +9,7 @@ include $(SRC_PATH)/rules.mak $(call set-vpath, $(SRC_PATH):$(SRC_PATH)/hw) -QEMU_CFLAGS+=-I.. -I$(SRC_PATH)/fpu +QEMU_CFLAGS+=-I.. -I$(SRC_PATH)/fpu -fno-strict-overflow include $(SRC_PATH)/Makefile.objs -- 1.7.6
Re: [Qemu-devel] [PATCH 2/3] Add fno-strict-overflow
On 4 July 2011 23:00, Raghavendra D Prabhu raghu.prabh...@gmail.com wrote: This is to avoid gcc optimizating out the comparison in assert, due to assumption of signed overflow being undefined by default (-Werror=strict-overflow). --- a/Makefile.hw +++ b/Makefile.hw @@ -9,7 +9,7 @@ include $(SRC_PATH)/rules.mak $(call set-vpath, $(SRC_PATH):$(SRC_PATH)/hw) -QEMU_CFLAGS+=-I.. -I$(SRC_PATH)/fpu +QEMU_CFLAGS+=-I.. -I$(SRC_PATH)/fpu -fno-strict-overflow Can you give a more detailed description of the problem this is trying to solve? I think it would be nicer if we could remove the assumptions about signed overflows instead, if that's practical. (Also, if we do want to add this compiler flag then it ought to be done in configure I think, as we do for -fno-strict-aliasing.) -- PMM
Re: [Qemu-devel] [PATCH 3/3] hw/omap_gpio.c: Convert to qdev
Hi,
On 29 June 2011 20:53, Peter Maydell peter.mayd...@linaro.org wrote:
From: Juha Riihimäki juha.riihim...@nokia.com
Convert the OMAP GPIO module to qdev.
Signed-off-by: Juha Riihimäki juha.riihim...@nokia.com
[Riku Voipio: Fixes and restructuring patchset]
Signed-off-by: Riku Voipio riku.voi...@iki.fi
[Peter Maydell: More fixes and cleanups for upstream submission]
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
hw/nseries.c | 47 +--
hw/omap.h | 20 +-
hw/omap1.c | 10 ++-
hw/omap2.c | 26 --
hw/omap_gpio.c | 244 +++
hw/palm.c | 26 +++---
6 files changed, 181 insertions(+), 192 deletions(-)
diff --git a/hw/nseries.c b/hw/nseries.c
index 2f6f473..4ea2d6b 100644
--- a/hw/nseries.c
+++ b/hw/nseries.c
@@ -134,9 +134,9 @@ static void n800_mmc_cs_cb(void *opaque, int line, int
level)
static void n8x0_gpio_setup(struct n800_s *s)
{
qemu_irq *mmc_cs = qemu_allocate_irqs(n800_mmc_cs_cb, s-cpu-mmc, 1);
- omap2_gpio_out_set(s-cpu-gpif, N8X0_MMC_CS_GPIO, mmc_cs[0]);
+ qdev_connect_gpio_out(s-cpu-gpio, N8X0_MMC_CS_GPIO, mmc_cs[0]);
- qemu_irq_lower(omap2_gpio_in_get(s-cpu-gpif, N800_BAT_COVER_GPIO)[0]);
+ qemu_irq_lower(qdev_get_gpio_in(s-cpu-gpio, N800_BAT_COVER_GPIO));
}
#define MAEMO_CAL_HEADER(...) \
@@ -168,8 +168,8 @@ static void n8x0_nand_setup(struct n800_s *s)
omap_gpmc_attach(s-cpu-gpmc, N8X0_ONENAND_CS, 0, onenand_base_update,
onenand_base_unmap,
(s-nand = onenand_init(0xec4800, 1,
- omap2_gpio_in_get(s-cpu-gpif,
- N8X0_ONENAND_GPIO)[0])));
+ qdev_get_gpio_in(s-cpu-gpio,
+ N8X0_ONENAND_GPIO;
otp_region = onenand_raw_otp(s-nand);
memcpy(otp_region + 0x000, n8x0_cal_wlan_mac, sizeof(n8x0_cal_wlan_mac));
@@ -180,7 +180,7 @@ static void n8x0_nand_setup(struct n800_s *s)
static void n8x0_i2c_setup(struct n800_s *s)
{
DeviceState *dev;
- qemu_irq tmp_irq = omap2_gpio_in_get(s-cpu-gpif, N8X0_TMP105_GPIO)[0];
+ qemu_irq tmp_irq = qdev_get_gpio_in(s-cpu-gpio, N8X0_TMP105_GPIO);
/* Attach the CPU on one end of our I2C bus. */
s-i2c = omap_i2c_bus(s-cpu-i2c[0]);
@@ -249,8 +249,8 @@ static void n800_tsc_kbd_setup(struct n800_s *s)
/* XXX: are the three pins inverted inside the chip between the
* tsc and the cpu (N4111)? */
qemu_irq penirq = NULL; /* NC */
- qemu_irq kbirq = omap2_gpio_in_get(s-cpu-gpif,
N800_TSC_KP_IRQ_GPIO)[0];
- qemu_irq dav = omap2_gpio_in_get(s-cpu-gpif, N800_TSC_TS_GPIO)[0];
+ qemu_irq kbirq = qdev_get_gpio_in(s-cpu-gpio, N800_TSC_KP_IRQ_GPIO);
+ qemu_irq dav = qdev_get_gpio_in(s-cpu-gpio, N800_TSC_TS_GPIO);
s-ts.chip = tsc2301_init(penirq, kbirq, dav);
s-ts.opaque = s-ts.chip-opaque;
@@ -269,7 +269,7 @@ static void n800_tsc_kbd_setup(struct n800_s *s)
static void n810_tsc_setup(struct n800_s *s)
{
- qemu_irq pintdav = omap2_gpio_in_get(s-cpu-gpif, N810_TSC_TS_GPIO)[0];
+ qemu_irq pintdav = qdev_get_gpio_in(s-cpu-gpio, N810_TSC_TS_GPIO);
s-ts.opaque = tsc2005_init(pintdav);
s-ts.txrx = tsc2005_txrx;
@@ -361,7 +361,7 @@ static int n810_keys[0x80] = {
static void n810_kbd_setup(struct n800_s *s)
{
- qemu_irq kbd_irq = omap2_gpio_in_get(s-cpu-gpif,
N810_KEYBOARD_GPIO)[0];
+ qemu_irq kbd_irq = qdev_get_gpio_in(s-cpu-gpio, N810_KEYBOARD_GPIO);
DeviceState *dev;
int i;
@@ -726,15 +726,15 @@ static void n8x0_dss_setup(struct n800_s *s)
static void n8x0_cbus_setup(struct n800_s *s)
{
- qemu_irq dat_out = omap2_gpio_in_get(s-cpu-gpif,
N8X0_CBUS_DAT_GPIO)[0];
- qemu_irq retu_irq = omap2_gpio_in_get(s-cpu-gpif, N8X0_RETU_GPIO)[0];
- qemu_irq tahvo_irq = omap2_gpio_in_get(s-cpu-gpif, N8X0_TAHVO_GPIO)[0];
+ qemu_irq dat_out = qdev_get_gpio_in(s-cpu-gpio, N8X0_CBUS_DAT_GPIO);
+ qemu_irq retu_irq = qdev_get_gpio_in(s-cpu-gpio, N8X0_RETU_GPIO);
+ qemu_irq tahvo_irq = qdev_get_gpio_in(s-cpu-gpio, N8X0_TAHVO_GPIO);
CBus *cbus = cbus_init(dat_out);
- omap2_gpio_out_set(s-cpu-gpif, N8X0_CBUS_CLK_GPIO, cbus-clk);
- omap2_gpio_out_set(s-cpu-gpif, N8X0_CBUS_DAT_GPIO, cbus-dat);
- omap2_gpio_out_set(s-cpu-gpif, N8X0_CBUS_SEL_GPIO, cbus-sel);
+ qdev_connect_gpio_out(s-cpu-gpio, N8X0_CBUS_CLK_GPIO, cbus-clk);
+ qdev_connect_gpio_out(s-cpu-gpio, N8X0_CBUS_DAT_GPIO, cbus-dat);
+ qdev_connect_gpio_out(s-cpu-gpio, N8X0_CBUS_SEL_GPIO, cbus-sel);
cbus_attach(cbus, s-retu = retu_init(retu_irq, 1));
cbus_attach(cbus, s-tahvo = tahvo_init(tahvo_irq, 1));
@@ -743,13 +743,12 @@ static void n8x0_cbus_setup(struct n800_s *s)
static void n8x0_uart_setup(struct n800_s *s)
{
[Qemu-devel] buildbot failure in qemu on default_x86_64_out_of_tree
The Buildbot has detected a new failure on builder default_x86_64_out_of_tree while building qemu. Full details are available at: http://buildbot.b1-systems.de/qemu/builders/default_x86_64_out_of_tree/builds/145 Buildbot URL: http://buildbot.b1-systems.de/qemu/ Buildslave for this Build: b1_qemu_1 Build Reason: The Nightly scheduler named 'nightly_default' triggered this build Build Source Stamp: [branch master] HEAD Blamelist: BUILD FAILED: failed compile sincerely, -The Buildbot
[Qemu-devel] [Bug 568614] Re: x86_64 host curses interface: spacing/garbling
If I remember correctly, the type is unsigned long because it needs to match chtype as declared in curses.h. On some implementations of curses it may be declared differently, we really should use the chtype type directly but console.h is also used when the use of curses was disabled in qemu config. I'm pretty sure the curses support has been tested on machines of both endianness at one point, but mostly with ncurses only. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/568614 Title: x86_64 host curses interface: spacing/garbling Status in QEMU: In Progress Bug description: Environment: Arch Linux x86_64, kernel 2.6.33, qemu 0.12.3 Steps to reproduce: 1. Have a host system running 64-bit Linux. 2. Start a qemu VM with the -curses flag. Expected results: Text displayed looks as it would on a real text-mode display, and VM is therefore usable. Actual results: Text displayed contains an extra space between characters, causing text to flow off the right and bottom sides of the screen. This makes the curses interface unintelligible. The attached patch fixes this problem on 0.12.3 on my installation without changing behavior on a 32-bit machine. I don't know enough of the semantics of console_ch_t to know if this is the correct fix or if there should be, say, an extra cast somewhere instead. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/568614/+subscriptions
[Qemu-devel] buildbot failure in qemu on pci_x86_64_debian_5_0
The Buildbot has detected a new failure on builder pci_x86_64_debian_5_0 while building qemu. Full details are available at: http://buildbot.b1-systems.de/qemu/builders/pci_x86_64_debian_5_0/builds/24 Buildbot URL: http://buildbot.b1-systems.de/qemu/ Buildslave for this Build: b1_qemu_1 Build Reason: The Nightly scheduler named 'nightly_pci' triggered this build Build Source Stamp: [branch pci] HEAD Blamelist: BUILD FAILED: failed compile sincerely, -The Buildbot
Re: [Qemu-devel] [PATCH v5] showing a splash picture when start, seabios image for test
于 2011-7-5 2:31, Paul Brook 写道: jpeg decoder have its limitation, it only accept jpg file with width=16*M, height=16*N. bmp decoder only accept 24bpp file, with a resolution that a video mode could support. Recommended is 640x480(mostly used). Doing image decoding in the bios seems particularly pointless. Why don't you just pass the bios raw image data? If you really want to directly support fancier formats IMO it makes much more sense to do that in qemu itself. There we can use the same libraries as everyone else (libjpeg, libpng, etc) rather than badly reimpleenting them inside the bios. I think the BMP file with 24bpp is almost the raw image data that need just a little format adjusting in bios according to the video mode it found. Jpeg and LZMA decoder are the old small functions that sea-bios support, so I think user could use that format as an option. Paul -- Best Regards Wayne Xia mail:xiaw...@linux.vnet.ibm.com tel:86-010-82450803
Re: [Qemu-devel] [PATCH v5] showing a splash picture when start, seabios image for test
于 2011-7-5 2:31, Paul Brook 写道: jpeg decoder have its limitation, it only accept jpg file with width=16*M, height=16*N. bmp decoder only accept 24bpp file, with a resolution that a video mode could support. Recommended is 640x480(mostly used). Doing image decoding in the bios seems particularly pointless. Why don't you just pass the bios raw image data? If you really want to directly support fancier formats IMO it makes much more sense to do that in qemu itself. There we can use the same libraries as everyone else (libjpeg, libpng, etc) rather than badly reimpleenting them inside the bios. Paul I think the BMP file with 24bpp is almost the raw image data that need just a little format adjusting in bios according to the video mode it found. Jpeg and LZMA decoder are the old small functions that sea-bios support, so I think user could use that format as an option. -- Best Regards Wayne Xia mail:xiaw...@linux.vnet.ibm.com tel:86-010-82450803
[Qemu-devel] buildbot failure in qemu on trivial-patches_i386_debian_5_0
The Buildbot has detected a new failure on builder trivial-patches_i386_debian_5_0 while building qemu. Full details are available at: http://buildbot.b1-systems.de/qemu/builders/trivial-patches_i386_debian_5_0/builds/24 Buildbot URL: http://buildbot.b1-systems.de/qemu/ Buildslave for this Build: yuzuki Build Reason: The Nightly scheduler named 'nightly_trivial-patches' triggered this build Build Source Stamp: [branch trivial-patches] HEAD Blamelist: BUILD FAILED: failed git sincerely, -The Buildbot
[Qemu-devel] [PATCH 5/5] block: add bdrv_copy_header()
Signed-off-by: Devin Nakamura devin...@gmail.com
---
block.c | 10 ++
block.h |2 ++
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/block.c b/block.c
index c9ea201..c6c36e7 100644
--- a/block.c
+++ b/block.c
@@ -3061,3 +3061,13 @@ int bdrv_map(BlockDriverState *bs, uint64_t
*guest_offset,
return drv-bdrv_map(bs, guest_offset, host_offset,
contiguous_bytes);
}
+
+int bdrv_copy_header(BlockDriverState *bs)
+{
+BlockDriver *drv = bs-drv;
+if (!drv)
+return -ENOMEDIUM;
+if (!drv-bdrv_copy_header)
+return -ENOTSUP;
+return drv-bdrv_copy_header(bs);
+}
diff --git a/block.h b/block.h
index ed21ead..0583875 100644
--- a/block.h
+++ b/block.h
@@ -256,6 +256,8 @@ int bdrv_get_mapping(BlockDriverState *bs, uint64_t
*guest_offset,
uint64_t *host_offset, uint64_t *contiguous_bytes);
int bdrv_map(BlockDriverState *bs, uint64_t *guest_offset,
uint64_t *host_offset, uint64_t *contiguous_bytes);
+int bdrv_copy_header(BlockDriverState *bs);
+
typedef enum {
BLKDBG_L1_UPDATE,
--
1.7.6.rc1
[Qemu-devel] [PATCH 2/5] block: add bdrv_open_conversion_target
Signed-off-by: Devin Nakamura devin...@gmail.com
---
block.c | 19 +++
block.h |2 ++
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/block.c b/block.c
index 24a25d5..e7699a6 100644
--- a/block.c
+++ b/block.c
@@ -3018,3 +3018,22 @@ out:
return ret;
}
+
+
+int bdrv_open_conversion_target(BlockDriverState **bs,
+char *filename, char *target_fmt, QEMUOptionParameter *options)
+{
+BlockDriver *drv;
+
+drv = bdrv_find_format(target_fmt);
+if(!drv){
+return -ENOENT;
+}
+
+if(!drv-bdrv_open_conversion_target){
+return -ENOTSUP;
+}
+*bs = bdrv_new();
+(*bs)-opaque = qemu_malloc(drv-instance_size);
+return drv-bdrv_open_conversion_target(*bs, filename, options);
+}
diff --git a/block.h b/block.h
index 859d1d9..da87afb 100644
--- a/block.h
+++ b/block.h
@@ -250,6 +250,8 @@ int64_t bdrv_get_dirty_count(BlockDriverState *bs);
void bdrv_set_in_use(BlockDriverState *bs, int in_use);
int bdrv_in_use(BlockDriverState *bs);
+int bdrv_open_conversion_target(BlockDriverState **bs, char *filename,
+char *target_fmt, QEMUOptionParameter
*options);
typedef enum {
BLKDBG_L1_UPDATE,
--
1.7.6.rc1
[Qemu-devel] [PATCH 4/5] block: add bdrv_map()
Signed-off-by: Devin Nakamura devin...@gmail.com
---
block.c | 12
block.h |2 ++
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/block.c b/block.c
index 302b0d5..c9ea201 100644
--- a/block.c
+++ b/block.c
@@ -3049,3 +3049,15 @@ int bdrv_get_mapping(BlockDriverState *bs, uint64_t
*guest_offset,
return drv-bdrv_get_mapping(bs, guest_offset, host_offset,
contiguous_bytes);
}
+
+int bdrv_map(BlockDriverState *bs, uint64_t *guest_offset,
+ uint64_t *host_offset, uint64_t *contiguous_bytes)
+{
+BlockDriver *drv = bs-drv;
+if (!drv)
+return -ENOMEDIUM;
+if (!drv-bdrv_map)
+return -ENOTSUP;
+return drv-bdrv_map(bs, guest_offset, host_offset,
+contiguous_bytes);
+}
diff --git a/block.h b/block.h
index 8207389..ed21ead 100644
--- a/block.h
+++ b/block.h
@@ -254,6 +254,8 @@ int bdrv_open_conversion_target(BlockDriverState **bs, char
*filename,
char *target_fmt, QEMUOptionParameter
*options);
int bdrv_get_mapping(BlockDriverState *bs, uint64_t *guest_offset,
uint64_t *host_offset, uint64_t *contiguous_bytes);
+int bdrv_map(BlockDriverState *bs, uint64_t *guest_offset,
+ uint64_t *host_offset, uint64_t *contiguous_bytes);
typedef enum {
BLKDBG_L1_UPDATE,
--
1.7.6.rc1
[Qemu-devel] [PATCH 1/5] block_int: add basic conversion api
add functions to block driver interface to support inplace image conversion
Signed-off-by: Devin Nakamura devin...@gmail.com
---
block_int.h | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/block_int.h b/block_int.h
index 1e265d2..ef311c7 100644
--- a/block_int.h
+++ b/block_int.h
@@ -136,6 +136,16 @@ struct BlockDriver {
* zeros, 0 otherwise.
*/
int (*bdrv_has_zero_init)(BlockDriverState *bs);
+
+/* Image conversion stuff */
+int (*bdrv_open_conversion_target)(BlockDriverState *bs, char *filename,
+QEMUOptionParameter *options);
+int (*bdrv_get_mapping)(BlockDriverState *bs, uint64_t *guest_offset,
+uint64_t *host_offset, uint64_t *contiguous_bytes);
+int (*bdrv_map)(BlockDriverState *bs, uint64_t *guest_offset,
+uint64_t *host_offset, uint64_t *contiguous_bytes);
+int (*bdrv_copy_header) (BlockDriverState *bs);
+
QLIST_ENTRY(BlockDriver) list;
};
--
1.7.6.rc1
[Qemu-devel] [PATCH 3/5] block: add bdrv_get_mapping()
Signed-off-by: Devin Nakamura devin...@gmail.com
---
block.c | 12
block.h |2 ++
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/block.c b/block.c
index e7699a6..302b0d5 100644
--- a/block.c
+++ b/block.c
@@ -3037,3 +3037,15 @@ int bdrv_open_conversion_target(BlockDriverState **bs,
(*bs)-opaque = qemu_malloc(drv-instance_size);
return drv-bdrv_open_conversion_target(*bs, filename, options);
}
+
+int bdrv_get_mapping(BlockDriverState *bs, uint64_t *guest_offset,
+ uint64_t *host_offset, uint64_t *contiguous_bytes)
+{
+BlockDriver *drv = bs-drv;
+if (!drv)
+return -ENOMEDIUM;
+if (!drv-bdrv_get_mapping)
+return -ENOTSUP;
+return drv-bdrv_get_mapping(bs, guest_offset, host_offset,
+contiguous_bytes);
+}
diff --git a/block.h b/block.h
index da87afb..8207389 100644
--- a/block.h
+++ b/block.h
@@ -252,6 +252,8 @@ int bdrv_in_use(BlockDriverState *bs);
int bdrv_open_conversion_target(BlockDriverState **bs, char *filename,
char *target_fmt, QEMUOptionParameter
*options);
+int bdrv_get_mapping(BlockDriverState *bs, uint64_t *guest_offset,
+ uint64_t *host_offset, uint64_t *contiguous_bytes);
typedef enum {
BLKDBG_L1_UPDATE,
--
1.7.6.rc1
[Qemu-devel] buildbot failure in qemu on ppc-next_i386_debian_5_0
The Buildbot has detected a new failure on builder ppc-next_i386_debian_5_0 while building qemu. Full details are available at: http://buildbot.b1-systems.de/qemu/builders/ppc-next_i386_debian_5_0/builds/24 Buildbot URL: http://buildbot.b1-systems.de/qemu/ Buildslave for this Build: yuzuki Build Reason: The Nightly scheduler named 'nightly_ppc-next' triggered this build Build Source Stamp: [branch ppc-next] HEAD Blamelist: BUILD FAILED: failed git sincerely, -The Buildbot
[Qemu-devel] buildbot failure in qemu on ppc-next_x86_64_debian_5_0
The Buildbot has detected a new failure on builder ppc-next_x86_64_debian_5_0 while building qemu. Full details are available at: http://buildbot.b1-systems.de/qemu/builders/ppc-next_x86_64_debian_5_0/builds/24 Buildbot URL: http://buildbot.b1-systems.de/qemu/ Buildslave for this Build: yuzuki Build Reason: The Nightly scheduler named 'nightly_ppc-next' triggered this build Build Source Stamp: [branch ppc-next] HEAD Blamelist: BUILD FAILED: failed git sincerely, -The Buildbot
Re: [Qemu-devel] [PATCH 2/3] Add fno-strict-overflow
On Mon, Jul 4, 2011 at 11:38 PM, Peter Maydell peter.mayd...@linaro.org wrote: On 4 July 2011 23:00, Raghavendra D Prabhu raghu.prabh...@gmail.com wrote: This is to avoid gcc optimizating out the comparison in assert, due to assumption of signed overflow being undefined by default (-Werror=strict-overflow). --- a/Makefile.hw +++ b/Makefile.hw @@ -9,7 +9,7 @@ include $(SRC_PATH)/rules.mak $(call set-vpath, $(SRC_PATH):$(SRC_PATH)/hw) -QEMU_CFLAGS+=-I.. -I$(SRC_PATH)/fpu +QEMU_CFLAGS+=-I.. -I$(SRC_PATH)/fpu -fno-strict-overflow Can you give a more detailed description of the problem this is trying to solve? I think it would be nicer if we could remove the assumptions about signed overflows instead, if that's practical. (Also, if we do want to add this compiler flag then it ought to be done in configure I think, as we do for -fno-strict-aliasing.) a correct C/C++ program must never generate signed overflow when computing an expression. It also means that a compiler may assume that a program will never generated signed overflow. http://www.airs.com/blog/archives/120 Stefan
[Qemu-devel] [Bug 591666] Re: broken pci_add auto storage
Hi Eran, Could you lauch lspci command on guestOS to see whether there is a new pci device hot-plug in? On the other hand, the guestOS need to be configured with CONFIG_VIRTIO_PCI, otherwise it can not contain the driver to monitor the virtio-pci device. Thanks -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/591666 Title: broken pci_add auto storage Status in QEMU: New Bug description: Doing: (qemu) pci_add auto storage file=/dev/ram0,if=virtio Results in: OK domain 0, bus 0, slot 5, function 0 However no device is actually added to the guest. QEMU: Latest git code (June 9) from git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git (seems to be broken from 0.12.1.2) KVM: Compiled from git://git.kernel.org/pub/scm/virt/kvm/kvm-kmod.git checked out (refs/remotes/origin/stable-2.6.32) Both guest and host are Ubuntu 9.10 with 2.6.32 kernel. Guest kernel has ACPI enabled (specifically, the PCI slot detection driver) Guest executed with the following parameters: -boot c -drive file=/home/eranr/kvm_images/ubuntu-9.10-2.6.32-perf.img,if=ide,boot=on -m 4096 -net nic,model=virtio -net tap,ifname=qtap0,script=no -vnc :0 -smp 1,cores=1,threads=0 -monitor tcp:localhost:6001,server,nowait To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/591666/+subscriptions
