[Spice-commits] 8 commits - VERSION docs/specs hmp.c hw/pci-host hw/virtio target-ppc/machine.c

Gerd Hoffmann kraxel at kemper.freedesktop.org
Wed Apr 22 04:54:50 PDT 2015

 VERSION               |    2 
 docs/specs/fw_cfg.txt |  205 ++++++++++++++++++++++++++++++++++++++++++++++++++
 hmp.c                 |    3 
 hw/pci-host/bonito.c  |    4 
 hw/virtio/vhost.c     |    7 +
 target-ppc/machine.c  |    4 
 6 files changed, 217 insertions(+), 8 deletions(-)

New commits:
commit f2a581010cb8e3a2564a45a2863a33a732cc2fc7
Author: Peter Maydell <peter.maydell at linaro.org>
Date:   Mon Apr 20 17:13:16 2015 +0100

    Update version for v2.3.0-rc4 release
    Signed-off-by: Peter Maydell <peter.maydell at linaro.org>

diff --git a/VERSION b/VERSION
index b1a306a..c3c2c0e 100644
@@ -1 +1 @@
commit e05ca8200216149008fa1b1d1d847bf16691f6b4
Author: Michael S. Tsirkin <mst at redhat.com>
Date:   Fri Apr 17 17:13:24 2015 +0200

    vhost: fix log base address
    VHOST_SET_LOG_BASE got an incorrect address, causing
    migration errors and potentially even memory corruption.
    Reported-by: Wen Congyang <wency at cn.fujitsu.com>
    Signed-off-by: Michael S. Tsirkin <mst at redhat.com>
    Reviewed-by: Amos Kong <akong at redhat.com>
    Message-id: 1429283565-32265-1-git-send-email-mst at redhat.com
    Signed-off-by: Peter Maydell <peter.maydell at linaro.org>

diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
index 5a12861..54851b7 100644
--- a/hw/virtio/vhost.c
+++ b/hw/virtio/vhost.c
@@ -288,7 +288,7 @@ static inline void vhost_dev_log_resize(struct vhost_dev* dev, uint64_t size)
     int r;
     log = g_malloc0(size * sizeof *log);
-    log_base = (uint64_t)(unsigned long)log;
+    log_base = (uintptr_t)log;
     r = dev->vhost_ops->vhost_call(dev, VHOST_SET_LOG_BASE, &log_base);
     assert(r >= 0);
     /* Sync only the range covered by the old log */
@@ -1057,10 +1057,13 @@ int vhost_dev_start(struct vhost_dev *hdev, VirtIODevice *vdev)
     if (hdev->log_enabled) {
+        uint64_t log_base;
         hdev->log_size = vhost_get_log_size(hdev);
         hdev->log = hdev->log_size ?
             g_malloc0(hdev->log_size * sizeof *hdev->log) : NULL;
-        r = hdev->vhost_ops->vhost_call(hdev, VHOST_SET_LOG_BASE, hdev->log);
+        log_base = (uintptr_t)hdev->log;
+        r = hdev->vhost_ops->vhost_call(hdev, VHOST_SET_LOG_BASE, &log_base);
         if (r < 0) {
             r = -errno;
             goto fail_log;
commit 638b8366200130cc7cf7a026630bc6bfb63b0c4c
Author: Alberto Garcia <berto at igalia.com>
Date:   Fri Apr 17 15:44:48 2015 +0300

    hmp: fix crash in 'info block -n -v'
    The image field in BlockDeviceInfo should never be null, however
    bdrv_block_device_info() is not filling it in.
    This makes the 'info block -n -v' command crash QEMU.
    The proper solution is probably to move the relevant code from
    bdrv_query_info() to bdrv_block_device_info(), but since we're too
    close to the release for that this simpler workaround solves the
    Signed-off-by: Alberto Garcia <berto at igalia.com>
    Message-id: 1429274688-8115-1-git-send-email-berto at igalia.com
    Signed-off-by: Peter Maydell <peter.maydell at linaro.org>

diff --git a/hmp.c b/hmp.c
index f31ae27..f142d36 100644
--- a/hmp.c
+++ b/hmp.c
@@ -391,7 +391,8 @@ static void print_block_info(Monitor *mon, BlockInfo *info,
-    if (verbose) {
+    /* TODO: inserted->image should never be null */
+    if (verbose && inserted->image) {
         monitor_printf(mon, "\nImages:\n");
         image_info = inserted->image;
         while (1) {
commit 87a8adc0876c11a434d3ecdfb10cd797259ddaaa
Merge: b6df74c 0ca4f94
Author: Peter Maydell <peter.maydell at linaro.org>
Date:   Fri Apr 17 12:54:46 2015 +0100

    Merge remote-tracking branch 'remotes/lalrae/tags/mips-20150417-2' into staging
    MIPS patches 2015-04-17
    * fix broken fulong2e
    # gpg: Signature made Fri Apr 17 12:14:37 2015 BST using RSA key ID 0B29DA6B
    # gpg: Can't check signature: public key not found
    * remotes/lalrae/tags/mips-20150417-2:
      mips: fix broken fulong2e machine
    Signed-off-by: Peter Maydell <peter.maydell at linaro.org>

commit b6df74c46528646f3163890cf16b74af551c3494
Merge: 993ebe4 6cec43e
Author: Peter Maydell <peter.maydell at linaro.org>
Date:   Fri Apr 17 12:37:38 2015 +0100

    Merge remote-tracking branch 'remotes/kraxel/tags/pull-fwcfg-20150414-1' into staging
    fw_cfg: add documentation file (docs/specs/fw_cfg.txt)
    # gpg: Signature made Tue Apr 14 12:22:20 2015 BST using RSA key ID D3E87138
    # gpg: Good signature from "Gerd Hoffmann (work) <kraxel at redhat.com>"
    # gpg:                 aka "Gerd Hoffmann <gerd at kraxel.org>"
    # gpg:                 aka "Gerd Hoffmann (private) <kraxel at gmail.com>"
    * remotes/kraxel/tags/pull-fwcfg-20150414-1:
      fw_cfg: add documentation file (docs/specs/fw_cfg.txt)
    Signed-off-by: Peter Maydell <peter.maydell at linaro.org>

commit 0ca4f94195cce77b624edc6d9abcf14a3bf01f06
Author: Paolo Bonzini <pbonzini at redhat.com>
Date:   Thu Apr 16 21:11:23 2015 +0100

    mips: fix broken fulong2e machine
    After commit 5312bd8 the bonito_readl() and bonito_writel() have been
    accessing incorrect addresses. Consequently QEMU is crashing when trying
    to boot Linux kernel on fulong2e machine.
    Cc: qemu-stable at nongnu.org
    Signed-off-by: Paolo Bonzini <pbonzini at redhat.com>
    Signed-off-by: Leon Alrae <leon.alrae at imgtec.com>

diff --git a/hw/pci-host/bonito.c b/hw/pci-host/bonito.c
index 8bdd569..8134d0b 100644
--- a/hw/pci-host/bonito.c
+++ b/hw/pci-host/bonito.c
@@ -233,7 +233,7 @@ static void bonito_writel(void *opaque, hwaddr addr,
     uint32_t saddr;
     int reset = 0;
-    saddr = (addr - BONITO_REGBASE) >> 2;
+    saddr = addr >> 2;
     DPRINTF("bonito_writel "TARGET_FMT_plx" val %x saddr %x\n", addr, val, saddr);
     switch (saddr) {
@@ -295,7 +295,7 @@ static uint64_t bonito_readl(void *opaque, hwaddr addr,
     PCIBonitoState *s = opaque;
     uint32_t saddr;
-    saddr = (addr - BONITO_REGBASE) >> 2;
+    saddr = addr >> 2;
     DPRINTF("bonito_readl "TARGET_FMT_plx"\n", addr);
     switch (saddr) {
commit 993ebe4a0be9aa4e4821818a81fab00b1ab1a79a
Author: Mark Cave-Ayland <mark.cave-ayland at ilande.co.uk>
Date:   Fri Apr 17 08:16:49 2015 +0100

    target-ppc: don't invalidate msr MSR_HVB bit in cpu_post_load
    The invalidation code introduced in commit 2360b works by inverting most bits
    of env->msr to ensure that hreg_store_msr() will forcibly update the CPU env
    state to reflect the new msr value post-migration. Unfortunately
    hreg_store_msr() is called with alter_hv set to 0 which preserves the MSR_HVB
    state from the CPU env which is now the opposite value to what it should be.
    Ensure that we don't invalidate the msr MSR_HVB bit during cpu_post_load so
    that the correct value is restored. This fixes suspend/resume for PPC64.
    Reported-by: Stefan Berger <stefanb at linux.vnet.ibm.com>
    Signed-off-by: Mark Cave-Ayland <mark.cave-ayland at ilande.co.uk>
    Reviewed-by: Alexander Graf <agraf at suse.de>
    Message-id: 1429255009-12751-1-git-send-email-mark.cave-ayland at ilande.co.uk
    Signed-off-by: Peter Maydell <peter.maydell at linaro.org>

diff --git a/target-ppc/machine.c b/target-ppc/machine.c
index 3921012..d875211 100644
--- a/target-ppc/machine.c
+++ b/target-ppc/machine.c
@@ -192,9 +192,9 @@ static int cpu_post_load(void *opaque, int version_id)
         ppc_store_sdr1(env, env->spr[SPR_SDR1]);
-    /* Mark msr bits except MSR_TGPR invalid before restoring */
+    /* Invalidate all msr bits except MSR_TGPR/MSR_HVB before restoring */
     msr = env->msr;
-    env->msr ^= ~(1ULL << MSR_TGPR);
+    env->msr ^= ~((1ULL << MSR_TGPR) | MSR_HVB);
     ppc_store_msr(env, msr);
commit 6cec43e178cde38a3eac43a2cd741ce741b10f36
Author: Gabriel L. Somlo <somlo at cmu.edu>
Date:   Thu Apr 9 10:40:01 2015 -0400

    fw_cfg: add documentation file (docs/specs/fw_cfg.txt)
    This document covers the guest-side hardware interface, as
    well as the host-side programming API of QEMU's firmware
    configuration (fw_cfg) device.
    Signed-off-by: Jordan Justen <jordan.l.justen at intel.com>
    Signed-off-by: Gabriel Somlo <somlo at cmu.edu>
    Reviewed-by: Laszlo Ersek <lersek at redhat.com>
    Signed-off-by: Gerd Hoffmann <kraxel at redhat.com>

diff --git a/docs/specs/fw_cfg.txt b/docs/specs/fw_cfg.txt
new file mode 100644
index 0000000..6accd92
--- /dev/null
+++ b/docs/specs/fw_cfg.txt
@@ -0,0 +1,205 @@
+QEMU Firmware Configuration (fw_cfg) Device
+= Guest-side Hardware Interface =
+This hardware interface allows the guest to retrieve various data items
+(blobs) that can influence how the firmware configures itself, or may
+contain tables to be installed for the guest OS. Examples include device
+boot order, ACPI and SMBIOS tables, virtual machine UUID, SMP and NUMA
+information, kernel/initrd images for direct (Linux) kernel booting, etc.
+== Selector (Control) Register ==
+* Write only
+* Location: platform dependent (IOport or MMIO)
+* Width: 16-bit
+* Endianness: little-endian (if IOport), or big-endian (if MMIO)
+A write to this register sets the index of a firmware configuration
+item which can subsequently be accessed via the data register.
+Setting the selector register will cause the data offset to be set
+to zero. The data offset impacts which data is accessed via the data
+register, and is explained below.
+Bit14 of the selector register indicates whether the configuration
+setting is being written. A value of 0 means the item is only being
+read, and all write access to the data port will be ignored. A value
+of 1 means the item's data can be overwritten by writes to the data
+register. In other words, configuration write mode is enabled when
+the selector value is between 0x4000-0x7fff or 0xc000-0xffff.
+NOTE: As of QEMU v2.4, writes to the fw_cfg data register are no
+      longer supported, and will be ignored (treated as no-ops)!
+Bit15 of the selector register indicates whether the configuration
+setting is architecture specific. A value of 0 means the item is a
+generic configuration item. A value of 1 means the item is specific
+to a particular architecture. In other words, generic configuration
+items are accessed with a selector value between 0x0000-0x7fff, and
+architecture specific configuration items are accessed with a selector
+value between 0x8000-0xffff.
+== Data Register ==
+* Read/Write (writes ignored as of QEMU v2.4)
+* Location: platform dependent (IOport [*] or MMIO)
+* Width: 8-bit (if IOport), 8/16/32/64-bit (if MMIO)
+* Endianness: string-preserving
+[*] On platforms where the data register is exposed as an IOport, its
+port number will always be one greater than the port number of the
+selector register. In other words, the two ports overlap, and can not
+be mapped separately.
+The data register allows access to an array of bytes for each firmware
+configuration data item. The specific item is selected by writing to
+the selector register, as described above.
+Initially following a write to the selector register, the data offset
+will be set to zero. Each successful access to the data register will
+increment the data offset by the appropriate access width.
+Each firmware configuration item has a maximum length of data
+associated with the item. After the data offset has passed the
+end of this maximum data length, then any reads will return a data
+value of 0x00, and all writes will be ignored.
+An N-byte wide read of the data register will return the next available
+N bytes of the selected firmware configuration item, as a substring, in
+increasing address order, similar to memcpy().
+== Register Locations ==
+=== x86, x86_64 Register Locations ===
+Selector Register IOport: 0x510
+Data Register IOport:     0x511
+== Firmware Configuration Items ==
+=== Signature (Key 0x0000, FW_CFG_SIGNATURE) ===
+The presence of the fw_cfg selector and data registers can be verified
+by selecting the "signature" item using key 0x0000 (FW_CFG_SIGNATURE),
+and reading four bytes from the data register. If the fw_cfg device is
+present, the four bytes read will contain the characters "QEMU".
+=== Revision (Key 0x0001, FW_CFG_ID) ===
+A 32-bit little-endian unsigned int, this item is used as an interface
+revision number, and is currently set to 1 by QEMU when fw_cfg is
+=== File Directory (Key 0x0019, FW_CFG_FILE_DIR) ===
+Firmware configuration items stored at selector keys 0x0020 or higher
+(FW_CFG_FILE_FIRST or higher) have an associated entry in a directory
+structure, which makes it easier for guest-side firmware to identify
+and retrieve them. The format of this file directory (from fw_cfg.h in
+the QEMU source tree) is shown here, slightly annotated for clarity:
+struct FWCfgFiles {		/* the entire file directory fw_cfg item */
+    uint32_t count;		/* number of entries, in big-endian format */
+    struct FWCfgFile f[];	/* array of file entries, see below */
+struct FWCfgFile {		/* an individual file entry, 64 bytes total */
+    uint32_t size;		/* size of referenced fw_cfg item, big-endian */
+    uint16_t select;		/* selector key of fw_cfg item, big-endian */
+    uint16_t reserved;
+    char name[56];		/* fw_cfg item name, NUL-terminated ascii */
+=== All Other Data Items ===
+Please consult the QEMU source for the most up-to-date and authoritative
+list of selector keys and their respective items' purpose and format.
+=== Ranges ===
+Theoretically, there may be up to 0x4000 generic firmware configuration
+items, and up to 0x4000 architecturally specific ones.
+Selector Reg.    Range Usage
+---------------  -----------
+0x0000 - 0x3fff  Generic (0x0000 - 0x3fff, RO)
+0x4000 - 0x7fff  Generic (0x0000 - 0x3fff, RW, ignored in QEMU v2.4+)
+0x8000 - 0xbfff  Arch. Specific (0x0000 - 0x3fff, RO)
+0xc000 - 0xffff  Arch. Specific (0x0000 - 0x3fff, RW, ignored in v2.4+)
+In practice, the number of allowed firmware configuration items is given
+by the value of FW_CFG_MAX_ENTRY (see fw_cfg.h).
+= Host-side API =
+The following functions are available to the QEMU programmer for adding
+data to a fw_cfg device during guest initialization (see fw_cfg.h for
+each function's complete prototype):
+== fw_cfg_add_bytes() ==
+Given a selector key value, starting pointer, and size, create an item
+as a raw "blob" of the given size, available by selecting the given key.
+The data referenced by the starting pointer is only linked, NOT copied,
+into the data structure of the fw_cfg device.
+== fw_cfg_add_string() ==
+Instead of a starting pointer and size, this function accepts a pointer
+to a NUL-terminated ascii string, and inserts a newly allocated copy of
+the string (including the NUL terminator) into the fw_cfg device data
+== fw_cfg_add_iXX() ==
+Insert an XX-bit item, where XX may be 16, 32, or 64. These functions
+will convert a 16-, 32-, or 64-bit integer to little-endian, then add
+a dynamically allocated copy of the appropriately sized item to fw_cfg
+under the given selector key value.
+== fw_cfg_add_file() ==
+Given a filename (i.e., fw_cfg item name), starting pointer, and size,
+create an item as a raw "blob" of the given size. Unlike fw_cfg_add_bytes()
+above, the next available selector key (above 0x0020, FW_CFG_FILE_FIRST)
+will be used, and a new entry will be added to the file directory structure
+(at key 0x0019), containing the item name, blob size, and automatically
+assigned selector key value. The data referenced by the starting pointer
+is only linked, NOT copied, into the fw_cfg data structure.
+== fw_cfg_add_file_callback() ==
+Like fw_cfg_add_file(), but additionally sets pointers to a callback
+function (and opaque argument), which will be executed host-side by
+QEMU each time a byte is read by the guest from this particular item.
+NOTE: The callback function is given the opaque argument set by
+fw_cfg_add_file_callback(), but also the current data offset,
+allowing it the option of only acting upon specific offset values
+(e.g., 0, before the first data byte of the selected item is
+returned to the guest).
+== fw_cfg_modify_file() ==
+Given a filename (i.e., fw_cfg item name), starting pointer, and size,
+completely replace the configuration item referenced by the given item
+name with the new given blob. If an existing blob is found, its
+callback information is removed, and a pointer to the old data is
+returned to allow the caller to free it, helping avoid memory leaks.
+If a configuration item does not already exist under the given item
+name, a new item will be created as with fw_cfg_add_file(), and NULL
+is returned to the caller. In any case, the data referenced by the
+starting pointer is only linked, NOT copied, into the fw_cfg data
+== fw_cfg_add_callback() ==
+Like fw_cfg_add_bytes(), but additionally sets pointers to a callback
+function (and opaque argument), which will be executed host-side by
+QEMU each time a guest-side write operation to this particular item
+completes fully overwriting the item's data.
+NOTE: This function is deprecated, and will be completely removed
+starting with QEMU v2.4.

More information about the Spice-commits mailing list