qemu-devel
[Top][All Lists]
Advanced

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

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


From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH V5 16/18] virtio-pci: increase the maximum number of virtqueues to 513
Date: Wed, 8 Apr 2015 10:13:52 +0200



> 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


reply via email to

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