On Fri, 6 Feb 2015 15:54:09 +0800 Jason Wang <jasow...@redhat.com> wrote:
> VIRTIO_PCI_QUEUE_MAX was not specific to pci, so rename it to > VIRTIO_QUEUE_MAX. > > Cc: Amit Shah <amit.s...@redhat.com> > Cc: Anthony Liguori <aligu...@amazon.com> > Cc: Michael S. Tsirkin <m...@redhat.com> > Cc: Alexander Graf <ag...@suse.de> > Cc: Richard Henderson <r...@twiddle.net> > Cc: Cornelia Huck <cornelia.h...@de.ibm.com> > Cc: Christian Borntraeger <borntrae...@de.ibm.com> > Cc: Paolo Bonzini <pbonz...@redhat.com> > Signed-off-by: Jason Wang <jasow...@redhat.com> > --- > hw/char/virtio-serial-bus.c | 2 +- > hw/s390x/s390-virtio-bus.c | 4 ++-- > hw/s390x/s390-virtio-ccw.c | 2 +- > hw/s390x/virtio-ccw.c | 10 +++++----- > hw/scsi/virtio-scsi.c | 4 ++-- > hw/virtio/virtio-mmio.c | 4 ++-- > hw/virtio/virtio-pci.c | 10 +++++----- > hw/virtio/virtio.c | 26 +++++++++++++------------- > include/hw/s390x/s390_flic.h | 2 +- > include/hw/virtio/virtio.h | 2 +- > 10 files changed, 33 insertions(+), 33 deletions(-) While I certainly agree with the patch on its own, I read through your complete patch series as well and I have some additional comments. Your patch series bumps up the maximum number of virtqueues for all transports, but I think we need to consider carefully what this means for each transport. For virtio-ccw, for example, we'll run into trouble when the guest uses classic queue indicators: These are limited to 64 per device (as I assumed 64 virtqueues per device initially and they fit quite nicely into a 64 bit integer). If the guest uses adapter interrupts with two-stage indicators, we should probably be fine. The guest will hopefully care about that, but we need to describe failure modes for this in the spec. For s390-virtio, I frankly have no idea what large numbers of queues will do :) Maybe we just run out of space for devices much earlier. You seem to need some changes for this to work for virtio-pci as well, don't you?
