1. 23 8月, 2010 6 次提交
  2. 21 8月, 2010 2 次提交
    • B
      Replace qemu_malloc + memset with qemu_mallocz · cc597832
      Blue Swirl 提交于
      Replace a qemu_malloc call, followed by a memset, with qemu_mallocz.
      
      Found with this Coccinelle semantic patch, adapted from
      Coccinelle test package rule 94:
      @@
      type T;
      expression x;
      expression E;
      @@
      
      - x = (T)qemu_malloc(E)
      + x = qemu_mallocz(E)
        ...
      (
      - memset(x,0,E);
      |
      - memset(x,0,sizeof(*x));
      )
      
      Some files (tests/*) had to be filtered out.
      Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>
      cc597832
    • B
      Use ARRAY_SIZE macro · 66fe09ee
      Blue Swirl 提交于
      Replace array size calculations with ARRAY_SIZE macro.
      
      Implemented with this Coccinelle semantic patch, adapted from
      Linux kernel:
      @@
      type T;
      T[] E;
      @@
      
      - (sizeof(E)/sizeof(*E))
      + ARRAY_SIZE(E)
      
      @@
      type T;
      T[] E;
      @@
      
      - (sizeof(E)/sizeof(E[...]))
      + ARRAY_SIZE(E)
      
      @@
      type T;
      T[] E;
      @@
      
      - (sizeof(E)/sizeof(T))
      + ARRAY_SIZE(E)
      
      Some files (*-dis.c, tests/*) had to be filtered out.
      Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>
      66fe09ee
  3. 20 8月, 2010 2 次提交
  4. 19 8月, 2010 4 次提交
  5. 16 8月, 2010 1 次提交
    • A
      sparc escc IUS improvements (SunOS 4.1.4 fix) · 9fc391f8
      Artyom Tarasenko 提交于
      According to scc_escc_um.pdf:
       - Reset Highest IUS must update irq status to allow processing
         of the next priority interrupt.
       - rx interrupt has always higher priority than tx on same channel
      
      The documentation only explicitly says that Reset Highest IUS
      command (0x38) clears IUS bits, not that it clears the corresponding
      interrupt too, so don't clear interrupts on this command.
      
      The patch allows SunOS 4.1.4 to use the serial ports
      Signed-off-by: NArtyom Tarasenko <atar4qemu@gmail.com>
      Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>
      9fc391f8
  6. 15 8月, 2010 7 次提交
  7. 11 8月, 2010 5 次提交
  8. 09 8月, 2010 2 次提交
  9. 08 8月, 2010 1 次提交
  10. 06 8月, 2010 3 次提交
  11. 04 8月, 2010 1 次提交
  12. 03 8月, 2010 6 次提交
    • A
      ide: Avoid canceling IDE DMA · 953844d1
      Andrea Arcangeli 提交于
      The reason for not actually canceling the I/O is because with
      virtualization and lots of VM running, a guest fs may mistake a
      overload of the host, as an IDE timeout. So rather than canceling the
      I/O, it's safer to wait I/O completion and simulate that the I/O has
      completed just before the io cancellation was requested by the
      guest. This way if ntfs or an app writes data without checking for
      -EIO retval, and it thinks the write has succeeded, it's less likely
      to run into troubles. Similar issues for reads.
      
      Furthermore because the DMA operation is splitted into many synchronous
      aio_read/write if there's more than one entry in the SG table, without this
      patch the DMA would be cancelled in the middle, something we've no idea if it
      happens on real hardware too or not. Overall this seems a great risk for zero
      gain.
      
      This approach is sure safer than previous code given we can't pretend all guest
      fs code out there to check for errors and reply the DMA if it was completed
      partially, given a timeout would never materialize on a real harddisk unless
      there are defective blocks (and defective blocks are practically only an issue
      for reads never for writes in any recent hardware as writing to blocks is the
      way to fix them) or the harddisk breaks as a whole.
      Signed-off-by: NIzik Eidus <ieidus@redhat.com>
      Signed-off-by: NAndrea Arcangeli <aarcange@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      953844d1
    • M
      block: Change bdrv_eject() not to drop the image · 4be9762a
      Markus Armbruster 提交于
      bdrv_eject() gets called when a device model opens or closes the tray.
      
      If the block driver implements method bdrv_eject(), that method gets
      called.  Drivers host_cdrom implements it, and it opens and closes the
      physical tray, and nothing else.  When a device model opens, then
      closes the tray, media changes only if the user actively changes the
      physical media while the tray is open.  This is matches how physical
      hardware behaves.
      
      If the block driver doesn't implement method bdrv_eject(), we do
      something quite different: opening the tray severs the connection to
      the image by calling bdrv_close(), and closing the tray does nothing.
      When the device model opens, then closes the tray, media is gone,
      unless the user actively inserts another one while the tray is open,
      with a suitable change command in the monitor.  This isn't how
      physical hardware behaves.  Rather inconvenient when programs
      "helpfully" eject media to give you a chance to change it.  The way
      bdrv_eject() behaves here turns that chance into a must, which is not
      what these programs or their users expect.
      
      Change the default action not to call bdrv_close().  Instead, note the
      tray status in new BlockDriverState member tray_open.  Use it in
      bdrv_is_inserted().
      
      Arguably, the device models should keep track of tray status
      themselves.  But this is less invasive.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      4be9762a
    • K
      block: Fix bdrv_has_zero_init · 336c1c12
      Kevin Wolf 提交于
      Assuming that any image on a block device is not properly zero-initialized is
      actually wrong: Only raw images have this problem. Any other image format
      shouldn't care about it, they initialize everything properly themselves.
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      336c1c12
    • Y
      bd0858bb
    • M
      loadvm: improve tests before bdrv_snapshot_goto() · f0aa7a8b
      Miguel Di Ciurcio Filho 提交于
      This patch improves the resilience of the load_vmstate() function, doing
      further and better ordered tests.
      
      In load_vmstate(), if there is any error on bdrv_snapshot_goto(), except if the
      error is on VM state device, load_vmstate() will return zero and the VM will be
      started with major corruption chances.
      
      The current process:
      - test if there is any writable device without snapshot support
          - if exists return -error
      - get the device that saves the VM state, possible return -error but unlikely
      because it was tested earlier
      - flush I/O
      - run bdrv_snapshot_goto() on devices
          - if fails, give an warning and goes to the next (not good!)
          - if fails on the VM state device, return zero (not good!)
      - check if the requested snapshot exists on the device that saves the VM state
      and the state is not zero
          - if fails return -error
      - open the file with the VM state
          - if fails return -error
      - load the VM state
          - if fails return -error
      - return zero
      
      New behavior:
      - get the device that saves the VM state
          - if fails return -error
      - check if the requested snapshot exists on the device that saves the VM state
      and the state is not zero
          - if fails return -error
      - test if there is any writable device without snapshot support
          - if exists return -error
      - test if the devices with snapshot support have the requested snapshot
          - if anyone fails, return -error
      - flush I/O
      - run snapshot_goto() on devices
          - if anyone fails, return -error
      - open the file with the VM state
          - if fails return -error
      - load the VM state
          - if fails return -error
      - return zero
      
      do_loadvm must not call vm_start if any error has occurred in load_vmstate.
      Signed-off-by: NMiguel Di Ciurcio Filho <miguel.filho@gmail.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      f0aa7a8b
    • K
      block: Change bdrv_commit to handle multiple sectors at once · 8a426614
      Kevin Wolf 提交于
      bdrv_commit copies the image to its backing file sector by sector, which
      is (surprise!) relatively slow. Let's take a larger buffer and handle more
      sectors at once if possible.
      
      With a 1G qcow2 file, this brought the time bdrv_commit takes down from
      5:06 min to 1:14 min for me.
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      8a426614