On Thu, Apr 23, 2015 at 02:21:33PM +0800, Jason Wang wrote: > We current limit the max virtio queues to 64. This is not sufficient > to support multiqueue devices (e.g recent Linux support up to 256 > tap queues). So this series tries to let virtio to support more > queues.
I put some of these in my tree. Pls check it out to make sure I didn't make mistakes, and send patches on top. > No much works need to be done except: > > - Introducing transport specific queue limitation. This is used to > simplify increasing the limitation for one transport without > harming the rest. > - Let each virtio transport to use specific limit. > - Speedup the MSI-X masking and unmasking through per vector queue > list, and increase the maximum MSI-X vectors supported by qemu. > - With the above enhancements, increase the maximum number of > virtqueues supported by PCI from 64 to 1024. > - Compat legacy virtio queue limit > > With this patch, we can support up to 256 queues. Since x86 can only > allow about 240 interrupt vectors for MSI-X, current Linux driver can > only have about 80 queue pairs has their private MSI-X interrupt > vectors. With sharing IRQ with queue pairs (RFC posted in > https://lkml.org/lkml/2014/12/25/169), Linux driver can have up > to about 186 queue pairs has their private MSI-X interrupt vectors. > > Stress/migration test on virtio-pci, compile test on other > targets. And make check on s390x-softmmu and ppc64-softmmu. > > Cc: Paolo Bonzini <pbonz...@redhat.com> > Cc: Richard Henderson <r...@twiddle.net> > Cc: Michael S. Tsirkin <m...@redhat.com> > Cc: Alexander Graf <ag...@suse.de> > Cc: Keith Busch <keith.bu...@intel.com> > Cc: Kevin Wolf <kw...@redhat.com> > Cc: Stefan Hajnoczi <stefa...@redhat.com> > Cc: Christian Borntraeger <borntrae...@de.ibm.com> > Cc: Cornelia Huck <cornelia.h...@de.ibm.com> > Cc: Amit Shah <amit.s...@redhat.com> > Cc: qemu-...@nongnu.org > > Please review > > Thanks > > Changes from V6: > - Tweak some commit logs > - Replace the missed VIRTIO_PCI_MAX in ccw with a bus specific limit > - Bump the pci queue limit from 513 to 1024 > > Changes from V5: > - Rebase to HEAD > - Drop the patch that introduce helper to get vq index since there has > already one > - Don't try to solve the migration compatibility issue for invalid > configuration like vectors > 128 with only 64 virto queues. This is > done by let msix calaucalte the correct bar size and drop the patch > 18 that intrdouces the auto_msix_bar_size. > - Cleanup the bar size and pba offset calcuation code > - Add a comment to explain the new virtio pci queue limit number 513 > > Changes from V4: > - Drop the patch of bus limitation validation and send it as an > independent patch > - Don't let the virtio-pci to calculate the MSI-X bar size, instead, > tell the msix code whether or not to use legacy bar size and let it > to do this > - Make sure the MSI-X bar size is at least 4K > - Subject typos fixes for patch 8 > - Mention adapter routes changes in the commit log of patch 9 > - Only use the vector to queue list for virtio-pci to avoid the > unnecessary possible overhead on other transport. > > Changes from V3: > - rebase to master and target to 2.4 > - handling compat issues for spapr > - fixes for hmp command completion when we have a nic with 256 queues > - using VIRTIO_NO_VECTOR instead of 0 for invalid virtqueue in > virtio-ccw > - fix compile issues for ppc64-softmmu > - don't export VIRTIO_CCW_QUEUE_MAX by introducing a gsi limit and > inherit in ccw > - use transport specific queue limit in virtio-serial > - correct the stale comment for AdapterRoutes and move it to ccw patch > - replace 128 with queue_max + 64 and add a comment for this in > virtio_ccw_notify() > > Changes from V2: > - move transport specific limitation to their implementation. (The > left is VIRTIO_CCW_QUEUE_MAX since I fail to find a common header > files other than virtio.h) > - use virtio_get_queue_ma) if possible in virtio.c > - AdapterRoutes should use ccw limit > - introduce a vector to queue mapping for virito devices and speedup > the MSI-X masking and unmasking through this. > > Changes from V1: > - add a validation against the bus limitation > - switch to use a bus specific queue limit instead of a global one, > this will allow us to just increase the limit of one transport > without disturbing others. > - only increase the queue limit of virtio-pci > - limit the maximum number of virtio queues to 64 for legacy machine > types > > Jason Wang (16): > virtio-net: fix the upper bound when trying to delete queues > pc: add 2.4 machine types > spapr: add machine type specific instance init function > ppc: spapr: add 2.4 machine type > monitor: replace the magic number 255 with MAX_QUEUE_NUM > monitor: check return value of qemu_find_net_clients_except() > virtio-ccw: using VIRTIO_NO_VECTOR instead of 0 for invalid virtqueue > virtio: introduce bus specific queue limit > virtio-ccw: introduce ccw specific queue limit > virtio-s390: switch to bus specific queue limit > virtio-mmio: switch to bus specific queue limit > virtio-pci: switch to use bus specific queue limit > virtio: introduce vector to virtqueues mapping > virtio-pci: speedup MSI-X masking and unmasking > virtio-pci: increase the maximum number of virtqueues to 513 > pci: remove hard-coded bar size in msix_init_exclusive_bar() > > hw/char/virtio-serial-bus.c | 2 +- > hw/i386/pc_piix.c | 34 ++++++++++++++++--- > hw/i386/pc_q35.c | 31 ++++++++++++++++-- > hw/net/virtio-net.c | 6 ++-- > hw/pci/msix.c | 30 ++++++++++------- > hw/ppc/spapr.c | 59 +++++++++++++++++++++++++++++++-- > hw/s390x/s390-virtio-bus.c | 7 ++-- > hw/s390x/s390-virtio-ccw.c | 7 ++-- > hw/s390x/virtio-ccw.c | 22 ++++++++----- > hw/scsi/virtio-scsi.c | 4 +-- > hw/virtio/virtio-mmio.c | 7 ++-- > hw/virtio/virtio-pci.c | 65 +++++++++++++++++++++++-------------- > hw/virtio/virtio.c | 74 > +++++++++++++++++++++++++++++++++--------- > include/hw/s390x/s390_flic.h | 4 ++- > include/hw/virtio/virtio-bus.h | 2 ++ > include/hw/virtio/virtio.h | 6 ++-- > monitor.c | 25 +++++++------- > 17 files changed, 291 insertions(+), 94 deletions(-) > > -- > 2.1.0
