Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu
切换分支/标签
  1. 11 6月, 2015 19 次提交
  3. 10 6月, 2015 1 次提交
  5. 04 6月, 2015 3 次提交
  7. 01 6月, 2015 3 次提交
  9. 31 5月, 2015 7 次提交
  11. 30 4月, 2015 1 次提交
  13. 28 4月, 2015 4 次提交
    • S
      virtio-scsi: Move DEFINE_VIRTIO_SCSI_FEATURES to virtio-scsi · da2f84d1
      由 Shannon Zhao 提交于 
      So far virtio-scsi-device can't expose host features to guest while
using virtio-mmio because it doesn't set DEFINE_VIRTIO_SCSI_FEATURES on
backend or transport.

The host features belong to the backends while virtio-scsi-pci,
virtio-scsi-s390 and virtio-scsi-ccw set the DEFINE_VIRTIO_SCSI_FEATURES
on transports. But they already have the ability to forward property
accesses to the backend child. So if we move the host features to
backends, it doesn't break the backwards compatibility for them and
make host features work while using virtio-mmio.

Move DEFINE_VIRTIO_SCSI_FEATURES to the backend virtio-scsi. The
transports just sync the host features from backends.
Signed-off-by: NShannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: NShannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
      da2f84d1
    • S
      virtio-net: Move DEFINE_VIRTIO_NET_FEATURES to virtio-net · da3e8a23
      由 Shannon Zhao 提交于 
      So far virtio-net-device can't expose host features to guest while
using virtio-mmio because it doesn't set DEFINE_VIRTIO_NET_FEATURES on
backend or transport. So the performance is low.

The host features belong to the backend while virtio-net-pci,
virtio-net-s390 and virtio-net-ccw set the DEFINE_VIRTIO_NET_FEATURES
on transports. But they already have the ability to forward property
accesses to the backend child. So if we move the host features to
backends, it doesn't break the backwards compatibility for them and
make host features work while using virtio-mmio.

Here we move DEFINE_VIRTIO_NET_FEATURES to the backend virtio-net. The
transports just sync the host features from backend. Meanwhile move
virtio_net_set_config_size to virtio-net to make sure the config size
is correct and don't expose it.
Signed-off-by: NShannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: NShannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
      da3e8a23
    • J
      virtio-pci: speedup MSI-X masking and unmasking · 851c2a75
      由 Jason Wang 提交于 
      This patch tries to speed up the MSI-X masking and unmasking through
the mapping between vector and queues. With this patch it will there's
no need to go through all possible virtqueues, which may help to
reduce the time spent when doing MSI-X masking/unmasking a single
vector when more than hundreds or even thousands of virtqueues were
supported.

Tested with 80 queue pairs virito-net-pci by changing the smp affinity
in the background and doing netperf in the same time:

Before the patch:
5711.70 Gbits/sec
After the patch:
6830.98 Gbits/sec

About 19.6% improvements in throughput.

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>
      851c2a75
    • J
      virtio: introduce vector to virtqueues mapping · e0d686bf
      由 Jason Wang 提交于 
      Currently we will try to traverse all virtqueues to find a subset that
using a specific vector. This is sub optimal when we will support
hundreds or even thousands of virtqueues. So this patch introduces a
method which could be used by transport to get all virtqueues that
using a same vector. This is done through QLISTs and the number of
QLISTs was queried through a transport specific method. When guest
setting vectors, the virtqueue will be linked and helpers for traverse
the list was also introduced.

The first user will be virtio pci which will use this to speed up
MSI-X masking and unmasking handling.

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>
      e0d686bf
  15. 25 4月, 2015 1 次提交
    • L
      balloon: improve error msg when adding second device · 46abb812
      由 Luiz Capitulino 提交于 
      A VM supports only one balloon device, but due to several changes
in infrastructure the error message got messed up when trying
to add a second device. Fix it.

Before this fix

Command-line:

qemu-qmp: -device virtio-balloon-pci,id=balloon0: Another balloon device already registered
qemu-qmp: -device virtio-balloon-pci,id=balloon0: Adding balloon handler failed
qemu-qmp: -device virtio-balloon-pci,id=balloon0: Device 'virtio-balloon-pci' could not be initialized

HMP:

Another balloon device already registered
Adding balloon handler failed
Device 'virtio-balloon-pci' could not be initialized

QMP:

{ "execute": "device_add", "arguments": { "driver": "virtio-balloon-pci", "id": "balloon0" } }
{
	"error": {
		"class": "GenericError",
		"desc": "Adding balloon handler failed"
	}
}

After this fix

Command-line:

qemu-qmp: -device virtio-balloon-pci,id=balloon0: Only one balloon device is supported
qemu-qmp: -device virtio-balloon-pci,id=balloon0: Device 'virtio-balloon-pci' could not be initialized

HMP:

(qemu) device_add virtio-balloon-pci,id=balloon0
Only one balloon device is supported
Device 'virtio-balloon-pci' could not be initialized
(qemu)

QMP:

{ "execute": "device_add",
          "arguments": { "driver": "virtio-balloon-pci", "id": "balloon0" } }
{
    "error": {
        "class": "GenericError",
        "desc": "Only one balloon device is supported"
    }
}
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
      46abb812
  17. 20 4月, 2015 1 次提交