Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu
切换分支/标签
  1. 19 1月, 2017 1 次提交
    • J
      vhost_net: device IOTLB support · c471ad0e
      由 Jason Wang 提交于 
      This patches implements Device IOTLB support for vhost kernel. This is
done through:

1) switch to use dma helpers when map/unmap vrings from vhost codes
2) introduce a set of VhostOps to:
   - setting up device IOTLB request callback
   - processing device IOTLB request
   - processing device IOTLB invalidation
2) kernel support for Device IOTLB API:

- allow vhost-net to query the IOMMU IOTLB entry through eventfd
- enable the ability for qemu to update a specified mapping of vhost
- through ioctl.
- enable the ability to invalidate a specified range of iova for the
  device IOTLB of vhost through ioctl. In x86/intel_iommu case this is
  triggered through iommu memory region notifier from device IOTLB
  invalidation descriptor processing routine.

With all the above, kernel vhost_net can co-operate with userspace
IOMMU. For vhost-user, the support could be easily done on top by
implementing the VhostOps.

Cc: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: NJason Wang <jasowang@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      c471ad0e
  3. 10 1月, 2017 5 次提交
  5. 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
  7. 18 11月, 2016 2 次提交
  9. 15 11月, 2016 6 次提交
  11. 02 11月, 2016 4 次提交
  13. 31 10月, 2016 11 次提交
  15. 10 10月, 2016 5 次提交
  17. 27 9月, 2016 1 次提交
    • M
      virtio-net: allow increasing rx queue size · 1c0fbfa3
      由 Michael S. Tsirkin 提交于 
      This allows increasing the rx queue size up to 1024: unlike with tx,
guests don't put in huge S/G lists into RX so the risk of running into
the max 1024 limitation due to some off-by-one seems small.

It's helpful for users like OVS-DPDK which don't do any buffering on the
host - 1K roughly matches 500 entries in tun + 256 in the current rx
queue, which seems to work reasonably well. We could probably make do
with ~750 entries but virtio spec limits us to powers of two.
It might be a good idea to specify an s/g size limit in a future
version.

It also might be possible to make the queue size smaller down the road, 64
seems like the minimal value which will still work (as guests seem to
assume a queue full of 1.5K buffers is enough to process the largest
incoming packet, which is ~64K).  No one actually asked for this, and
with virtio 1 guests can reduce ring size without need for host
configuration, so don't bother with this for now.

Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
Cc: Jason Wang <jasowang@redhat.com>
Suggested-by: NPatrik Hermansson <phermansson@gmail.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: NJason Wang <jasowang@redhat.com>
      1c0fbfa3
  19. 24 9月, 2016 1 次提交
  21. 15 9月, 2016 2 次提交
    • M
      virtio-bus: Plug devices after features are negotiated · d1b4259f
      由 Maxime Coquelin 提交于 
      Currently, devices are plugged before features are negotiated.
If the backend doesn't support VIRTIO_F_VERSION_1, the transport
needs to rewind some settings.

This is the case for CCW, for which a post_plugged callback had
been introduced, where max_rev field is just updated if
VIRTIO_F_VERSION_1 is not supported by the backend.
For PCI, implementing post_plugged would be much more
complicated, so it needs to know whether the backend supports
VIRTIO_F_VERSION_1 at plug time.

Currently, nothing is done for PCI. Modern capabilities get
exposed to the guest even if VIRTIO_F_VERSION_1 is not supported
by the backend, which confuses the guest.

This patch replaces existing post_plugged solution with an
approach that fits with both transports.
Features negotiation is performed before ->device_plugged() call.
A pre_plugged callback is introduced so that the transports can
set their supported features.

Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: qemu-stable@nongnu.org
Tested-by: Cornelia Huck <cornelia.huck@de.ibm.com> [ccw]
Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com>
Reviewed-by: NMarcel Apfelbaum <marcel@redhat.com>
Signed-off-by: NMaxime Coquelin <maxime.coquelin@redhat.com>
      d1b4259f
    • L
      Remove unused function declarations · d4b84d56
      由 Ladi Prosek 提交于 
      Unused function declarations were found using a simple gcc plugin and
manually verified by grepping the sources.
Signed-off-by: NLadi Prosek <lprosek@redhat.com>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>
      d4b84d56
  23. 10 9月, 2016 1 次提交