Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 12 5月, 2017 1 次提交
  3. 24 4月, 2017 2 次提交
  5. 10 2月, 2017 1 次提交
  7. 25 1月, 2017 2 次提交
  9. 11 1月, 2017 3 次提交
  11. 03 1月, 2017 2 次提交
  13. 20 12月, 2016 1 次提交
    • G
      virtio-gpu: track and limit host memory allocations · 9b7621bc
      由 Gerd Hoffmann 提交于 
      This patch makes virtio-gpu track host memory allocations for ressources
and applies a limit (configurable 256M by default).  When exceeding the
limit virtio-gpu throws VIRTIO_GPU_RESP_ERR_OUT_OF_MEMORY errors (like
it already does today when pixman image allocations fail).

This patch covers 2d mode only.  For 3d mode we have to figure how we
are going to handle this best.  qemu doesn't track resources in case
virglrenderer is used, so I guess we should extend virglrenderer to
allow setting a limit, then let qemu set the limit and catch
virgl_renderer_resource_create failures.

Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: 李强 <liqiang6-s@360.cn>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Message-id: 1480423356-22255-1-git-send-email-kraxel@redhat.com
      9b7621bc
  15. 05 12月, 2016 1 次提交
  17. 26 10月, 2016 1 次提交
  19. 10 10月, 2016 2 次提交
  21. 22 7月, 2016 2 次提交
  23. 12 7月, 2016 1 次提交
  25. 06 7月, 2016 1 次提交
  27. 06 6月, 2016 1 次提交
  29. 03 6月, 2016 1 次提交
    • G
      virtio-gpu: fix scanout rectangles · fa06e5cb
      由 Gerd Hoffmann 提交于 
      Commit "ca58b45f ui/virtio-gpu: add and use qemu_create_displaysurface_pixman"
breaks scanouts which use a region of the underlying resource only.

So, we need another way to handle the underlying issue.  Lets create a
new pixman image, grab a reference on the pixman providing the
underlying storage, hook up a destroy callback which releases the
reference.  That way regions work again and releasing the backing
storage should still be impossible thanks to the extra reference we are
holding.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 1464597655-26341-1-git-send-email-kraxel@redhat.com
      fa06e5cb
  31. 23 5月, 2016 5 次提交
  33. 19 5月, 2016 1 次提交
  35. 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
  37. 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
  39. 03 2月, 2016 3 次提交
  41. 29 1月, 2016 1 次提交
  43. 17 12月, 2015 1 次提交
  45. 08 10月, 2015 4 次提交