On Thu, Feb 26, 2015 at 6:20 PM, Michael S. Tsirkin <m...@redhat.com>
wrote:
On Thu, Feb 26, 2015 at 03:04:43PM +0800, Jason Wang wrote:
Instead of depending on a macro, switch to use a bus specific queue
limit.
Cc: Anthony Liguori <aligu...@amazon.com>
Cc: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Jason Wang <jasow...@redhat.com>
---
hw/virtio/virtio-pci.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index 7fa8141..23c4649 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -215,7 +215,7 @@ static void
virtio_pci_start_ioeventfd(VirtIOPCIProxy *proxy)
return;
}
- for (n = 0; n < VIRTIO_PCI_QUEUE_MAX; n++) {
+ for (n = 0; n < virtio_get_queue_max(vdev); n++) {
if (!virtio_queue_get_num(vdev, n)) {
continue;
}
This is done on guest IO, and I think after applying the
next patch which increases the number to >500 for pci, it's too much
work: VCPU is blocked meanwhile. Same applies to other places.
At minimum, we'll need a faster way to locate active VQs.
Maybe just replace the continue with break in above. Since it looks
like virtqueue index used by all virtio devices are contiguous?