1. 11 4月, 2016 2 次提交
    • G
      virtio-gpu: block live migration · fa49e465
      Gerd Hoffmann 提交于
      Feeling a bit nervous putting the full live migration support
      patch (https://patchwork.ozlabs.org/patch/606902/) in that
      late in the 2.6 devel cycle as it carries some non-trivial
      changes.  So disable migration in case virtio-gpu is present
      for now.
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      fa49e465
    • G
      ui/virtio-gpu: add and use qemu_create_displaysurface_pixman · ca58b45f
      Gerd Hoffmann 提交于
      Add a the new qemu_create_displaysurface_pixman function, to create
      a DisplaySurface backed by an existing pixman image.  In that case
      there is no need to create a new pixman image pointing to the same
      backing storage.  We can just use the existing image directly.
      
      This does not only simplify things a bit, but most importantly it
      gets the reference counting right, so the backing storage for the
      pixman image wouldn't be released underneath us.
      
      Use new function in virtio-gpu, where using it actually fixes
      use-after-free crashes.
      
      Cc: qemu-stable@nongnu.org
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      Message-id: 1459499240-742-1-git-send-email-kraxel@redhat.com
      ca58b45f
  2. 07 2月, 2016 1 次提交
    • P
      virtio: move allocation to virtqueue_pop/vring_pop · 51b19ebe
      Paolo Bonzini 提交于
      The return code of virtqueue_pop/vring_pop is unused except to check for
      errors or 0.  We can thus easily move allocation inside the functions
      and just return a pointer to the VirtQueueElement.
      
      The advantage is that we will be able to allocate only the space that
      is needed for the actual size of the s/g list instead of the full
      VIRTQUEUE_MAX_SIZE items.  Currently VirtQueueElement takes about 48K
      of memory, and this kind of allocation puts a lot of stress on malloc.
      By cutting the size by two or three orders of magnitude, malloc can
      use much more efficient algorithms.
      
      The patch is pretty large, but changes to each device are testable
      more or less independently.  Splitting it would mostly add churn.
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com>
      51b19ebe
  3. 03 2月, 2016 3 次提交
  4. 29 1月, 2016 1 次提交
  5. 17 12月, 2015 1 次提交
  6. 08 10月, 2015 4 次提交
  7. 27 7月, 2015 1 次提交
  8. 07 7月, 2015 1 次提交
  9. 12 6月, 2015 1 次提交
  10. 10 6月, 2015 1 次提交