Skip to content
Snippets Groups Projects
  1. Jan 19, 2015
  2. Jan 16, 2015
    • Peter Maydell's avatar
      Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20150116' into staging · 1e42c353
      Peter Maydell authored
      
      target-arm queue:
       * fix endianness handling in fwcfg wide registers
       * fix broken crypto insn emulation on big endian hosts
      
      # gpg: Signature made Fri 16 Jan 2015 12:04:08 GMT using RSA key ID 14360CDE
      # gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>"
      
      * remotes/pmaydell/tags/pull-target-arm-20150116:
        fw_cfg: fix endianness in fw_cfg_data_mem_read() / _write()
        target-arm: crypto: fix BE host support
      
      Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      1e42c353
    • Laszlo Ersek's avatar
      fw_cfg: fix endianness in fw_cfg_data_mem_read() / _write() · 36b62ae6
      Laszlo Ersek authored
      
      (1) Let's contemplate what device endianness means, for a memory mapped
      device register (independently of QEMU -- that is, on physical hardware).
      
      It determines the byte order that the device will put on the data bus when
      the device is producing a *numerical value* for the CPU. This byte order
      may differ from the CPU's own byte order, therefore when software wants to
      consume the *numerical value*, it may have to swap the byte order first.
      
      For example, suppose we have a device that exposes in a 2-byte register
      the number of sheep we have to count before falling asleep. If the value
      is decimal 37 (0x0025), then a big endian register will produce [0x00,
      0x25], while a little endian register will produce [0x25, 0x00].
      
      If the device register is big endian, but the CPU is little endian, the
      numerical value will read as 0x2500 (decimal 9472), which software has to
      byte swap before use.
      
      However... if we ask the device about who stole our herd of sheep, and it
      answers "XY", then the byte representation coming out of the register must
      be [0x58, 0x59], regardless of the device register's endianness for
      numeric values. And, software needs to copy these bytes into a string
      field regardless of the CPU's own endianness.
      
      (2) QEMU's device register accessor functions work with *numerical values*
      exclusively, not strings:
      
      The emulated register's read accessor function returns the numerical value
      (eg. 37 decimal, 0x0025) as a *host-encoded* uint64_t. QEMU translates
      this value for the guest to the endianness of the emulated device register
      (which is recorded in MemoryRegionOps.endianness). Then guest code must
      translate the numerical value from device register to guest CPU
      endianness, before including it in any computation (see (1)).
      
      (3) However, the data register of the fw_cfg device shall transfer strings
      *only* -- that is, opaque blobs. Interpretation of any given blob is
      subject to further agreement -- it can be an integer in an independently
      determined byte order, or a genuine string, or an array of structs of
      integers (in some byte order) and fixed size strings, and so on.
      
      Because register emulation in QEMU is integer-preserving, not
      string-preserving (see (2)), we have to jump through a few hoops.
      
      (3a) We defined the memory mapped fw_cfg data register as
      DEVICE_BIG_ENDIAN.
      
      The particular choice is not really relevant -- we picked BE only for
      consistency with the control register, which *does* transfer integers --
      but our choice affects how we must host-encode values from fw_cfg strings.
      
      (3b) Since we want the fw_cfg string "XY" to appear as the [0x58, 0x59]
      array on the data register, *and* we picked DEVICE_BIG_ENDIAN, we must
      compose the host (== C language) value 0x5859 in the read accessor
      function.
      
      (3c) When the guest performs the read access, the immediate uint16_t value
      will be 0x5958 (in LE guests) and 0x5859 (in BE guests). However, the
      uint16_t value does not matter. The only thing that matters is the byte
      pattern [0x58, 0x59], which the guest code must copy into the target
      string *without* any byte-swapping.
      
      (4) Now I get to explain where I screwed up. :(
      
      When we decided for big endian *integer* representation in the MMIO data
      register -- see (3a) --, I mindlessly added an indiscriminate
      byte-swizzling step to the (little endian) guest firmware.
      
      This was a grave error -- it violates (3c) --, but I didn't realize it. I
      only saw that the code I otherwise intended for fw_cfg_data_mem_read():
      
          value = 0;
          for (i = 0; i < size; ++i) {
              value = (value << 8) | fw_cfg_read(s);
          }
      
      didn't produce the expected result in the guest.
      
      In true facepalm style, instead of blaming my guest code (which violated
      (3c)), I blamed my host code (which was correct). Ultimately, I coded
      ldX_he_p() into fw_cfg_data_mem_read(), because that happened to work.
      
      Obviously (...in retrospect) that was wrong. Only because my host happened
      to be LE, ldX_he_p() composed the (otherwise incorrect) host value 0x5958
      from the fw_cfg string "XY". And that happened to compensate for the bogus
      indiscriminate byte-swizzling in my guest code.
      
      Clearly the current code leaks the host endianness through to the guest,
      which is wrong. Any device should work the same regardless of host
      endianness.
      
      The solution is to compose the host-endian representation (2) of the big
      endian interpretation (3a, 3b) of the fw_cfg string, and to drop the wrong
      byte-swizzling in the guest (3c).
      
      Brown paper bag time for me.
      
      Signed-off-by: default avatarLaszlo Ersek <lersek@redhat.com>
      Message-id: 1420024880-15416-1-git-send-email-lersek@redhat.com
      Reviewed-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      36b62ae6
    • Ard Biesheuvel's avatar
      target-arm: crypto: fix BE host support · b449ca3c
      Ard Biesheuvel authored
      
      The crypto emulation code in target-arm/crypto_helper.c never worked
      correctly on big endian hosts, due to the fact that it uses a union
      of array types to convert between the native VFP register size (64
      bits) and the types used in the algorithms (bytes and 32 bit words)
      
      We cannot just swab between LE and BE when reading and writing the
      registers, as the SHA code performs word additions, so instead, add
      array accessors for the CRYPTO_STATE type whose LE and BE specific
      implementations ensure that the correct array elements are referenced.
      
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Acked-by: default avatarLaszlo Ersek <lersek@redhat.com>
      Message-id: 1420208303-24111-1-git-send-email-ard.biesheuvel@linaro.org
      Reviewed-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      b449ca3c
    • Peter Maydell's avatar
      Merge remote-tracking branch 'remotes/amit-migration/tags/mig-2.3-1' into staging · e68cba36
      Peter Maydell authored
      
      A set of patches collected over the holidays.  Mix of optimizations and
      fixes.
      
      # gpg: Signature made Fri 16 Jan 2015 07:42:00 GMT using RSA key ID 854083B6
      # gpg: Good signature from "Amit Shah <amit@amitshah.net>"
      # gpg:                 aka "Amit Shah <amit@kernel.org>"
      # gpg:                 aka "Amit Shah <amitshah@gmx.net>"
      
      * remotes/amit-migration/tags/mig-2.3-1:
        vmstate: type-check sub-arrays
        migration_cancel: shutdown migration socket
        Handle bi-directional communication for fd migration
        socket shutdown
        Tests: QEMUSizedBuffer/QEMUBuffer
        QEMUSizedBuffer: only free qsb that qemu_bufopen allocated
        xbzrle: rebuild the cache_is_cached function
        xbzrle: optimize XBZRLE to decrease the cache misses
      
      Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      e68cba36
    • Paolo Bonzini's avatar
      vmstate: type-check sub-arrays · ea987c2c
      Paolo Bonzini authored
      
      While we cannot check against the type of the full array, we can check
      against the type of the fields.
      
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarAmit Shah <amit.shah@redhat.com>
      ea987c2c
    • Dr. David Alan Gilbert's avatar
      migration_cancel: shutdown migration socket · a26ba26e
      Dr. David Alan Gilbert authored
      
      Force shutdown on migration socket on cancel to cause the cancel
      to complete even if the socket is blocked on a dead network.
      
      Signed-off-by: default avatarDr. David Alan Gilbert <dgilbert@redhat.com>
      Reviewed-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Reviewed-by: default avatarAmit Shah <amit.shah@redhat.com>
      Signed-off-by: default avatarAmit Shah <amit.shah@redhat.com>
      a26ba26e
    • Cristian Klein's avatar
      Handle bi-directional communication for fd migration · 131fe9b8
      Cristian Klein authored
      
      libvirt prefers opening the TCP connection itself, for two reasons.
      First, connection failed errors can be detected easier, without having
      to parse qemu's error output.
      Second, libvirt might be asked to secure the transfer by tunnelling the
      communication through an TLS layer.
      Therefore, libvirt opens the TCP connection itself and passes an FD to qemu
      using QMP and a POSIX-specific mechanism.
      
      Hence, in order to make the reverse-path work in such cases, qemu needs to
      distinguish if the transmitted FD is a socket (reverse-path available)
      or not (reverse-path might not be available) and use the corresponding
      abstraction.
      
      Signed-off-by: default avatarCristian Klein <cristian.klein@cs.umu.se>
      Reviewed-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Reviewed-by: default avatarAmit Shah <amit.shah@redhat.com>
      Signed-off-by: default avatarAmit Shah <amit.shah@redhat.com>
      131fe9b8
    • Dr. David Alan Gilbert's avatar
      socket shutdown · e1a8c9b6
      Dr. David Alan Gilbert authored
      
      Add QEMUFile interface to allow a socket to be 'shut down' - i.e. any
      reads/writes will fail (and any blocking read/write will be woken).
      
      Signed-off-by: default avatarDr. David Alan Gilbert <dgilbert@redhat.com>
      Reviewed-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Reviewed-by: default avatarAmit Shah <amit.shah@redhat.com>
      Signed-off-by: default avatarAmit Shah <amit.shah@redhat.com>
      e1a8c9b6
    • Yang Hongyang's avatar
      Tests: QEMUSizedBuffer/QEMUBuffer · 8580b064
      Yang Hongyang authored
      
      Modify some of tests/test-vmstate.c due to qemu_bufopen() change.
      If you create a QEMUSizedBuffer yourself, you have to explicitly
      free it.
      
      Signed-off-by: default avatarYang Hongyang <yanghy@cn.fujitsu.com>
      Cc: Dr. David Alan Gilbert <dgilbert@redhat.com>
      Cc: Juan Quintela <quintela@redhat.com>
      Cc: Amit Shah <amit.shah@redhat.com>
      Reviewed-by: default avatarDr. David Alan Gilbert <dgilbert@redhat.com>
      Signed-off-by: default avatarAmit Shah <amit.shah@redhat.com>
      8580b064
    • Yang Hongyang's avatar
      QEMUSizedBuffer: only free qsb that qemu_bufopen allocated · f018d8cd
      Yang Hongyang authored
      
      Only free qsb that qemu_bufopen allocated, and also allow
      qemu_bufopen accept qsb as input for write operation. It
      will make the API more logical:
      1.If you create the QEMUSizedBuffer yourself, you need to
        free it by using qsb_free() but not depends on other API
        like qemu_fclose.
      2.allow qemu_bufopen() accept QEMUSizedBuffer as input for
        write operation, otherwise, it will be a little strange
        for this API won't accept the second parameter.
      
      This brings API change, since there are only 3
      users of this API currently, this change only impact the
      first one which will be fixed in patch 2 of this patchset,
      so I think it is safe to do this change.
      
      1     70  tests/test-vmstate.c <<open_mem_file_read>>
                  return qemu_bufopen("r", qsb);
      2    404  tests/test-vmstate.c <<test_save_noskip>>
                  QEMUFile *fsave = qemu_bufopen("w", NULL);
      3    424  tests/test-vmstate.c <<test_save_skip>>
                  QEMUFile *fsave = qemu_bufopen("w", NULL);
      
      Signed-off-by: default avatarYang Hongyang <yanghy@cn.fujitsu.com>
      Cc: Dr. David Alan Gilbert <dgilbert@redhat.com>
      Cc: Juan Quintela <quintela@redhat.com>
      Cc: Amit Shah <amit.shah@redhat.com>
      Reviewed-by: default avatarDr. David Alan Gilbert <dgilbert@redhat.com>
      Signed-off-by: default avatarAmit Shah <amit.shah@redhat.com>
      f018d8cd
  3. Jan 15, 2015
  4. Jan 14, 2015
  5. Jan 13, 2015
    • Peter Maydell's avatar
      Merge remote-tracking branch 'remotes/sstabellini/xen-2015-01-13' into staging · 3a7f560f
      Peter Maydell authored
      
      * remotes/sstabellini/xen-2015-01-13:
        xen-hvm: increase maxmem before calling xc_domain_populate_physmap
        xen-pt: Fix PCI devices re-attach failed
      
      Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      3a7f560f
    • Stefano Stabellini's avatar
      xen-hvm: increase maxmem before calling xc_domain_populate_physmap · c1d322e6
      Stefano Stabellini authored
      
      Increase maxmem before calling xc_domain_populate_physmap_exact to
      avoid the risk of running out of guest memory. This way we can also
      avoid complex memory calculations in libxl at domain construction
      time.
      
      This patch fixes an abort() when assigning more than 4 NICs to a VM.
      
      Signed-off-by: default avatarStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Signed-off-by: default avatarDon Slutz <dslutz@verizon.com>
      c1d322e6
    • Peter Maydell's avatar
      Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' into staging · a00369fc
      Peter Maydell authored
      
      # gpg: Signature made Tue 13 Jan 2015 13:48:06 GMT using RSA key ID 81AB73C8
      # gpg: Good signature from "Stefan Hajnoczi <stefanha@redhat.com>"
      # gpg:                 aka "Stefan Hajnoczi <stefanha@gmail.com>"
      
      * remotes/stefanha/tags/block-pull-request: (38 commits)
        NVMe: Set correct VS Value for 1.1 Compliant Controllers
        MAINTAINERS: Add migration/block* to block subsystem
        MAINTAINERS: Update email addresses for Chrysostomos Nanakos
        nvme: Fix get/set number of queues feature
        ide: Implement VPD response for ATAPI
        block: Split BLOCK_OP_TYPE_COMMIT to BLOCK_OP_TYPE_COMMIT_{SOURCE, TARGET}
        block: limited request size in write zeroes unsupported path
        coroutine: try harder not to delete coroutines
        coroutine: drop qemu_coroutine_adjust_pool_size
        coroutine: rewrite pool to avoid mutex
        QSLIST: add lock-free operations
        test-coroutine: avoid overflow on 32-bit systems
        qemu-thread: add per-thread atexit functions
        coroutine-ucontext: use __thread
        qemu-iotests: Add supported os parameter for python tests
        qemu-iotests: Add "_supported_os Linux" to 058
        qemu-iotests: Replace "/bin/true" with "true"
        .gitignore: Ignore generated "common.env"
        libqos: Convert malloc-pc allocator to a generic allocator
        migration/block: fix pending() return value
        ...
      
      Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      a00369fc
Loading