qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [Qemu-devel] [PATCH V5 16/18] virtio-pci: increase the ma


From: Jason Wang
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH V5 16/18] virtio-pci: increase the maximum number of virtqueues to 513
Date: Wed, 08 Apr 2015 16:30:06 +0800



On Wed, Apr 8, 2015 at 4:13 PM, Alexander Graf <address@hidden> wrote:



 Am 08.04.2015 um 10:10 schrieb Jason Wang <address@hidden>:
 On 04/08/2015 12:54 AM, Alexander Graf wrote:
 On 04/01/2015 10:15 AM, Jason Wang wrote:
This patch increases the maximum number of virtqueues for pci from 64 to 513. This will allow booting a virtio-net-pci device with 256 queue
 pairs.
To keep migration compatibility, 64 was kept for legacy machine types. This is because qemu in fact allows guest to probe the limit of
 virtqueues through trying to set queue_sel. So for legacy machine
 type, we should make sure setting queue_sel to more than 63 won't
 make effect.
Cc: Paolo Bonzini <address@hidden>
 Cc: Richard Henderson <address@hidden>
 Cc: Michael S. Tsirkin <address@hidden>
 Cc: Alexander Graf <address@hidden>
 Cc: address@hidden
 Signed-off-by: Jason Wang <address@hidden>
 ---
  hw/i386/pc_piix.c      | 5 +++++
  hw/i386/pc_q35.c       | 5 +++++
  hw/ppc/spapr.c         | 5 +++++
  hw/virtio/virtio-pci.c | 2 +-
  4 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
 index 212e263..6e098ce 100644
 --- a/hw/i386/pc_piix.c
 +++ b/hw/i386/pc_piix.c
 @@ -49,6 +49,7 @@
  #include "hw/acpi/acpi.h"
  #include "cpu.h"
  #include "qemu/error-report.h"
 +#include "hw/virtio/virtio-bus.h"
  #ifdef CONFIG_XEN
  #  include <xen/hvm/hvm_info_table.h>
  #endif
@@ -312,6 +313,10 @@ static void pc_init_pci(MachineState *machine)
    static void pc_compat_2_3(MachineState *machine)
  {
 +    ObjectClass *klass = object_class_by_name("virtio-pci-bus");
 +    VirtioBusClass *k = VIRTIO_BUS_CLASS(klass);
 +
 +    k->queue_max = 64;
  }
    static void pc_compat_2_2(MachineState *machine)
 diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
 index e67f2de..ff7c414 100644
 --- a/hw/i386/pc_q35.c
 +++ b/hw/i386/pc_q35.c
 @@ -45,6 +45,7 @@
  #include "hw/usb.h"
  #include "hw/cpu/icc_bus.h"
  #include "qemu/error-report.h"
 +#include "include/hw/virtio/virtio-bus.h"
    /* ICH9 AHCI has 6 ports */
  #define MAX_SATA_PORTS     6
@@ -291,6 +292,10 @@ static void pc_q35_init(MachineState *machine)
    static void pc_compat_2_3(MachineState *machine)
  {
 +    ObjectClass *klass = object_class_by_name("virtio-pci-bus");
 +    VirtioBusClass *k = VIRTIO_BUS_CLASS(klass);
 +
 +    k->queue_max = 64;
  }
    static void pc_compat_2_2(MachineState *machine)
 diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
 index 8e43aa2..ee8f6a3 100644
 --- a/hw/ppc/spapr.c
 +++ b/hw/ppc/spapr.c
 @@ -50,6 +50,7 @@
  #include "hw/pci/pci.h"
  #include "hw/scsi/scsi.h"
  #include "hw/virtio/virtio-scsi.h"
 +#include "hw/virtio/virtio-bus.h"
    #include "exec/address-spaces.h"
  #include "hw/usb.h"
@@ -1827,6 +1828,10 @@ static const TypeInfo spapr_machine_info = {
    static void spapr_compat_2_3(Object *obj)
  {
 +    ObjectClass *klass = object_class_by_name("virtio-pci-bus");
 +    VirtioBusClass *k = VIRTIO_BUS_CLASS(klass);
 +
 +    k->queue_max = 64;
  }
    static void spapr_compat_2_2(Object *obj)
 diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
 index 9a5242a..02e3ce8 100644
 --- a/hw/virtio/virtio-pci.c
 +++ b/hw/virtio/virtio-pci.c
 @@ -42,7 +42,7 @@
   * configuration space */
#define VIRTIO_PCI_CONFIG_SIZE(dev) VIRTIO_PCI_CONFIG_OFF(msix_enabled(dev))
  -#define VIRTIO_PCI_QUEUE_MAX 64
 +#define VIRTIO_PCI_QUEUE_MAX 513
513 is an interesting number. Any particular reason for it? Maybe this
 was mentioned before and I just missed it ;)
Alex
The number were chose to match kernel limit for tuntap queues. Recent kernel allow up to 256 queues for tuntap, so 513 is in fact 256 * 2 plus
 1 control vq.

I see. I'm not fully convinced that it's a good idea to bake that limit into qemu, but we have to have a limit somewhere.

However, could you please make it more obvious in the code where thid number stems from? Either by using defines or with a comment.


Alex

Will add a comment for this.

Thanks.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]